Even when Internet content is protected by encryption with HTTPS or TLS protocols, user online activity can still be exposed to spies who monitor DNS transactions. Understanding how to mitigate the privacy threat posed by DNS begins with understanding how DNS can expose information about the websites that users access.
Pretty much every time we use a network app it starts with a DNS query to dynamically map the name of a server that we need to access a set of IP addresses that can be used by the internet protocol. For example, in the most trivial case where a user wants to visit a website – for example, www.example.com – the first step performed by the web browser is to obtain an IP address that matches the domain name. So the set of DNS queries we make may disclose information about the websites we visit, the applications we use, and sometimes even the people we communicate with.
Consider how the different types of DNS servers interact in order to resolve a domain name to an IP address. The diagram below shows how a recursive resolver first queries an authoritative root server to confirm the top level of the domain name; then the authoritative server for all domains with the top level domain .com; then the authoritative server for the example.com domain.
A simple analysis of this DNS resolution scenario sheds light on the implications of DNS privacy. First, since DNS does not implement any mechanism to ensure the confidentiality of DNS transactions, all DNS queries and responses are sent in the clear, and therefore all nodes that handle the queries – including the recursive resolver and the various Authoritative DNS servers – will be able to record the original query. Second, all nodes that process the request packets – that is, all intervening routers – can access the original request as well. Finally, because the recursive resolver returns the original request to every authoritative server it contacts, the original request is also leaked to them, unnecessarily.
Improve DNS privacy
Here are two changes to the DNS resolution process that can improve end-user privacy protection:
- ensure the confidentiality of DNS transactions through encryption; and
- minimize information disclosed to authoritative DNS name servers.
Making DNS transactions confidential involves encrypting transactions between stub resolvers and recursive resolvers and transactions between recursive resolvers and authoritative name servers. Because it is easier to secure transactions between a stub resolver and a recursive resolver, this is the only set of transactions for which confidentiality mechanisms have been standardized and implemented.
Protocols for DNS privacy via encryption
DNSCrypt was the first widely used protocol to encrypt and authenticate DNS transactions between stub resolvers and recursive resolvers. The DNSCrypt protocol has never been subjected to the Internet Engineering Task Force (IETF) standards process. But it is publicly documented, and open source implementations are available.
In recent years, the IETF has produced three encryption and authentication protocols to improve DNS privacy:
- Point: DNS over TLS is a standards-compliant protocol defined in RFC (Request for Comments) 7858 that specifies the use of DoT to provide privacy through encryption.
- DoD: An experimental protocol defined in RFC 8094, DNS over Datagram Transport Layer Security relies on DTLS to protect User Datagram Protocol traffic, in the same way that TLS protects TCP traffic.
- DoH: Another standards-compliant protocol defined in RFC 8484, DNS over HTTPS provides a mechanism for sending DNS queries and responses through the HTTP Secure Protocol, which defines the protocol for sending HTTP traffic over TLS.
All three approaches encrypt DNS transactions between stub resolvers and recursive resolvers. DoT can also potentially be used to encrypt transactions between recursive resolvers and authoritative name servers. Each of these techniques has different levels of implementation and deployment. For obvious reasons, all techniques require support for both stub resolver and recursive resolver, as well as proper configuration on both.
Improve DNS privacy by limiting data leaks
Preventing the original DNS query from leaking to authoritative name servers is a much easier task than implementing encryption protocols. It boils down to returning the original query only when strictly necessary. As illustrated above, in the traditional DNS resolution process, the original DNS query is returned to each of the authoritative name servers that are contacted. However, a recently standardized technique called minimization of the query name, or minimizing QNAME, changes the DNS resolution process at the recursive resolver level so that the original query is exposed to authoritative servers only when strictly necessary.
With QNAME minimization in place, the previous example of DNS resolution of the domain name www.example.com to an IP address would be as shown here.
Rather than returning the original query to each authoritative name server, the recursive resolver instead queries the authority of each of the zones involved, starting with the root zone – thus requesting name server records only for a suffix of the original domain name – and return the original request only to the authoritative name server of the corresponding zone. This effectively mitigates information leakage to authoritative name servers. QNAME minimization only requires proper support in recursive resolvers, and many popular resolvers already ship with QNAME minimization support enabled by default.