DDNS update not sent on initial DHCP offer/request/ack

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

DDNS update not sent on initial DHCP offer/request/ack

Forman, Jeffrey
I've got a fairly standard setup here, ISC dhcpd handing out IPv4 address, updating a DNS zone handled by BIND with those hostnames. Though it seems lately (perhaps it's always been this case?) that the first time a new host comes up and requests an IP from the dhcp server, BIND is not notified of the new hostname and IP address. I have to reboot the client and then, on the subsequent request/ack cycle, is DNS updated. So my question is, why do I have to reboot the clients to get dhcpd to update bind? Is something misconfigured in my DHCPD to not do the intial update, or is it something client-side that is needed?

Infrastructure:
  • dhcp server os: OpenBSD 6.0 on amd64 ($OPENBSD in the below logs)
  • dhcpd version: isc dhcpd 4.3.4
  • bind version: isc bind 9.10-4p2
  • client OS: CoreOS (though I also run ubuntu and OSX locally as well) ($COREOSCLIENT in the below logs)
From the DHCPD logs, the initial request:

Dec  7 06:25:49 $OPENBSD dhcpd: DHCPOFFER on 10.10.2.245 to 52:54:00:18:f7:fb via vlan12

Dec  7 06:25:49 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1) from 52:54:00:18:f7:fb via vlan12

Dec  7 06:25:49 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to 52:54:00:18:f7:fb via vlan12

I reboot the client, and then:

Dec  7 06:27:59 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1) from 52:54:00:18:f7:fb via vlan12

Dec  7 06:27:59 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to 52:54:00:18:f7:fb (coreE3) via vlan12

07-Dec-2016 06:27:59.177 update-security: info: client 10.10.2.1#28804/key $TSIG-KEY: signer "$TSIG-KEY" approved

07-Dec-2016 06:27:59.177 update: info: client 10.10.2.1#28804/key $TSIG-KEY: updating zone 'dns.zone.net/IN': adding an RR at '$COREOSCLIENT' A 10.10.2.245

07-Dec-2016 06:27:59.177 update: info: client 10.10.2.1#28804/key $TSIG-KEY: updating zone 'dns.zone.net/IN': adding an RR at '$COREOSCLIENT' TXT "31b0331ba3cfc488d24fbfc87f9e127924"

Dec  7 06:27:59 $OPENBSD dhcpd: Added new forward map from $COREOSCLIENT to 10.10.2.245

07-Dec-2016 06:27:59.182 update-security: info: client 10.10.2.1#28804/key $TSIG-KEY: signer "$TSIG-KEY" approved

07-Dec-2016 06:27:59.182 update: info: client 10.10.2.1#28804/key $TSIG-KEY: updating zone '2.10.10.in-addr.arpa/IN': deleting rrset at '245.2.10.10.in-addr.arpa' PTR

07-Dec-2016 06:27:59.182 update: info: client 10.10.2.1#28804/key $TSIG-KEY: updating zone '2.10.10.in-addr.arpa/IN': adding an RR at '245.2.10.10.in-addr.arpa' PTR $COREOSCLIENT.

relevant dhcpd config:

ddns-updates on;
ddns-update-style interim;
update-optimization off;

subnet 10.10.2.0 netmask 255.255.255.0 {
   range 10.10.2.200 10.10.2.250;
   option routers 10.10.2.1;
   option domain-name-servers 10.10.2.1;


   zone dns.zone.net {
       primary 10.10.2.1;
       key "$TSIG-KEY";
   }

   zone 2.10.10.in-addr.arpa {
       primary 10.10.2.1;
       key "$TSIG-KEY";
   }
}


What am I missing here? Why does it require a restart of the client to get the dns entry added?

Thanks,
Jeff


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DDNS update not sent on initial DHCP offer/request/ack

/dev/rob0
On Wed, Dec 07, 2016 at 10:33:02AM -0500, Forman, Jeffrey wrote:

> I've got a fairly standard setup here, ISC dhcpd handing out IPv4
> address, updating a DNS zone handled by BIND with those hostnames.
> Though it seems lately (perhaps it's always been this case?) that
> the first time a new host comes up and requests an IP from the dhcp
> server, BIND is not notified of the new hostname and IP address. I
> have to reboot the client and then, on the subsequent request/ack
> cycle, is DNS updated. So my question is, why do I have to reboot
> the clients to get dhcpd to update bind? Is something misconfigured
> in my DHCPD to not do the intial update, or is it something
> client-side that is needed?

What you showed us suggests it's a client issue.

> Infrastructure:
>
>    - dhcp server os: OpenBSD 6.0 on amd64 ($OPENBSD in the below logs)
>    - dhcpd version: isc dhcpd 4.3.4
>    - bind version: isc bind 9.10-4p2
>    - client OS: CoreOS (though I also run ubuntu and OSX locally as well)
>    ($COREOSCLIENT in the below logs)
>
> From the DHCPD logs, the initial request:
>
> Dec  7 06:25:49 $OPENBSD dhcpd: DHCPOFFER on 10.10.2.245 to
> 52:54:00:18:f7:fb via vlan12
>
> Dec  7 06:25:49 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1)
> from 52:54:00:18:f7:fb via vlan12
>
> Dec  7 06:25:49 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to 52:54:00:18:f7:fb
> via vlan12

I don't see in that where any hostname was provided.

> I reboot the client, and then:
>
> Dec  7 06:27:59 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1)
> from 52:54:00:18:f7:fb via vlan12
>
> Dec  7 06:27:59 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to 52:54:00:18:f7:fb
> (coreE3) via vlan12

Here "coreE3" is the hostname ... was this a munging failure meant to
be "$COREOSCLIENT"?

> 07-Dec-2016 06:27:59.177 update-security: info: client 10.10.2.1#28804/key
> $TSIG-KEY: signer "$TSIG-KEY" approved
>
> 07-Dec-2016 06:27:59.177 update: info: client 10.10.2.1#28804/key
> $TSIG-KEY: updating zone 'dns.zone.net/IN': adding an RR at '$COREOSCLIENT'
> A 10.10.2.245

"Zone.net" is not a good choice for a home zone name.  If you're
simply hiding the real name behind "zone.net", use "example.net"
which has been set aside for such use.

[snip]
> What am I missing here? Why does it require a restart of the client
> to get the dns entry added?

Apparently it did not provide a hostname to add to DNS.
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DDNS update not sent on initial DHCP offer/request/ack

Rick Dicaire
Jeff, I have the following in global options:

ddns-hostname = pick (option fqdn.hostname, option host-name, concat ("ddns-", binary-to-ascii (10, 8, "-", leased-address)));
option host-name = config-option server.ddns-hostname;

If the client doesnt send a hostname, one is created in the form of ddns-192-168-17-34, then the forward and reverse zones are updated accordingly.
If the client sends a hostname, then the zones are updated accordingly.

hope that helps.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DDNS update not sent on initial DHCP offer/request/ack

Simon Hobson
Is this an issue with all clients, or just a subset ?
Is it consistent, or does it vary ?

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DDNS update not sent on initial DHCP offer/request/ack

Forman, Jeffrey
In reply to this post by /dev/rob0


On Wed, Dec 7, 2016 at 11:11 AM, /dev/rob0 <[hidden email]> wrote:
On Wed, Dec 07, 2016 at 10:33:02AM -0500, Forman, Jeffrey wrote:
> I've got a fairly standard setup here, ISC dhcpd handing out IPv4
> address, updating a DNS zone handled by BIND with those hostnames.
> Though it seems lately (perhaps it's always been this case?) that
> the first time a new host comes up and requests an IP from the dhcp
> server, BIND is not notified of the new hostname and IP address. I
> have to reboot the client and then, on the subsequent request/ack
> cycle, is DNS updated. So my question is, why do I have to reboot
> the clients to get dhcpd to update bind? Is something misconfigured
> in my DHCPD to not do the intial update, or is it something
> client-side that is needed?

What you showed us suggests it's a client issue.

> Infrastructure:
>
>    - dhcp server os: OpenBSD 6.0 on amd64 ($OPENBSD in the below logs)
>    - dhcpd version: isc dhcpd 4.3.4
>    - bind version: isc bind 9.10-4p2
>    - client OS: CoreOS (though I also run ubuntu and OSX locally as well)
>    ($COREOSCLIENT in the below logs)
>
> From the DHCPD logs, the initial request:
>
> Dec  7 06:25:49 $OPENBSD dhcpd: DHCPOFFER on 10.10.2.245 to
> 52:54:00:18:f7:fb via vlan12
>
> Dec  7 06:25:49 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1)
> from 52:54:00:18:f7:fb via vlan12
>
> Dec  7 06:25:49 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to 52:54:00:18:f7:fb
> via vlan12

I don't see in that where any hostname was provided.

> I reboot the client, and then:
>
> Dec  7 06:27:59 $OPENBSD dhcpd: DHCPREQUEST for 10.10.2.245 (10.10.2.1)
> from 52:54:00:18:f7:fb via vlan12
>
> Dec  7 06:27:59 $OPENBSD dhcpd: DHCPACK on 10.10.2.245 to 52:54:00:18:f7:fb
> (coreE3) via vlan12

Here "coreE3" is the hostname ... was this a munging failure meant to
be "$COREOSCLIENT"?

yes 

> 07-Dec-2016 06:27:59.177 update-security: info: client 10.10.2.1#28804/key
> $TSIG-KEY: signer "$TSIG-KEY" approved
>
> 07-Dec-2016 06:27:59.177 update: info: client 10.10.2.1#28804/key
> $TSIG-KEY: updating zone 'dns.zone.net/IN': adding an RR at '$COREOSCLIENT'
> A 10.10.2.245

"Zone.net" is not a good choice for a home zone name.  If you're
simply hiding the real name behind "zone.net", use "example.net"
which has been set aside for such use.

Nod. I can do so in later examples if necessary.
 

[snip]
> What am I missing here? Why does it require a restart of the client
> to get the dns entry added?

Apparently it did not provide a hostname to add to DNS.

Huh. Apparently even if the host knows its hostname upon install. :/ 
--
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DDNS update not sent on initial DHCP offer/request/ack

Forman, Jeffrey
In reply to this post by Rick Dicaire


On Wed, Dec 7, 2016 at 11:26 AM, Rick Dicaire <[hidden email]> wrote:
Jeff, I have the following in global options:

ddns-hostname = pick (option fqdn.hostname, option host-name, concat ("ddns-", binary-to-ascii (10, 8, "-", leased-address)));
option host-name = config-option server.ddns-hostname;

If the client doesnt send a hostname, one is created in the form of ddns-192-168-17-34, then the forward and reverse zones are updated accordingly.
If the client sends a hostname, then the zones are updated accordingly.

I'd thought about doing something like this, but wasn't sure of the incantation of how to do so.

Thanks,


hope that helps.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|

Re: DDNS update not sent on initial DHCP offer/request/ack

Forman, Jeffrey
In reply to this post by Simon Hobson


On Wed, Dec 7, 2016 at 11:31 AM, Simon Hobson <[hidden email]> wrote:
Is this an issue with all clients, or just a subset ?

I just tried it with a fresh install of Ubuntu, on another internal subnet range (10.10.0.0/24), and it seems like slightly improved behavior is exhibited.

First DHCP request (during the install):

Dec  7 20:16:18 $OPENBSDHOST dhcpd: DHCPDISCOVER from 52:54:00:28:49:b9 via em1

Dec  7 20:16:19 $OPENBSDHOST dhcpd: DHCPOFFER on 10.10.0.214 to 52:54:00:28:49:b9 via em1

Dec  7 20:16:19 $OPENBSDHOST dhcpd: DHCPREQUEST for 10.10.0.214 (10.10.0.1) from 52:54:00:28:49:b9 via em1

Dec  7 20:16:19 $OPENBSDHOST dhcpd: DHCPACK on 10.10.0.214 to 52:54:00:28:49:b9 via em1

 
First reboot post-install:
Dec  7 20:46:43 $OPENBSDHOST dhcpd: DHCPDISCOVER from 52:54:00:28:49:b9 via em1
Dec  7 20:46:44 $OPENBSDHOST dhcpd: DHCPOFFER on 10.10.0.214 to 52:54:00:28:49:b9 via em1
Dec  7 20:46:44 $OPENBSDHOST dhcpd: DHCPREQUEST for 10.10.0.214 (10.10.0.1) from 52:54:00:28:49:b9 via em1
Dec  7 20:46:44 $OPENBSDHOST dhcpd: DHCPACK on 10.10.0.214 to 52:54:00:28:49:b9 (dnstest2) via em1
Dec  7 20:46:44 $OPENBSDHOST dhcpd: Added new forward map from dnstest2.example.net to 10.10.0.214
Dec  7 20:46:44 $OPENBSDHOST dhcpd: Added reverse map from 214.0.10.10.in-addr.arpa. to dnstest2.example.net

Is it consistent, or does it vary ?

So it does seem to vary OS to OS. CoreOS required a subsequent reboot, while Ubuntu did the right thing (sent its hostname) upon the first post-install boot.

Sounds like I'm off to look for a potential bug to file regarding sending the hostname as part of the DHCP request for CoreOS. 

Thanks all,


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users