Improved Recursive DNS Server Selection for Multi-Interfaced Nodes
Extracted elements (29)
Network-interface-specific IP addresses (including NAT64 synthetic AAAA records from RFC 6147 and RFC 6418 scenarios) may only be reachable on the interface over which the name was resolved, making interface-aware RDNSS selection a prerequisite for correct destination reachability rather than a mere optimization.
The DHCPv4 option encodes both a primary and secondary RDNSS address in a single option instance (unlike DHCPv6 which uses one option per RDNSS) to accommodate DHCPv4's single-option-per-type expectation; long domain lists MAY span multiple concatenated option instances per RFC 3396.
The option is not enabled by default because DHCP itself cannot determine whether it is operating on a secure channel or whether the client performs DNSSEC validation; enabling without preconditions would allow untrusted networks to redirect DNS resolution silently.
DNS cache entries for private namespaces can become obsolete when a network interface is closed or when a new parallel interface alters RDNSS preferences; implementations SHOULD manage per-interface caches or flush stale cache entries on interface change events.
OPTION_RDNSS_SELECTION coexists with DHCPv6 OPTION_DNS_SERVERS (RFC 3646), DHCPv4 Domain Server option (RFC 2132), and IPv6 RA RDNSS Option (RFC 6106). If a node signals support for OPTION_RDNSS_SELECTION, the DHCPv6 server MAY omit OPTION_DNS_SERVERS to allow low-preference-only advertisement.
A resolver SHALL build a preference list of RDNSSes per query and SHALL request RDNSS selection information via the DHCP options before any DNS queries need to be made.
Any follow-up queries (e.g., on CNAME or DNAME) MUST continue to use the same interface or RDNSS as the original query, irrespective of the RDNSS selection settings on any other interface, to prevent referral failures.
For conflict resolution across DHCP versions on equally trusted interfaces, DHCPv6 MUST be preferred over DHCPv4 unless DHCPv4 is utilizing additional security frameworks for message protection.
In the case of a validated NXDOMAIN response received from an RDNSS that can provide answers for the queried name, a node MUST NOT accept non-validated replies from other RDNSSes.
Information received from all RDNSS configuration tools (DHCPv4, DHCPv6, RA) MUST be combined together into a single list. RDNSSes learned via tools other than the RDNSS selection options MUST be handled as default RDNSSes with medium preference.
It is RECOMMENDED for administrators utilizing private namespaces to deploy DNSSEC for their zone in order to counter attacks against private namespaces.
OPTION_RDNSS_SELECTION MUST NOT appear in any DHCPv6 messages other than Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
Private namespaces MUST be globally unique to keep DNS unambiguous and avoid caching and destination-selection problems. Private namespaces MUST only consist of subdomains of domains for which the relevant operator provides authoritative name service.
The client SHALL periodically refresh information learned with OPTION_RDNSS_SELECTION; the information SHALL be refreshed on link-state changes such as node mobility and when renewing IPv6/IPv4 address leases.
The list of networks in the RDNSS selection option MUST cover all the domains configured in that option. The network prefix length SHOULD be as long as possible to avoid collision with information from other option instances or other interfaces.
The RDNSS selection option SHOULD NOT be enabled by default; it may only be used when delivered over a trusted channel, when DNSSEC validation is performed by the client or a trusted resolver, or when the RDNSS is already trusted by the client.
The resolver MUST NOT prioritize less-trusted RDNSSes higher than trusted ones, even when the less-trusted RDNSS apparently has additional information.
The resolver MUST prefer RDNSSes of trusted interfaces. RDNSSes of untrusted interfaces can be of highest preference only if trusted interfaces specifically configure low-preference RDNSSes.
When a conflicting RDNSS address is learned from a less-trusted interface, the node MUST ignore the option; it MUST NOT remove previously obtained information, and SHOULD NOT extend the lifetime of earlier information.
When a DNS query needs to be made, the resolver MUST give highest preference to RDNSSes explicitly known to serve a matching domain or network, and MUST take into account differences in trust levels of received RDNSS selection information.
When a requested name matches a specific domain or network rule accepted from any interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that cannot be validated using DNSSEC until all RDNSSes on the preference list have been contacted or timed out, to protect against redirection attacks.
A special domain value of '.' in the 'Domains and networks' field indicates the RDNSS has capability to resolve global names and acts as a default RDNSS. Absence of '.' means the RDNSS only has information for the explicitly listed domains and networks.
The 2-bit 'prf' preference field encodes: 01=High, 00=Medium, 11=Low, 10=Reserved. The Reserved value (10) MUST NOT be sent; on receipt it MUST be treated as Medium (00). Medium preference is also used for RDNSSes learned from sources that carry no explicit preference.
IANA assigned DHCPv4 option code 146 (RDNSS Selection) from the 'BOOTP Vendor Extensions and DHCP Options' registry, and DHCPv6 option code 74 (OPTION_RDNSS_SELECTION) from the 'DHCP Option Codes' registry.
Attackers may use OPTION_RDNSS_SELECTION or the DHCPv4 RDNSS Selection option to redirect DNS queries to malicious destinations for denial of service or man-in-the-middle attacks, by advertising broad domains/networks or placing an attacker's RDNSS as the highest-preference default. The primary countermeasure is implementing validating DNSSEC-aware resolvers.
Section 4 uses normative language for node internal behavior to ensure that accidental use of RDNSS selection options does not open new attack vectors. Consensus during standardization was that the option is safer disabled by default.
Trustworthiness of an interface is implementation- and deployment-dependent; authenticated encrypted VPN or trusted home/cellular links may be considered trusted, while unauthenticated connections to unknown visited networks are typically untrusted. Implementations may require explicit user or administrator configuration to assign trust.
DHCPv4 RDNSS Selection option (code 146) carries a 1-byte code, 1-byte length, 1-byte Reserved+prf, a 4-byte primary RDNSS IPv4 address, a 4-byte secondary RDNSS IPv4 address (0.0.0.0 if absent), and a variable-length 'Domains and networks' field encoded per RFC 3315 Section 8.
DHCPv6 OPTION_RDNSS_SELECTION (code 74) carries a 16-byte IPv6 RDNSS address, a 1-byte Reserved+prf field (6 reserved bits, 2-bit preference), and a variable-length 'Domains and networks' field encoded per RFC 3315 Section 8.