DHCP and Router Advertisement Options for the Discovery of Network-designated Resolvers (DNR)
Extracted elements (32)
A single option encodes both the ADN and IP addresses rather than using separate options. Using separate options would require a correlation mechanism to associate IP addresses with ADNs when multiple ADNs are present, adding unnecessary complexity.
DNR options (DHCP/RA) take precedence over Discovery of Designated Resolvers (DDR, RFC 9462), because DDR uses Do53 queries to an external resolver that is susceptible to both internal and external attacks, whereas DHCP/RA is protected by link-layer mechanisms such as DHCPv6-Shield and RA-Guard.
IP addresses are included alongside the ADN to avoid adding a dependency on an external resolver to resolve the ADN. Early drafts considered reusing the existing DNS server address options, but that would require clients to probe each address for each supported protocol. Bundling the ADN with IPs and SvcParams eliminates this probing.
Service parameters are encoded using the existing RFC 9460 SvcParams wire format rather than a new encoding. While this may increase option size, it reuses an existing IANA registry and accommodates future encrypted DNS protocols and parameters without requiring new option definitions.
The Encrypted DNS options always include an ADN to enable PKIX-based authentication of the resolver. IP-address-only certificates are extremely rare (less than 1% of issued certificates per RFC 6125 Section 1.7.2), so using an FQDN as the reference identifier aligns with current certificate issuance best practices.
If no port SvcParam is included in the Encrypted DNS option, default port numbers apply: 853 for DoT, 443 for DoH, and 853 for DoQ. Implementations MUST use these defaults when the port parameter is absent.
The 'alpn' SvcParam may not be required in contexts where DNS runs over a variant of CoAP with OSCORE encryption, since OSCORE provides a different protocol-disambiguation mechanism. In such contexts, implementations MAY omit the 'alpn' SvcParam.
A DNR implementation MUST support the 'alpn' SvcParam (to indicate supported protocols) and the 'port' SvcParam (to indicate the target port). Support for 'dohpath' is RECOMMENDED.
DHCPv6 and DHCPv4 clients MUST be prepared to receive multiple instances of OPTION_V6_DNR or DNR Instance Data entries; each is treated as a separate encrypted DNS resolver. These MUST be processed in ascending service priority order (smaller value = higher preference).
DHCPv6 and DHCPv4 clients MUST silently discard any Encrypted DNS option that fails the validation checks defined in Section 3.1.8, including absence of ADN, malformed SvcParams, no valid IP address, or presence of 'ipv4hint'/'ipv6hint' SvcParams.
DHCPv6 clients, DHCPv4 clients, and IPv6 hosts MUST silently discard multicast and host loopback addresses conveyed in Encrypted DNS options.
If encrypted DNS resolvers are discovered via both RA and DHCP, the conflict-resolution rules in RFC 8106 Section 5.3.1 MUST be followed.
OPTION_V4_DNR is a concatenation-requiring option; the mechanism specified in RFC 3396 MUST be used if the option exceeds the maximum DHCPv4 option size of 255 octets.
SvcParams in all three option formats MUST NOT include 'ipv4hint' or 'ipv6hint' parameters, as these are superseded by the IP addresses included directly in the option.
The Addr Length field, when present in DHCPv6 and RA options, MUST be a multiple of 16; in DHCPv4 options, it MUST be a multiple of 4.
The RA Encrypted DNS option MUST be padded with zeros so that the full enclosed data is a multiple of 8 octets, per RFC 4861 Section 4.6.
To discover an encrypted DNS resolver via DHCPv6, the client MUST include OPTION_V6_DNR in an Option Request Option (ORO) per RFC 8415 Sections 18.2.1, 18.2.2, 18.2.4, 18.2.5, 18.2.6, and 21.7.
When a client learns both Do53 and encrypted DNS resolvers from the same network, it is RECOMMENDED to prefer the encrypted DNS resolvers. If an authenticated encrypted connection cannot be established, the client MAY fall back to the Do53 resolver.
The DNR discovery mechanisms allow inference that a DHCP client or IPv6 host supports Encrypted DNS options, but do not reveal whether clients can consume them or disclose their encryption capabilities. The mechanisms do not expose more privacy information than existing Do53 discovery options. Encrypted DNS does not reduce data available at the resolver itself.
Service Parameters (SvcParams) are encoded following the wire-format rules of RFC 9460 Section 2.2. The 'alpn' and 'port' SvcParams MUST be supported. The 'dohpath' SvcParam is RECOMMENDED. SvcParams MUST NOT include 'ipv4hint' or 'ipv6hint', as these are superseded by the explicitly included IP addresses.
The Authentication Domain Name (ADN) is a FQDN encoded in the DNS wire format as specified in RFC 8415 Section 10, using length-prefixed labels terminated by a zero-length label. For example, 'doh1.example.com.' encodes to 18 octets. The ADN serves as the reference identifier for PKIX-based authentication of the encrypted DNS resolver.
The Lifetime field in the RA Encrypted DNS option is a 32-bit unsigned integer in seconds representing the validity period of the discovered ADN. The default SHOULD be at least 3 * MaxRtrAdvInterval. A value of 0xffffffff means infinity; a value of zero means the ADN MUST no longer be used.
The Service Priority field is a 16-bit unsigned integer present in all three option formats (DHCPv6, DHCPv4, RA), interpreted per RFC 9460 Section 2.4.1. A smaller value indicates higher preference. Clients MUST process multiple resolver instances in service priority order.
IANA assigned DHCPv4 Option Tag 162 (OPTION_V4_DNR) in the 'BOOTP Vendor Extensions and DHCP Options' registry with variable data length, describing an Encrypted DNS Server.
IANA assigned DHCPv6 Option Code 144 (OPTION_V6_DNR) in the 'Option Codes' registry. The option supports Client ORO and is not a singleton option.
IANA assigned IPv6 Neighbor Discovery Option Type 144 (Encrypted DNS Option) in the 'IPv6 Neighbor Discovery Option Formats' subregistry under ICMPv6 Parameters.
DHCP/RA messages are unencrypted and unprotected on the LAN; an active attacker can spoof them to advertise a rogue encrypted DNS resolver. Mitigation mechanisms include DHCPv6-Shield (RFC 7610), RA-Guard (RFC 7113), and SAVI for DHCP (RFC 7513). Even so, these mechanisms cannot authenticate the DHCP server itself; PKIX validation of the resolver certificate against the ADN provides the end-to-end authentication.
DNS clients that ignore PKIX authentication failures and accept spoofed certificates will be subject to attacks such as redirection to malicious resolvers or interception of sensitive data. Encrypted DNS sessions with rogue resolvers spoofing an IP address will fail authentication because the ADN in the option will not match the certificate.
Wireless LANs are vulnerable to evil-twin, KRACK, and Dragonblood attacks. Because DHCP and RA messages are unauthenticated, information provided over WLANs using shared PSK (WPA-PSK) is untrusted. Using per-device credentials (802.1x / EAP-pwd or unique PSKs) provides mutual authentication and is the recommended mitigation.
The DHCPv4 Encrypted DNS option (OPTION_V4_DNR, code 162) contains one or more DNR Instance Data entries, each with a 16-bit DNR Instance Data Length, 16-bit Service Priority, 8-bit ADN Length, variable-length authentication-domain-name, optional 8-bit Addr Length followed by 4-byte IPv4 addresses, and optional SvcParams. Multiple resolvers are encoded by repeating the DNR Instance Data field.
The DHCPv6 Encrypted DNS option (OPTION_V6_DNR, code 144) carries a 16-bit Option-code, 16-bit Option-length, 16-bit Service Priority, 16-bit ADN Length, variable-length authentication-domain-name (FQDN encoded per RFC 8415 Section 10), optional 16-bit Addr Length followed by 16-byte IPv6 addresses, and optional SvcParams. In ADN-only mode, Addr Length, addresses, and SvcParams are absent.
The IPv6 RA Encrypted DNS option has an 8-bit Type (144), 8-bit Length (in units of 8 octets), 16-bit Service Priority, 32-bit Lifetime, 16-bit ADN Length, variable authentication-domain-name, optional 16-bit Addr Length with IPv6 addresses, 16-bit SvcParams Length, and variable SvcParams. The full option MUST be padded to a multiple of 8 octets.