This table lists the best understanding of the current status of DNS-over-TLS related features in the latest stable releases of a selection of standalone open source DNS software.
Also see DNS Privacy Clients for a full list of OS, mobile apps, routers and browsers that support DoT.
If there are errors or glaring omission please email sara@sinodun.com
Also see guides on how to use NGINX and other proxies to provide DNS-over-TLS, also see here.
This works with a couple of provisos:
(1) Be aware that a client will think it is talking to a DNS-over-TLS server and so may keep connections open when idle even when not using EDNS0 Keepalive (as allowed by RFC7858 ). The nameserver will see only TCP connections which were historically used just for one-shot TCP and may not be robust to many long-lived connections.
(2) Therefore this will work much better if the nameserver has robust TCP capabilities (as described in Sections 6.2.2 and 10 of RFC7766), and would be required for production level service. Any server that fully implements EDNS0 Keepalive (RFC7828) should meet this criteria.
See the DNS Privacy Reference Material page for more details on the individual features.
| Mode | Stub | Caching forwarder/proxy | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Software | ldns (drill) | digit | getdns (Stubby) | BIND (dig) | Knot (kdig) | Go DNS | Unbound | BIND | Knot Res | dndist |
| Send ECS with SOURCE PREFIX-LENGTH value of 0 | Y | Y | Y | |||||||
| TCP fast open (a) | P | Y | Y | Y | Y | Y | Y | Y | ||
| Connection reuse (Q/R, Q/R, Q/R) | P | Y | Y | Y | Y | Y | Y | Y | Y | |
| Pipelining of queries(Q,Q,Q,R,R,R) | n/a | Y | Y | Y | n/a | Y | Y | Y | Y | Y |
| Process OOOR (Q1,Q2,R2,R1) | n/a | Y | Y | Y | n/a | W | Y | Y | Y | |
| EDNS0 Keepalive (b) | Y | Y | (c) | |||||||
| TLS encryption (Port 853) | P | Y | Y | Y | Y | Y | Y | Y | Y | |
| TLS authentication | Y | Y | Y | Y | Y | |||||
| EDNS0 Padding | Y | Y | Y | Y | Y | Y | ||||
| TLS DNSSEC Chain Extension (e) |
| Mode | Load Balancer | Recursive | Auth | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Software | dnsdist | Unbound | BIND | Knot Res | PowerDNS Recursive | CoreDNS(e) | Tenta(e) | NSD | BIND | Knot Auth | PowerDNS Auth |
| QNAME minimisation | n/a | Y | Y | Y | Y | Y | |||||
| TCP fast open(a) | Y | Y | Y | Y | Y | Y | Y | Y | |||
| Process Pipelined queries | Y | Y | Y | Y | Y | Y | Y | Y | |||
| Provide OOOR | (d) | Y | Y | Y | Y | n/a | n/a | n/a | |||
| EDNS0 Keepalive(b) | Y | Y | Y | Y | |||||||
| TLS encryption (Port 853) | Y | Y | Y | Y | Y | Y | Y | ||||
| Provide TLS auth credentials | Y | Y | Y | Y | Y | Y | |||||
| EDNS0 Padding (basic) | Y | Y | Y | (f) | Y | ||||||
| TLS DNSSEC Chain Extension(e) |
KEY:
(a) not yet available on Windows
(b) Implies robust TCP connection management (see RFC7828 and
RFC7766)
(c) Can be added to queries but the response is currently ignored.
(d) Supports OOOR but could be limited by the nameserver or
configuration used for recursion.
(e) RFC9102 Note this draft was published via the Independent Stream.
(f) This option adds padding to clear text queries to support running behind a DoT/DoH proxy such as dnsdist
Note pipelining/OOOP are not applicable (n/a) for some synchronous applications.
See the list of implementations maintained on the curl github site:
(1) Browsers and
Clients.
(2) Tools including various proxies (client and
server)
e.g dnscrypt-proxy, Facebooks experimental DoH proxy
| Mode | Load Balancer | Recursive | ||
|---|---|---|---|---|
| Software | dnsdist | Unbound | BIND | Knot Res |
| DoH support | Y | Y | Y | Y |
DoQ implementations are still in the early stages, the list below is an overview of the current status.
A matrix of the interoperability of various QUIC libraries is available here: https://interop.seemann.io
Note that as of March 2022 there is early, experimental support for QUIC as a base transport protocol (i.e. without HTTP/3) in both nginx and HAProxy but that during work at the IETF 113 Hackathon neither could be configured to be useable for DoQ.
There are some experimental implementation of this draft, a brief summary is given below.
This table is a work in progress - please notify us it updates/corrections are needed
This table reflects some of the current behaviour on implementations and also some features proposed in RFC9103. It is noted that some name servers will behave differently when starting up and first loading zones to steady state behaviour.
| Feature | BIND | NSD | Knot Auth | PowerDNS | ||||
|---|---|---|---|---|---|---|---|---|
| Features applicable to Secondary | Sec | Pri | Sec | Pri | Sec | Pri | Sec | Pri |
TCP: Typically performs AXFRs for different |
Y |
Y |
Y |
Y |
||||
| TCP: Typically performs IXFRs in parallel to AXFRs to the same primary using separate connections (in steady state) |
Y |
Y |
Y |
Y |
||||
| TCP: Connection re-use for XFRs to same primary is possible |
(a) | |||||||
| TCP: When re-using connections, will pipeline all XFR requests |
Y |
|||||||
| Handle empty AXFR responses | NT |
NT |
NT |
NT |
NT |
NT |
NT |
NT |
| Supports XoT | 9.18 | 9.18 | v4.3.7 | |||||
| Feature applicable to Primary | ||||||||
Handle pipelined XFR requests on one |
Y |
Y(b) | Y |
Y |
||||
| Always sends AXFR responses for different zones serially on the same connection (not intermingled) |
Y |
Y |
Y |
Y |
||||
Sends all AXFR/IXFR responses serially |
(d) | (b) | ||||||
| Handle sequential XFR requests on one connection for the same zone |
Y |
(c) | Y |
Y |
||||
| Default size of XFR response | ~20kB | 16kB | 16kB | 4-8kB | ||||
| Explicit configuration limit on num of concurrent XFRs | Y |
(e) | (e) | (e) | ||||
| Supports XoT | 9.18 | 9.18 | ||||||
KEY:
(a) Current release will re-use connections if the max outgoing TPC
connections is hit. This PR
provides a configuration option to make that behaviour the default.
(b) NSD does not support IXFR as a primary
(c) Because NSD requires a reload to update a zone, an old version of
the zone will currently be sent on a TCP connection opened before the
reload. A fix/workaournd is proposed.
(d) e.g. If BIND receives an IXFR request whilst sending a large AXFR
response, it will send the IXFR response immediately intermingled with
the AXFR response.
(e) Whilst there is no limit explicitly for XFRs, the primary has a
configuration option to limit the total number of incoming TCP
connections
(defaults for relevant limits are: BIND - 25, NSD - 100, Knot - one
half of the file descriptor limit for the server process, - PowerDNS
20
(g) See this issue for
progress. Support
was added in development release 9.17.10