DNS over TLS for Improved Privacy

For various reasons, DNS transport could be secured through encryption, with DNS over TLS (aka DoT) being one obvious solution to increase user security. User privacy reached the DNS area some while ago – we have seen a massive move from browser solutions to the adoption and more importantly the usage of secured DNS by applying, in some countries, an automatic switch to encrypted transport.

DNS is business-critical so has to be secured

Why is securing DNS so important? Mostly because DNS is at the intent of most IP communications. Any application on any type of device, on any kind of wired or wireless network – fixed or mobile – uses the DNS protocol to perform resolution of names (human usable) into IP addresses (software usable). As a central component of the IP protocol, the DNS service is key, it has never been replaced and is roughly working like it was in the first days of the Internet.

By analyzing DNS requests used for resolution of public internet sites into IP addresses, it’s possible to get very valuable information on a requester’s device. Details can be obtained about sites visited (through their FQDN), the frequency of the visits, and trends, for example if the user behind the device visits sites related to a specific service, a disease, a product, a travel destination, a religious orientation or a political opinion.

This data can be highly valuable on the open market, so some organizations may be tempted to collect, analyze and monetize it. On the one hand, many users don’t trust their DNS provider in every circumstance, especially on public networks like in hotels or cafés. On the other hand, some users have security concerns and want to be sure that the site and application they are visiting are effectively the legitimate ones. These two simple examples imply that DNS requests are not transformed on their transport route and are not listened to by unauthorized entities using eavesdropping. Bear in mind that collecting DNS information can also be performed using the logging feature of most DNS servers (cf query-log and answer-log), which is very easy to set-up, but requires a powerful engine and storage.

Security starts with DNSSEC

The DNS standard transport protocol (UDP port 53) is really easy to intercept and analyse. It has been built for the purposes of performance, simplicity and robustness, but not for security of the data transported. In order to secure the DNS mechanism, we can act at different levels. The integrity of the exchanged data is already covered by the DNSSEC implementation (see What is DNSSEC) which guarantees the authenticity of the information, though it does not protect against eavesdropping and traffic analysis.

Protection against eavesdropping requires encryption of the communication channel between the DNS clients and servers. DoT and DoH (see What is DNS over HTTPS) offer such functional transport security. DoT proposes transportation of the DNS requests and answers in an encrypted tunnel using the TLS security solution. TLS, previously known as SSL, is used in most protocol implementations using TCP as the transport protocol, with HTTPS being another widely used example of such security. It proposes mutual authentication of encryption and endpoints using public certificates. Using TLS to secure the transport of DNS is costly, it implies delay in exchanges, requires CPU on both sides to perform ciphering and ideally needs a lot of optimization in order to prevent user experience being deeply impacted on low delay transit networks (e.g. FTTH and 5G networks). Finally, to be really efficient, DoT (and also DoH) requires implementation of TLS certificate validation for detection of man-in-the-middle attacks, otherwise it is totally useless with regards to user data security.

DNS Guardian supports DoT

For corporations and operators wishing to provide protection to their users, EfficientIP proposes the support of the DoT encryption service in DNS servers containing our DNS Guardian feature from release 7.2 onwards. This allows protection of devices and traffic from any forwarder server which supports DoT. Located on the same server as all the DNS services and security, it allows the client to easily switch from UDP to TLS. Most implementations on the client side have the ability to test the presence of a DoT service on the standard DNS server IP address and perform fallback if UDP is the only transport protocol available.

So as you can see, DoT is able to improve user security since it covers the eavesdropping and man-in-the-middle parts, but a more important requirement is that the recursive server should be trustworthy. The “honesty” of the resolver is not guaranteed by usage of DoT or DoH as there is no way to be sure it doesn’t collect the data and use it for an undesired purpose. For more information on this part, please take a look at our blog post Why You Shouldn’t Rush Into DoH , which for most aspects is also applicable to DoT.