DNS Privacy: Minimizing end-to-end Exposure

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:

Source: DNSCrypt.info

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.

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 server using Unbound software.

DNSSEC enables you to authenticate the veracity of the domain name zone information, by looking at its provided signature and checking it against its associated public key.

This itself enables users to verify that the actual answering server response regarding a certain domain name zone query is exactly the same as the one received by the questioning client.

You may check zone validity using different methods. Some involve command line knowledge (eg: using dig command), by using a browser plugin or by configuring your own DNS resolver which validates the actual zone for authenticity.

To do this, let’s showcase Unbound DNS open source software, which enables you to set up a recursive DNS really quickly with DNSSEC validation. Simply uncomment the following line inside your unbound.conf file after installing:

# File with trusted keys, kept uptodate using RFC5011 probes, # initial file like trust-anchor-file, then it stores metadata. # Use several entries, one per domain name, to track multiple zones. # # If you want to perform DNSSEC validation, run unbound-anchor before # you start unbound (i.e. in the system boot scripts). And enable: # Please note usage of unbound-anchor root anchor is at your own risk # and under the terms of our LICENSE (see that file in the source). auto-trust-anchor-file: "/var/unbound/db/root.key"

Once that’s done, you need to run the “unbound-anchor” command to download the root key needed for validations:

# unbound-anchor -v /var/unbound/db/root.key does not exist success: the anchor is ok

And in case the file exists and doesn’t need updating, the message would be this:

# unbound-anchor -v /var/unbound/db/root.key has content success: the anchor is ok

If you look in the file, you’ll encounter the root zone DNSKEY needed to start validating signed zones:

# cat /var/unbound/db/root.key ; autotrust trust anchor file ;;id: . 1 ;;last_queried: 1595963484 ;;Tue Jul 28 16:11:24 2020 ;;last_success: 1595963484 ;;Tue Jul 28 16:11:24 2020 ;;next_probe_time: 1596003450 ;;Wed Jul 29 03:17:30 2020 ;;query_failed: 0 ;;query_interval: 43200 ;;retry_time: 8640 . 172800 IN DNSKEY 257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9 tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU= ;{id = 20326 (ksk), size = 2048b} ;;state=2 [ VALID ] ;;count=0 ;;lastchang e=1508533746 ;;Fri Oct 20 18:09:06 2017

Actually, one caveat is that some domains may be misconfigured or have some kind of error. Then, DNS queries may fail despite having a correct answer/response handshake.

To overcome this using Unbound, you need to create an exception so Unbound doesn’t make DNSSEC validations for this domain name:

# Ignore chain of trust. Domain is treated as insecure. # domain-insecure: "example.com" domain-insecure: "*.nflxvideo.net"

In any case, you need to reload the Unbound daemon afterwards to re-initialize the configuration, by doing:

# unbound-control reload ok

Your local validating and recursive DNS is now ready, so to better understand the validation process flow, take a look at this flow diagram:

Source: DNSCrypt.info

You may notice in the image above that while this architecture protects you from DNS zone poisoning, it doesn’t solve the problem of privacy; the traffic is still subject to sniffing.

So while DNSSEC addresses some security problems, it doesn’t cover all of them. What protocols and techniques could solve your DNS privacy issues? We’ll cover two mainstream options in the next sections!

DNSCrypt

DNSCrypt is a protocol that enables you to secure communications between your personal devices and the recursive DNS server configured on the respective operating systems.

This protocol’s implementation can be installed as a client on different desktop operating systems such as Windows, Linux, and macOS; on mobile devices using Android or iOS with root privileges (jailbroken), home routers using OpenWrt and others; and also as a proxy on multiple additional operating systems including Windows, Linux, FreeBSD, OpenBSD, NetBSD and the like.

DNSCrypt client software allows you to package all DNS queries and send them using available-by-design strong encryption to the configured recursive DNS, which will answer with the desired results using the exact same channel.

In their website, there’s also a list of DNSCrypt-enabled servers that may provide you with service by using the desired channel encryption.

Great! So now you can encrypt information between your devices and the recursive server, but what happens when the recursive server doesn’t know the answer?

The way that DNS works implies that the recursive server must ask the corresponding authoritative server of the domain name for an answer.

To protect this process, in the next section we’ll showcase DNSCurve, a protocol that protects server-to-server communications.

DNSCurve

DNSCurve is a security protocol specially designed to allow you to protect the communications between DNS servers. The querying server will determine whether the answering has DNSCurve enabled, and if so, it will encrypt communications using state-of-the-art algorithms such as Curve25519 for key exchange and XSalsa20Poly1305 for stream encryption.

This encryption will provide privacy regarding server communications, but it will not protect you (configured like this) from traffic eavesdropping between your personal devices and the recursive DNS configured on their operating systems.

A network map regarding DNSCurve protection should look like the image below. Any attempt to sniff this traffic will be futile as all communications are encrypted.

Curious about how the handshake works? DNSCurve provides a clever way to determine whether an authoritative nameserver is encryption-capable or not. First, when a query is received from a client (like your personal device or application), recursive name servers will query themselves about the requested domain name record. If that information is not present within its cache memory, it will then start asking which authority server may answer properly.

This is when DNSCurve detects the other’s server capability. By querying a domain name NS record it will determine the hostname of the server that has the authority to answer. This hostname will be specially crafted with an encoded section that will trigger the encryption handshake.

In the image below, you’ll notice that the hostnames contain a subdomain part, which has a special set of strings (known as magic string) that indicates the start of a payload containing the requested server’s public key.

All of this is done within a total of 54 bytes, which includes the 3-byte magic string plus a 51-byte public key, all base32 encoded and placed inside a subdomain.

Once the connection is created using the asymmetric encryption algorithm (Curve25519), the symmetric key for the stream connection is exchanged between them. Thus begins the DNS zone information query/response traffic.

World Deployment

Regarding DNS security, especially about query-encryption protocols, one may wonder if it’s actually being used on the wide open Internet. Well, let’s figure this out using our own SecurityTrails API interface! The following script is plain and simple and takes advantage of the search functionality:

API="YOUR-API-KEY" OUTPUT=$(curl --silent \ --request POST \ --header "Content-Type: application/json" \ --header "APIKEY: $API" \ --data-binary "{ \"query\" : \"ns LIKE 'uz5%'\" }" \ 'https://api.securitytrails.com/v1/search/list') echo $OUTPUT | jq --raw-output '.records | .[].hostname' | sort

This script will place a query on all registered nameservers that have names starting with “uz5”, which is the DNSCurve magic string we talked about earlier. The results will bring up all domain names that at least have one name server that matches.

The results are as follows:

In case you want to actually see what name servers these domains have configured, you can run the following script to print the information:

#!/bin/sh for domain in $(sh dnscurve.sh) do ns=$(dig +short ns $domain) echo "Domain: $domain" echo "NameServers:\n$ns" echo "=---------------" done

And the results, as you can see, are positive:

As it appears, there is one service called buddyns.com that implements DNSCurve on their own servers. Despite this fact, you can do it on your own set of private DNS servers as well.

Summary

As you’ve now seen, there are several techniques that may help in making your DNS traffic more secure and private. Name server queries, despite many differing opinions, should be kept in confidence whether it is your personal traffic or your company’s.

Leaking DNS traffic information to a malicious third party may disclose unwanted network behavior that may tip you off to where to look, with extra and special care.

Deployment of these security measures isn’t difficult but it may take some planning along with acceptance from the users. Still, the techniques and protocols shown in this post aren’t disruptive enough to make it unusable for non-technical users (PGP/GPG with email usage anyone?).