DNS, also known as Domain Name System, is the internet-wide service that translates fully qualified hostnames (FQDNs) such as www.netsparker.com into an IP address. It was developed because it's much easier to remember a domain name than an IP address.

In 2017, an internet draft to send DNS requests over HTTPS was filed to the IETF by P. Hofmann (from ICANN) and P. McManus (from Mozilla). Was this a positive move toward a more secure internet, or will it only create more problems?

In this article we dig deep into the subject, explaining our angle on the pros and cons of running DNS over HTTPS.

What is the DNS and How Does It Work?

First, let's refresh our memories on how DNS works. When you visit https://www.netsparker.com the following happens:

1. Your browser sends a request to a recursive domain name server (DNS) that is configured on your computer. Let’s call this DNS server 8.8.8.8.
2. Since 8.8.8.8 does not know the IP address of www.netsparker.com, it queries the internet root servers, which refer 8.8.8.8 to the nameserver responsible for the .com top level domain (TLD).
3. Next, 8.8.8.8 asks the .com TLD name server for the name servers of the netsparker.com domain.
4. Then, 8.8.8.8 asks the netsparker.com name servers for the IP address of the FQDN www.netsparker.com. Once the server gets the response, it forwards it to the web browser.
5. The web browser connects to this IP address and requests the website www.netsparker.com.

How Far Does DNS Lag Behind?

Back in 1983, when DNS has just been invented, DNS requests and responses were sent over the internet in clear text, and they still are. Now, with so much at stake on the internet, there is an additional need to encrypt DNS traffic.

However – like many other fundamental building blocks of the modern web – DNS was not ready for the hype!

Unlike other protocols such as HTTP and FTP, DNS never got a security upgrade that prompted widespread adoption. Instead, one of the most important features of our modern internet has used the same level of encryption for the last 35 years – none at all!

Introducing DNS Over HTTPS

In 2017, following years of unencrypted DNS requests, the first IETF Internet Draft (I-D) for DNS Over HTTPS (DoH) was published. It was a precursor to an official RFC document, and you can the 13th revision of the initial draft (DNS Queries over HTTPS (DoH), though its RFC is not yet finalised. It isn't the only protocol that aims to add encryption to the DNS protocol (there is also DNS over TLS and DNSCrypt), but it's the one that companies such as Mozilla and Google chose to integrate into their products.

Let's take a look at how it works and why it's probably not the solution to all DNS privacy problems.

DNS over HTTPS – Technical Basics

First, let's look at the technical aspects described in the latest Internet Draft and implemented in real-world applications.

The client sends a DNS query via an encrypted HTTP request – not a shocking revelation, given the name of the protocol. There are two possible ways to send the data – via a GET or POST request. Each has its own characteristics and advantages.

GET and POST Requests

If you send the data via a POST request:

• The Content-Type header field indicates the media type:
  • The I-D describes one media type (application/dns-message), but the major DoH providers we'll talk about use another one (application/dns-json) that is better suited for web applications.
• The DNS query is sent in the message body:
  • This has the additional advantage that you don't need to encode the message
• The message size is smaller than sending it with a GET request:
  • As described above, this has to do with encoding

If you send the data via a GET request:

• It's bigger than a POST request:
  • The encoding that you need to use is base64url, which means that the encoded message is about one third larger than the original one
• It's HTTP Cache-friendly:
  • Caching GET requests is well supported even in older cache servers
• The DNS query is sent in a GET parameter
  • This is not surprising, since the I-D mentions 'dns' as the GET parameter name

However, even though GET requests are more cache-friendly than POST requests, there is still one problem. Usually DNS packets have an ID field, that is used in order to correlate request and response packets. It is a unique, random identifier that results in different request URLs for what is essentially the same request. Therefore, clients should set this ID field to '0'.

This demonstrates that porting DNS from cleartext UDP/TCP to encrypted HTTPS requires some adjustments, at least if you want to use HTTP's full potential (which is advisable since HTTPS comes with quite a bit of overhead compared to the simple, unencrypted wire protocol of DNS).

Is Today's Web Ready for DNS Over HTTP?

Now that you know some of the important technical details regarding DNS over HTTP, what about the infrastructure of DoH?

Let's keep in mind that this technology is still in an experimental state and there is a lot of old DNS infrastructure that doesn't support encryption. Could you even deploy DoH when most of the name servers out there don't encrypt their DNS responses? Does DNS over HTTPS even make sense? And wouldn't you need to change how browsers or operating systems work in order to use it?

It turns out that it's not really necessary to update everything, even though the latest, nightly Firefox build added support for DNS over HTTPS. This is a recent, bleeding-edge version that may contain features that aren't yet available in the latest stable version. And Google's Android Pie is going to have a built-in DoH feature.

There is a way to use DoH without an operating system or browser update, though. Obviously, you should keep browsers and operating systems updated, but let me tell you why it will take a long time for most people with an Android phone to use DoH (even though Google added it in Android Pie).

Why You Won't See Native DoH on Your Android Phone for a Long Time

From painful personal experience, I can explain. Some time ago, I bought a new Samsung smartphone. Then Google released a new Android version. The update included a cool UI overhaul and some new features.

Then I waited. Yet month after month, my screen informed me, "Your phone is up to date". This annoying delay was down to the fact that Samsung heavily customizes Android on their own phones. Back then, their version of Android was called TouchWiz and it was full of bloatware. Following complaints, they slowly removed most of the annoying features and software, to the point where people couldn't recognize it as TouchWiz anymore and they had to rename it. (I'm not making this up.) Even though now they have a few fewer Samsung-specific features that they need to adjust to new Android versions, it still takes much too long to get a new update.

A friend of mine had a much older Android device from the same manufacturer and always had the latest Android version installed. That's because he flashed a new CyanogenMod operating system to the phone. It was third-party software that didn't have the TouchWiz UI, but it was the latest Android version that was available. Other problems aside, it's ironic that you could get a fully-patched, up-to-date phone by flashing third party software a few days or weeks after Android published it, yet you needed to wait months for your phone manufacturer to do the same. Obviously, doing that would void your warranty and the average user won't even be aware such a thing is possible. So, even though Android 9 will have DoH support, it may take months or even years for you to be able to use it.

Is There An Alternative Way to Use DoH Even Though Your OS or Browser Doesn't Support It?

There are several options:

• You can install a DoH proxy on the name server in your local network, which means that your device still sends traditional, unencrypted DNS packets to the local name server. However, that server will query DNS over HTTPS servers on the internet in order to resolve your query, which enables you to use DoH without having to modify your system. Still, it's unencrypted within your local network.
• It's also possible to install a DoH proxy on your local system, even though I'm not sure if it's possible for Android phones. Using this technique, instead of relying on a second machine in the local network, the proxy runs on the same machine as your browser. Therefore, even if you have an attacker in your local network, he can't read your DNS requests since they are already encrypted once they leave your machine.

Does DNS Over HTTP Enhance Security and Privacy?

It's up for debate. There are some problems with DoH that are worth a mention. The first of these, due to the way DNS works, is that it's almost impossible to have an end-to-end encrypted connection from your browser to example.com's name server, without making it known to intermediate servers.

Let's recap by looking at how the recursive name server from our earlier example resolves the IP for www.example.com:

1. It asks one of the internet root servers:
   • Question: "I want to visit www.example.com, do you know where it is?"
   • Answer: "No, but here are the nameservers for .com. Try your luck there!"
2. Then it asks the .com name servers:
   • Question: "So, can you tell me www.example.com's IP address?"
   • Answer: "You should ask the example.com name servers."
3. Finally it asks the example.com name servers:
   • Question: "What is the IP of www.example.com?"
   • Answer: "The ip is 123.123.123.123"

In each of these queries, the full hostname is sent to the DNS server. All of these servers now know that you want to visit www.example.com, even though this information is only of real interest to example.com's name server – obviously less than ideal in terms of privacy.

DNS Query Name Minimization

There is a solution to the problem described above and it's not even a DoH-specific one. It's called DNS Query Name Minimization and this is how it works.

If you want to visit example.com, the conversation between your recursive name server and the other name servers would look like this:

1. It would ask the internet root servers:
   • Question: "Do you know the nameservers for .com?"
   • Answer: "Yes, here is their IP address"
2. Next, it would ask the .com nameservers:
   • Question: "Do you know the nameservers for example.com?"
   • Answer: "Yes, here is the IP address of the example.com nameserver"
3. Finally, it would ask the example.com nameservers:
   • Question: "Do you know the IP of www.example.com?"
   • Answer: "Yes, it is 123.123.123.123"

The only name server that knows the full hostname is the one for example.com, since it's also the only server that needs to know it. All the other servers only know a part of the query. This doesn't help you to stay completely anonymous, yet it does reduce the amount of data you give away. This is part of the Firefox DoH implementation and its Trusted Recursive Resolver (TRR) technology.

There are Some Trust Issues

The second problem with DoH is Threat Models. Threat Modeling involves identifying potential vulnerabilities and suggesting counter measures. And it means ignoring low-level risks. Even though they are an important part of information security, I'm usually not a fan, at least when it comes to the average user. Sure, air gapping your PC and placing it behind two layers of bulletproof glass and an electric crocodile pit is a little over the top if you only use your computer for playing spider solitaire. But if you need to decide whether you should enable HTTPS for your homepage or not, you don't really need to spend hours pondering your threat model. It takes less than 15 minutes to set up with Let's Encrypt, so just set it up.

Unfortunately TRR is a completely different beast. I don't know the rationale behind Mozilla's decision, but I assume since it takes a huge amount of bandwidth and the fact that Mozilla may want to have TRR enabled by default in future versions of Firefox, they wanted to build infrastructure that was both reliable and safe from DDoS attacks. If you think about reliability and DDoS proof, Cloudflare immediately comes to mind. Mozilla partnered up with them and use their 1.1.1.1 server for their DoH implementation.

This causes problems for some people. But, if you only ever visit Facebook and Twitter, you couldn't care less whether Cloudflare knows about your DNS requests. However, if you are a reporter conducting research for articles, and handling sensitive information, you may not want to route all your DNS requests through an American company that could potentially trace it back to you. But there are a few benefits to having an external DoH server. For example, if you are working on an insecure public network, you don't have to communicate with a DNS server via cleartext if you use the encrypted Cloudflare server. Also, all the server's 1.1.1.1 queries will only see a Cloudflare DNS server asking for the IP that belongs to a given hostname, not your IP.

How Common is it for Tech Companies to Lose Customer Data?

The question is, is Cloudflare trustworthy? Well, yes of course it is. And they promise to delete any information they have stored about you within 24 hours. But, mistakes happen.

• Just this year, Twitter admitted to accidentally storing the plaintext passwords of their users in a log file.
• Then, German domain registrar DomainFactory unintentionally leaked sensitive user account data, which was retrieved by an attacker. I'd love to report that this was an elaborate hack by a gang of sophisticated attackers, probing the company's website and infrastructure for months with the goal of selling the data. But the vulnerability was painfully simple. It appears that they exposed some error data via an XML feed (why would you do that?!) when a user caused an error in some way and a lot of their sensitive data was leaked via that feed. You may wonder what triggered the error for so many users? The culprit – yet again, I wish I was making this up – was actually an error in the gdpr_policy_accepted field. (If you don't know what GDPR is and why this is ironic on multiple levels, you can get up to speed by reading our Whitepaper: The Road to GDPR Compliance.) They asked the user to acknowledge their data protection policy, but when the user clicked 'Yes', an error occurred and the data that should be protected became readable for everyone. This was because the backend expected a boolean value but got a string instead, triggering an error message that contained user data that ended up in a publicly accessible XML feed. Ouch!

The bottom line is that people make mistakes – even those that work in the IT departments of large corporations. Even at Cloudflare.

A Single Point of Failure

What's also worth mentioning is that even if customer data is secure, there might be outages. If 1.1.1.1 becomes the default DNS server for Firefox and there are any availability issues, not a single Firefox user will be able to issue DNS requests or therefore open a website (assuming they changed no default settings). If you think that outages are impossible, given the vast resources Cloudflare boasts, remember that even AWS had a major outage last year. You may not have noticed the outage just by looking at Amazon's status page, since it relied on AWS (the service that it's supposed to monitor) in order to work correctly and show its status!

That's why Firefox allows you to use your own Trusted Recursive Resolver. You only have to change the IP in the settings – but how many users know about TRR and how to change it or why? One percent would be a very generous estimate and that's troubling.

Are DNS Over HTTP Servers Secure?

As we've already established, DNS over HTTPS is a very young technology. It's not clear yet which server software will end up being most popular with website administrators. However, if you simply copy Google or Cloudflare's implementation, you could run into an issue – CORS. Let me cite some text from the I-D:

The integration with HTTP provides a transport suitable for both existing DNS clients and native web applications seeking access to the DNS. Two primary use cases were considered during this protocol's development. They were preventing on-path devices from interfering with DNS operations and allowing web applications to access DNS information via existing browser APIs in a safe way consistent with Cross Origin Resource Sharing (CORS).

Format of DoH Responses

Before we talk about CORS, let's think about the format of DoH responses. The I-D describes the application/dns-message media type, which is essentially a raw DNS packet in the HTTP response message. It's useful for most computer programs as there are already parsers available for that message format. However, the I-D states that it would allow web applications to "access DNS information via existing browser APIs". There is no existing browser API allowing you to decode DNS packets, so that's done on the server side and Google, and Cloudflare can send back a message in JSON format (which, on the other hand, can be easily decoded by a browser).

However, if your web application that wants to access this data doesn't run on the same host as the DoH server, you encounter a problem. You can't access the data due to the Same Origin Policy (SOP). That's why the Internet Draft mentions CORS. It allows you to access the data anyway, even though the origins don't match.

But – and let's assume your local server would also have such an API – is that dangerous?

Well, it can certainly lead to problems in an example where you have set up some custom domains that should only be correctly resolved to the specified IP address from within your network. Let's say your company's website is example.com and you have a special developer.example.com subdomain that should resolve to an internal IP from within the company building. Attackers could trick you into opening a website they control. It would contain JavaScript code that can query your DoH server's API, and try different subdomains and domains. Since it's CORS enabled, attackers could read the response and gain important information about your internal network. They could then use one of the techniques described in our blog post Vulnerable Web Applications on Developers Computers Allow Hackers to Bypass Corporate Firewalls in order to attack it and probe it for weaknesses. That would only work if these DoH servers had a CORS-enabled API as described in the I-D and implemented by Google and Cloudflare.

How do You Disable Trusted Recursive Resolver or DNS Over HTTP in General?

As you see, whether TRR/DoH is useful depends on a lot of factors. You need to think about whether you want your DNS requests to be routed through an American company and if it suits your threat model. There, I said it! On the other hand, it's also not ideal to send all of your DNS requests in plaintext.

If, ultimately, you decide that TRR or DoH are not right for you, this is how you disable it in its current implementations.

Firefox

1. If you want to disable DoH in Firefox, you must be brave, as you have to open about:config and dismiss the scary 'This might void your warranty!' dialog.

2. Once you do this, you need to search for network.trr.mode in the search bar. You will be left with exactly one option. You can type multiple numbers into the field. And even though this goes without saying, 2 activates DoH and 5, obviously, deactivates it. (Zero and 1 would be simpler, but I'm sure it makes sense on some level.)

Android

If DoH is enabled by default in Android Pie, there is an easy way to disable it. Reportedly, there is a setting in the Network and Internet Settings menu, called Private DNS. As mentioned in the Android Developers blog, there is a button you need to check that turns it off. Unfortunately, I'm unable to independently verify that claim, simply because my latest Android phone was made by Samsung (which, unsurprisingly, tells me that my phone is up to date). So, even though technology companies do their best to change DNS for the better, some things just never change.

Is DNS Over HTTP the future of DNS?

In this article, we looked at the technology behind DoH and DNS as well as the history of the Domain Name System. While DoH may not  yet be widespread, it is a good and necessary addition to DNS – if implemented correctly. We established that it depends on your personal use of the web whether or not you want to route your DNS requests through an American company. If you don't trust Cloudflare or Google, you can alternatively set up your own DoH resolver, but just beware of vulnerabilities such as the permissive CORS implementation we talked about in this post.