ADoX is used here as a short hand term for ‘Recursive resolver to Authoritative server encrypted transport using DoT or DoQ’.
The term ADoT was defined in RFC 9499: DNS Terminology:
“Authoritative DoT (ADoT): … ADoT specifically means DNS-over-TLS for transport between recursive resolvers and authoritative servers”
DoQ was also standardized for transport between recursives and authoritative servers in RFC 9250, so by extension ADoQ means “DNS-over-QUIC for transport between recursive resolvers and authoritative servers”.
Since ADoT/Q is hard to say, we use ADoX (‘a-docks’) here to mean encrypted transport using either TLS or QUIC!
A meeting was held to evaluate the current activities around and interest in deployment of ADoX. The minutes can be found here.
There is a public OARC Mattermost channel for ongoing discussions on this topic
The DPRIVE working group at IETF was chartered to work on encrypting the stub to recursive communications from its creation in 2014 until 2018, when it was re-chartered to include working on the recursive resolver to authoritative server problem.
Between 2018 and 2021 at least 6 solutions and at least 12 drafts were discussed in the working group to try to find a solution that enabled authoritative servers to securely publish credentials in the DNS that recursive resolvers could then use to authenticate encrypted connections to those servers.
Unfortunately no solution found consensus due to several hurdles:
As a result, work stopped in DPRIVE in around 2021 on this and attention turned to trying to standardise an opportunistic model that could be used for experimentation (see below).
Acknowledging the multiple restrictions that the current delegation model posed on the DNS protocol as whole, the IETF created the DELEG working group in 2024. It is hoped that work from that group will provide an mechanism to specify authenticated encryption credentials at the delegation point to be deployed within the DNS.
RFC 9539 - Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS is now published was published in February 2024.
This document sets out steps that DNS servers (recursive resolvers and authoritative servers) can take unilaterally (without any coordination with other peers) to defend DNS query privacy against a passive network monitor by directly probing port 853 to see if an authoritative servers supports encrypted transports.
A new Internet Draft was first published in June 2025 proposing a new mechanism based on SVCB records Authoritative DNS Transport Signaling:
This document proposes a mechanism for authoritative DNS servers to opportunistically signal their support for alternative transport protocols (e.g., DNS over TLS (DoT), DNS over HTTPS (DoH) and DNS over QUIC (DoQ)) directly within the Additional section of authoritative DNS responses. This “hint-based” approach aims to enable resolvers to discover and upgrade transport connections more efficiently, thereby improving privacy, security, and performance for subsequent interactions.
The authors have an open source prototype implementation https://github.com/johanix/tdns and would love feedback. This was discussed in the DNSOP meeting at IETF 123 and seems to be gaining support.
| Feature | Recursives | Load Balancer/proxy | Authoritatives | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Software | Unbound | BIND | Knot Resolver | PowerDNS Recursive | dnsdist | NSD | BIND | Knot Auth | PowerDNS Auth (1) | |||
| Unilateral probing | Prototyping at IETF Hackathon |
Experimental implementation |
||||||||||
| Other discovery | Experimental auto discovery |
|||||||||||
| DoT | Y | Y | Y | Y | ||||||||
| DoQ | Y | Y |
This table is a work in progress and some entries require references and/or more details. Please send updates/corrections to sara@sinodun.com
| Who | What |
|---|---|
| b-root | Have enabled DNS over TLS support |
| Did a pilot back in 2018 and are observed to have DoT enabled on port 853 today | |
| deSEC | Announced on the DPRIVE mailing list that they have support for DoT and DoQ on our authoritative anycast deployments. |
| CDN77 | Observed to have DoT enabled on port 853 today |
| ccTLDs | A few small TLDs e.g. .gr, .co, .kg are observed to have DoT enabled on port 853 today |
| Who | What |
|---|---|
| Google Public DNS | Have said they have implemented RFC9539 and “And ADoT is in use for around 6% of egress traffic.” |
| Quad9 | Use PowerDNS Recursor and enabled RFC9538 probing in July 2025 |
| Let’s Encrypt | Are sharing plans to enable DoX from their Hickory recursive resolver to a set of auth servers that are known to support encrypted transports |