When it comes to digital age, we quickly adopted a wide range of technologies that enable us manage our finances, collaborate with colleges around the world or calling a cab with a touch of our phone.
Using our web browsers we can consume and create content on demand anywhere and anytime. All of this would fall apart weren’t it for a single protocol developed in the dark ages of the internet.
The DNS or the Domain Name System is an network name resolution system and a protocol used to translate domain names like “facebook.com” to a corresponding IP address. Without it, our web browsers, applications and services would be clueless where to direct our network and internet requests.
DNS uses a hierarchy pyramid like system to ensure high availability. On its top are only 13 root DNS servers which are authoritative to all of its subsidiaries. Should these go down, the global internet as we know it would start to fall apart.
So how does DNS work ?
If you are unfamiliar with the concept of DNS, let’s go through it in steps:
- You type a web address into your browser, for instance “www.facebook.com”. To reach the service however, your browser needs to know the correct IP address of the site.
- Operating system queries the DNS server configured within your network connection with a simple request on port 53: Get me the IP address for “facebook.com” domain.
- These DNS server or resolver is typically operated by your internet service provider (ISP). This server does not contain the IP addresses to all domains of the internet, so it contacts other DNS servers. First the root DNS server is contacted. Since this is a top level domain, the root server will return an address of the top level domain (TLD) name server. ISPs resolver then queries the TLD DNS server and is provided with the name server of the service you are trying to access.
- At last the resolver contacts the name server of Facebook and asks for the IP address of the “www.facebook.com”. The response is forward to your computer.
- Your browser reads the response and connects to the correct IP address.
- All of this takes milliseconds to process.
What about security ?
This is basically the operation of DNS in a nutshell, but this blog is focused on security. So how is this fundamental service secured by default?
The answer might surprise you. By nature DNS uses a plain text protocol without any security measures what-so-ever.
Remember it comes from the dark ages of internet. When the first computer networks were designed, there were no hackers, malware, e-commerce, internet banking at that time. Probably even the first pioneers of IP networking did not foresee the masive impact its going to have on a world in a few years.
So security at that time was not a concern. Okay, so why should we care?
From security standpoint there are two concerns:
- Since DNS uses a plain text protocol, any party between the client and the server can read its contents. A party that has access to the DNS communication logs (typically ISP) know every web page, application, service that we have visited. This data is used for marketing and business inteligence purposes to target advertisements.
- The modification of the DNS response however is a completely different story. Since your browser depends on the DNS response to direct him to the correct server, if a malicious party modifies the response, your browser will connect to a server that has been put into the DNS response. That could be a fake internet site built for the purpose of misuse or theft. The chances for detection are minimal.
There has been calls for securing DNS for quite some time, and there are results. Unfortunately its not so simple. Currently there are three approaches to secure DNS with their upsides and downsides. They all use cryptography and Public Key Infrastructure in their core.
Root DNS organizations
University of Southern California (ISI)
University of Maryland
Internet Systems Consortium, Inc.
US Department of Defense (NIC)
US Army (Research Lab)
Let’s go through the various security mechanism to show how they protect the standard DNS name resolution.
DNS Security Extensions (DNSSEC)
DNSSEC has been developed for the purpose of preventing DNS spoofing (replacing the correct IP address in the response with a fake one). It utilizes a digital signature added by the DNS server in each response.
The digital signature is a hashed value of the correct response encrypted by the private key of the DNS server. When your computer receives the response, the digital signature is decrypted using the public key and the hash is compared with the response.
If an attacker replaces the correct address in the response with a fake one, your computer is able to detect a mismatch. Since the attacker without the knowledge of the DNS server private key is not able to modify the digital signature to match the fake IP address.
This effectively prevents the replacement of IP address in the response. The DNSSEC uses the same port 53 as the DNS, but instead of UDP it uses TCP to allow much larger payloads.
DNS over TLS (DoT)
DoT is a protocol developed for DNS with the objective to completely encrypt and wrap the DNS request and response into a standard Transport Layer Security protocol.
It uses dedicated TCP port 853. Before the DNS data are exchanged between the client and the DNS resolver a TLS session is established, verifying the resolver public certificate and calculating symmetric key for encryption.
The communication between the resolver and the client is then fully encrypted preventing the attacker from seeing or modifying the DNS request and response.
DNS over HTTPS (DoH)
DoH is the newest approach to the problem of plain text DNS requests and responses. While similar to DoT, the main difference is that DoH is directly used by the internet browsers and applications, without the use of the legacy domain name resolution in operating system.
It wraps DNS request and response directly within the HTTPS which enabled its rapid deployment in the past months despite the fact being younger then DoT.
DoH is currently implemented in Google Chrome and Mozzila and Microsoft plans to implement it within the standard Windows DNS services.
Since it uses HTTPS port 443, there is no need for specific port configuration or tools. It works seamlessly just like standard HTTPS and can be used and implemented immediately without the need of OS support or DNS daemon.
The core for all DNS security mechanisms is proper Public Key Infrastructure and certificate life cycle management. A single expired certificate can have a huge impact on the whole operation of the secured DNS.
While the three DNS extensions provide significant security benefits, they are not without fault. All of them have their shortcommings.
DNS Security Extensions (DNSSEC) for instance only provides protection against the modification/hijacking of DNS replies.
It does not prevent the attacker to eavesdrop, providing him with the complete browsing history.
The use of DNSSEC also brings complexity and performance issues as each reply has to be signed.
The biggest issue however is that it is rarely used in an end-to-end manner. DNSSEC is usually deployed between the DNS responder of the ISP and the root and TLD DNS of the target web service.
The last mile between the your computer and the DNS of your ISP is not secured. A compromised router or a malware can still be used to modify the DNS response and redirect your browser.
DNS over TLS and DNS over HTTPS main issue lies in what comes after the browser obtained the correct IP address of the server.
The browser will establish a connection to the server, which means establishing a TLS secured connection. To get the correct certificate containing the public key of the service, the server needs to know what web page the client is trying to access. This is provided in a Server Name Indicator header in plain text HTTP before the encryption is established.
Now all of the effort that went into protecting the DNS data is basically nullified, since the attacker has access to the page we are trying to access from a different channel.
DNS over TLS has another big issue as its not natively supported by major operating systems and uses a specific port that might not be enabled in your ISPs or corporate firewalls.
This is why DNS over HTTPS has replaced DoT before the service even began to be adopted.
The light at the end of the tunnel
In September 2018, Cloudflare has drafted an ESNI initiative. Its purpose is to encrypt the SNI header using a public key obtained from the DNS over HTTPS reply.
In simple words, when you query the DoH with a domain name (for instance www.google.com), the IP address of the service as well as the public key to encrypt the SNI header is provided.
This completely closes the communication in an encrypted session and closes one of the biggest internet bug. The draft has been opened within the Internet Engineering Task Force which develops internet standards. We are likely going to see the full standard to be released in 2020.
We went through advantages of encrypted DNS and through some of its struggles. So whats the ugly part ?
Too much anonymity
The first one is related to the fact that completely hiding the activity of the user on the web provides complete browsing privacy, but that might go against the needs of the ISPs or network administration teams in companies.
How do you prevent employees from accessing malicious sites, unwanted content in offices or criminal activity? Creating a blacklist of IP addresses that are supposed to be blocked is not realistic so security based software and proxies use DNS for this task.
Privacy vs. Security
Most of us have experience with site blocking in a corporate office. Instead of opening a web page of the requested site you are presented with a warning page that informs you that this content is blocked.
Security software has intercepted your DNS request for the site. Instead of the correct IP address it has modified the response and provided your browser with a site presenting the warning message. This is very similar of what an attacker would do, hijacking the connection session using malformed DNS reply to direct victims browser to a different site.
So if the DNS requests are originating from the browser itself in a encrypted session over HTTPS, most of the network security measures preventing the users to access malicious sites are basically useless, creating considerate security loophole.
Another “ugly” part comes from how the DNS over HTTPS operates.
The browser queries its predefined secure DNS servers directly instead of using the network configuration of the computer. The principle “my network, my rules” does not apply anymore. Instead of using decentralized DNS servers, the browser prefers the centralized infrastructure of DNS over HTTPS that is controlled by the developer of the browser itself.
So what if these servers are compromised or out of service ? While companies like google or Mozilla are arguing that they would fallback to the default DNS, network administrators and users loose control over the DNS.
We are looking in the future, where encrypted DNS services are going to be mass deployed. But that also creates challenges for the network administrators and security officers to adjust their operation to allow this new trend while maintaining secure internal networks.
Get in touch with us to know more!
We are on LinkedIn, follow us!
If you like what we are doing than do not hesitate and contact us for more information! We believe that we have experience and knowledge that can be a benefit for your business.