[*SP4M*] DHCPd only updating the forward zone
Rick Dicaire
kritek at gmail.com
Thu Dec 24 22:58:12 UTC 2020
Where's your dhcpd.conf declaration for 10.168.192.in-addr.arpa?
On Thu, Dec 24, 2020 at 5:23 PM Dan Egli <dan at newideatest.site> wrote:
> Alright. I did a test, and it's still not even trying to create the
> reverse mapping. I don't know why. I created a machine called terra. It
> asked dhcpd for a least. It got a lease. But that least never made it to
> named's in-addr.arpa zone, even though named is running too. I'm at a loss
> as to what's up and why it won't try to create the reverse DNS pointer. the
> DNS. Here's the setup:
>
> terra: Booting from a Gentoo Minimal CD, running dhcpcd -h terra so that
> the hostname gets passed to dhcpd
>
> pluto: dhcpd running. Receives a lease request, offers a new least,
> receive the ack, writes the forward mapping, ends. Does not write the
> reverse mapping. Here's the log segment:
>
> Dec 24 15:02:22 pluto dhcpd[2439]: DHCPDISCOVER from 08:00:27:03:d3:23 via
> enp0s8
> Dec 24 15:02:23 pluto dhcpd[2439]: DHCPOFFER on 192.168.10.128 to
> 08:00:27:03:d3:23 (terra) via enp0s8
> Dec 24 15:02:23 pluto dhcpd[2439]: DHCPREQUEST for 192.168.10.128
> (192.168.10.1) from 08:00:27:03:d3:23 (terra) via enp0s8
> Dec 24 15:02:23 pluto dhcpd[2439]: DHCPACK on 192.168.10.128 to
> 08:00:27:03:d3:23 (terra) via enp0s8
> Dec 24 15:02:23 pluto dhcpd[2439]: Added new forward map from
> terra.eglifamily.name to 192.168.10.128
>
>
> As you can see, dig works for terra, not for it's IP:
>
> pluto /etc/systemd # dig a +short terra.eglifamily.name
> 192.168.10.128
> pluto /etc/systemd # dig a -x +short 192.168.10.128
> pluto /etc/systemd # dig ptr -x 192.168.10.128
> ; <<>> DiG 9.16.6 <<>> ptr -x 192.168.10.128
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14327
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ; COOKIE: 0de11839ad25b1b5010000005fe51320c8672852930cb66c (good)
> ;; QUESTION SECTION:
> ;128.10.168.192.in-addr.arpa. IN PTR
>
> ;; AUTHORITY SECTION:
> 10.168.192.in-addr.arpa. 60 IN SOA pluto.eglifamily.name.
> dan.eglifamily.name. 2 1800 300 86400 60
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Thu Dec 24 15:16:00 MST 2020
> ;; MSG SIZE rcvd: 145
>
> pluto /etc/systemd # dig +short ptr -x 192.168.10.128
> pluto /etc/systemd #
>
> So, pluto is obviously recognized as the SOA for 192.168.10.x, which is
> good. Why then is dhcpd only sending a forward mapping?
>
> FWIW, although they haven't changed, I'll repost the zone files and the
> config files.
>
> eglifamily.zone:
>
> $ORIGIN .
> $TTL 21600 ; 6 hours
> eglifamily.name IN SOA pluto.eglifamily.name. dan.eglifamily.name.
> (
> 4 ; serial
> 1800 ; refresh (30 minutes)
> 300 ; retry (5 minutes)
> 86400 ; expire (1 day)
> 60 ; minimum (1 minute)
> )
> NS pluto.eglifamily.name.
> MX 1 jupiter.eglifamily.name.
> charon A 192.158.10.1
> jupiter A 192.168.10.3
> pluto A 192.168.10.2
> $TTL 1800 ; 30 minutes
> terra A 192.168.10.128
> TXT "311fd3292f4dc507ed06f247665a4ac9ab"
>
> That's after terra gets registered, obviously. But at the same time,
> here's the reverse zone.
>
> 10.168.192.arpa.zone:
> $TTL 10m
> @ IN SOA pluto.eglifamily.name. dan.eglifamily.name. (
> 2 ; serial
> 30m ; refresh
> 5m ; retry
> 1d ; expire
> 1m ; negative response cache
> )
> NS pluto.eglifamily.name.
> 1 PTR charon.eglifamily.name.
> 2 PTR pluto.eglifamily.name.
> 3 PTR jupiter.eglifamily.name.
>
> Notice no PTR to terra. As to config files, here's dhcpd:
>
> default-lease-time 3600;
> max-lease-time 43200;
>
> ddns-update-style interim;
>
> authoritative;
> log-facility local1;
>
>
> allow booting;
>
> subnet 10.0.0.0 netmask 255.0.0.0 {
> # no services at all! That's the llnk from the ISP. Don't touch it!
> }
>
>
> subnet 192.168.10.0 netmask 255.255.255.0 {
> interface enp0s8;
> range 192.168.10.128 192.168.10.254;
> if exists user-class and option user-class = "iPXE" {
> filename "pxelinux.efi";
> } else {
> filename "pxelinux.0";
> }
> next-server 192.168.10.3;
> option domain-name-servers 192.168.10.2;
> option domain-name "eglifamily.name";
> option routers 192.168.10.1;
>
> }
>
> host fixed-1 {
> hardware ethernet 08:00:27:D5:AA:3C;
> fixed-address 192.168.10.64;
> option host-name "fixed-1";
> ddns-hostname "fixed-1.eglifamily.name";
> }
>
>
> And here's named.conf:
>
>
> On 12/22/2020 7:48 AM, /etc/bind/named.conf
> acl "xfer" {
> none;
> };
> acl "trusted" {
> 10.0.2.15/32;
> 192.168.10.0/24;
> 127.0.0.0/8;
> ::1/128;
> # eventualy add valid IPv6 addresses here.
> };
>
> acl "myself" {
> 127.0.0.0/24;
> ::1/128;
> 192.168.10.2/32;
> 10.0.2.15/32;
> };
>
> options {
> directory "/var/bind";
> pid-file "/run/named/named.pid";
> tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab";
> minimal-responses yes;
>
>
> listen-on-v6 { none; }; // for now
> listen-on { 192.168.10.2; 127.0.0.1; };
>
> allow-query {
> trusted;
> };
>
> allow-query-cache {
> trusted;
> };
>
> allow-recursion {
> trusted;
> };
>
> allow-transfer {
> none;
> };
>
> allow-update {
> myself;
> };
>
> dnssec-validation auto;
> };
>
>
> logging {
> channel default_log {
> file "/var/log/named/named.log" versions 5 size 50M;
> print-time yes;
> print-severity yes;
> print-category yes;
> };
>
> category default { default_log; };
> category general { default_log; };
> };
>
>
> include "/etc/bind/rndc.key";
> controls {
> inet 127.0.0.1 port 953 allow { 127.0.0.1/32; ::1/128; } keys {
> "rndc-key"; };
> };
>
> zone "localhost" IN {
> type master;
> file "pri/localhost.zone";
> notify no;
> };
>
> zone "eglifamily.name" {
> type master;
> file "pri/eglifamily.zone";
> notify yes;
> };
>
>
> zone "10.168.192.in-addr.arpa" {
> type master;
> file "pri/10.168.192.arpa.zone";
> notify yes;
> };
>
> include "/var/lib/samba/bind-dns/named.conf";
>
> So, what is wrong?
>
>
> --
>
> Dan Egli
> From my Test Server
>
> _______________________________________________
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20201224/07691d4b/attachment-0001.htm>
More information about the dhcp-users
mailing list