Summary

  • An authenticated encrypted DNS session is a bounded transport receipt; it does not prove what a recursive resolver stores, correlates, shares, filters or sends upstream.
  • RFC 8932’s Recursive operator Privacy Statement makes those choices comparable, but a credible privacy claim still needs separate, time-bounded evidence for transport, processing, storage/access and onward disclosure.

A user changes one setting and the browser displays a familiar sign of safety. DNS is now travelling over TLS, HTTPS or QUIC to a named recursive resolver. A passive observer on the local network has lost an easy view of the questions. The client can authenticate the service. Those are material gains, not cosmetic ones.

Then the encrypted connection ends at the resolver.

On the far side of that endpoint, the operator can in principle see the query and the transport identifiers attached to its user. It can decide which fields to log, how long to keep them, who may read them, whether to correlate sessions, which answers to alter and what information to forward. None of those choices is visible in the padlock. Encryption has changed the observer on the path; it has not abolished the operator.

That is the useful boundary in RFC 8932, Recommendations for DNS Privacy Service Operators. Published in October 2020 as Best Current Practice 232, the document is collective work by Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij and Allison Mankin. Dickinson’s IETF profile lists the RFC among eight and records her as a chair of the Privacy Enhancements and Assessments Research Group. RIPE Labs identifies her as a co-founder of Sinodun IT. These records establish participation and sustained DNS work, not sole invention or control over any resolver deployment.

RFC 8932 does two things at once. It recommends operational practices for services offering encrypted DNS, and it proposes a Recursive operator Privacy Statement, or RPS. The RPS gives operators a common outline for saying what they do. It lets a reader compare measurable properties with claimed ones. It is deliberately not legal advice, a universal privacy policy or an automatic compliance certificate.

The distinction matters because “encrypted DNS” names only one part of a longer transaction.

The first receipt concerns the client-to-resolver transport. It can record the endpoint and authentication name, the protocol, certificate result, TLS or QUIC version, padding configuration, availability and any fallback to cleartext. RFC 8310 describes usage profiles for DNS over TLS; RFC 8484 defines DNS over HTTPS; RFC 9250 later defines DNS over dedicated QUIC connections. Each can protect the link to the resolver. None specifies that the operator must forget what arrives after decryption.

Transport also does not replace answer authentication. RFC 8932 is explicit that DNSSEC and encrypted transport solve different problems. For a client that does not validate DNSSEC itself, an authenticated encrypted connection proves neither that the resolver performed validation nor that the returned data was DNSSEC-authenticated. The client may still be trusting the resolver’s Authentic Data bit. A TLS certificate is therefore the wrong receipt for a DNSSEC claim.

The second receipt concerns processing inside the service. Which validation mode ran? Did the resolver alter an answer? Did an exception or threat policy fire? Which cache behavior applied? Did the service bind several sessions to one user through an IP address, a resumption token, an HTTP characteristic or a recurring query pattern? RFC 9076 notes that even encrypted queries and responses can sometimes be correlated with cleartext requests leaving a recursive resolver. A fixed encrypted resolver can make the visible counterparty predictable while also making one user easier to recognize across networks.

Filtering belongs in this processing record because it is an operator decision, not an encryption property. RFC 8932 asks an RPS to disclose whether answers are filtered or altered for network security, binding law, voluntary legal-risk policy, commercial reasons or anything else. It also asks how filter lists are created and which third-party sources feed them. “Secure DNS” can therefore describe a confidential channel and a modified answer at the same time. Readers need both facts.

The third receipt concerns storage and access. RFC 8932 recommends minimizing or avoiding retention. Where data must be retained, it recommends encryption and, where possible, aggregation, pseudonymization or anonymization. Log periods should be no longer than operational or regulatory need; access should be restricted to the personnel who require it.

Those are disciplined recommendations, but their verbs expose the evidence gap. A policy may say “seven days”; a deletion log can show that one scheduled purge completed. A role definition may say “operations only”; an access record can show which account opened a dataset. A cryptographic storage setting can show encryption at rest. None of those observations proves the others. Pseudonymization should not be casually renamed anonymization either: a stable substitute can preserve the linkability that makes long-term profiles possible, and some schemes can be reversed when the mapping or method is available.

The fourth receipt concerns data leaving the resolver. Recursive DNS normally sends questions towards other resolvers or authoritative servers. RFC 8932 recommends QNAME minimization so that each server is told less of the full name than it needs. RFC 9156 later updates that technique. The document also recommends avoiding EDNS Client Subnet where possible, or using the shortest operationally feasible prefix and clearly publishing the policy when ECS is sent.

This is where a service can protect the first hop yet leak detail on the second. An external test may observe that a particular query was minimized or that ECS was absent. That is valuable evidence with a time, vantage point and test case. It is not proof that every destination, forwarder and policy branch behaved the same way. Nor can it reveal an undisclosed data transfer after the query has been stored.

RFC 8932 therefore asks the RPS to cover more than a slogan. The policy portion should state whether IP addresses are treated as personal data; what is collected, retained, shared, sold or rented; the minimization methods and transfer conditions; exceptions; associated entities and funding; correlation with other personal information; and filtering. The practice portion should describe current client-facing transports and authentication, upstream behavior, deviations, support and relevant processing information.

The RPS is strongest when it is treated as a map of claims to evidence. A line saying “we minimize QNAMEs” can point to implementation configuration and an independent probe. A retention commitment can point to lifecycle controls and deletion results. A restriction on access can point to role policy and audited access events. A statement about third-party sharing can name the recipient, purpose, fields, term and expiry. Transparency reports and scoped third-party audits can test more of the map.

But the map is not the territory. An audit has a period, sample and scope. A probe has a vantage point. A transparency report is written by someone with defined access. A published RPS may lag a live configuration. The honest conclusion is not that privacy is unknowable; it is that each claim has a proper witness and a proper limit.

Dickinson and her co-authors gave operators a vocabulary for exposing those limits. The durable contribution is less glamorous than another padlock and more operationally useful. It moves the privacy question from “is the pipe encrypted?” to “who can make each decision after the query arrives, what evidence survives, and how quickly can the promise be checked?”

Sources