Summary

  • RFC 9606 gives resolvers one authoritative RESINFO record for claims such as QNAME minimisation, supported Extended DNS Error codes and an HTTPS diagnostic page.
  • An authenticated resolver connection or local DNSSEC validation protects the answer from third-party forgery; it does not independently verify that each advertised behavior occurred.
  • Selection policy, reputation, anycast consistency, per-query observation and downstream service outcome remain separate receipts.

The cleanest answer contained the hardest caveat

Imagine a fleet-selection system testing a newly discovered encrypted resolver. It sends a RESINFO query with recursion disabled. The answer has the authoritative bit set. The secure connection authenticates the resolver's domain. The RRset contains exactly one well-formed record: qnamemin, a range of Extended DNS Error codes and an HTTPS help page.

The inventory now has excellent evidence of who made the declaration. It still has no trace showing which labels an authoritative server saw, no blocked query paired with the promised diagnostic code, and no proof that another anycast instance would answer the same way.

This is not a defect in RFC 9606. It is the standard's most important boundary. RESINFO standardises self-description so clients do not have to guess capabilities from opportunistic behavior. It also says an encrypted resolver may return incorrect information. Authentication can bind a statement to its speaker without making the statement true.

Three receipts precede the first capability claim

The exchange begins before RESINFO. DNR or DDR can discover an encrypted DNS resolver and an Authentication Domain Name. Discovery identifies a candidate and the name used to authenticate it. It does not yet say which optional privacy or filtering features are active.

The client then queries RESINFO for that ADN. If DDR uses resolver.arpa, the same special name can be queried. The client sets RD to zero because resolver information belongs to the resolver itself and must not be recursively fetched. It rejects a response with AA cleared. A supporting resolver returns exactly one record; malformed records are ignored.

These controls answer concrete questions. Which resolver was addressed? Was the reply presented as authoritative rather than recursive data? Did the syntax fit the shared format? A secure authenticated connection or local DNSSEC validation then protects against an intermediary forging the response. For resolver.arpa, only the authenticated-connection method applies.

None of those checks observes the resolver executing QNAME minimisation or filtering. They establish custody of a declaration. That is already valuable, provided an operator does not promote custody into performance.

qnamemin is a configured intention, not a packet transcript

The first initial key is presence-only. qnamemin says the resolver is configured to minimise privacy-sensitive query-name data sent to authoritative servers under RFC 9156. It is deliberately compact. It does not contain a query, a cache state, a delegation walk, an exception, a fallback or the authoritative server's observation.

A meaningful behavior test needs those missing coordinates. Start with a controlled name and a known cache condition. Record the resolver instance and time. Observe the queries at authoritative servers for successive zones. Compare the labels exposed at each step with the expected minimisation algorithm. Repeat after configuration or software changes.

Even that test remains scoped. One successful trace does not certify all names, all cache paths or all future instances. But it is qualitatively different from the self-description: the record states intention; the trace witnesses execution.

exterr advertises a vocabulary, not the justice of a decision

The exterr value lists Extended DNS Error codes the resolver can return. A range containing Blocked, Censored and Filtered tells a client that the resolver is configured to explain certain policy outcomes when they occur. It does not promise that every blocked answer will carry an EDE, that the policy was authorized, that the classification was accurate or that the application will surface the reason.

RFC 9606 supplies a particularly useful audit edge. If a client receives an EDE absent from the advertised set, it can query RESINFO again. A persistent mismatch identifies inaccurate resolver information and permits the client to discard it. Here running behavior corrects the symbolic inventory.

The inverse needs care. An advertised code that never appears may mean no triggering event occurred. It may mean the feature is dormant, the test is incomplete or the declaration is stale. Absence of an observation is not automatically evidence of deception. Test design must create a controlled condition and preserve the answer, EDE, policy expectation and time.

The help page is deliberately not a policy oracle

infourl points to generic operational information and problem-reporting instructions. The URL must use HTTPS; invalid values are ignored. RFC 9606 limits the surface to diagnostic use by IT staff and says it is not intended for end-user consumption.

That distinction prevents a convenient support page from becoming a silent consent mechanism. HTTPS authenticates and protects the connection to the named information server. It does not make prose complete, current or enforceable. A reporting procedure is not proof that reports are resolved. A description of filtering is not a machine-verifiable policy. The URL belongs in an operator's evidence bundle, not in the column labelled observed behavior.

Anycast turns one correct receipt into a sampling problem

Resolvers sharing an ADN or anycast address should expose consistent RESINFO. The word “should” matters operationally. A shared name can lead different clients, or the same client at different times, to different instances. One instance may have received a configuration update while another still serves the earlier record. Routing can change the reached instance between the declaration query and the behavior test.

The measurement record therefore needs a vantage, destination, resolved endpoint where observable, transport session, collection time and repeated sample. When the same ADN yields different RESINFO answers, the disagreement is the finding. It should not be averaged into one fictional resolver profile.

Consistency of the record is still narrower than consistency of behavior. Two instances can publish identical qnamemin keys while running different code paths. Conversely, temporarily different records may accompany equivalent execution. The inventory and the test results need separate version histories.

Reputation is a local decision, not a field inside the record

RFC 9606 acknowledges that some attributes cannot be directly validated at selection time. It advises processing them only when the encrypted resolver has sufficient reputation under local policy. That reputation may come from the user, an administrator or a built-in list.

This is where authority returns to the client. The IANA registry standardises names. The resolver authors a claim. The secure channel identifies the claimant. Local policy decides how much reliance the claim earns. No registry entry or authenticated response compels selection.

Heng Lu's minimum-specification discipline fits this division. The common layer should make declarations comparable without centralising the later decision. A client can demand measurements, prefer another resolver, tolerate a gap for one network or reject unverifiable filtering claims. Voluntary adoption survives because the shared format does not confiscate the selector.

Sources