Skip Menu |
Report information
The Basics
Id: 42621
Status: resolved
Priority: 5/5
Queue: dhcp-public

Bug Information
Version Fixed: 4.4.0
Version Found: (no value)
Versions Affected: (no value)
Versions Planned: 4.4.0
Priority: P2 Normal
Severity: S2 Normal
CVSS Score: (no value)
CVE ID: (no value)
Component: DHCP Common
Area: feature

Dates
Created:Wed, 08 Jun 2016 13:46:04 -0400
Updated:Fri, 08 Dec 2017 13:09:26 -0500
Closed:Fri, 08 Dec 2017 13:09:26 -0500



This bug tracker is no longer active.

Please go to our Gitlab to submit issues (both feature requests and bug reports) for active projects maintained by Internet Systems Consortium (ISC).

Due to security and confidentiality requirements, full access is limited to the primary maintainers.

Subject: Dual stack environments with 'standard' and 'update-conflict-detection false' need also to apply this to name deletions
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"?