The Evolving World of DNS Security

I was recently at an event listening to representatives of ICANN and CloudFlare speak on security with DNS and it occurred to me that very few of us really understand or appreciate its nuances. It also so happens that the past 5 years have brought forward a lot of curious, and interesting, developments in one of the last untouched founding components of the internet.

DNS Primer

The Domain Name System (DNS) is comprised of a number of different Domain Name Servers (DNS). I wrote an article that offers an illustration and better understanding of how the entire DNS ecosystem works together. There is an even cooler illustration explaining how DNS works.

This article will focus on the part of DNS we all interact with, but rarely think about – DNS resolvers (Recursive DNS).

Why DNS Matters to You

DNS resolvers (Recursive DNS) is the gate we all pass through when accessing the web – also known as the “first port of call”.

Assume you want to open an App on your mobile device, or go to your favorite social platform on your Mac of Windows machine, in either case you begin the entire exchange by making a basic request known as a DNS query. This begins your entire online exchange, whether it’s via email, mobile applications or the browser.

We all have the ability to take control of the DNS resolvers we want to use – but few of us think of this option. Personally, I use CleanBrowsing and share the configuration I use at home to create a safe online experience for my family.

For most, we leverage the default DNS resolver provided by our Internet Service Provider (ISP) or whatever network we are on. Assume you go to your local coffee shop and they offer you free Wi-Fi, or maybe you are at the office and you use the Wi-Fi they offer. In either case, and many more, when you connect to the Internet your machine is being told what DNS to use (this is default).

These DNS resolvers are your gateway to the internet, as such they are prime targets for attackers. They have the ability to do good, or bad. For many online users, it’d be impossible to know if requests were being intercepted (as has been seen with many governments or companies) or if what the browser renders is the correct site.

DNS Security Options

Although a critical protocol of the Internet, something every device and human online depends on, it was never built for security and is one of the few remaining protocols that has not been adequately updated to account for the new age of security threats and privacy concerns.

The biggest issues technologists have with the existing system include:

• Susceptibility to monitoring (privacy concerns);
• Susceptibility to falsification (security concerns);

There has been a lot of renewed focus on the subject, but it’s not new. This conversation has been going for a long time, and the biggest issue continues to be wide scale distribution and adoption by consumers and organizations alike. It’s further complicated by the wide range of options available.

If you want to take take control of your DNS here are a few options:

• DNS Security Extensions (DNSSEC)
• DNSCrypt
• DNS over HTTPS (DOH)
• DNS over TLS (DOT)

Three are similar, one is not; I’ll share them and work to give you a basic understanding of the options.

DNS Security Extensions (DNSSEC)

DNSSEC is the outlier to the other four options. It was introduced back in 2004 via RFC 3833. Conversations can be traced back to 1997.

It was introduced to protect DNS resolvers by ensuring that an attacker is unable to forge DNS data when requested (i.e., it was trying to solve the falsification problem). It does this by adding something known as cryptography to the entire process.

These new cryptographic signatures allow the system to introduce a new layer of “trust” by facilitating better authentication of DNS records inside the Authoritative DNS zone files.

For instance, if you were looking for perezbox.com, as the domain owner, I would need to enable DNSSEC on my zone files so that it could be authenticated on requests when a local DNS resolver was trying to find it. There is a long illustration of what this looks like, but in short it creates something known as a “chain of trust” through the entire process.

Unfortunately, adoption of DNSSEC is extremely low (as of Dec ’17 its adoption was less than ~1% of .com, .net and .org domains – source: APIC). The biggest hurdle to its adoption has been its configuration. I won’t get into the details why here, but understand that it involves working with Registrars and Registries and that’s an entirely different animal (not all Registrars support it). The end result is poorly configured DNSSEC which then leads to a site that is not accessible.

No one wants a site that is not accessible. :)

DNSCrypt

DNSCrypt is a different animal. This protocol allows you to control how you communicate to the internet. DNSSEC was authenticating that the responses you were getting back were right, while DNSCrypt allows you to communicate externally in a way that doesn’t allow anyone to see your requests.

The DNSCrypt protocol was introduced to tackle the monitoring problem by doing to DNS traffic what SSL/ TLS did to HTTP – wrapping the traffic in a tunnel of encryption. Via this secure tunnel anyone monitoring the network would not be able to intercept or manipulate the communication. Unlike SSL / TLS, DNSCrypt uses a different crypto library known as elliptic-curve cryptography (specifically Curve25519). In order for this to work, your DNS resolvers must support DNSCrypt as well.

Here is an example of what you might get from your DNS Resolvers (Example provided by CleanBrowsing for their Free Family Filter:

For IPv4 traffic: sdns://AQMAAAAAAAAAFDE4NS4yMjguMTY4LjE2ODo4NDQzILysMvrVQ2kXHwgy1gdQJ8MgjO7w6OmflBjcd2Bl1I8pEWNsZWFuYnJvd3Npbmcub3Jn

Unlike traditional DNS that runs over port 53, it it defaults to port 443 (same as HTTPS) and can function over UDP or TCP protocols.

Why does this matter?

Well, assume you’re at the office and you really want to access your favorite whatever site, but it’s being blocked. You can now bypass whatever organizational controls exist to access that site because it looks like normal web traffic.

The good news is your connection is secure, the bad news is that most organizations have no controls in place to help defend against this. There in lies one of the big security conundrums of our decade. Yes, we can secure the communication but now we have introduced a way to bypass controls.

DNS over TLS

Because DNSCrypt was not good enough for the community, we decided to really make things fun by introducing DNS over Transport Layer Security (TLS) (DOT) introducing it in 2016 via RFC 7858.

Similar to DNSCrypt, in that it was designed to help address the monitoring problem (i.e., privacy), it works a little differently.

First, it uses the TLS protocol for encryption, which is the same thing used by HTTPS. Cool. Second, it works over TCP only. Third, it requires the use of port 853. Similar to DNSCrypt, in order to use DOT your resolver has to support it.

Here is an example of what you might get from your DNS Resolvers (Example provided by CleanBrowsing for their Free Family Filter:

Domain:: family-filter-dns.cleanbrowsing.org
IPv4 address: 185.228.168.168:853 and 185.228.169.168:853
IPv6 address: [2a0d:2a00:1::]:853 and [2a0d:2a00:2::]:853

This is really cool because we now have a way to communicate securely while not sacrificing existing security controls. Makes sense.

DNS Over HTTPS (DOH)

Naturally, since everyone else was doing it, the browsers decided to get involved in the creation of yet another way to solve the monitoring problem (i.e., privacy) by introducing their own approach – DNS over HTTPS (DOH). This standard is now ratified through RFC 8484.

Mozilla Firefox and CloudFlare specifically partnered to build and test the idea of DOH. Their goal was to help ensure real privacy, while also introducing improved performance.

DOH configuration is similar to DNSCrypt and DOT in that it’s designed to ensure that requests cannot be intercepted. Where it differs is that it makes use of the HTTPS protocol (which by the way makes use of TLS as well).

Here is an example of what you might get from your DNS Resolvers (Example provided by CleanBrowsing for their Free Family Filter:

URLs: https://doh.cleanbrowsing.org/doh/family-filter/
sdns://AgMAAAAAAAAAAAAVZG9oLmNsZWFuYnJvd3Npbmcub3JnEy9kb2gvZmFtaWx5LWZpbHRlci8

DOH has the same challenges as DNSCrypt in that it’s extremely easy to use to bypass organizational controls.

Making Sense of The Various Options

There is no denying that change in how DNS works is a necessity. Where I see the real contention is in the various options and their various implications (all justifiable depending on your view of the world). Unfortunately, as we debate these issues to death we do nothing more than delay progress and adoption, and introduce confusion to every day consumers.

I can appreciate and understand both sides of the argument.

DNS hijacking occurs daily by ISP's and governments all over the world. Have you ever typed in the wrong domain on a Frontier network? Ever notice how the search page that is returned is something completely different than what you expected? When wandering abroad, ever wonder why certain sites are not accessible? Ever try to change your local DNS resolvers only to find out that your ISP doesn't allow you to define your own? 

These are real-world examples that I myself have experienced, and I’m sure many of you have experienced whether you recognize it or not.

Now flip your role, and imagine yourself the network engineer for a large organization. You are tasked with protecting the network. You know DNS is a critical piece of your infrastructure. But now, you have no way detecting malicious external requests. This too is a real problem.

This will be the big philosophical debate for years to come, that will allow us technologists to giggle when watching debates on the subject and introduce extreme frustration across the aisle for those intimately involved.

This doesn’t include the technical challenges like using TCP, and it’s dependency on a three-way handshake, and potential conflicts between DNS and HTTPs traffic. Thankfully there are some really smart engineers working on this, and so I expect that with time it might be a non-issue.

Some Quick Take Aways

Here are some interesting notes you can leverage to make sense of the differences:

• DNSSEC is about authentication, not privacy.
• Concerns driving change were around monitoring (privacy) and falsification (security);
• DNSCrypt was first to leverage HTTPS ports, but uses different encryption;
• DOT is for operating systems, DOH is for browsers (really good for JavaScript);
• DoT runs over port 853, DOH runs under HTTPS on normal port 443;
• Neither DoT nor DoH specify how the user should be able to set up the protocol, or whether they can even tell that the protocol is running;
• DoT seemed uncontroversial because people assumed computers would be configured to use the same recursive resolver that was already trusted by the user;
• DoH quickly became controversial because FireFox performed tests using a cloud provider that was not necessarily trusted by the user;

My Personal Preference

I like, and prefer, DNSCrypt. Easiest way to try it is using DNSCrypt-Proxy for NIX based machines, or Simple DNSCrypt for Windows.

Personally, I have an issue with Browsers controlling what I can and can’t do. Their intentions are always wrapped around privacy and security, and yet somehow always find their way into their monetary engines (showing up on my social platforms, site visits, emails and search results).

Separation of powers and controls serves a purpose.

Who will win and become the default?

If I were a betting man I would probably put my money on DOH. The biggest issue with most DNS changes is adoption, it has to be default in the environment – every day users don’t want to waste mental calories thinking about this stuff. DOH has an advantage because of the prevalence of browsers (Mozilla Firefox is already doing this).

DOT has a fighting chance, but only if Operating systems deploy it by default – which hasn’t happened to date.