Accept DNS configuration from IPv6 router advertisements only within option lifetimes

Use this document to resolve one bounded operational decision: Accept DNS configuration from IPv6 router advertisements only within option lifetimes. Only the official source and traced locations below supply facts. Confirm applicability before acting.

Source fact:

The official RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration from RFC Editor / Internet Engineering Task Force supports the following bounded statements:

• An RDNSS option’s Lifetime is the maximum time its advertised recursive-server addresses may be used; a zero lifetime removes them immediately. The research record locates this support at Section 5.1 (Recursive DNS Server Option).
• A DNSSL option applies the same lifetime semantics to its advertised DNS search suffixes, including immediate withdrawal at zero. The research record locates this support at Section 5.2 (DNS Search List Option).
• A host discards invalid RA DNS options and stores valid options in ordered repositories alongside information learned from other RAs and DHCP. The research record locates this support at Section 5.3.1 (Procedure in IPv6 Hosts).

Only the traced statements above are asserted as source facts. Apply the review to address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains after confirming that the source and deployed context match.

What the source does not establish

This RFC evidence supports only the named network-protocol decision; it does not select vendor settings, topology, capacity, or an acceptable failure mode. Do not read the source as proof of implementation or permission to change production. Its guidance remains conditional on DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring and the environment’s recorded constraints.

Applicability questions

• For source statement 1 at Section 5.1 (Recursive DNS Server Option), which observable configuration, record, or test can confirm applicability here?
• For source statement 2 at Section 5.2 (DNS Search List Option), which observable configuration, record, or test can confirm applicability here?
• For source statement 3 at Section 5.3.1 (Procedure in IPv6 Hosts), which observable configuration, record, or test can confirm applicability here?
• Within address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, which versions, roles, and configuration states define the review population?
• Could DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring invalidate the test, hide a failure, or change applicability?
• Who owns the decision, and which observation requires stopping, escalation, or rollback?

DSE recommendation:

DSE recommends using the cited source as the evidence anchor for this decision. Begin by recording scope and current state before deciding whether a change is warranted. Record the source location, examined part of address plans, interfaces, routes, peers, protocol roles, timers, middleboxes, and intended failure domains, observed and expected states, owner, and reason for deviation.

An implementation decision needs an owner, approved window, prechecks, observable outcome, stop authority, and rollback path. Validate DNS, Active Directory authentication, PKI, time, routing policy, transport reachability, and monitoring before and after the test, and store only sanitized operational evidence.

Verification and evidence

Build a reproducible chain from Section 5.1 (Recursive DNS Server Option); Section 5.2 (DNS Search List Option); Section 5.3.1 (Procedure in IPv6 Hosts) to the observed environment. Useful domain evidence includes configuration snapshots, route or neighbor state, packet captures, counters, topology records, and controlled failover results; label every item with scope, timestamp, collector, and stable identifier.

Record the decision even when no change is made, including uncertainty and the next trigger. Use safe testing conditions for disruptive work, preserve rollback proof, and revisit the conclusion after relevant platform, dependency, vendor, or ownership changes.

Official references

• RFC 8106 — IPv6 Router Advertisement Options for DNS Configuration — RFC Editor / Internet Engineering Task Force