DNS Privacy Solutions

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.

IETF Standards Track protocol options

DNS-over-TLS (DoT)

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. 

DNS-over-HTTP (DoH)

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

DNS-over-QUIC (DoQ)

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.

XFR-over-TLS (XoT)

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.

Non Standards Track protocol options

DNS-over-DTLS

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

DNSCrypt is a method of authenticating communications between a DNS client and a DNS resolver that has been around since 2011. 

  • It prevents DNS spoofing. 
  • It uses cryptographic signatures to verify that responses originate from the chosen DNS resolver and haven’t been tampered with (the messages are still sent over UDP). 
  • As a side effect it provides increased privacy because the DNS message content is encrypted.  
  • It is an open specification but it has not been standardized by the IETF. 
  • There are multiple implementations and a set of DNSCrypt servers available.
  • OpenDNS offers DNSCrypt 

Also check out an in depth comparison from Tenta.

DNSCurve

DNSCurve was developed in 2010 with encrypting the resolver to authoritative communications in mind. It was not standardized by the IETF.

DNS-over-HTTPS

Google offers a proprietary DNS-over-HTTPS service using a JSON format for DNS queries.

The Discovery Problem

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.

Stub to recursive discovery

  • Early solutions require hard-coding information of trusted servers in different ways e.g. Firefox’s TRR list or Stubby’s config file
  • More recently work has been done in the ADD Working Group at IETF to find automated solutions to the variety of situations that clients have

The Recursive to Authoritative Problem

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.

Unilateral Probing

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.