In this guide, we are going to cover the issues with unencrypted DNS, as well as the protocols for encryption, privacy-respecting DNS resolver resources to use and the installation of DNSCrypt for windows.

The Domain Name System Problem

Almost every activity on the Internet starts with a DNS query (and often several.) A key function of the DNS — Domain Name System — is to map human-readable names (e.g. to IP addresses that computers need in order to connect to each other. The DNS is, in essence, a phonebook for the Internet’s domain names. Those queries can reveal not only what websites an individual visits but also metadata about other services such as the domains of email contacts or chat services. While the data in the DNS is public, individual actions made by an end user should not be public.

There are two sides to DNS: Authoritative (on the content side) and a recursive resolver (on your ISP’s side.) In broad terms, you can think of DNS resolvers asking the questions (i.e., “where can I find this site?,”) and authoritative DNS nameservers providing the answers. This was set up as to not put strain on the authoritative servers.

Data moving between the resolver and the authoritative server is (theoretically) protected by DNSSEC. However, the “last mile” — the part between your computer (called the stub resolver) and the recursive resolver — is not secure.

If the data between the resolver and authoritative server are not secure, for instance, using encryption would help to secure domains that do not use DNSSEC.

Regarding DNSSEC

DNSSEC provides authentication. The system will cryptographically ensure that the response provided matches the intended response of the domain operator. In the event of a fail cryptographic exchange, the system will not return an answer at all. This ensures protection against domain spoofing or other attacks that attempt to provide false data. DNSSEC provides a chain of trust to help establish confidence that the answers you’re getting are verifiable. DNSSEC doesn’t provide encryption for DNS records, even those signed by DNSSEC.

However DNS queries are sent in clear text (using UDP or TCP) which means passive eavesdroppers can observe all the DNS lookups performed and they can reveal significant information that an Internet user may want to keep private, including the websites that user is visiting, the IP address or subnet of the device that issued the initial query, and even the types of devices that a user has in his or her home network. The DNS is a globally distributed system that crosses international boundaries and often uses servers in many different countries in order to provide resilience. It is well known that the NSA used the MORECOWBELL and QUANTUMDNS tools to perform covert monitoring, mass surveillance and hijacking of DNS traffic. Some ISPs log DNS queries at the resolver and share this information with third parties in ways not known or obvious to end users. Some ISPs embed user information (e.g. a user id or MAC address) within DNS queries that go to the ISPs resolver in order to provide services such as Parental Filtering. This allows for fingerprinting of individual users. Some CDNs embed user information (client subnets) in queries from resolvers to authoritative servers (to geo-locate end users). This allows for correlations of queries to particular subnets.

DNS is a weak link in the internet chain because this traffic is most often unencrypted and open to man-in-the-middle (MITM) attacks, even when visiting an encrypted (https) website. In such a case the attacker can easily set up their own DNS server and, using a little social engineering and or malware (also known as "cache poisoning" a form of MITM attack,) convince you to change your current DNS server, or change it without your knowledge, to the one controlled by the attacker. One possible result is that you could visit ‘’ but actually land on a phishing website that may look exactly like the authentic one and thus there would be no cause for alarm while you log on with your username and password, which would then be in the hands of the attacker. I am quite sure the tactic of DNS spoofing is used by law enforcement as well.

Without encryption, attackers can listen to your data packets and know which site you’re visiting. The lack of encryption also leaves you vulnerable to man-in-the-middle (MITM) attacks such as "Cache poisoning" as mentioned above. Man-in-the-middle (MITM) attacks are frequent and cause devastating damage to unsuspecting users.

If you're using a VPN for the sake of anonymity, then be sure your provider is offering DNS along with the VPN. DNS is the anonymity part of a VPN service. Just like the protocols in this article, with the exception of ODNS, requires you to trust your upstream provider. VPN services often have their own DNS servers or instead go without any or worse use Googles. So you need to be certain what you're getting. The easiest way to see if you are resolving your VPN provider's or ISP's DNS server's is

If you are looking to hide your identity/browsing history, then Mysterium or Sentinel VPN would be ideal. The VPN server is the third party that connects to the web on your behalf (so again you would have to trust your provider to not log.) A VPN is nothing more than a glorified proxy and basically only encrypts the contents of what you're doing and the DNS provides the anonymity while online. For an expert review of this topic have a read at DNS Privacy Considerations. It presents an analysis of the problem.

Let's have a look at the difference between the protocols before we get to the installation.

The Protocols

It should be noted: Any of these protocols is only secure as the upstream servers (servers you are connecting via the protocol of your choice) you are using. If any one of those is compromised, keep logs or unable to keep it's services up and is turned over to authorities then your data is jeopardized. It certainly isn't foolproof but better than DPI harvesting your data or having the ISP log you.


A protocol for securing communications between a client and a DNS resolver. The DNSCrypt protocol uses high-speed high-security elliptic-curve cryptography and is very similar to DNSCurve, but focuses on securing communications between a client and its first-level resolver. Basically, it provides payload (data) encryption and server authentication, within the context of otherwise-normal DNS queries. So it's obvious that you're doing DNS, and some metadata can be collected. For instance, DNS interarrival times could fingerprint specific web pages visited. Basically, it gets the job done, but it's not an ambitious solution, and it's not an IETF standard, so it's not terribly widely implemented. OpenDNS implemented it globally at a time when there were no other options, so it provided a critical feature at an important time, and got people thinking about the issue.


DNS-over-HTTPS is an ugly solution, to try to camouflage DNS queries as web queries, and get them past redirecting proxies (such as many telcos use) and protocol filters and so forth. That said, like NAT, it's an ugly hack that will probably have legs. It'll likely become an open standard eventually. It provides the same full-stream encryption as DNS-over-TLS (since it's essentially just DNS-over-HTTP-over-TLS), just on a non-DNS-specific port.


Transport layer security (TLS) is a cryptographic protocol that’s used around the internet for secure data transfer. It is an actual IETF standard, with a lot of interoperability work behind it. The consequence of that, it's the most widely supported in software, of the three options and some DNS services are now compatible with DNS queries sent over TLS. DNS-over-TLS provides full-stream encryption (as opposed to payload only) which gives some additional protection against metadata collection. It also provides server authentication, but in a standardized way, so implementing it should, in the long term, be pretty easy.

ODNS: Oblivious DNS

This is a relatively new concept, which is a new design of the DNS ecosystem that allows current DNS servers to remain unchanged and increases privacy for data in motion and at rest. In the ODNS system, both the client is modified with a local resolver, and there is a new authoritative name server for .odns. To prevent an eavesdropper from learning information, the DNS query must be encrypted; the client generates a request for, generates a session key k, encrypts the requested domain, and appends the TLD domain .odns, resulting in {}k.odns. The client forwards this, with the session key encrypted under the .odns authoritative server's public key ({k}PK) in the "Additional Information" record of the DNS query to the recursive resolver, which then forwards it to the authoritative name server for .odns. The authoritative server decrypts the session key with his private key, and then subsequently decrypts the requested domain with the session key. The authoritative server then forwards the DNS request to the appropriate name server, acting as a recursive resolver. While the name servers see incoming DNS requests, they do not know which clients they are coming from; additionally, an eavesdropper cannot connect a client with their corresponding DNS queries. It's actively working to become an open standard with the IETF.

Oblivious DNS (ODNS) adds a custom stub resolver at the client to obfuscate the original query, which the authoritative server for ODNS can decrypt. But, the ODNS authoritative server never sees the IP address of the client that issued the query.A news article on ODNS.We recommend you use DNSCrypt or DNS-over-TLS out of all the protocols they're tried and tested. ODNS doesn't have enough real-world testing to back up its theory and we have yet to see it action, so hold off on ODNS, for now.

DNS Resolvers

There are many DNS resolvers out there, from Google to Dyn, but this list is a result of the best I find to be robust in terms of its service/privacy policy and philosophy.

Our Privacy Tools resource hosts a list of DNS resolvers, check them out.

Also, check out solutions to hosting your own resolvers and other DNS tools.

The Solution

Securing your DNS traffic is easy using DNSCrypt. If you’re not afraid of the command-line and wish to keep the process as efficient as possible, I would suggest DNSCrypt-Proxy, which I use, it doesn't have a GUI, you are basically setting it up as a service. If you prefer a point-and-click approach, however, along with a nice GUI for controlling DNSCrypt and selecting your DNS server, here’s how to install and configure Simple DNSCrypt below:

If you have another version of DNSCrypt installed, uninstall it first. If there is no uninstaller, then run the following command:

dnscrypt-proxy --uninstall

Windows Installation

Next, download Simple DNSCrypt from the author's site and install the .msi package. The GUI to configure the DNSCrypt client should start automatically after the installation is complete. Configuring the DNSCrypt client is easy:

  1. Enable DNSCrypt for your network adapter.
  2. Enable the Primary DNSCrypt Service. If the service does not start, try disabling DNSCrypt for your adapter and then enabling the service. Note that the Secondary Resolver settings are disabled because this feature is not completely implemented at the time of this writing.
  3. In the ‘Advanced Settings’ you can download a fresh copy of the DNS resolvers list and by clicking the ‘Plugins’ button you can disable IPV6.
  4. Open port 443 in your firewall to allow outgoing UDP traffic for dnscrypt-proxy.exe if you need to.
  5. If you installed the ‘dnscrypt-proxy’ service, you can exit the Simple DNSCrypt GUI, otherwise, it will need to be left running.

Verify DNSCrypt is working

To verify that everything is working, check the properties for your network adapter (Control Panel > Network and Internet > Network Connections and right click on your adapter go down to IPv4 or IPv6 whichever you're using) and make sure the primary DNS server is set to and that the secondary server is empty. If it is not, make it so. Next, try visiting to make sure everything is working fine.

If necessary, reboot your machine or flush the Windows DNS cache by opening a command prompt and entering: ipconfig /flushdns, then load a web page to ensure DNSCrypt is working.

If you’re wondering about the default Windows ‘DNS Client’ service, leave it running. You can also leave in place any firewall rules for DNS lookups on port 53 to enable easy switching of the DNS servers in your network adapter for troubleshooting purposes.

Linux and macOS, unfortunately, there is no GUI version for these platforms, however, there are guides for a somewhat easy Shell installation that can be found for Linux and macOS.