DoT Implementation Status

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:

  • 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.
  • 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. 

Clients/Forwarders

Mode

Stub 

Caching forwarder/proxy

Software

ldns

(drill)

digit

getdns

(Stubby)

BIND

(dig)

Go
DNS 

Knot

(kdig)

UnboundBIND

Knot Res

dndist
GeneralSend ECS with SOURCE PREFIX-LENGTH value of 0 

(tick)(tick)
(tick)





TCP/TLS Features

TCP fast open(b)
(tick)

(tick)




(tick)(tick)
(tick)
Connection reuse (Q/R, Q/R, Q/R)
(tick)

(tick)

(tick)(tick)(tick)(tick)(tick)(tick)(tick)

Pipelining of queries(Q,Q,Q,R,R,R)

n/a(tick)

(tick)

(tick)(tick)(tick)(tick)(tick)(tick)(tick)
Process OOOR (Q1,Q2,R2,R1)n/a (tick)

(tick)

(tick)

(tick)(tick)(tick)
EDNS0 Keepalive(c)

(tick)(tick)



(f)



TLS Features

TLS encryption (Port 853)
(tick)(tick)
(tick)(tick)(tick)(tick)(tick)
TLS authentication

(tick)

(tick)(tick)(tick)(tick)
EDNS0 Padding
(tick)(tick)(tick)
(tick)
(tick)

TLS DNSSEC Chain Extension(h)










Servers

ModeLoad BalancerRecursiveAuth
Softwarednsdist

Unbound

BIND

Knot

Res

CoreDNS(e)Tenta(e)NSDBIND

Knot

Auth

GeneralQNAME minimisationn/a(tick)(tick)(tick)





TCP/TLS Features

TCP fast open(b)(tick)(tick)(tick)(tick)

(tick)(tick)(tick)

Process Pipelined queries

(tick)(tick)(tick)(tick)

(tick)(tick)(tick)
Provide OOOR(g)(tick)(tick)(tick)

n/an/an/a
EDNS0 Keepalive(c)
(tick)(tick)(tick)


(tick)



TLS Features

TLS encryption (Port 853)(tick)(tick)(tick)(tick)(tick)(tick)(tick)

Provide TLS auth credentials(tick)(tick)(tick)(tick)(tick)(tick)


EDNS0 Padding (basic)

(tick)(tick)


(tick)
TLS DNSSEC Chain Extension(h)









KEY:

  • Green square (tick) - indicates latest release already supports this functionality
  • Blue square - indicates that a patch is available in our git repo. See here for details: DNS-over-TLS patches
  • Yellow square - indicates work in progress, or availabe in next release
  • P - Requires building against a patched version of libunbound


(a)    getdns uses libunbound in recursive mode
(b)    not yet available on Windows 
(c)    Implies robust TCP connection management (see RFC7828 and RFC7766)
(e)    Full list of supported features to be confirmed
(f)    Can be added to queries but the response is currently ignored.
(g)    Supports OOOR but could be limited by the nameserver or configuration used for recursion.
(h)   This is no longer an active draft in the TLS working group. 

Note pipelining and OOOP are not applicable for synchronous applications. 

Other implementation work

DOH Implementation status

The picture for DOH implementation is move very rapidly. Some work to date

See the list of implementations maintained on the curl github site: 

  • For work done at the IETF 101 Hackathon see the DOH Hackathon presentation
  • We also maintain a list of some DOH clients (includes web browsers)
  • And below is the state of DoH implementation is well know open-source DNS recursive resolvers/load-balancers
ModeLoad BalancerRecursive
Softwarednsdist

Unbound

BIND

Knot Res

DoH support(tick)(tick)

WIP (H1 2021)

(tick)


XFR/XoT Implementation status

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 draft-ietf-dprive-xfr-over-tls. It is noted that some name servers will behave differently when starting up and first loading zones to steady state behaviour. 

Feature BINDNSDKnot AuthPowerDNS
Features applicable to SecondarySecPriSecPriSecPriSecPri

TCP: Typically performs AXFRs for different
zones in parallel to the same primary using
separate connections (in steady state)









TCP: Typically performs IXFRs in parallel to AXFRs
to the same primary using
separate connections (in steady state)








TCP: Connection re-use for XFRs
to same primary is possible


(a)




TCP: When re-using connections, will pipeline
all XFR requests 








Handle empty AXFR responses







Supports XoT (g)
(f)




Feature applicable to Primary







Handle pipelined XFR requests on one
connection for different zones




(b)



Always sends AXFR responses for different zones serially
on the same connection (not intermingled)








Sends all AXFR/IXFR responses serially
on the same connection


 (d)
(b)



Handle sequential XFR requests on one
connection for the same zone



(c)












Default size of XFR response
~20kB
16kB

Up to
65kB


4-8kB
Explicit configuration limit on num of concurrent XFRs


(e)
(e)
(e)
Supports XoT(g)






KEY:

  • Green square (tick) - indicates latest release supports this functionality
  • Blue square - indicates that a patch or PR is available
  • Yellow square - indicates work in progress, or available in next release.
  • Red square - not tested yet, or cannot be tested.

(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
(f) See the PR.
(g) See this issue for progress.


  • No labels

4 Comments

  1. Anonymous

    According to http://ftp.isc.org/isc/bind9/9.12.0b1/RELEASE-NOTES-bind-9.12.0b1.html Bind 9.12 should support EDNS0 Padding Option. Not market yellow with "9.12" in table bind in recursive mode.

    1. Thanks for spotting - fixed!

  2. Anonymous

    What do the asterisks on "TCP fast open**" and "EDNS0 Keepalive***" indicate?

    1. They should have been (b) and (c) as in the top table. Fixed and thanks.