The Address Arrived. The Resolver Didn't: IPv6 Learns to Advertise DNS

Summary

SLAAC could give an IPv6 host an address and a route without supplying the recursive DNS server needed to turn names into destinations.
RDNSS moved resolver discovery into Router Advertisements; DNSSL added search suffixes, and later rules addressed expiry, source ordering and support.

An address is not a resolver

An IPv6 host can have a valid address, a prefix and a default router and still fail before it reaches a website: it has no recursive resolver to ask what the website’s name means. The network has told the host where packets can go. It has not told the host where name questions belong.

Neighbor Discovery and Stateless Address Autoconfiguration handled the first part. Router Advertisements carried link information; SLAAC let a host form an address without a DHCPv6 address lease. DNS configuration followed a different path. In 2007, RFC 5006 stated that DHCP was the IETF’s only Standards Track way to configure DNS. For a laptop that moved between wireless networks, manually replacing a resolver at every stop was a poor bargain.

RFC 5006 offered another route, but marked it Experimental: an IPv6 Router Advertisement could carry a Recursive DNS Server option, or RDNSS. A host could learn the recursive server from the same advertisement that carried link configuration. No second protocol exchange was needed. The option still depended on router configuration; the RFC did not make routers discover their own DNS servers.

The router advertisement took on names

RFC 6106 moved the DNS options onto the Standards Track in 2010 and added DNSSL, a DNS Search List. RDNSS supplied one or more resolver addresses. DNSSL supplied suffixes a host could append when an application asked about an unqualified name. A laptop could receive its prefix, router, resolver and search list through the same Router Advertisement stream.

DHCPv6 did not disappear. RFC 6106 described DHCPv6 and RA as options that could coexist, useful in different networks and host configurations. RFC 8106 later made the host keep an ordered list when DNS information came from several Router Advertisements or from DHCP. User-set static DNS configuration remained a separate choice. The issue had become source order, not a contest with one winner.

A timer exposed packet loss

RDNSS and DNSSL entries have lifetimes. A host removes an entry when it expires, so an advertisement is a lease on resolver information, not a permanent setting. RFC 6106 bounded the lifetime using the maximum Router Advertisement interval. RFC 8106, published in 2017, recorded that the earlier lower bound of twice that interval could let DNS options expire on links with high packet loss. It relaxed that bound and set a higher default of three times the interval.

The change is small in a packet diagram and large in an operator’s incident log: the address and route can remain valid while the resolver entry disappears. An application may then look as if the network is down even though the host can still reach an IP address directly.

Support became part of the IPv6 baseline

The requirement level rose with the design. RFC 6434 in 2011 said implementations SHOULD support the DNS RA option. RFC 8504 in 2019 said IPv6 nodes MUST support it. The sequence ran from an experimental escape hatch to a required host capability because an address alone could not provide practical Internet service.

The source rules give the feature its real control surface. RFC 8106 says a host should retain ordered information from RA and DHCP sources; DHCP information normally appears first. An RA secured with SEND is preferred over an unauthenticated DHCP source. Static DNS set by the user can take precedence over advertised information.

These RFCs establish design and requirement changes; they do not provide an official census of hosts using RDNSS, so the number of deployed clients cannot be stated.