Cache normal records and choose TTL with care
04An initiator can cache the answer normally. A time to live, TTL, limits how long the cached record remains usable; it is not a permanent ban on asking a name.
At elapsed 60 seconds the illustrated TTL reaches zero. That cached record no longer supports this reuse decision. Any new query follows ordinary DNS and local policy; the page does not issue network requests.
Source for this drawing: RFC 8482 · Read RFC section 5 ↗
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.
Normal caching and optional suppression can reduce repeated ANY work without claiming a complete record list.
- An initiator receiving HINFO or a single RRset as described MAY cache it; cached records SHOULD be retained using normal caching semantics.
- With a matching cached HINFO CPU marker, an initiator MAY suppress ANY queries or MAY answer them with local cache contents. This is optional behavior, not a new mandatory refusal or permanent server-wide block.
- The synthesized HINFO TTL SHOULD be operator-configurable and chosen large enough to suppress frequent repeated ANY queries; too long a TTL can delay policy changes (§4.2).
- Cached synthesized HINFO can also mask a real HINFO RRset in the zone. Operators relying on genuine HINFO SHOULD choose the single-RRset method or another type (§6).
The worked TTL of 60 seconds is fictional local policy, not a required default. The example assumes the same matching name and applicable cached record. Ordinary DNS cache rules and validation remain outside this bounded countdown.
Read the RFC section ↗