OARC 45 Hears Why Encrypting the DNS Resolver-to-Authoritative Hop Has Stalled

The Domain Name System (DNS), often described as the internet's phonebook, translates human-friendly domain names into the numerical IP addresses computers use. Almost every online activity begins with a DNS query, and if someone can observe all your DNS queries, they can build a detailed picture of your online life. For years this privacy weakness attracted little attention, but the Snowden revelations in 2013 put mass surveillance and DNS privacy firmly on the agenda. By default, DNS queries and responses travel in plain text, which makes them vulnerable to eavesdropping and manipulation by anyone in the network path.

To address this, the Internet Engineering Task Force (IETF) developed encrypted DNS protocols: DNS over TLS (DoT), DNS over QUIC (DoQ), and DNS over HTTPS (DoH), collectively known as DoX. These add encryption and server authentication to the link between a user's device (the 'stub resolver') and a recursive resolver, the server that does the actual legwork of finding DNS answers. Setting up an encrypted session adds overhead compared to a plain UDP query, but because the device can reuse the same encrypted session for many queries, the cost is amortised. Geoff Huston notes that at Cloudflare's 1.1.1.1 public resolver, DoH accounts for about 15% of query load and DoT about 10%, although he suspects the numbers are much lower for ISP-run resolvers where the user is already on the ISP's network.

However, this only covers the first hop. The second hop is between the recursive resolver and the authoritative name servers that hold the official records for a domain. This leg is less of an individual privacy risk because the user's IP address is not included in the query, but there is still exposure: queries reveal which domain is being looked up, and if an attacker can alter a response, they can poison the recursive resolver's cache so it serves false answers to many users until the cache expires, an attack known as cache poisoning. One mitigation is Query Name Minimisation (RFC 9516), where the recursive resolver sends only the minimum necessary labels to each authoritative server during the discovery process and may hide the original query type. A 2020 measurement study found that about 18% of internet users passed their queries through recursive resolvers that performed Query Name Minimisation.

Another approach is opportunistic encryption of the recursive-to-authoritative hop, described in RFC 9539 'Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS'. This uses encryption without authentication, following the principle of opportunistic security in RFC 7435. A recent study presented at OARC 46 measured support for opportunistic Authoritative DNS over encrypted transport (ADoX). It found that authoritative servers for 3,074,281 registered domains (0.93%) support some form of ADoX, and looking at the IP addresses of those nameservers, only 2,585 unique nameservers (0.32%) support ADoX. A comparable study using RIPE Atlas probes found no recursive resolvers using ADoQ and only 44 probes behind recursive resolvers that used ADoT, mostly operated by the Quad9 open resolver service. In practice, deployment has stalled: authoritative server operators see little benefit in supporting ADoX if no resolver uses it, and the incremental server costs for encrypted sessions are much higher than stateless UDP. Recursive resolvers see no reason to support ADoX if no authoritative servers support it.

The opportunistic approach has clear downsides. It takes several round-trip exchanges to attempt a TLS/TCP or QUIC connection with an authoritative server; for a single query, that overhead is higher than a simple UDP transaction. Unlike the stub-to-resolver case, there is no certainty of session reuse: the resolver may never query that authoritative server again. Also, because the server is not authenticated in opportunistic encryption, an attacker could still act as a man in the middle; DNSSEC validation of signed domains is needed to confirm the authenticity of answers. On the upside, encrypted transport can handle large responses better and enables experimental approaches like CHAIN Query Requests (RFC 7901).

A different approach uses the proposed DELEG resource record to signal a server's encrypted transport capabilities. DELEG builds on the Service Binding (SVCB) format and is not a minor tweak; it represents a major architectural change. In a DELEG record, the parent zone includes information that a label is a delegation point, along with the delegated zone's nameservers, their cryptographic keys, IP addresses, and protocol capabilities, all in one DNSSEC-signed record. For a resolver, DELEG can communicate in a strict manner which encrypted transport the authoritative servers support, so the resolver can skip opportunistic probing and simply use the advertised protocol. However, Huston points out that DNSSEC validation only guarantees the authenticity of the final DNS response; it does not guarantee that the resolver actually traversed from parent to child or that each DELEG delegation was independently validated. There were warnings at the OARC workshop that shifting the entire DNS from lightweight UDP to encrypted sessions could have 'catastrophic consequences' if done hastily.

So is this work more than an academic exercise? Right now, the specifications for opportunistic ADoX and DELEG are mostly paper exercises. The internet's current framework for authenticating online transactions relies on X.509 domain name certificates and TLS, not on assurance of DNS resolution outcomes. An attacker can still inject false DNS information, but when an application service uses TLS (for example HTTPS), the server must prove it holds the private key for the domain name; if it cannot, the connection is abandoned. ADoX or DELEG does not change that picture. They also cannot substitute for DNSSEC; the two solve different problems: ADoX is about how a resolver resolves a name, while DNSSEC is about whether a user can trust the result. They are complementary.

A security purist would want strict controls at every step: validate signed DELEG records, open encrypted and endpoint-authenticated sessions with every authoritative server, and DNSSEC-validate the final answer. But the pragmatic reality is that users and service providers favour fast, cheap DNS. The authentication function is pushed to the application layer via the TLS handshake, and DNS infrastructure operators bear none of the incremental costs. Attempting to push assurance costs back onto the name resolution infrastructure meets considerable resistance. In other words, the DPRIVE agenda stopped at the recursive-to-authoritative hop because there was insufficient interest in running that infrastructure model.

What is the future for encrypting the recursive-to-authoritative hop? Huston is not sure he can point to any assured future. The economics work