Re: DHCPv6 DDNS registration with FQDN

On Thu, 2015-02-26 at 11:12 +0100, Alexander Groß wrote:
​The patch was applied successfully and I was able to build on Fedora 21
with these commands (if you have opinions about these, I'm happy to learn
more about your build system - I'm still a Linux noob):

$ ./ \
  --prefix=/usr        \
  --sysconfdir=/etc    \
  --localstatedir=/var \
$ make
$ make install

​The DHCP packets look good now and I got the occasional DDNS update to
happen successfully. I write "occassional", because there's a new
outstanding issue.

Excellent.  I'll merge the patch then.

Windows DHCP has the option to protect DNS entries with a DHCID RR
<> next to the
A/AAAA RR to prevents name squatting (examples
It's not really Windows-specific, but from my 30 minute research there
seems to be a problem with two dhclient instances (-4 and -6) requesting
IPv4 and IPv6 addresses in short succession.

For illustration, let's say IPv4 is the first DHCP server transaction to
finish. The DHCP server will request a DDNS update with a DHCID computed
based on the DHCPv4 request. The DHCID RR is placed next to the A RR in
DNS. The last string is the DHCID:

Yes, the interaction between DHCPv6 DUID and the IPv4 client ID is a bit
more complicated than just treating the two separately as used to be the
case.  I don't think we can ignore existing client IDs since that would
break stable IP addresses for many people, but we can start using the
DUID to create the v4 ClientID for new leases, I think.  That'll take a
bit more work though.

30,02/26/15,00:15:39,DNS Update
32,02/26/15,00:15:40,DNS Update

When the DHCPv6 transaction finishes a couple of milliseconds later, the
DHCPv6 server will request a DDNS update with a DHCID computed based on the
DHCPv6 request, which is different:

11022,02/26/15,00:15:41,DNS IPV6 Update
11024,02/26/15,00:15:41,DNS IPV6 Update

​The DNS server will check the second DHCID against the one it already
knows and reject the DDNS update (the log above says it was successful, but
Windows logs generally suck ;-)

It's easy to confirm that the DHCID RR is actually the culprit. Just delete
it from the DNS, re-request DHCPv6 and the AAAA RR shows up.

My dhclient man page has the following snippet:

-df duid-lease-file
              Path  to a secondary lease file.  If the primary lease file
doesn't contain a DUID this file will be searched.  The
              DUID read from the secondary will be written to the primary.
This option can be used to allow an IPv4 instance  of
              the  client  to  share a DUID with an IPv6 instance.  After
starting one of the instances the second can be started
              with this option pointing to the lease file of the first
instance.  There is no default.  If no file  is  specified
              no search is made for a DUID should one not be found in the
main lease file.

The DUID <> is a main
contributor to the DHCID. As both IPv4 and IPv6 addresses are requested
by/for the same interface it seems NM should make sure to use the same DUID
for its requests.

Yes, it should, according to .

I've filed to track
the issue.

Thanks for your help!

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]