A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
updated by
- rfc-5494 — IANA Allocation Guidelines for the Address Resolution Protocol (ARP)
Extracted elements (18)
A DHCPv4 updater uses type code 0x0002 if a Client Identifier option is present and encoded per RFC 4361 (DUID-based), 0x0001 if a Client Identifier option is present (non-DUID), and 0x0000 if no Client Identifier option is present. A DHCPv6 updater always uses 0x0002.
A distinct RR type (DHCID, type code 49) was defined rather than overloading an existing type to provide clarity: it is preferable for DHCP conflict-resolution information to use a distinct RR type recognizable by DNS software.
The hash input includes both the client identifier and the FQDN, so the DHCID RDATA varies if a single client is associated with more than one name over time, making it difficult to track a client across different domain name associations.
Both DHCP clients and servers SHOULD use some form of update authentication (e.g., TSIG per RFC 2845) when performing DNS updates. Administrators should be wary of permitting unsecured DNS updates to zones.
If an updater discovers DHCID RRs whose RDATA does not match the computed client identity, the updater SHOULD conclude that a different client is currently associated with the name and SHOULD proceed according to site administrative policy.
The DHCID RR MUST NOT be used for any purpose other than that detailed in RFC 4703 (FQDN conflict resolution). New data formats may only be defined through actions of the DHC Working Group via revision of RFC 4703.
When the updater uses the client's DUID (from DHCPv6 Client Identifier or RFC 4361-encoded DHCPv4 Client Identifier), the first two octets of the DHCID RR MUST be 0x0002 in network byte order, and the rest MUST contain the SHA-256 hash of the DUID followed by the FQDN.
When the updater uses the client's link-layer address (htype and chaddr), the first two octets of the DHCID RDATA MUST be zero, followed by digest type 1 (SHA-256) and the hash of htype || chaddr || FQDN.
When the updater uses the DHCPv4 Client Identifier option, the first two octets of the DHCID RR MUST be 0x0001 in network byte order, and the rest MUST contain SHA-256 of the option's Type and Client-Identifier fields followed by the FQDN.
The DHCID presentation format in DNS master files represents RDATA as a single block in base-64 encoding, which may be divided into white-space-separated substrings and can span lines using standard parentheses.
The DHCID RR is defined with mnemonic DHCID and type code 49, defined only in the IN class. It stores a DHCP client identity hash to unambiguously associate DNS domain names with DHCP clients, enabling conflict resolution in dynamic DNS updates.
Updaters compute a client identity hash from DHCP client request data and the desired FQDN, then compare it to existing DHCID RRs on that name. If RDATA does not match, the updater SHOULD conclude a different client is currently associated with the name.
IANA maintains a registry of 1-octet DHCID RR Digest Type Codes: value 0 is reserved, value 1 is SHA-256. New values require IETF Standards Action, and defining new values also requires documenting how DNS updaters handle multiple digest types.
IANA maintains a registry of 2-octet DHCID RR Identifier Type Codes: 0x0000 (htype+chaddr from DHCPv4 DHCPREQUEST), 0x0001 (DHCPv4 Client Identifier option data), 0x0002 (client DUID from DHCPv6 or RFC 4361-encoded DHCPv4), 0x0003-0xfffe (unassigned), 0xffff (reserved). New values require Standards Action.
An attacker with knowledge of commonly used MAC addresses in DHCP client identification data may be able to discover a client's DHCP identity via brute-force attack, as the number of unknown bits in the hash input is typically only 48 to 80.
The DHCID record uses a one-way SHA-256 hash to obscure client identity information. The FQDN is included in the hash computation to prevent tracking a client across multiple domain names by matching hash values.
The DHCID digest is computed as SHA-256(identifier || FQDN), where the FQDN is in canonical DNS wire format per RFC 4034 Section 6.2. The full RDATA is: identifier-type (2 octets) || digest-type (1 octet) || digest (32 octets for SHA-256).
The DHCID RDATA consists of a 2-octet identifier type code (network byte order), followed by a 1-octet digest type code, followed by n octets of digest. For SHA-256 (digest type 1), the digest is 32 octets, making the total RDATA 35 octets.