DDNS from DHCPv4 and DHCPv6

[Nicolas C.]

On 04/04/2014 14:49, Philipp Schulz wrote:
> Hello,
> 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'.
> Quote:....
>
>   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 ;)

Hello Philipp,

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 :

https://conf-ng.jres.org/2013/document_revision_1437.html?download

Feel free to ask me (or the isc-dhcp-users list) if you need help.

Cheers,

Nicolas