DDNS from DHCPv4 and DHCPv6
bind at nryc.fr
Fri Apr 4 16:07:46 UTC 2014
On 04/04/2014 14:49, Philipp Schulz wrote:
> I hope this wasn't allready discussed in the past.
> I am currently trying to setup a "dual Stack Network". Both of the two
> dhcpd instances are doing their job, updating the nameserver, but when i
> try using both of them at the same time some problems accure.
> Running named in foregroung tells me .
> client ::1# 52164: updating zone 'example.org/IN': update
> unsuccessful: tux.example.org/A: 'rrset does not exist' prerequisite not
> satisfied (YXRRSET)
> So i took a look at RFC 2136 which tells me , I can't add an additional
> RR because there is allready a RR for 'tux'.
> For this prerequisite, a requestor adds to the section a single RR
> whose NAME and TYPE are equal to that of the RRset whose nonexistence
> is required.
> My question is: can I somehow disable that behaviour?
> Sorry for the poor english ;)
This is a known behavior caused by different identifiers :
"client-identifier" in DHCPv4 and DUID in DHCPv6. DDNS doesn't work
because this identifiers are conflicting, even if they're coming from
the same host.
The answer is to use DHCPv4 clients that comply with RFC 4361, it is the
case of ISC-DHCP 4.3.x. In this case, v4 and v6 clients use the same
DUID as identifier and they can update the same FQDN independently.
Unfortunately, ISC-DHCP 4.3.x has been release recently and I don't
think Linux distros have updated their "isc-dhcp-client" package yet. As
far as I know, DHCPv4 clients in Windows OS aren't RFC 4361-compliants.
The other solution is to stop doing statefull DHCPv6 and going back to
EUI64 addresses. As such, you can script DDNS of EUI64 addresses, this
is what I have in production in my campus.
If you can read french, I wrote an article about it :
Feel free to ask me (or the isc-dhcp-users list) if you need help.
More information about the bind-users