Whether you like it or not, everyone can see which websites you’re visiting. Even when you see that secure padlock in your browser indicating an ‘HTTPS’ secured website, the actual request your computer makes for the website URL was anything but secure.  The sad fact is that one of the core backbones of the internet, DNS, has no security. It leaves data unprotected in transit, sent in plain text for anyone to see or modify.

What is DNS?

The Domain Name System (DNS) is what your computer uses to figure out where to go when you type in an address like ‘www.globalcerts.net’. With every domain, there needs to be an IP address (think a postal address, but for computers) associated with it so that your browser knows where to connect to load the web site. Since its inception decades ago, DNS has been expanded upon to improve its reliability, speed, and scope. The whole system is distributed across thousands of servers, each having specific ‘zones’ that they have information for.

Not only does DNS serve domain-to-IP address mappings, but various components related to email and internet security. ‘MX’ records tell your mail systems where to send email when you try to send an email to someone. ‘SPF’ records list which servers are supposed to be sending email for a given domain; which greatly help in combating ‘spoofing’, where emails supposedly from a friend are sent via some computer in Russia or China.

Further, DNS can be used to retrieve the official certificates corresponding to a given website, or a given email address. Serving these certificates in DNS allows for you to check that the website you’re connecting to securely is using the right TLS certificate independent of trusting the certificate’s issuer.

DNS is the building block of our patented SecureTier system, which stores the public certificates of all GlobalCerts users as DNS records. This allows our SecureMail Gateway servers to quickly and easily query the SecureTier (like DNS) for the public certificate associated with a recipient. This public certificate is required when sending an S/MIME encrypted email to a given recipient. SecureTier allows for all our customers to be connected in a common, federated system so that they can exchange secure email completely automatically via S/MIME without needing to manually exchange certificates. Although our system is a closed/private one, NIST has recommended a similar approach for secure email for public DNS.

What’s the problem with DNS?

By default, DNS is completely unsecured. The queries coming from your computer, and the responses it receives, travel over the internet unencrypted, with no protection. Anyone with a couple basic tools can easily see these requests coming from your devices and know what sites you’re accessing. Further, DNS responses are completely unsecured and only loosely validated. This can lead to a variety of security issues; the most obvious being all the websites you visit are basically public knowledge.

But it is also possible for the DNS responses to be modified or faked, with potentially disastrous consequences. Imagine typing in ‘yourbank.com’ to visit to your online banking website. But instead of receiving the proper IP address back, your browser receives an bad IP address and sent to a malicious website, ‘yourbank.anothersite.com’. That site could even have a valid SSL certificate, and a login page nearly identical to your bank. Similarly, injecting a ‘poisoned’ MX record into DNS could potentially cause your mail server to deliver your private emails, addressed to an important business partner, to a hacker’s server. Their server will gladly accept it and allow the hacker to read your emails. Neither you or your business partner would even realize this has occurred for days.

Enter DNSSEC

The first step to adding some level of security and authentication to DNS responses was ‘DNSSEC’ (DNS Security Extensions). In DNSSEC, the responses received for a query will also contain a digital signature, and the public certificate of the key used to create the signature. The DNS client or resolver can then verify that the unique signature matches the response received, and further verify that the public key is also valid by checking its ‘issuer’ is trusted, all the way to the DNS root servers if necessary.

The key advantage to DNSSEC is ensuring the integrity of the responses and the authenticity of the servers responding. As long as the signatures verify and the signing certificate links to a trusted root, then there’s no feasible way that it could have been altered or generated by a malicious party.

However, there are a few shortcomings of DNSSEC. First, it provides no confidentiality of the queries, or the responses. It’s still trivial for eavesdroppers to see the websites your visiting, etc. They just can’t fake the responses. Also, the entire system adds lots of complexity to both the DNS records themselves, the size of the responses, and the speed at which DNS queries can be made and validated.

DNSSEC has been available for about a decade now, but it is still very slow to catch on despite being pushed heavily by Internet standards groups and the U.S. National Strategy to Secure Cyberspace. This is mostly due to the complexity, the lack of finalized standards (the RFC defining DNSSEC, proposed in 1999 is still a proposed standard) Many DNS providers (like GoDaddy for example) do not fully support DNSSEC, especially when using a secondary DNS system.

DNS over TLS (DoT)

So how can we improve on the security of DNS without radically disturbing the decades old standards and protocol? Simple: do what was done with email and the SMTP protocol. In the past, all emails travelled over the internet from server to server in plain text, with absolutely no protection. Messages could be intercepted and read, or even modified to change the content. Around the turn of the century, STARTTLS was introduced, which takes regular SMTP traffic exactly as-is, but pushes it through a TLS connection (the same technology used to secure web traffic). Nothing about the SMTP protocol needed to be changed; all traffic simply passed through an encrypted ‘tunnel’ established between the email servers.

The exact same technique is now being applied to DNS requests and responses via DNS over TLS (DoT). A dedicated port (853) is used to differentiate DoT from regular DNS traffic (port 53). This is just like HTTP (port 80) vs secured HTTPS (port 443) traffic. This simple solution not only provides confidentiality of the requests and the responses, but can guarantee the integrity and authenticity when a trusted certificate is used by the server. DoT will even allow for you to mask your activity from your ISP.

It’s 2019; why isn’t all DNS traffic sent over TLS? Well, for one reason, it costs more. DNS is super-lightweight and super-quick, so a modest DNS server can handle thousands of requests a second. Adding a TLS handshake on top of each request/response not only adds a lot of latency in the response, but takes more computing power on both sides, and requires additional overhead to manage the connections. With the adoption of the much quicker TLS version 1.3 protocol, the speed of the initial handshakes will be less of an issue. Also, DNS is NOT a simple end-to-end protocol. When a DNS resolver requests the record for a given domain, the server will need to make ‘recursive’ requests to a hierarchy of servers until it finds the right server that has an authoritative answer for you. To provide TOTAL security, each one of these request/responses will need to be over TLS and the server certificates need to be validated and trusted.

DNS over HTTPS (DOH)

Another emerging technology starting to gain traction now is similar to DNS over TLS but with a slight twist. DNS over HTTPS (DOH) takes your DNS traffic and forms them into an HTTP request (like when you request a certain web page). This request is sent via HTTPS (which uses TLS encryption). The DNS response is sent as a standard HTTP response, again over HTTPS. It’s just like an HTTPS request for a web page or image, but instead the media type is the new ‘application/dns-message’ type. Google and Mozilla are leading the charge in adopting this technology, with Google already providing this as an experimental feature of its latest Chrome browser.

There are criticisms to DOH however. First, it adds a layer of complexity that may not be needed. In essence, we’re converting DNS formatted messages to HTTP requests, THEN applying TLS security on top of that; with no real clear purpose for the HTTP protocol to be involved. The DNS traffic is also carried over the same port 443 for HTTPS, which allows the traffic to pass through most firewalls without modifications, but also makes this traffic indistinguishable from HTTPS web traffic. This can be a positive or negative, depending on if you’re an administrator trying to monitor traffic, or a privacy minded user.

Other than DoT and DOH, there are many other similar DNS technologies that are in various stages of adoption. There is DNSCrypt, an open source project which has been around for a while, but has no formal RFC. There is also CurveDNS, which is a similar technology using Elliptic Curve Cryptography to encrypt DNS traffic.

Conclusion

DNSSEC was a great step forward in offering some level of security to the inherently unsecure DNS protocol. But as we saw, it leaves a lot to be desired regarding message confidentiality. There are many emerging standards and technologies to provide additional security to DNS; most are based around layering security on top of standard DNS requests, whether TLS, HTTPS, or a custom form of encryption.

DoT and DOH are both very similar to STARTTLS (SMTP over TLS). If every server mandated a TLS connection, then there would be no potential for information to be intercepted or modified. However, it is important to note that even if the connection between your computer and your DNS server is encrypted over TLS, it doesn’t necessarily mean that all responses from upstream/root DNS servers also used TLS. So there is still the possibility that your DNS server may be receiving a tampered response from a zone server or a faked response from a 3rd party, pointing you to the wrong server (‘cache poisoning’).

These new technologies are not necessarily a replacement for DNSSEC; both technologies can be used together to provide the best security possible. DNSSEC provides standardized and tested way of verifying DNS responses, all the way from the root DNS servers down. DoT and DOH both provide an easy way to add confidentiality to both DNS requests and responses, while also providing a good level of assurance of the integrity/authenticity of the data.

Sources

https://9to5google.com/2019/10/28/chrome-encrypt-dns/
https://www.bleepingcomputer.com/news/technology/google-unveils-dns-over-https-doh-plan-mozillas-faces-criticism/

DNS over TLS:
https://tools.ietf.org/html/rfc7858
https://developers.google.com/speed/public-dns/docs/dns-over-tls
https://blog.apnic.net/2018/08/20/dnssec-and-dns-over-tls/
https://blog.apnic.net/2017/01/06/lets-encrypt-dane/

DNS over HTTPS:
https://tools.ietf.org/html/rfc8484