Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients
Extracted elements (19)
The DHCID-based conflict detection algorithm only works when all updating entities cooperate; it is advisory only and is not a substitute for DNS security (e.g., TSIG/DNSSEC), nor is it replaced by DNS security.
The DHCID RR is used to associate client identification information with an FQDN so that cooperating DNS updaters can determine whether their client is currently associated with a particular FQDN. This allows multiple DHCP servers or clients to detect conflicts without requiring direct server-to-server communication.
There is no need to validate the DHCID RR for PTR updates because a DHCP server only assigns an address to a single client at a time, eliminating the ambiguity that exists for A/AAAA RRs.
A dual-stack client using older-style DHCPv4 client identifiers (not DUID-based) will only be able to have either its A or AAAA records in DNS under a single FQDN due to DHCID RR conflicts, unless both DHCPv4 and DHCPv6 use the same DUID.
If any status other than YXDOMAIN is returned from the initial DHCID RR request, the updater SHOULD NOT attempt an update.
If the DNS UPDATE response returns FORMERR, SERVFAIL, REFUSED, or NOTIMP, the updater MUST terminate its update attempt.
Implementers SHOULD limit the total number of DNS update attempts for a single transaction, as the update sequence described in Section 5.3 can result in loops.
Sites that wish to permit a single FQDN to contain both A and AAAA RRs MUST use DHCPv4 clients and servers that support DUID-based client identifiers so that the same DUID is used in computing the DHCID RR RDATA by both DHCPv4 and DHCPv6.
The updater should only remove the DHCID RR if there are no A or AAAA RRs remaining for the client; the second UPDATE request asserts no A RRs and no AAAA RRs as prerequisites before deleting all RRs for the FQDN.
When a lease expires or a client issues DHCPRELEASE/Release, the DHCP server SHOULD delete the PTR RR matching the DHCP binding and SHOULD assert in its UPDATE request that the PTR record's PTRDNAME matches the client's FQDN before deleting all RRs for the FQDN.
When removing DNS entries, the updater MUST NOT delete the FQDN if either the specific A/AAAA RR delete or the subsequent full FQDN delete UPDATE request fails, as the client may have moved and updated from another server.
When the UPDATE response returns NXRRSET (no matching DHCID RR), the updater SHOULD either choose another FQDN and restart the update process or terminate the update with a failure.
For PTR RR updates, the DHCP server submits a DNS UPDATE that deletes all PTR RRs for the client's assigned IP address and adds a PTR RR pointing to the client's FQDN. The server MAY also add a DHCID RR for the PTR entry.
The initial DNS UPDATE request for adding A/AAAA RRs includes as a prerequisite the assertion that the FQDN does not exist, and the update section adds the new FQDN, its IP address mapping (A and/or AAAA RRs), and the DHCID RR with the unique client identity.
When the FQDN is already in use, the DNS UPDATE request includes two prerequisites: (1) the FQDN exists, and (2) the FQDN has a DHCID RR whose contents match the client identity. The update section conditionally deletes existing A/AAAA RRs and adds new ones.
Both DHCP clients and servers SHOULD use some form of update request authentication (e.g., TSIG) when performing DNS updates, as administrators should be wary of permitting unsecured DNS updates to zones.
DHCP servers currently have difficulty establishing confidence in client identities because DHCP itself lacks entity authentication. The DHCID mechanism is advisory only and does not provide cryptographic binding between client identity and DNS records.
In DOCSIS cable modem environments or PPP-based network access, the infrastructure (CMTS or NAS) may provide additional assurance about client identity that allows the DHCP server to more confidently trust client identification when performing DNS updates.
Adding A/AAAA RRs proceeds through three states: (1) attempt initial update asserting FQDN does not exist; if YXDOMAIN, (2) attempt update asserting FQDN exists with matching DHCID RR; if NXRRSET, (3) choose another FQDN or terminate with failure.