Refresh and withdraw DNS data using its own lifetime
04Receipt-relative DNS lifetimes survive router-lifetime expiry and require synchronized removal from both repositories.
In a separate case, finite expiry 400 is past at 401 and the entry is removed from both lists. A different server learned in a separate option with Lifetime 0xffffffff remains until withdrawn or changed; infinity is not a reachability guarantee.
Source for this drawing: RFC 8106 · Read RFC section 6.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.
The replacement uses a higher recommended DNS-option lifetime default, removes freshness-triggered solicitation text and the old three-entry maximum recommendation, and makes SEND a possible mechanism rather than recommending it with SHOULD. Three remains a recommended minimum storage ability for mixed sources, not a maximum.
Read the updated RFC section ↗For RDNSS and DNSSL, Lifetime SHOULD by default be at least 3 × MaxRtrAdvInterval, the maximum Router Advertisement interval. This is a recommended default, not a universal mandatory lifetime. With chosen MaxRtrAdvInterval 100 seconds, 300 seconds illustrates that default (§§5.1–5.2). RFC 8106 replaces 6106 with a higher default and removes the earlier freshness-triggered Router Solicitation text (Appendix A).
- For RDNSS and DNSSL, Lifetime SHOULD by default be at least 3 × MaxRtrAdvInterval, the maximum Router Advertisement interval. This is a recommended default, not a universal mandatory lifetime. With chosen MaxRtrAdvInterval 100 seconds, 300 seconds illustrates that default (§§5.1–5.2). RFC 8106 replaces 6106 with a higher default and removes the earlier freshness-triggered Router Solicitation text (Appendix A).
- Lifetime is measured from reception. An entry received at t=100 with Lifetime 300 has Expiration-time 400. A new option for the same value on the same interface at t=250 with Lifetime 300 refreshes it to 550 (§6.1). DNS option lifetimes are separate from the RA Router Lifetime: losing a default-router entry need not delete still-valid DNS configuration. Reachability is still a separate question.
- A zero Lifetime means the corresponding values MUST no longer be used (§§5.1–5.2). Remove an existing value from both the DNS list and Resolver Repository (§§6.2–6.3). Our model never inserts a previously unseen zero-lifetime value for use. Withdrawal can also remove a previously infinite entry.
- Expired entries are removed from both repositories. The chosen integer-clock helper follows §6.1’s “current time becomes larger than Expiration-time” test; displayed expiry examples are strictly beyond the deadline. Zero-lifetime withdrawal is immediate and separate from that comparison.
- All-one-bits Lifetime 0xffffffff denotes infinity, not −1 or a permanently reachable/trusted server (§§5.1–5.2). A finite and an infinite server example require separate options. New entries preserve advertised order; existing entries refresh their expiry. A chosen finite RDNSS capacity can evict the earliest-expiring entry under §6.2, but three is not a protocol maximum. The repository helper models single-entry updates and fully new ordered groups; mixed existing/new groups or reordering existing groups are outside its selected teaching cases, not invalid RFC options.
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 ↗