The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option
Extracted elements (28)
Authority over PTR RRs always resides with the DHCP server that allocates the address, while authority over A RRs may be delegated to either the client or the server depending on site policy. This asymmetry drives the two primary models of operation.
The RCODE1 and RCODE2 fields are retained despite being deprecated because the option is already in wide use. They were originally defined to convey DNS update response codes but became inadequate after EDNS0 extended RCODE to 12 bits.
A substantial population of clients implemented an earlier draft permitting ASCII encoding (E=0). Servers SHOULD be aware of such clients and MAY return ASCII-encoded Domain Name fields to them; servers not prepared to do so MUST ignore Client FQDN options with E=0.
A client MUST set the O bit to 0. A server MUST set the O bit to 1 if the S bit in its reply does not match the S bit received from the client.
A client that desires to perform DNS updates to A RRs SHOULD NOT do so if the client's address is a private address (RFC 1918).
Clients that send the Client FQDN option in their messages MUST NOT also send the Host Name option. Clients that receive both options from a server SHOULD prefer the Client FQDN option data.
DHCP clients and servers supporting the Client FQDN option MUST implement DHCP option concatenation (RFC 3396), as the Client FQDN option is a concatenation-requiring option.
DHCP clients and servers that send the Client FQDN option MUST clear the MBZ bits and MUST ignore them on receipt.
DNS RR TTLs for DHCP-assigned addresses SHOULD NOT exceed 1/3 of the lease time but SHOULD NOT be less than 10 minutes. Administrators SHOULD be allowed to configure TTL values.
If a client releases its lease and is responsible for updating its A RR, the client SHOULD delete the A RR before sending DHCPRELEASE. If unable to renew, the client SHOULD attempt to delete the A RR before lease expiry.
If a client sends both the Client FQDN and Host Name options, the server SHOULD ignore the Host Name option. The server MUST use the same encoding format as the client and MUST set the E bit accordingly.
If a client sends the Client FQDN option in its DHCPDISCOVER message, it MUST send the option in subsequent DHCPREQUEST messages, though the contents MAY change.
If the N bit is 1 in the Flags field, the S bit MUST be 0.
The Domain Name field SHOULD appear in canonical DNS wire format (RFC 1035 Section 3.1). The client and server MUST NOT alter the Domain Name field contents unless the FQDN has actually changed, to allow detecting changes between message exchanges.
The E bit encoding SHOULD be DNS canonical wire format (E=1); this MUST be supported by servers. A server MUST use the same encoding format as used by the client, and a server that does not support deprecated ASCII encoding MUST ignore Client FQDN options with E=0.
The server MUST NOT initiate DNS updates when responding to DHCPDISCOVER messages from a client; DNS updates may only be performed in response to DHCPREQUEST.
The server SHOULD NOT perform any DNS updates if N=1 in the DHCPACK Flags field; however, the server SHOULD delete any RRs it previously added via DNS updates for the client.
When a client desires no server DNS updates (N=1), the N bit MUST be 1 and the S and O bits MUST be 0 in the Client FQDN option sent in DHCPREQUEST.
When a client desires the server to perform DNS updates (S=1), the S bit MUST be 1 and the O and N bits MUST be 0 in the Client FQDN option sent in DHCPREQUEST.
When a client desires to update A RRs itself, the S, O, and N bits in the Client FQDN option MUST all be 0 in the DHCPREQUEST. The client MAY originate the A RR update after receiving DHCPACK, unless the server has set S=1.
When a lease expires, the server SHOULD delete any PTR RR it added via DNS update. If the server also added an A RR on the client's behalf, the server SHOULD delete that A RR as well.
A fully qualified domain name is encoded with a terminating zero-length label; a partial name is encoded without the terminating zero-length label. A client MAY leave the Domain Name field empty to request the server to provide a name.
The RCODE1 and RCODE2 fields (each 1 octet) are deprecated. A client SHOULD set them to 0 and SHOULD ignore them on receipt. A server SHOULD set them to 255 when sending and MUST ignore them on receipt.
DHCP option 81 is assigned to the Client FQDN option. IANA is requested to reference RFC 4702 for option 81 in the DHCP option registry.
DHCP servers currently have limited ability to verify client identity due to the absence of entity authentication in DHCP itself. If DHCP Authentication (RFC 3118) becomes widely deployed, servers could develop greater confidence in client identities.
Unauthenticated DNS updates can lead to confusion through malicious attack or misconfiguration. Both DHCP clients and servers should use update request origin authentication (e.g., Secure DNS Dynamic Update, RFC 3007) when performing DNS updates.
The 1-octet Flags field contains four named bits: S (bit 0, server should update A RR), O (bit 1, server overrode client's S preference), N (bit 2, no server DNS updates), and E (bit 3, domain name encoding: 1=DNS wire format, 0=deprecated ASCII). Bits 4-7 are MBZ.
The Client FQDN option (code 81) has a minimum length of 3 octets and contains: a 1-octet Flags field, two 1-octet RCODE fields (RCODE1, RCODE2), and a variable-length Domain Name field.