Bound extra work and keep the privacy limits visible
05Limit label-driven probes, reuse knowledge and distinguish minimisation from encryption.
A stub/forwarder sends information that eventually reaches its upstream resolver. QNAME minimisation does not protect against that resolver, encrypt traffic or guarantee anonymity. Historical research percentages are not live telemetry.
Source for this drawing: RFC 9156 · Read RFC section 2.3 ↗
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.
Resolvers supporting QNAME minimisation MUST implement a mechanism limiting outgoing queries per user request (§2.3). Many labels and changing wildcard names can create excessive work. A cache can soften overhead but is not a substitute for that requirement.
- Resolvers supporting QNAME minimisation MUST implement a mechanism limiting outgoing queries per user request (§2.3). Many labels and changing wildcard names can create excessive work. A cache can soften overhead but is not a substitute for that requirement.
- One mechanism MAY append several labels in an iteration. For this mechanism select MAX_MINIMISE_COUNT; the RECOMMENDED value is10. Optionally select MINIMISE_ONE_LAB;4 is described as a good value. These are not universal fixed limits on all DNS packets, retries or additional address-resolution work (§2.3).
- The RFC’s18-label example adds1,1,1,1,2,2,2,2,3,3 labels across10iterations. Early small steps expose less near the top; distribute the remaining labels over the remaining iterations, adding division remainders to the last iterations (§2.3). The drawn spans represent actual counts of labels, not elapsed time or byte sizes.
- Another optional mechanism groups underscore-prefixed labels: after mail.example.org, the query can add _25._tcp together to form _25._tcp.mail.example.org (§2.3). This is an optional boundary assumption, not a new general DNS-name parsing rule.
- Stub or forwarding minimisation MAY reduce later exposure if an upstream resolver does not minimise, but cannot hide the request from that upstream. The recursive resolver sees the full stub request; the eventual authoritative server receives what it needs. Encryption addresses a different threat and is not supplied by this algorithm (§§2.4,6).
- The performance percentages and deployment observations in §§1.1,5 describe cited research at publication. We do not present them as current measurements or promise fewer queries for every lookup. Cached NXDOMAIN cuts can save work in some cases; cold caches and extra probes can add it (§5).
Documentation-domain examples. Suffixes, supplied response events and label budgets are bounded teaching models, not a DNS wire codec, validating resolver or live privacy measurement.
Read the RFC section ↗