Authoritative DNS over encrypted transport at OARC 45

8organicbits1 pts0 comments

Authoritative DNS over encrypted transport at OARC 45 | APNIC Blog

Skip to content

Skip to the article

Image by Black_Hole_Agency from Pixabay.

The DNS Operations, Analysis, and Research Center (DNS-OARC) met for two days in Edinburgh in May 2026. The topic of using encrypted DNS transports for communication between recursive resolvers and authoritative services in the DNS was discussed at this meeting, and I’d like to share my impressions of this work.

Much has been said about the use of the DNS to track the online behaviour of individual users, and for online censorship and control. Almost every online transaction starts with a DNS query, and with the complete set of DNS queries generated by an individual user, it would be possible to assemble a relatively complete profile of their online activity.

For many years, the use of DNS to observe the activities of others received little attention. The release of the Snowden papers in 2013 raised the prominence of sensitivities over state and private digital mass surveillance. This episode brought significant attention to the topic of DNS privacy, as the DNS name resolution protocol has been sadly lacking in some basic protections. By default, DNS queries and responses are in the clear, which makes the DNS prone to hostile man-in-the-middle manipulation and eavesdropping.

Stub to recursive

There have been some responses to try to mitigate these DNS privacy issues. One is to make eavesdropping and manipulation harder by using encryption for DNS transactions. The DNS Privacy Working Group of the IETF (DRPIVE) generated several specifications that introduced channel encryption and remote server authentication through DNS over Transport Layer Security (DoT), DNS over QUIC (DoQ) and DNS over HTTPS (DoH), collectively referred to as ‘DoX’.

Compared to a simple UDP transaction, the overheads of setting up a TCP session and then establishing an encrypted session context are high, even if you combine these two tasks with QUIC. This would be an unsustainable overhead if the stub resolver was not able to reuse this session for all of its queries to the recursive resolver. Because it can, the cost of the initial session establishment can be amortised over all subsequent queries. What remains is the tradeoff between:

Encryption and decryption

The avoidance of UDP fragmentation, DNS truncation, and TCP follow-up

These DoX tools apply to the connection between the ‘stub’ resolver operated in the user’s environment and the recursive resolver. They can be applied when the recursive resolver is operated by the user’s Internet Service Provider (ISP) (though the net change in the security stance is minimal, as the ISP is already in a privileged position with respect to the user’s traffic). They make much more sense when the user uses a remote open resolver, passing DNS traffic across open Internet segments. In the traffic profile of a large open DNS recursive resolver, the use of DoH and DoT is significant, at 15% and 10% of the query load as seen by Cloudflare’s 1.1.1.1 service. While I do not have access to data from large-scale retail ISPs’ recursive resolvers, I suspect that the DoX query levels are much smaller in that localized context.

Recursive to authoritative

However, this is just one part of the DNS privacy story. The second part is the DNS traffic between the recursive resolver and DNS authoritative servers.

Arguably, this second part is less of an individual privacy concern, as the end user’s identity (in the form of the user’s current IP address) is not carried in these queries. However, there is still some information exposure, both in the queries themselves and in the possibility of response interception or response substitution. It’s still a privacy and resilience problem, but different to the stub-to-recursive step. If an attacker can successfully alter a response from an authoritative server, it will be loaded into the recursive resolver’s cache, and then will be used to answer subsequent stub queries for the ensuing cache lifetime (commonly termed ‘cache poisoning’).

An approach to reducing the information exposure risk in the recursive-to-authoritative path is to perform DNS Query Name Minimisation (RFC 9516, ‘DNS Query Name Minimisation to Improve Privacy’, November 2021). Here, during the process of nameserver discovery, each authoritative nameserver is presented with a query name that is stripped to just one label more than the longest matching domain name for which the nameserver is known to be authoritative. A QTYPE is selected by the resolver to possibly obscure the original query’s QTYPE. This has proved to be quite popular in DNS recursive resolvers, and a measurement study performed in 2020 indicated that 18% of the Internet user population passed their queries through recursive resolvers that performed Query Name Minimisation.

Another approach is described in RFC 9539, ‘Unilateral Opportunistic Deployment of Encrypted...

recursive resolver authoritative query queries user

Related Articles