| Subject: | Add "DDNS solo" option for operation of v4/v6 with prerequisites that ignore the other v6/v4 RRs |
Dual-stack DDNS environments are hard.
In theory, all clients are well-behaved and consistently supply the same DUID and the same hostname when requesting and releasing v4 and v6 leaases. In this environment, operating ISC DHCP servers for v4 and v6 in 'standard' mode should work delightfully well.
Except that clients are not well-behaved. They may use the same hostnames for v4 and v6 lease handling, but they often don't use the same client ID/DUID information for the TXT or DHCID RR that is deployed in the DNS to synchronise the DNS A and AAAA RRs with the client.
In that case, we suggested (in KB article https://kb.isc.org/article/AA-01091) that having e.g. the DHCPv4 server use 'interim' and the DHCPv6 use 'standard' would work, and both could happily cohabit with the other, because on is using TXT and the other DHCID for synchronization.
Except that - this doesn't work, because both servers are operating in the belief that they are coexisting with the other - and that therefore when managing 'A' records, they should also consider the existence of AAAA and vice versa.
Problems that arise:
a) The DHCPv4 server has added A and TXT RRs for 'test1.mydomain'. When the DHCPv6 server wants to add AAAA and DHCID for 'test1.mydomain', it checks first to see if the name 'test1.mydomain' is already in use without a DHCID RR. If that is the case, then it is not allowed to add it, because it assumes that it is a static name already in use.
b) We somehow have succeeded in adding both A and AAAA RRs for test1.mydomain, and now it is time to release the DHCPv4 lease. Because the AAAA RR exists, the DHCPv4 server only deletes the A RR, but leaves the TXT RR in place.
And possibly more of which we have not yet dreamed...
What would 'fix' this (or rather 'fudge' this ) to work better?
Could we have a different setting for the prerequisite behaviour, that says 'when operating as a DHCPv4 server, pay no attention to the existence (or not) of the AAAA RRs for the hostname.
This would do the same thing for a DHCPv6 server - pay no attention to the existence or not of the A RRs for the hostname.
=====
What could possibly go wrong?
1) Clients could chose the same hostname and we could end up with a cross-ways collision where one is allowed to use the A RR and the other is allowed to use the AAAA RR
2) v4 clients wouldn't check for the existence of the AAAA RR (without TXT/DHCID) so could potentially create a dynamic A RR alongside a static AAAA RR.
-- mitigation - if an AAAA RR exists without TXT or DHCID, then it should not be possible to add a dynamic A RR - and vice versa?
3) Is there any scenario here in which we might end up deleting a static A or AAAA RR due to a name collision?
-- mitigation - put the dynamic clients in a zone of their own - never ever mix static and dynamic clients?
And I'm sure there are more - but at the moment, this suggested mode of operation, just doesn't work as is. So we either have to create a fudge option that does make it work (mostly, with plenty of notes about where this still can go wrong),
OR - we have to put our feet down and say that if you want to run in a dual-stack environment, it's 'standard' for both (oh, and get your users to upgrade their clients, otherwise block them from the network), or nothing.
Cathy