This page is mainly focussed on following the development and deployment of DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH) as the leading solutions for DNS Privacy because they are the only protocols currently standardized by the IETF.
Some history and background on other alternatives are outlined below and we intend to follow other solutions as they evolve.
See our Implementation Status page to see the current status of each solution.
RFC7858 specified DNS-over-TLS as a Standards Track protocol in May 2016 with a port assignment of 853 from IANA. There is active work in this area.
There are now multiple implementations (including Stubby a local DNS Privacy stub resolver) and a number of experimental and public servers deployed.
RFC8484 specifies DNS-over-HTTPS as a Standards Track protocol on October 2018.
There are several implementations (including Firefox) and deployments. Note that with DoH it is possible to intermingle DNS and HTTP traffic on the same port 443 connection and make blocking of encrypted DNS harder. It should be noted that this RFC addresses almost purely protocol issues, there is no dynamic discovery mechanism for DoH specified yet so it cannot be done opportunistically (it must be configured).
A draft was submitted in April 2017 to the IETF QUIC Working group on DNS-over-QUIC.
QUIC is a particularly good fit for encrypted DNS and this specification defines it as a ‘genearl-purpose’ transport, in other words it explicitly includes using DoQ for recursive to authoritative queries.
RFC9103 specifies how to encrypt zone transfers to prevent zone content collection via passive monitoring. The above DoQ RFC also specifies that DoQ can be used for zone transfer encryption.
RFC8094 specified DNS-over-DTLS as an Experimental Standard in Feb 2017. To our knowledge that are no implementations of DNS-over-DTLS planned or in progress.
One issue with DNS-over-DTLS is that it must still truncate DNS responses if the response size it too large (just as UDP does) and so it cannot be a standalone solution for privacy without a fallback mechanism (such as DNS-over-TLS) also being available.
DNSCrypt is a method of authenticating communications between a DNS client and a DNS resolver that has been around since 2011.
Also check out an in depth comparison from Tenta.
DNSCurve was developed in 2010 with encrypting the resolver to authoritative communications in mind. It was not standardized by the IETF.
Google offers a proprietary DNS-over-HTTPS service using a JSON format for DNS queries.
Historically, only an IP address was required to discover a DNS resolver for queries to be sent over clear text. Encrypted protocols require the client has more information so it can trust the server. This problem space is very different between stub and recursive resolver.
After much discussion in DPRIVE, the attempts to provide an authenticated mechanism for encryption of transport between recursives and authoritatives was but on hold. There are fundamental technical issues blocking this path related to limitations of the parent-child relationship as currently defined in DNS zone data, and also significant deployment hurdles to modification in this specifications.
As an interim solution the concept of ‘Unilateral Probing’ has been introduced in draft https://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/ and as of Jan 2023 various experimental implementations are in progress.