Merge sources without mistaking configuration for trust
05An ordered resolver list needs source-aware preference, while well-formed advertisements can still be malicious.
In this separate guarded case, a network policy blocks an unauthorized RA before the host while permitting the configured router. Such blocking is RECOMMENDED; SEND is another possible protection, not a new blanket MUST. No cryptographic or deployment guarantee is asserted.
Source for this drawing: RFC 8106 · Read RFC section 5.3.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
RA and DHCP DNS data can coexist. Unless user-specified static DNS applies, conforming hosts MUST extract RA DNS data and MUST maintain an ordered list for multiple sources (§1.2). Hosts SHOULD retain some information from all sources; exact counts are local policy. The ability to store at least 3 addresses or suffixes from multiple sources is RECOMMENDED, not a maximum (§5.3.1).
- RA and DHCP DNS data can coexist. Unless user-specified static DNS applies, conforming hosts MUST extract RA DNS data and MUST maintain an ordered list for multiple sources (§1.2). Hosts SHOULD retain some information from all sources; exact counts are local policy. The ability to store at least 3 addresses or suffixes from multiple sources is RECOMMENDED, not a maximum (§5.3.1).
- DHCP data SHOULD normally appear before RA data. But SEND-protected RA data MUST be preferred over non-SEND RA data and unauthenticated DHCP (§5.3.1). Our three-source example orders SEND RA, unauthenticated DHCP, then plain RA. It does not claim a universal SEND-over-authenticated-DHCP order or perform authentication.
- Entries in an option retain their advertised order. A newly received, previously unknown group can be inserted before earlier entries while retaining its internal order; an existing same-link entry merely updates expiry (§6.2). DNS and Resolver Repositories SHOULD stay synchronized (§6.1), including DNSSL handling (§6.3).
- Multiple mechanisms or interfaces can provide inconsistent DNS information; this RFC does not fully determine which source address or interface a multihomed host will use (§5.3.2). Local link scoping is necessary for link-local servers, but does not solve every cross-interface policy problem.
- An attacker can send a well-formed RA naming an unintended RDNSS or search suffix (§7.1). Valid option lengths do not authenticate the router or DNS answers. The unsafe scene is a separate illustrative case, not proof that every plain RA is malicious.
- SEND is a possible ND protection mechanism; RFC 8106 removed the older SHOULD/RECOMMENDED language for using it (Appendix A). Network mechanisms blocking rogue DNS-bearing RAs from unauthorized nodes are RECOMMENDED (§7.2). The final scene assumes such a configured guard; it does not make base RAs universally signed or encrypted.
Fictional documentation addresses/domains and chosen seconds. The isolated-option codecs and repository snapshots are bounded teaching models; no real RA, DNS query, operating-system configuration or security validation occurs.
Read the RFC section ↗