ADoX Status and Deployment

What is ADoX?

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!

IETF 123 ADoX Deployment initiative (July 2025)

A meeting was held to evaluate the current activities around and interest in deployment of ADoX. The minutes can be found here.

Standards work

A bit of history

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:

  • Primarily the fundamental technical issue that delegations (NS and glue records) are not DNSSEC signed and therefore secure credentials cannot be provided before a recursive resolver first attempts to connect the nameserver authoritative for the zone.
  • Any change to this model would require protocol changes in the DNS, updates to the EPP provisioning protocol and therefore updates to registrar processes which were likely to take many, many years to deploy.
  • Although several clever workarounds to try to overload/re-use existing records were proposed, none could find consensus due to one or more serious drawbacks.

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 Probing

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.

Internet Draft: Authoritative DNS Transport Signaling

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.

Implementation Status

Open source implementation overview

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
  • PowerDNS Resolver 4.7.0 supports an experimental version of this “The implementation does not follow the existing draft to the letter, but was strongly inspired by it.” More here.
  • Knot resolver implements a custom auto-discovery feature based on an nameserver name format
  • (1) PowerDNS Auth does not implement any encrypted transports natively, but the same organisation develops dnsdist for use as load balancer/proxy to terminate encrypted connections

Operator activities

This table is a work in progress and some entries require references and/or more details. Please send updates/corrections to sara@sinodun.com

Auth operators

Who What
b-root Have enabled DNS over TLS support
Facebook 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
  • PCH have discussed that they would like to enable this for customers in the near future.
  • IBM are doing an internal proof-of-concept using ADoT and would like to offer this publicly in the future.
  • Cloudflare are open to experiments using ADoX

Recursive operators

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
  • DNS4EU have expressed being open to enabling ADoX but currently use Knot resolver which does not support it.