IPv6 Router Advertisement Options for DNS Configuration
obsoletes
- rfc-6106 — IPv6 Router Advertisement Options for DNS Configuration
Extracted elements (25)
RFC 8106 removes the RFC 6106 hard limit of three RDNSS addresses and three DNSSL domain names; the number to maintain is now determined by local policy and implementation choice.
RFC 8106 removes the RFC 6106 recommendation to send a Router Solicitation before RDNSS expiry, to avoid increasing multicast traffic on the link.
The default Lifetime was raised from 2 * MaxRtrAdvInterval (RFC 6106) to 3 * MaxRtrAdvInterval to match the Router Lifetime default (AdvDefaultLifetime) and to allow DNS options to survive up to three consecutive lost RAs on lossy links.
Implementations updated to RFC 8106 still interoperate with RFC 6106 implementations because the only substantive change is the increase of the default Lifetime value for DNS options.
Link-local RDNSS addresses should be stored in the Resolver Repository along with their corresponding link zone indices, formatted per RFC 4007 scoped address notation, to allow proper link selection when querying.
When DNS information is available from both RA options and DHCPv6, both sources should be maintained. The DNS options from different sources should be stored with DHCP-sourced entries first (taking precedence), but all sources should be kept.
A Lifetime value of zero in the RDNSS or DNSSL option means that the addresses or domain names MUST no longer be used for name resolution.
DNS options announced by RAs via SEND MUST be preferred over those announced by unauthenticated DHCP. RAs using SEND MUST be preferred over RAs not using SEND.
Hosts conforming to this specification MUST extract DNS information from RA messages, unless static DNS configuration has been specified by the user.
If DNS information is available from multiple RAs 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, the host SHOULD copy the values into the DNS Repository and the Resolver Repository in order; otherwise, the host MUST discard the options.
In the case of multiple sources, the ability to store a total of at least three RDNSS addresses (or DNSSL domain names) from multiple sources is RECOMMENDED.
RDNSS addresses in the RDNSS option MAY be link-local addresses. When a resolver sends a DNS query to an RDNSS identified by a link-local address, it MUST use the corresponding link.
The Lifetime field in both RDNSS and DNSSL options SHOULD by default be at least 3 * MaxRtrAdvInterval, where MaxRtrAdvInterval is defined in RFC 4861. This default allows DNS options to survive up to three consecutive lost RAs.
The validity of the RDNSS option MUST be checked: Length >= 3 and (Length - 1) % 2 == 0, and the RDNSS addresses must be unicast. The DNSSL option Length must be >= 2.
When multiple DNS sources exist (RAs and DHCP), DNS options from DHCP SHOULD appear first in the DNS Repository and Resolver Repository, giving DHCP-sourced DNS information precedence over RA-sourced information.
The DNSSL option carries one or more DNS suffix domain names. Fields: Type (8-bit, value 31), Length (8-bit, in units of 8 octets, minimum 2), Reserved (16-bit), Lifetime (32-bit, in seconds), and domain names encoded per RFC 1035 Section 3.1 (uncompressed), padded to a multiple of 8 octets with zeros.
The RDNSS option carries one or more IPv6 addresses of Recursive DNS Servers. Fields: Type (8-bit, value 25), Length (8-bit, in units of 8 octets, minimum 3), Reserved (16-bit), Lifetime (32-bit, in seconds), and one or more 128-bit IPv6 RDNSS addresses. Number of addresses = (Length - 1) / 2.
The RDNSS option (Type 25) and DNSSL option (Type 31) are registered in the IANA 'IPv6 Neighbor Discovery Option Formats' registry. These assignments are pre-existing (from RFC 6106) and confirmed by this document.
A bogus DNSSL option can cause a victim to send DNS queries to a specific server for non-FQDN queries. DNS resolvers can mitigate this via recommendations in RFC 1535, RFC 1536, and RFC 3646.
An attacker can send a fraudulent RA with a bogus RDNSS address, redirecting IPv6 hosts to a malicious DNS server. Similarly, a fraudulent DNSSL can cause hosts to resolve short unqualified names to unintended IP addresses.
SEND (RFC 3971) can be used to digitally sign RA messages including RDNSS and DNSSL options. Network devices SHOULD block rogue RA messages from unauthorized nodes using RA Guard techniques (RFC 6104, RFC 6105).
RDNSS entry lifecycle: NEW entry is registered when address first received (Step d); EXISTING entry has its Expiration-time updated on re-receipt with non-zero Lifetime (Step c); entry is DELETED immediately when Lifetime=0 is received (Step b) or when current time exceeds Expiration-time (expiry handling).
DNSSL option domain names MUST be encoded as described in RFC 1035 Section 3.1 (label sequence ending in zero octet) and MUST NOT use the compressed form from RFC 1035 Section 4.1.4. The field MUST be padded to a multiple of 8 octets with zeros.
RDNSS option Lifetime field is a 32-bit unsigned integer representing maximum seconds the addresses MAY be used. Value 0xffffffff means infinity; value 0 means the addresses MUST no longer be used.