RDNSS

RDNSS in IPv6 name resolution

RDNSS sits in the IPv6 neighbour discovery and router advertisement flow, so it is part of the network’s control plane rather than an application-layer DNS feature. The value of the option is that hosts can learn which recursive resolvers to use without a separate DHCPv6 configuration path, which makes it especially relevant in SLAAC-oriented networks and other environments that rely on router advertisements for basic client setup.

Because it is delivered through Router Advertisement messages, RDNSS inherits the trust assumptions of the local IPv6 segment. A host that accepts a forged or altered advertisement can be pointed at a resolver chosen by an attacker, which can affect name resolution, traffic steering, and the integrity of subsequent connections that depend on DNS answers.

How RDNSS behaves on the wire

RDNSS is advertised as an option inside IPv6 Router Advertisement messages. Hosts read the option, cache the listed recursive DNS servers for a limited time, and use them when resolving names for the life of that configuration. This makes the option a neighbour-discovery companion to router reachability, not a replacement for DNS itself.

In practice, the mechanism is attractive where DHCPv6 is not used for DNS distribution or where administrators want a lighter-weight way to deliver resolver settings to clients. That convenience also means the correctness of the router advertisement source and its path through the local network becomes operationally important.

Why RDNSS matters for control-plane trust

RDNSS is only as trustworthy as the IPv6 control plane that carries it. If rogue router advertisements are accepted, clients can be redirected to malicious, unstable, or privacy-invasive DNS infrastructure. Even without a full compromise, a mistaken advertisement can break resolution for large numbers of hosts by sending them to the wrong resolver or by advertising an unreachable one.

The security consequence is broader than simple lookup failure. DNS is a dependency for service discovery, certificate validation, software updates, and many authentication workflows, so poisoning or disruption of resolver selection can become an access, availability, or interception problem.

Where administrators should validate and prefer RDNSS

RDNSS should be treated as a configuration choice that needs validation in the same way as any other network control-plane setting. Administrators should confirm whether router advertisements are expected to carry DNS information, whether the advertised resolvers match the intended design, and whether the environment has protections against unauthorised advertisements. In mixed networks, it is important to understand whether RDNSS, DHCPv6, or both are authoritative for host resolver configuration.

It is also worth checking operational consistency across segments. If some subnets rely on RDNSS and others do not, clients may experience different resolver behaviour when they move between links, which can complicate troubleshooting, policy enforcement, and incident review.

Risk and Threat Considerations

RDNSS can be abused when an attacker can inject or tamper with Router Advertisement traffic on the local link. That makes it a useful target for rogue-RA attacks, misconfiguration, and denial-of-service conditions that alter which DNS servers hosts trust.

Failure mechanism: A client accepts a false or poisoned advertisement, caches attacker-controlled resolver settings, and then sends name resolution traffic to an untrusted endpoint.

Impact: The result can be DNS interception, service disruption, policy bypass, or broader compromise of connections that depend on trustworthy name resolution.

Practitioner Guidance

What to watch for: Validate that only legitimate routers can supply IPv6 advertisements on each segment, and monitor for unexpected changes in advertised DNS servers or resolver lifetimes. If resolver behaviour changes without a planned network change, treat it as a control-plane event rather than a routine DNS issue.

Governance implication: Document whether RDNSS is the approved source of DNS configuration, then keep that choice aligned with router hardening, segmentation, and monitoring so local-link trust does not drift over time.