The Domain Name System (DNS) is one of the most important services running behind the scenes that allows the Internet to work effectively every day. Also, it's one of the most forgotten and abused which was covered previously in the "DNS attacks" article. Today we'll address some of the ins and outs of its inner workings and review some helpful resources that will help minimize the chances of traffic sniffing (password leaking anyone?).

**Why should DNS privacy even matter?** This kind of traffic will reveal the sites you visit, which can be used to target your behavior, consumer electronics, political orientation, personal choices, and more. Potentially, all of this information could be used to make up a person's profile, and even work as the base for a target: DNS responses could be intercepted and modified to access a malicious service, such as a phishing website or a malware downloading application even if your network uses a zero trust approach in its design.

DNS inner workings

Worldwide DNS, we could say, is one of the first distributed services that enables collaboration to "make the Internet work". Based upon 13 different DNS root servers (which are the root zone authorities) distributed across the globe through the announcement of the same IP addresses (anycast), it allows hierarchical travel across its tree shape to solve questions about hostnames.

These servers will provide the root of the DNS zone tree, and will know exactly what server to ask whether top-level domain is a gTLD (a generic-top-level domain like .com, .net or .org) or a ccTLD (meaning a country code TLD, like .us, .uk or .tv).

When asked, these root servers will provide the next server to ask for records, as they are authoritative of only the top-level zones.

Below you can see a scheme regarding the different phases in a DNS query. Take a look at all the players we'll be mentioning during this post:

Wondering what technical implications this kind of traffic has? We'll address this below.

Privacy issues

On the technical side, one of the main concerns about DNS privacy is that **traffic is sent in cleartext**. If a third party manages to capture the traffic you're sending to obtain services' IP addresses then that stream is highly subject to eavesdropping.

You can test this yourself by capturing traffic on the corresponding DNS working ports, which are TCP and UDP port 53. Once they're captured, you can browse the packet's content and check what queries and responses travel through the network.

To mitigate this, in the next section we'll show you a few techniques and protocols that may allow you to **protect DNS traffic between you and your name servers**, and between your recursive name servers and those who are authoritative for the queried domain name zone or record.

DNS privacy enhancement tools

Despite the fact that today's public DNS servers provide ways to encrypt information, and modern browsers implement different protocols to bypass the operating system name server resolution system by using DoH or DoT (DNS over HTTPs and DNS over TLS respectively) to protect their users (as showcased in "Firefox DNS over SSL and Cloudflare public resolvers"), we intend to enumerate some additional protocols that will allow you to secure your own infrastructure without trusting a third party to do so.

For that purpose, today we're bringing special attention to DNSSEC, DNSCrypt, and DNSCurve as three ways to make name server traffic security a reality. They can do so by authenticating the contents of a DNS response, encrypting the communication between client's devices and the recursive server, and protecting the recursive's DNS server query to the actual final and valid owner of the information (a.k.a. the authoritative server).

DNSSec

While we've already discussed this topic in our post "DNSSEC - What Is It? Why Is It So Important?", we wanted to show how easy it could be to enable validation inside a self-deployed DNS serv...