DNS over HTTPS (DoH)
The Privacy Problem
It is no secret that the original DNS design did not take security into account. While DNSSEC addresses many of the security short comings of the traditional DNS design, especially in server-to-server communication, it falls short in adequately addressing the “last mile” problem, that is the communication between DNS client (such as a mobile phone) and its nearest DNS server (such as the corporate or ISP DNS server).
Truth be told, there are two major reasons why DNSSEC is the wrong tool for this job:
- DNSSEC does not encrypt traffic: DNSSEC uses public key cryptography to provide authentication and data integrity, so we know precisely who sent the data, and whether or not that data changed during transmission. However, it does not provide any privacy, meaning someone eavesdropping on the wire can still see all the DNS message in the clear; it is just extremely difficult for them to alter the data.
- DNSSEC validation is resource intensive: DNSSEC validation requires more computing power and network queries to fully validate an answer. While it is possible to have the client perform all of these queries itself, we do not do it for the same reason why we have a local DNS server: so nearby clients can share the resources and cache of the server, and spare themselves the busy work. Just imagine if a mobile phone could not rely on a DNS server to perform all the queries and lookups, but rather had to do all of the lookups itself AND perform full validation on each answer. This would likely drain the phone’s battery so quickly that it would render the device less useful.
To fill this big gap that is the “last mile,” many competing technologies have emerged over the years, such as DNSCurve and DNSCrypt. While these technologies try to bring privacy between DNS client and server, they have one thing in common: they are proprietary and non-standardized. The standards body IETF (Internet Engineering Task Force) recognizes the need for DNS privacy, and released two new standards in 2016 that address these needs. In this article, we will be discussing one of the two new standards1, DNS over HTTPS, or DoH as it is commonly referred to. It also has drafts being worked on for both Confidential DNS and IPSECA.
DoH Basics
To understand DoH, we first need to understand HTTPS. Many people may know the S stands for SSL (Secure Socket Layer), and the modern version of HTTPS is based on TLS2, Transport Layer Security, the successor to SSL.
In a standard HTTPS communication, a client (usually a web browser) reaches out to the web server, obtains the server’s certificate (usually a X.509 cert), and runs through the standard certificate authority validation process to decide whether or not it trusts this server, i.e. is it signed by a certificate authority the client trusts, etc. This is an important detail that deserves highlighting, and we will discuss its impact later. After the client decides to trust the server, they negotiate an encryption key, and are ready to start encrypting data. This is known as a TLS handshake.
RFC 8484 describes DoH at a high level. A DoH client reaches out to a DNS server that supports DOH over standard TCP port 443. The DoH client receives the server’s certificate, somehow validates it (more on this later), then generates a symmetrical encryption key that they both agree on (such as AES) for the actual data encryption. In short, DoH behaves exactly like a web browser, with the exception that it encodes DNS data within HTTPS sessions in the form of GET and POST messages.
Similar to DoT, DoH protects the per-hop communication between server and client; but different from DoT, it is not intended to be used to secure server-to-server communication. This means DoH is truly a technology meant to secure the “last mile.” Similar to DoT, DoH does not provide the authentication and integrity checking that DNSSEC offers.
DoH Considerations
DoH has the following characteristics:
- It encrypts
- It runs over HTTPS
- It uses a different DNS setting than the rest of the system
Encryption/Privacy:
DoH grants privacy between two parties, meaning it is per-hop privacy. Your communication might be private between your web browsers and your ISP, but it may not be between your ISP and its upstream DNS server. Privacy may sound like a good idea for end users, but when used in a controlled environment such as corporate network, it may cause more concern than benefits. Running a rogue DoH client in a corporate setting means that the IT or security team is unable to look into the DNS queries the client makes, be it that the client is visiting a known malware-infected domain, or is using (encrypted) DNS to exfiltrate sensitive data out of the corporate network.
HTTPS:
Running yet another service over HTTP(S) has its advantages and disadvantages. HTTP is a mature protocol that offers many performance enhancement features such as compression and session reuse, but it also has a wide attack surface and presents a high value target. HTTPS relies on TLS, and it brings DoH right back to the problem with certificate authorities (CA). During the TLS handshake, the client receives a certificate from the server, and the client needs to follow all the standard procedure a web browser would, to validate this certificate; this usually means by checking if the certificate is signed by a trusted root CA, or the certificate is self-signed. One possible solution is to leverage DANE to lessen the dependency on CA.
Unique DNS Setting:
Although not mandatory, nearly all DoH clients are web browsers, which makes sense since the original problem they were trying to solve was how the web browser could use a more trust-worthy DNS server than the one defined by the operating system. Whether or not this is a good thing depends on your point of view: from a corporate security and IT support point of view, this is unacceptable. Not only do we have to troubleshoot two separate DNS settings on the same client, there is no visibility into the DNS queries that the web browser is making over HTTPS.
Why Use DoH?
Major DNS service providers such as Google DNS, CloudFlare, and Quad9 have started offering DoH as part of their public offerings. If your web browser supports DoH (Firefox and Bromite both support DoH), you may point your web browser to use one of these DNS servers and have the communication between your web browser and the DNS server encrypted.
Just like DoT, If you trust the DNS service provider (such as Google), using DoH provides an extra layer of security between you and the service provider. Just understand that communication between the service provider and the rest of the Internet could still be wide open and not secured by anything.
If you are stuck on a machine or an environment where you know the DNS queries are filtered or blocked, and you have no access to alter the system’s DNS setting, using a DoH-enabled web browser might provide a path out to the Internet without filter or detection.
1 The other leading new standard is DNS over TLS, or DoT
2 RFC 2818 describes HTTP over TLS, DoH is largely based on TLS 1.2
