The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option
Extracted elements (26)
A fully qualified domain name is encoded with a terminating zero-length label; a partial name is encoded without the terminating zero-length label, signaling that the client knows only part of its name and not the zone. An empty Domain Name field requests the server to provide a name.
Authority over PTR RRs for an address logically belongs to the DHCPv6 server that allocates the address, since PTR records are tied to the assigned address space. Authority over AAAA RRs may rest with either the client (if it controls its FQDN) or the server (to prevent clients from associating addresses with arbitrary domain names).
The two primary supported models are: (1) client updates AAAA RRs, server updates PTR RRs; (2) server updates both AAAA and PTR RRs. Other permutations are not practically meaningful because of DNS authority considerations. A third case where the server performs no updates is supported but presumed rare.
Servers SHOULD send the complete fully qualified domain name in Client FQDN options. If a server modifies or substitutes the domain name, the domain name returned to the client may differ between two DHCPv6 exchanges (e.g., after conflict resolution), requiring clients to handle name changes gracefully.
A client MUST only include the Client FQDN option in SOLICIT, REQUEST, RENEW, or REBIND messages. A client that sends the Client FQDN option MUST also include the option in the Option Request option if it expects the server to include the Client FQDN option in responses.
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 SHOULD NOT perform DNS updates to AAAA RRs for its non-Global Unicast addresses or temporary addresses.
If a client is responsible for updating its AAAA RR and releases an address, it SHOULD delete the AAAA RR before sending a RELEASE message. If unable to renew lifetimes, the client SHOULD attempt to delete the AAAA RR before the lifetime expires.
If the N bit is 1, the S bit MUST be 0. DHCPv6 clients and servers MUST clear the MBZ bits in the Flags field and MUST ignore those bits.
Servers MUST only include a Client FQDN option in ADVERTISE and REPLY messages if the client included a Client FQDN option and it is requested by the Option Request option in the client's message.
The Client FQDN option MUST only appear in a message's options field and applies to all addresses for all IA_NA bindings in the transaction.
The data in the Domain Name field MUST be encoded as described in Section 8 of RFC 3315 (DHCPv6). The client and server MUST NOT alter the Domain Name field contents unless the FQDN has actually changed.
The server MUST NOT initiate DNS updates when responding with an ADVERTISE message to the client.
The server SHOULD NOT perform any DNS updates if the N bit is 1 in the Flags field of the Client FQDN option in REPLY messages. However, the server SHOULD delete any RRs that it previously added via DNS updates for the client.
The TTL for RRs added as a result of DHCP address assignment SHOULD be less than the initial lifetime, SHOULD NOT exceed 1/3 of the lifetime, and SHOULD NOT be less than 10 minutes. DHCP servers and clients SHOULD allow administrators to configure TTL bounds.
When a client desires no server DNS updates, the N bit MUST be 1 and the S and O bits MUST be 0.
When a client desires the server to perform DNS updates, the S bit MUST be 1 and the O and N bits MUST be 0 in the Client FQDN option sent by the client.
When a client desires to update AAAA RRs itself, the S, O, and N bits in the Flags field MUST be 0. Once configuration is complete, the client MAY originate an update for the AAAA RRs unless the server has set the S bit to 1.
When a server receives a RELEASE or DECLINE, detects address lifetime expiry, or terminates a binding, the server SHOULD delete any PTR RR associated with the address. If the server took responsibility for AAAA RRs, it SHOULD also delete the AAAA RR.
The DHCPv6 Client FQDN option (OPTION_CLIENT_FQDN, code 39) carries a Flags field (1 octet) and a domain-name field (variable length). Its minimum length is 1 octet. It is used to exchange FQDN information and negotiate DNS update responsibilities between client and server.
IANA has assigned DHCPv6 option code 39 for the Client FQDN option (OPTION_CLIENT_FQDN).
Proper conflict resolution is critical; implementers MUST consider how name conflicts will be prevented, either through security tokens restricting which updaters may modify a given name, address-based FQDN assignment, or a name conflict resolution technique per RFC 4703.
Unauthenticated DNS updates can lead to serious confusion through malicious attack or misconfiguration. Both DHCPv6 clients and servers SHOULD use some form of update request origin authentication (e.g., Secure DNS Dynamic Update, RFC 3007) when performing DNS updates.
When a DHCPv6 server performs DNS updates on behalf of a client, it SHOULD be sure of the DNS name to use and of the identity of the client. Depending on authentication options used, a server may have limited confidence in client identity, creating risk of incorrect DNS mappings.
The Client FQDN option wire format is: 2-octet option-code (39), 2-octet option-len (1 + length of domain name), 1-octet flags field, and variable-length domain-name field encoded per DHCPv6 Section 8 (DNS wire format).
The Flags field is 1 octet with bits S (bit 0), O (bit 1), and N (bit 2); remaining bits (MBZ) are reserved. S indicates whether server SHOULD perform AAAA RR updates; O indicates server overrode client's S-bit preference; N indicates whether server SHOULD NOT perform any DNS updates.