Fotolia
How can DNS privacy issues be addressed?
Learn two techniques for improving end-user DNS privacy protection that prevent DNS from exposing information about websites users visit and the people users communicate with.
Even when internet content is protected by encryption with the HTTPS or TLS protocols, users' online activity can still be exposed to eavesdroppers who monitor DNS transactions. Understanding how to mitigate the threat to privacy posed by DNS begins with understanding how DNS can expose information about the websites users are accessing.
Virtually every time we use a network application, it starts with a DNS query to dynamically map the name of some server we need to access to a set of IP addresses that can be employed 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 the web browser performs is to obtain an IP address corresponding to the domain name. Thus, the set of DNS queries we perform can leak information about the websites we visit, the applications we use and, at times, even the people we communicate with.
Consider how different types of DNS servers interoperate 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 .com top-level domain; and then the authoritative server for the example.com domain.
A simple analysis of this DNS resolution scenario sheds some light on DNS privacy implications. First, since DNS does not implement any mechanisms to provide confidentiality to DNS transactions, all DNS queries and responses are sent in the clear, and therefore, all nodes that process the queries -- including the recursive resolver and the various authoritative DNS servers -- will be able to log the original query. Second, any nodes that process the query packets -- that is, any intervening routers -- can also access the original query. Finally, since the recursive resolver resends the original query to each authoritative server it contacts, the original query is leaked to them, unnecessarily, as well.
Improving DNS privacy
Two changes to the DNS resolution process that can improve end-user privacy protection are the following:
- providing confidentiality to DNS transactions through encryption; and
- minimizing the information leaked to DNS authoritative name servers.
Making DNS transactions confidential implies encrypting the transactions made between stub resolvers and recursive resolvers and the transactions between recursive resolvers and the authoritative name servers. Because it is easier to secure transactions between a stub resolver and a recursive resolver, this has been the only set of transactions for which confidentiality mechanisms have been standardized and implemented.
Protocols for DNS privacy through 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 submitted 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 protocols for encryption and authentication to improve DNS privacy:
- DoT: DNS over TLS is a standards-track 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 the DTLS protocol to protect User Datagram Protocol traffic, similar to the way TLS protects TCP traffic.
- DoH: Another standards-track protocol defined in RFC 8484, DNS over HTTPS provides a mechanism for sending DNS queries and responses over 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 in both the stub resolver and the recursive resolver, along with appropriate configuration on both.
Improving DNS privacy by limiting data leakage
Preventing the original DNS query from being leaked to authoritative name severs is a much easier task than implementing encryption protocols. It boils down to resending the original query only when strictly necessary. As illustrated above, in the traditional DNS resolution procedure, the original DNS query is resent to each of the authoritative name servers that are contacted. However, a recently standardized technique called query name minimization, or QNAME minimization, modifies the DNS resolution procedure at the recursive resolver such that the original query is exposed to authoritative servers only when strictly necessary.
With QNAME minimization in place, the previous DNS resolution example of the domain name www.example.com into an IP address would be as illustrated as seen here.
Rather than resending the original query to each authoritative name server, the recursive resolver instead queries for the authority of each of the involved zones, starting from the root zone -- thus requesting name server records only for a suffix of the original domain name -- and resending the original query only to the authoritative name server of the corresponding zone. This effectively mitigates the information leakage to authoritative name servers. QNAME minimization only requires appropriate support in recursive resolvers, and many popular resolvers already ship with support of QNAME minimization enabled by default.
