ISC DHCP Users

Re: DHCPd only updating the forward zone

Classic

List

Threaded

11 messages Options

Simon Hobson-2

Re: DHCPd only updating the forward zone

Dan Egli <[hidden email]> wrote:

> Here is the zone files. Note that the zone doesn't exist on the public internet.
...
Apart from ridiculously short timeout values, that looks mostly OK.

> After a machine called Venus boots, there's also a .jnl file for eglifamily.zone, but NOT for 10.168.192.arpa.zone

What do the logs for both DNS and DHCP show when this happens ?

> Here's dhcpd.conf:
> 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, 8.8.8.8;
> 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";
> }

Listing both your internal and an external DNS server is a bad idea - you'll have (seemingly) random DNS failures for your internal zones, and they may not start happening for some time after you've forgotten how you set things up. Many people setup this sort of thing thinking that clients will check with one, then the next. But some clients (at least some have in the past), if they experience a failure with the first server, will put it to the end of the list where it will stay until there's a failure with another server - and this will persist across reboots. The effect is that suddenly, for no apparent reason, all internal lookups fail. With a previous work hat on I've had colleagues bitten by this one.

You forgot to provide the output of :
dig eglifamily.name ns
dig 10.168.192.in-addr.arpa ns
but from the configs, I would expect both to show jupiter.eglifamily.name to be the name server for both.

BTW - you should not need "subnet 10.0.0.0 ..." or "interface enp0s8". That fact that they are there, presumably to get around your other problem, indicated that you are starting dhcpd with the wrong options. Normally you would simply list the interfaces you want the server to listen on on the command line - though it's usually abstracted into a config file to make life simple.

Simon

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Dan Egli

Re: [SP4M] Re: DHCPd only updating the forward zone

On 12/20/2020 9:46 AM, Simon Hobson wrote:
> Dan Egli <[hidden email]> wrote:
>
>> Here is the zone files. Note that the zone doesn't exist on the public internet.
> ...
> Apart from ridiculously short timeout values, that looks mostly OK.

Mostly OK? Besides the short timeouts, which are for testing and will be
increased to reasonable values once the whole system functions
correctly, and the combined internal/external name servers (which I
fixed) what's wrong?

>> After a machine called Venus boots, there's also a .jnl file for eglifamily.zone, but NOT for 10.168.192.arpa.zone
> What do the logs for both DNS and DHCP show when this happens ?
>
>
dhcpd.log:
Dec 20 20:55:57 pluto dhcpd[1129]: DHCPDISCOVER from 08:00:27:03:d3:23
via enp0s8
Dec 20 20:55:58 pluto dhcpd[1129]: DHCPOFFER on 192.168.10.128 to
08:00:27:03:d3:23 (venus) via enp0s8
Dec 20 20:55:58 pluto dhcpd[1129]: DHCPREQUEST for 192.168.10.128
(192.168.10.1) from 08:00:27:03:d3:23 (venus) via enp0s8
Dec 20 20:55:58 pluto dhcpd[1129]: DHCPACK on 192.168.10.128 to
08:00:27:03:d3:23 (venus) via enp0s8

No entries at all in named.log now that it's started not making dynamic
updates at all. The named.log shows startup messages, and nothing else.

As to the name server, it would be pluto actually, not jupiter. Here's
the digs:Here's your lookups:

  # dig ns eglifamily.name

; <<>> DiG 9.16.6 <<>> ns eglifamily.name
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31317
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 8ca383bc4b0726c1010000005fdfbba45cf747295c09d705 (good)
;; QUESTION SECTION:
;eglifamily.name.               IN      NS

;; ANSWER SECTION:
eglifamily.name.        21600   IN      NS pluto.eglifamily.name.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 20 14:01:24 MST 2020
;; MSG SIZE rcvd: 92

  # dig ns 10.168.192.in-addr.arpa

; <<>> DiG 9.16.6 <<>> ns 10.168.192.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64233
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 76d73c0142ca1363010000005fdfbbd64072f5769946d53c (good)
;; QUESTION SECTION:
;10.168.192.in-addr.arpa.       IN      NS

;; ANSWER SECTION:
10.168.192.in-addr.arpa. 600    IN      NS pluto.eglifamily.name.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Dec 20 14:02:14 MST 2020
;; MSG SIZE rcvd: 115

I don't know what's up, but there's no update of DNS at all right now.
I'm stumped. As far as I can tell, all is fine in the config. Maybe
someone can see something I missed. I hope so.

--

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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Simon Hobson

Re: [SP4M] DHCPd only updating the forward zone

Dan Egli <[hidden email]> wrote:

>> What do the logs for both DNS and DHCP show when this happens ?
>>
>>
> dhcpd.log:
> Dec 20 20:55:57 pluto dhcpd[1129]: DHCPDISCOVER from 08:00:27:03:d3:23 via enp0s8
> Dec 20 20:55:58 pluto dhcpd[1129]: DHCPOFFER on 192.168.10.128 to 08:00:27:03:d3:23 (venus) via enp0s8
> Dec 20 20:55:58 pluto dhcpd[1129]: DHCPREQUEST for 192.168.10.128 (192.168.10.1) from 08:00:27:03:d3:23 (venus) via enp0s8
> Dec 20 20:55:58 pluto dhcpd[1129]: DHCPACK on 192.168.10.128 to 08:00:27:03:d3:23 (venus) via enp0s8
>
> No entries at all in named.log now that it's started not making dynamic updates at all. The named.log shows startup messages, and nothing else.

That would be normal - once the DNS is updated, dhcpd won't send further updates until something changes - such as a lease timing out or being released. You could either release the lease from the client, let it expire, or shut down dhcpd and manually remove the DNS entries from the lease.

What we're looking for is to see if dhcpd tries to update and fails, or doesn't try at all.

> As to the name server, it would be pluto actually, not jupiter.

Oops, my mistake there.

> I don't know what's up, but there's no update of DNS at all right now. I'm stumped. As far as I can tell, all is fine in the config.

Yes, it all looks fine and should "just work automagically"

What should happen is dhcpd looks up the SOA record for the zone (sorry, I should have asked for that rather than NS records) to find the primary authoritative name server for the relevant zone - it will then send updates to that server. I can see from your previous message that pluto is given in both zones - so both updates should work. As far as I can see, everything is setup correctly for this to work.

There is an argument for using signed zone updates - but IMO that's not really necessary for a small home setup like this. There you define a key, add zone directives to the dhcp config, and reference the key (rather than an IP based ACL) in the allow updates directives in your dns setup.

Simon

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Dan Egli

Re: [SP4M] DHCPd only updating the forward zone

Actually, the issue at hand is that there is no trace of venus left at all. I killed dhcpd and named, then removed the journal files and ensured that venus wasn't listed in the main zone file (it wasn't). Then I removed the dhcpd.leases file and created a new one. After restarting bind and dhcpd I rebooted venus (which is only booting from a RO squashfs at the moment), and let it request an address. What you see below is what the logs show. DHCPd didn't even TRY to register it, even though as far as it's config files can tell this is a brand new registration.

I thought it should work too. So why is dhcpd not even trying to add the machine to the DNS?

On Mon, Dec 21, 2020 at 11:27:54AM +0000, Simon Hobson wrote:

> Dan Egli <[hidden email]> wrote:
>
> >> What do the logs for both DNS and DHCP show when this happens ?
> >>
> >>
> > dhcpd.log:
> > Dec 20 20:55:57 pluto dhcpd[1129]: DHCPDISCOVER from 08:00:27:03:d3:23 via enp0s8
> > Dec 20 20:55:58 pluto dhcpd[1129]: DHCPOFFER on 192.168.10.128 to 08:00:27:03:d3:23 (venus) via enp0s8
> > Dec 20 20:55:58 pluto dhcpd[1129]: DHCPREQUEST for 192.168.10.128 (192.168.10.1) from 08:00:27:03:d3:23 (venus) via enp0s8
> > Dec 20 20:55:58 pluto dhcpd[1129]: DHCPACK on 192.168.10.128 to 08:00:27:03:d3:23 (venus) via enp0s8
> >
> > No entries at all in named.log now that it's started not making dynamic updates at all. The named.log shows startup messages, and nothing else.
>
> That would be normal - once the DNS is updated, dhcpd won't send further updates until something changes - such as a lease timing out or being released. You could either release the lease from the client, let it expire, or shut down dhcpd and manually remove the DNS entries from the lease.
>
> What we're looking for is to see if dhcpd tries to update and fails, or doesn't try at all.
>
> > As to the name server, it would be pluto actually, not jupiter.
>
> Oops, my mistake there.
>
>
> > I don't know what's up, but there's no update of DNS at all right now. I'm stumped. As far as I can tell, all is fine in the config.
>
> Yes, it all looks fine and should "just work automagically"
>
>
> What should happen is dhcpd looks up the SOA record for the zone (sorry, I should have asked for that rather than NS records) to find the primary authoritative name server for the relevant zone - it will then send updates to that server. I can see from your previous message that pluto is given in both zones - so both updates should work. As far as I can see, everything is setup correctly for this to work.
>
> There is an argument for using signed zone updates - but IMO that's not really necessary for a small home setup like this. There you define a key, add zone directives to the dhcp config, and reference the key (rather than an IP based ACL) in the allow updates directives in your dns setup.

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Dan Egli

Re: [SP4M] DHCPd only updating the forward zone

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

Rick Dicaire

Re: [SP4M] DHCPd only updating the forward zone

Where's your dhcpd.conf declaration for 10.168.192.in-addr.arpa?

On Thu, Dec 24, 2020 at 5:23 PM Dan Egli <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Simon Hobson

Re: [SP4M] DHCPd only updating the forward zone

Rick Dicaire <[hidden email]> wrote:
>Where's your dhcpd.conf declaration for 10.168.192.in-addr.arpa?

It's not actually required IF the DNS is set up properly. dhcpd will look for the SOA record for the zone, and send updates to the primary server specified.

You do need zone declarations if either the DNS isn't setup to allow dhcpd to find the primary server or if you use signed updates.

Simon

_______________________________________________
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Rick Dicaire

Re: [SP4M] DHCPd only updating the forward zone

On Thu, Dec 24, 2020 at 6:12 PM Simon Hobson <[hidden email]> wrote:

It's not actually required IF the DNS is set up properly. dhcpd will look for the SOA record for the zone, and send updates to the primary server specified.

You do need zone declarations if either the DNS isn't setup to allow dhcpd to find the primary server or if you use signed updates.

I didn't know this. I have explicit declarations in my pool statement:

zone 17.168.192.in-addr.arpa {
primary dns1.ldev;
key gw-ddns;
}
zone dhcp.ldev {
primary dns1.ldev;
key gw-ddns;
}

and this seems to work.

Is this due to the use of TSIG keys (are these signed updates)?

Dan Egli

Re: [SP4M] DHCPd only updating the forward zone

As far as I'm aware everything is setup correctly. Pluto is the server listed in the SOA record. In fact, except for the domain itself, 10.168.192.in-addr.arpa and eglifamily.name have identical SOA records.

On Dec 24, 2020 4:19 PM, Rick Dicaire <[hidden email]> wrote:

On Thu, Dec 24, 2020 at 6:12 PM Simon Hobson <[hidden email]> wrote:
It's not actually required IF the DNS is set up properly. dhcpd will look for the SOA record for the zone, and send updates to the primary server specified.

You do need zone declarations if either the DNS isn't setup to allow dhcpd to find the primary server or if you use signed updates.

I didn't know this. I have explicit declarations in my pool statement:

zone 17.168.192.in-addr.arpa {
primary dns1.ldev;
key gw-ddns;
}
zone dhcp.ldev {
primary dns1.ldev;
key gw-ddns;
}

and this seems to work.
Is this due to the use of TSIG keys (are these signed updates)?

Rick Dicaire

Re: [SP4M] DHCPd only updating the forward zone

On Thu, Dec 24, 2020 at 10:31 PM <[hidden email]> wrote:

As far as I'm aware everything is setup correctly. Pluto is the server listed in the SOA record. In fact, except for the domain itself, 10.168.192.in-addr.arpa and eglifamily.name have identical SOA records.

Do you see anything in syslog from dhcpd or named?

Dan Egli

Re: [SP4M] DHCPd only updating the forward zone

On Thursday, December 24, 2020 09:20 PM MST, Rick Dicaire <[hidden email]> wrote:
>
> Do you see anything in syslog from dhcpd or named?

Nothing that makes any sense. I finally finished terra, so it's not using dhcpcd anymore, but systemd. Still, systemd is sending the hostname, as you can see from the log snip below:
==> /var/log/dhcpd.log <==
Dec 26 05:54:15 pluto dhcpd[952]: Copyright 2004-2020 Internet Systems Consortium.
Dec 26 05:54:15 pluto dhcpd[952]: All rights reserved.
Dec 26 05:54:15 pluto dhcpd[952]: For info, please visit https://www.isc.org/software/dhcp/
Dec 26 05:54:15 pluto dhcpd[952]: Wrote 0 deleted host decls to leases file.
Dec 26 05:54:15 pluto dhcpd[952]: Wrote 0 new dynamic host decls to leases file.
Dec 26 05:54:15 pluto dhcpd[952]: Wrote 0 leases to leases file.
Dec 26 05:54:15 pluto dhcpd[952]: Listening on LPF/enp0s8/08:00:27:0c:5c:4a/192.168.10.0/24
Dec 26 05:54:15 pluto dhcpd[952]: Sending on LPF/enp0s8/08:00:27:0c:5c:4a/192.168.10.0/24
Dec 26 05:54:15 pluto dhcpd[952]: Sending on Socket/fallback/fallback-net
Dec 26 05:54:15 pluto dhcpd[952]: Server starting service.
Dec 26 05:55:49 pluto dhcpd[952]: DHCPDISCOVER from 08:00:27:02:b2:6b (terra) via enp0s8
Dec 26 05:55:49 pluto dhcpd[952]: DHCPOFFER on 192.168.10.128 to 08:00:27:02:b2:6b (terra) via enp0s8
Dec 26 05:55:49 pluto dhcpd[952]: DHCPREQUEST for 192.168.10.128 (192.168.10.1) from 08:00:27:02:b2:6b (terra) via enp0s8
Dec 26 05:55:49 pluto dhcpd[952]: DHCPACK on 192.168.10.128 to 08:00:27:02:b2:6b (terra) via enp0s8
Dec 26 05:55:49 pluto dhcpd[952]: Added new forward map from terra.eglifamily.name to 192.168.10.128

So, dhcpd added a forward map, but no reverse map. Why? Here's the zone files:

eglifamily.zone file:
$TTL 21600 ; 6 hours
@ IN SOA pluto.eglifamily.name. dan.eglifamily.name. (
2 ; 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.
$ORIGIN 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 "3134bafe77ab7232c3190ea6548c12ad32"

And like I said before. I know the refresh and retry and what not are ridiculously low. Once I get this fixed I'll set them for real values. I also restarted named to ensure that it flushed the journal and wrote out the new zone info showing terra. Meanwhile, here's 10.168.192.arpa.zone:
$TTL 6h
@ IN SOA pluto.eglifamily.name. dan.eglifamily.nme. (
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.

So why is it not writing even the forward zone? Here's systemd's network file:
[Match]
Name=enp*

[Network]
DHCP=yes

[DHCPv4]
SendHostname=yes
UseDomain=yes

--
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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

Re: DHCPd only updating the forward zone

Re: DHCPd only updating the forward zone

Re: [*SP4M*] Re: DHCPd only updating the forward zone

Re: [*SP4M*] DHCPd only updating the forward zone

Re: [*SP4M*] DHCPd only updating the forward zone

Re: [*SP4M*] DHCPd only updating the forward zone

Re: [*SP4M*] DHCPd only updating the forward zone

Re: [*SP4M*] DHCPd only updating the forward zone

Re: [*SP4M*] DHCPd only updating the forward zone

Re: [*SP4M*] DHCPd only updating the forward zone

Re: [*SP4M*] DHCPd only updating the forward zone

Re: [*SP4M*] DHCPd only updating the forward zone

Re: [SP4M] Re: DHCPd only updating the forward zone

Re: [SP4M] DHCPd only updating the forward zone

Re: [SP4M] DHCPd only updating the forward zone

Re: [SP4M] DHCPd only updating the forward zone

Re: [SP4M] DHCPd only updating the forward zone

Re: [SP4M] DHCPd only updating the forward zone

Re: [SP4M] DHCPd only updating the forward zone

Re: [SP4M] DHCPd only updating the forward zone

Re: [SP4M] DHCPd only updating the forward zone

Re: [SP4M] DHCPd only updating the forward zone