Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


For a full discussion of the options available please see DNS Privacy - The Solutions.

One proposed solution is to change DNS to use TLS to send queries. TLS is an encrypted protocol (it is the same transport used for HTTPS) which will Client (stub) to recursive resolver

The two most widely deployed solutions for stub to recursive resolution are DNS-over-TLS and DNS-over-HTTP; they both encrypt DNS data and prevent passive surveillance of the network data revealing users' DNS queries.  This will also allow They can both allow users to validate the server they choose for their DNS service to make sure they are using a provider who has a good privacy policy for how they handle user data. However this is a non-trivial change . But they do have some different protocol properties and in practice are being deployed in somewhat different ways at the moment. Neither of these are trivial changes in the way DNS works and encryption of all DNS queries by default will not happen overnight. 

At the moment  several of experimental DNS servers  and two major operators support DNS-over-TLS. (Many users have resorted to using Google Public DNS  on to bypass their local ISP for censorship/surveillance reasons but sadly it doesn't support DNS-over-TLS yet.)  No desktop operating systems natively support DNS-over-TLS as a built-in option yet but Android does. Several options are available though, see Clients (e.g. Stubby) for end users that will enable them to choose to use DNS-over-TLS and to select the specific DNS server they want to use. 

Active work is also underway at the IETF on DNS-over-HTTP (DOH) but today the only method standardized by the IETF is DNS-over-TLS.See DNS Privacy ClientsDNS Privacy Implementation Status,  DNS Privacy Public ResolversDNS Privacy Test Servers for more information.

Recursive resolver to Authoritative server

The DPRIVE working group at the IETF has been working on solutions for that, if you are interested see the DPRIVE mailing list. 


Unfortunately the Server Name Indicator header in HTTPS messages also reveals the name of the website contacted by the user so provides a similar leakage channel for web traffic as the DNS queries. However there is work underway to try to encrypt that information too. in the TLS working group at IETF to encrypt the SNI: I-D: Encrypted Server Name Indication for TLS 1.3.