DNS – the Domain Name System – is a main cornerstone of the internet. Whenever you are browsing to a website, chances are high that your request will first go to one of the 1091 (as of 9th of May 2020) root servers. These are the only servers your primary DNS server (most likely provided by your ISP) knows for sure how to contact thanks to so-called “root hints file“. The root servers listed in this hints file will then help to start the iterative translation from a domain name like example.org to an IP address like 93.184.216.34.
Recursive and Iterative Queries
Usually, DNS servers only guide you to the next relevant DNS server: The root server tells you the DNS server for the top-level domain (TLD) “.org”, that DNS server in turn provides information on where to find the DNS server for the second-level domain (SLD) “example”. Your workstation will be responsible to recursively reach out to all these individual servers, unless one of the DNS servers in the chain supports recursion itself. To avoid reflection attacks – a special kind of Distributed Denial of Service (DDoS) attack – it is recommended to disable recursion on DNS servers. This means that they should only partake in iterative queries: While your client recursively moves from one DNS server (e.g. the root server) to the next (e.g. the DNS server responsible for .com), each server will only respond to one of your requests and lead you the way to the next DNS server for the next request (iteration). The downside of having your client performing the recursion is of course that observers can see which hostnames you are trying to resolve. DNS over HTTPS provides added (but not perfect) privacy, as I will explain later on.
Without root servers, internet dies within 48 hours
The root server providers and other research agencies take great care to avoid DNS attacks on the root level. Integrity attacks for example would allow attackers to redirect your request for google.com to their malicious website. It is on purpose that different root servers employ different hardware and software, so if an exploit is found in one system, it will not make all root servers in the world equally vulnerable.
All of the more than 1000 root servers contain (in general) equal information and are hence forming a highly available, distributed system. They are maintained by 12 different operators like Verisign, the University of Maryland, the U.S. Army Research Lab, or NASA. Yes, you do see a slight dominance of US American institutions; so much for internet “neutrality”.
Even in the unlikely case that all 1091 root servers went down at the same time, the internet would still stay functional for roughly 48 hours:
If all instances of all Root Servers were to instantaneously become unavailable, the Internet would not immediately shut down. The use of caching by recursive resolvers would keep some root zone information available until the Time-To-Live (TTL) period of cached records expires.
[…]
If the RSS was completely unavailable for an extended period, it is expected that the global set of recursive resolvers would begin to fail linearly over a period of the root zone record TTL (currently 48 hours). The number of Internet users affected by such an outage would roughly be proportional to the number of failed caching resolvers.
Distribution = Stability… and slow adoption
Unfortunately, there are serious design flaws that jeopardize security and privacy even when DNS is working as designed. Technologies such as Domain Name System Security Extensions (DNSSEC) – to ensure data integrity – and DNS over HTTPS (DoH) – to provide privacy and further security – are there for several years or even decades, but adoption is slow: While the distributed design of the internet makes it quite stable against a complete outage, it also requires to align many different parties to get new standards rolled out at scale. Also, since so many different systems and technologies are participating in this interconnected network, backward compatibility is paramount, which keeps loopholes open for attackers.
DNS over HTTPS does not protect from eavesdropping
DNS over HTTPS (DoH) is becoming ever more popular and meanwhile it can even be configured via the Firefox settings GUI – as opposed to the about:config adjustments required before. The difference to the “old” DNS when using DoH is that your workstation will not perform the recursive DNS query anymore, as it was described above. Instead, your DoH provider – such as Cloudflare or Quad9 – will act as your trusted recursive resolver (TRR). While I wrote above that usually a DNS provider will not want to allow recursive queries, but only iterative ones, this is different in the case of DoH. Here, the DNS provider on purpose performs the whole translation from URL to IP address, which otherwise would happen locally on your computer.
The benefit? Privacy and integrity. With some caveats.
Your computer simply reaches out to the DoH provider, using its IP. It then establishes a secure connection (HTTPS), tells the provider which hostname it wants to have resolved and obtains the corresponding IP address. All this happens in an encrypted manner, so an eavesdropper – and even your internet service provider (ISP) – would only see the connection to the DNS server, but the queries hostname would remain invisible.
The perfect solution?
Well, as I said, there are some caveats.
First, DoH does not solve the privacy problem, it simply shifts it. When using DoH, your ISP might not see your specific DNS queries anymore, but now you have to trust the DoH provider. At the end of the day, in both cases there are external entities you need to place your trust in.
Second, the ISP of course still sees the connection to the DoH provider. If they really want to keep you from using DoH, they can simply block that connection and provoke a fallback to “normal” DNS. Such techniques – called DNS hijacking – are also used by the Chinese censorship regime. When using DNS over HTTPS in Firefox, you can check if your browser fell back to plain DNS by opening about:networking.
Third, if you are working in an enterprise environment, your company might well use HTTPS Interception to perform security monitoring on encrypted connection. For this, the IT department will have placed your company’s own certificate authority (CA) into the Trusted Root Certification Authorities Store on your computer. This means that your browser will display the well-known “connection is secure” padlock when you open a website. If you look closely though, the certificate when opening your bank’s website is suddenly not signed by a well-known public CA anymore, but by your company’s CA. This is because in fact you just established an encrypted connection to your company’s gateway and there your connection is unencrypted, analyzed and another connection from there to your target website is established. Since your company computer trusts that CA, it does not complain. In such a setting where your employer has control over assets, you must assume that not only HTTPS Interception, but also many other techniques are in place that reveal just about anything you do.
DoH without ESNI does not make much sense
There is also a fourth point, which is relevant even if your newly set up DNS over HTTPS infrastructure is working properly: Even if you use DNS over HTTPS, eavesdroppers can still see which IP you are connecting to. Even if the DNS query and all your web traffic is encrypted, the destination IP by design must be visible to other machines on the network. As I wrote before, an IP address alone is not a clear indicator of the website you are visiting: In today’s internet with large Content Delivery Networks (CDNs), a whole lot of different websites might be hosted on one IP address. But wait, how does that webserver behind the IP address then know which website you are interested in?
Your browser openly sends out the hostname information – unencrypted.
Yes, that’s right! Even if your whole DNS query is neatly encrypted with DoH and even if your eventual connection to the website of interest is also secure using TLS, your browser will still shout out to the world – in unencrypted form – the hostname it is connecting to. This “shout out” is called Server Name Indication (SNI). It is necessary in situations where more than one domain is hosted on one IP address. It is not necessary in cases where only one specific domain is hosted on the IP address, but – guess what – in these cases it’s already enough to just observe the IP address you are connecting to in order to know which website you were visiting.
Why is SNI necessary?
Ironically enough, SNI is necessary to establish secure connections: If you want to initiate an encrypted connection to a server, you will connect to that IP. If that IP hosts several websites, the server will need to know which certificate to send to your browser. Only with the right certificate will your browser be able to set up an encrypted connection to that website.
If the server behind IP 1.2.3.4 hosts 10 different and mutually independent domains (companyA.org, companyB.org, etc.), it will not only have one certificate to be used for TLS, but more around 10 certificates: At least one for each domain. Each domain might use wildcard certificates for subdomains, but across different domains this is not possible. The server could also use subject alternative names (SANs), where indeed one certificate is valid for several domains. Unfortunately, this quickly becomes impractical when dealing with quickly changing and growing environments.
Enters SNI.
With SNI, your browser simply tells the server which domain it wants to connect to and the server knows which certificate to send. Since this is unencrypted, all your beautiful privacy gained by DoH is immediately lost.
Cloudflare is pushing Encrypted SNI (ESNI), where the trusted recursive resolver that performs the DoH query also provides a public key for the requested hostname. That key can be used to encrypt the SNI call to the target server. The problem is again the same like for DoH: Adoption is slow. As long as clients and servers are not implementing and using it, just having the technology ready “in theory” will not solve the problem of comprised privacy. Same of course applies for DNSSEC.
Hence, while the ongoing growth in DNS over HTTPS (DoH) adoption is certainly a good development in many aspects (although there is also lots of criticism), we will need to wait for a broader adoption of Encrypted Server Name Indication (ESNI), as well as DNSSEC security extension to improve security and privacy of one of the internet’s most important – and most vulnerable – parts: DNS.