IPv6 Router Advertisement Options for DNS Configuration
obsoleted by
- rfc-8106 — IPv6 Router Advertisement Options for DNS Configuration
obsoletes
- rfc-5006 — IPv6 Router Advertisement Option for DNS Configuration
Extracted elements (25)
RA-based DNS configuration was designed specifically for networks using IPv6 stateless address autoconfiguration (SLAAC) without DHCPv6 infrastructure or without DHCPv6 clients on all hosts. It allows complete basic network configuration — address, default router, and DNS — from a single RA message exchange.
The DNSSL option was added to RFC 5006's RDNSS-only specification to achieve parity with DHCPv6 DNS options (RFC 3646) and to ensure hosts can determine the appropriate DNS search domains without requiring DHCPv6.
RA-based DNS options and DHCPv6 DNS options (RFC 3646) can coexist. When both are present, DHCP-sourced DNS information is placed first in the Resolver Repository and therefore takes precedence over RA-sourced DNS information for resolver queries.
When multiple network interfaces provide different DNS information, inconsistent host behavior can result. This multi-interface DNS problem was an open issue at the time of publication, being tracked separately by the IETF MIF working group.
An RDNSS address or DNSSL domain name MUST be used only as long as both the RA router Lifetime and the corresponding option Lifetime have not expired, because the RDNSS may be unreachable or the DNSSL invalid on the current network.
Domain names in the DNSSL option MUST be encoded using the RFC 1035 Section 3.1 label sequence technique and MUST NOT be encoded in compressed form as described in RFC 1035 Section 4.1.4. The field size MUST be a multiple of 8 octets, with remaining octets padded with zeros.
For DNS options announced by RA, those that use the Secure Neighbor Discovery (SEND) protocol for RA security MUST be preferred over those that do not use SEND.
Hosts conforming to this specification MUST extract DNS information from Router Advertisement messages unless static DNS configuration has been specified by the user.
If DNS information is available from multiple Router Advertisements and/or from DHCP, the host MUST maintain an ordered list of this information as specified in Section 5.3.1.
If DNS options are valid (Length meets minimum), the host SHOULD copy the values into the DNS Repository and Resolver Repository in order; otherwise the host MUST discard the options.
The ability to store at least three RDNSS addresses (or DNSSL domain names) from at least two different sources is RECOMMENDED. DNS information from DHCP SHOULD be stored first in the Resolver Repository so that DHCP takes precedence over RA for DNS queries.
The RDNSS Lifetime SHOULD be bounded as MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval, providing stable DNS service to fixed hosts while allowing mobile hosts to prefer local RDNSSes. A value of 0xffffffff represents infinity; a value of zero means the RDNSS address MUST no longer be used.
Three is RECOMMENDED as a sufficient number of RDNSS addresses (or DNSSL domain names) to maintain, balancing robust DNS query support with timely recognition of DNS server unreachability.
The DNS Repository consists of two data structures maintained by the host: a DNS Server List (RDNSS addresses with Expiration-times) and a DNS Search List (DNSSL domain names with Expiration-times). These parallel the Neighbor Cache and Destination Cache used by Neighbor Discovery.
The DNS Search List (DNSSL) option is a new IPv6 Neighbor Discovery option that carries one or more DNS suffix domain names used by hosts when performing DNS queries for short, unqualified domain names. All names share a single Lifetime value.
The Recursive DNS Server (RDNSS) option is an IPv6 Neighbor Discovery option that carries one or more IPv6 addresses of recursive DNS servers, all sharing a single Lifetime value. Multiple RDNSS options may be used to convey addresses with different Lifetimes.
The Resolver Repository (e.g., Unix /etc/resolv.conf or Windows registry) is the user-space configuration consumed by the DNS resolver. New RDNSS addresses and DNSSL domain names are inserted at the front of the Resolver Repository in the order they appear within an option, establishing query preference.
Two IPv6 Neighbor Discovery Option types are registered in the ICMPv6 Parameters registry: Type 25 for the Recursive DNS Server (RDNSS) Option (originally assigned in RFC 5006) and Type 31 for the new DNS Search List (DNSSL) Option.
A bogus DNSSL option can cause a victim host to send DNS queries for non-FQDNs to an attacker-controlled server. DNS resolvers SHOULD apply mitigations from RFC 1535, RFC 1536, and RFC 3646 to reduce this exposure.
An attacker can send a rogue RA containing a fraudulent RDNSS address, misleading IPv6 hosts into contacting a malicious DNS server. Similarly, a fraudulent DNSSL option can cause hosts to resolve unqualified names to attacker-controlled addresses. These attacks are analogous to rogue DHCP and Neighbor Discovery redirect attacks.
It is RECOMMENDED that ND use SEND (RFC 3971) so that RDNSS and DNSSL options are covered by the RA integrity signature, preventing spoofing. Network devices are RECOMMENDED to block unauthorized nodes from sending RA messages containing RDNSS and DNSSL options, analogous to DHCPv6 server port-blocking.
The security vulnerability introduced by these RA DNS options does not worsen existing ND protocol security: learning bad DNS information via RA options is no worse than learning bad router information via RA, so the attack surface is a subset of what any LAN-attached node can already do.
Each RDNSS or DNSSL entry transitions from active to expired when the current system time exceeds its Expiration-time (set to current time plus Lifetime at receipt). On expiration the entry is deleted from both the DNS Repository and the Resolver Repository. A received Lifetime of zero triggers immediate deletion.
The DNSSL option consists of a 1-octet Type (value 31), a 1-octet Length in units of 8 octets (minimum 2), a 2-octet Reserved field, a 32-bit Lifetime, and one or more domain names encoded per RFC 1035 Section 3.1. The domain names field MUST be padded with zeros to a multiple of 8 octets and MUST NOT use DNS compression.
The RDNSS option consists of a 1-octet Type (value 25), a 1-octet Length in units of 8 octets (minimum 3 for one address, each additional address adds 2), a 2-octet Reserved field, a 32-bit Lifetime, and one or more 128-bit IPv6 recursive DNS server addresses. The number of addresses equals (Length - 1) / 2.