ddns-dhcid is not synced to failover peer

[Thomas Markwalder]

Hello:

First, it is important to know that dhcpd does not synchronize DNS 
information between fail over peers.  Thus, if you see DDNS information 
on a lease in the lease file, it was that server that granted the lease 
and udpated DDNS.  Next, look at the CLTT times of the two entries. For 
dhcp00, it is 11:01:45 on December 12, 2017, while on dhcp01 it is 04:45 
on August 8, 2018.  Finally, the dhcp00 entry is TXT and dhcp01 is DHCID.

Based on that, I would say that the lease on dhcp00 was updated via 
failover update after being granted by dhcp01.  You would need to look 
at prior entries for this client the in the lease file to see whether it 
was expired and then reissued (most likely). Because the servers do not 
exchange DNS data, they have no way to know the DNS state of a lease 
granted by its peer.

In your case dhcp00 granted (owned) the lease originally and did an 
interim-mode update.  Most recently it was granted by dhcp01 which did a 
standard-mode update.

Regards,

Thomas Markwalder
ISC Software Engineering

On 08/14/2018 08:32 AM, W.J.M. Nelis wrote:
> Hi,
>
> we are for some time now moving from 'ddns-update-style interim' to 
> 'ddns-update-style standard'. In the mean time most of the TXT RR in 
> DNS have been replaced by DHCID RR. We are facing however a difference 
> in the leases files of the two fail-over members which we do not 
> understand.
>
> The lease-entry of IP phone it1001 at DHCP-server dhcp00 is:
>
> lease 137.17.159.230 {
>   starts 2 2018/08/14 04:55:14;
>   ends 2 2018/08/14 17:25:14;
>   tstp 6 2017/12/16 05:46:45;
>   tsfp 2 2018/08/14 23:40:14;
>   atsfp 2 2018/08/14 23:40:14;
>   cltt 5 2017/12/15 11:01:45;
>   binding state active;
>   next binding state expired;
>   hardware ethernet 64:16:7f:03:b2:08;
>   set ddns-rev-name = "230.159.17.137.in-addr.arpa.";
>   set ddns-txt = "0001e0b227339ca36be2eb578af5a9f3c8";
>   set ddns-fwd-name = "it1001.nlr.nl.";
>   set network-location = "nlrlnx113;ge-0/0/45;224";
>   set vendor-string = "Polycom-VVX601";
>   set nlr-site = "asd";
>   set vendor-class-identifier = "Polycom-VVX601";
>   option agent.circuit-id "ge-0/0/45.0:224";
>   option agent.remote-id "nlrlnx113";
>   client-hostname "Polycom_64167f03b208";
> }
>
> The corresponding entry in de leases-file of server dhcp01 is:
>
> lease 137.17.159.230 {
>   starts 2 2018/08/14 04:55:14;
>   ends 2 2018/08/14 17:25:14;
>   tstp 2 2018/08/14 23:40:14;
>   tsfp 2 2018/08/14 23:40:14;
>   atsfp 2 2018/08/14 23:40:14;
>   cltt 2 2018/08/14 04:55:14;
>   binding state active;
>   next binding state expired;
>   hardware ethernet 64:16:7f:03:b2:08;
>   set ddns-rev-name = "230.159.17.137.in-addr.arpa.";
>   set ddns-fwd-name = "it1001.nlr.nl.";
>   set vendor-class-identifier = "Polycom-VVX601";
>   set nlr-site = "asd";
>   set vendor-string = "Polycom-VVX601";
>   set network-location = "nlrlnx113;ge-0/0/45;224";
>   set ddns-dhcid = 
> "\000\000\001UjIl`j\016\213\333t\330\214\350\005\204Wu\001\333#\222\3622@\234t\321\372\343+z\031";
>   option agent.circuit-id "ge-0/0/45.0:224";
>   option agent.remote-id "nlrlnx113";
>   client-hostname "Polycom_64167f03b208";
> }
>
> The logfile at server dhcp00 does not contain any entries for this IP 
> phone. The log file at server dhcp01 contains the following lines:
>
> Aug 14 06:55:14 soda134u dhcpd: DHCPREQUEST for 137.17.159.230 from 
> 64:16:7f:03:b2:08 (Polycom_64167f03b208) via bond0
> Aug 14 06:55:14 soda134u dhcpd: DHCPACK on 137.17.159.230 to 
> 64:16:7f:03:b2:08 (Polycom_64167f03b208) via bond0
> Aug 14 06:55:14 soda134u dhcpd: Added new forward map from 
> it1001.nlr.nl. to 137.17.159.230
> Aug 14 06:55:14 soda134u dhcpd: Added reverse map from 
> 230.159.17.137.in-addr.arpa. to it1001.nlr.nl.
>
> We are using ISC DHCP Server 4.4.1 at both servers.
>
> Is this difference in some way 'normal'? Is it possibly a remnant of 
> the old days, as the IP phone might have not been requesting a new IP 
> address since the introduction of 'ddns-update-style standard'? And 
> most importantly: can this difference be undone, without the need to 
> force all devices with a long uptime to request a new IP address?
>
>   Wim Nelis.
>
>
>
> _______________________________________________
> 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/20180814/652a2f42/attachment.html>