Subject: Dual stack environments with 'standard' and 'update-conflict-detection false' need also to apply this to name deletions MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Disposition: inline X-RT-Interface: Web Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: binary X-RT-Original-Encoding: utf-8 X-RT-Encrypt: 0 X-RT-Sign: 0 Content-Length: 2071 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. See https://bugs.isc.org/Ticket/Display.html?id=42620 for why this doesn't work as a workaround. So - back to the drawing board - let's have both DHCPv4 and DHCPv6 servers use standard, but use ''update-conflict-detection false" so that even though the clients might misbehave and use different values for Client ID/DUID, the DHCPv4 and DHCPv6 servers will just replace them when they don't match (and non-existence of the DHCID RR will prevent accidental updating of static hostnames). Except that... "update-conflict-detection false" was intended for resynchronizing scenarios when replacing dynamic hostnames - it doesn't deal with what happens when the lease is released. So - say we have the DHCID matching what the DHCPv6 server added for the AAAA RR. If the DHCPv4 server comes along to release the A RR, it won't do it... (whether or not the AAAA RR has already been deleted - and by the way, the DHCPv6 won't delete the DHCID RR in this case because it sees the A RR and expects that the DHCPv4 server is going to deal with that... For this to work therefore, we need to have "update-conflict-detection false" to also apply to name deletions. Or perhaps we need "delete-conflict-detection false"?