skip to content

Without QNAME minimisation, what does a recursive DNS resolver reveal to root and TLD servers, and how does RFC 9156 change what each server sees?

level: seniorimportance: nice to knowfreq 16%

answer

  1. need to know, per server
  2. one label past the cut
  3. hide the type as well
  4. more queries on a cold cache
  5. the resolver still sees everything

basics

~20 s

Traditionally every server on the path receives the full name and query type. Under RFC 9156 the resolver sends each server only one label more than the zone it serves, with a neutral type such as A.

solid answer

~50 s

In a traditional walk the recursive resolver sends the **full QNAME and original QTYPE** to the root, the TLD and the authoritative server, although only the last one needs them. **QNAME minimisation** (RFC 9156, Standards Track, which obsoletes the Experimental RFC 7816) sends a server not known to be authoritative for the full name only the name "stripped to just one label more than the longest matching domain name" it serves, and a QTYPE chosen to hide the real one; A or AAAA are recommended, where RFC 7816 had suggested NS. Because zone cuts need not sit at every label, a cold resolver probes label by label, so it sends more queries; RFC 9156 therefore **requires** a limit on outgoing queries per request and recommends 10 minimising iterations. It changes no protocol, so a resolver can deploy it alone, and it offers **no protection from the recursive resolver itself**.

code

pseudocode · 16 lines
pseudocode
# simplified from RFC 9156 section 3 (no DS case, no cache check per step)
ancestor = closest cached delegation for qname
child = ancestor
loop:
  if child == qname:
    reply = ask(ancestor.servers, qname, original_qtype)
    return reply                      # restart from the top on a CNAME
  child = child + next label(s) of qname  # budget: MAX_MINIMISE_COUNT
  reply = ask(ancestor.servers, child, A)
  if reply is referral:
    cache(reply.ns); ancestor = closest cached delegation for qname
    child = ancestor
  else if reply is NXDOMAIN:
    return NXDOMAIN                   # resolver applying RFC 8020
  else:
    cache(reply)                      # NOERROR or NODATA: no cut here

go deeper

for a junior

Recall that a normal lookup tells every server on the path the full name, and that minimisation sends each only what it needs to refer onward.

for a middle

Explain which part of the name each server receives, why a neutral type such as A is used, and why a cold cache costs extra queries.

for a senior

Show the operational edges: the mandatory query cap, early stops on NXDOMAIN, failures caused by servers that answer NXDOMAIN for empty non-terminals, and what it leaves exposed.

for a principal

Weigh the privacy gain against extra upstream load and a small failure rate, and place it beside encrypted transport as a complementary rather than competing control.

## What leaks in a traditional walk RFC 9156 starts from a simple observation: "The full QNAME and original QTYPE are only needed at the name server that is authoritative for the record requested by the client." Yet a traditional resolver sends every server on the path the whole question. For a cold-cache lookup of the IPv6 address of `www.example.org`: | Server asked | Traditional query | Minimised query | |---|---|---| | Root server | `www.example.org`, AAAA | `org`, A | | `org` server | `www.example.org`, AAAA | `example.org`, A | | `example.org` server | `www.example.org`, AAAA | `www.example.org`, A (checks whether `www` is delegated) | | `example.org` server | (none) | `www.example.org`, AAAA | With minimisation, the root operator learns only that someone is resolving something under `org`, and the `org` operator only that it concerns `example.org`. The price in this example is one extra query, because the real type differs from the hiding type; had the client asked for `A`, the third and fourth rows would merge, as RFC 9156's own examples note. ## How the resolver chooses the name and type - **Name**: RFC 9156 sends "the original QNAME, stripped to just one label more than the longest matching domain name for which the name server is known to be authoritative". That is enough for the server to answer with a delegation. - **Type**: any data type whose authority always lies below the zone cut, with no relation to the real type. RFC 9156 relaxed RFC 7816's advice to use NS, noting that the parent side answers with a referral whatever the type. **A or AAAA** are recommended because they are "the least likely to raise issues" in software and middleboxes, and they blend into ordinary traffic. - **Exception**: a type whose authority lies at the parent side, such as DS, is sent to the parent's servers with the full name. ## Unknown zone cuts and the query budget Zone cuts do not have to exist at every label. In `www.foo.bar.example` there might be a cut between `foo` and `bar` but not between `bar` and `example`, so a cold resolver must probe: ask for one more label, get a non-referral answer, add a label, ask again. RFC 9156 section 3 turns this into an algorithm: 1. Answer from the cache if possible. 2. Take the closest cached delegation for the name. 3. If the name being probed equals the full name, send the original query to that delegation's servers. 4. Otherwise add the next label or labels and query with the hiding type. 5. On a referral, cache it and restart from the new delegation; on a NOERROR or NODATA answer, add another label; on NXDOMAIN, a resolver that applies RFC 8020 stops. Because a name with many labels can force one query per label, RFC 9156 says resolvers "MUST implement a mechanism to limit the number of outgoing queries per user request". It describes a cap on minimising iterations, **MAX_MINIMISE_COUNT**, with a recommended value of 10, and an optional **MINIMISE_ONE_LAB**, the number of iterations that add one label each, for which it calls 4 "a good value"; the remaining labels are spread over the remaining iterations, several at a time for a deep name. ## The side benefit: stopping at the first nonexistent name RFC 8020 says that after an NXDOMAIN a resolver should treat every name below that node as nonexistent. Combined with minimisation, a resolver asked about `a.example`, `b.example` and `c.example`, where `example` is not a top-level domain, asks the root once, caches the NXDOMAIN and answers the rest from it. RFC 9156 notes this can make the query count "counterintuitively less" than traditional iteration. ## What it costs and what can break - **More queries on a cold cache.** RFC 9156 cites research finding up to 26% more lookups and up to 5% more failed lookups; a warm cache softens this. - **Query storms.** Random deep labels under a wildcard can drive one upstream query per label, which is why the cap is mandatory. - **Servers that answer NXDOMAIN for empty non-terminals.** RFC 8020 says a name that has children but no records of its own must get NODATA. A server that wrongly answers NXDOMAIN makes a minimising resolver that applies RFC 8020 stop early and fail a name that exists. ## What it does not protect RFC 9156 is explicit: minimisation "offers no protection against the recursive resolver, which still sees the full request coming from the stub resolver". The final authoritative server also sees the full name, since it must answer it. Stub and forwarding resolvers **may** minimise, but that hides nothing from their upstream resolver and, without their own zone-cut discovery, "will drastically increase the number of outgoing queries". Encrypting the query is a separate measure, covered with resolver privacy.

  • Why did RFC 9156 stop recommending the NS type for QNAME-minimised DNS queries?
    RFC 7816 had suggested NS. RFC 9156 notes that the parent side of a delegation answers with a referral whatever the type, so NS adds nothing, while A or AAAA are least likely to trip software and middleboxes that mishandle unusual types and blend in with ordinary traffic. NS remains allowed.
  • Can QNAME minimisation reduce the number of queries a DNS resolver sends?
    Yes, in one common case: many queries under a top-level domain that does not exist. Traditionally each full name goes to the root and earns its own NXDOMAIN; minimised, the resolver asks about the TLD once, caches the NXDOMAIN and, applying RFC 8020, answers the rest from the cache.
  • Does a stub resolver gain privacy by minimising its own DNS queries?
    Not from its upstream resolver: RFC 9156 section 2.4 notes all the information ends up there anyway. It can limit exposure between that resolver and authoritative servers when the upstream does not minimise, but without its own zone-cut discovery and caching it greatly increases the number of queries.

saying these in an interview costs you the question

  • QNAME minimisation hides the queried name from the recursive resolver.
  • Authoritative servers must be upgraded before a resolver can minimise.
  • RFC 9156 requires the minimised queries to use the NS type.
  • QNAME minimisation encrypts the name between the resolver and the root.
  • Minimising always reduces the number of queries a resolver sends.