DNS Privacy Considerations

This document is an analysis of the DNS privacy issues, in the spirit of Section 8 of [RFC6973].¶

The Domain Name System (DNS) is specified in [RFC1034], [RFC1035], and many later RFCs, which have never been consolidated. It is one of the most important infrastructure components of the Internet and is often ignored or misunderstood by Internet users (and even by many professionals). Almost every activity on the Internet starts with a DNS query (and often several). Its use has many privacy implications, and this document is an attempt at a comprehensive and accurate list.¶

Let us begin with a simplified reminder of how the DNS works (see also [RFC8499]). A client, the stub resolver, issues a DNS query to a server called the recursive resolver (also called caching resolver, full resolver, or recursive name server). Let's use the query "What are the AAAA records for http://www.example.com?" as an example. AAAA is the QTYPE (Query Type), and http://www.example.com is the QNAME (Query Name). (The description that follows assumes a cold cache, for instance, because the server just started.) The recursive resolver will first query the root name servers. In most cases, the root name servers will send a referral. In this example, the referral will be to the .com name servers. The resolver repeats the query to one of the .com name servers. The .com name servers, in turn, will refer to the example.com name servers. The example.com name servers will then return the answers. The root name servers, the name servers of .com, and the name servers of example.com are called authoritative name servers. It is important, when analyzing the privacy issues, to remember that the question asked to all these name servers is always the original question, not a derived question. The question sent to the root name servers is "What are the AAAA records for http://www.example.com?", not "What are the name servers of .com?". By repeating the full question, instead of just the relevant part of the question to the next in line, the DNS provides more information than necessary to the name server. In this simplified description, recursive resolvers do not implement QNAME minimization as described in [RFC7816], which will only send the relevant part of the question to the upstream name server.¶

DNS relies heavily on caching, so the algorithm described above is actually a bit more complicated, and not all questions are sent to the authoritative name servers. If the stub resolver asks the recursive resolver a few seconds later, "What are the SRV records of _xmpp-server._tcp.example.com?", the recursive resolver will remember that it knows the name servers of example.com and will just query them, bypassing the root and .com. Because there is typically no caching in the stub resolver, the recursive resolver, unlike the authoritative servers, sees all the DNS traffic. (Applications, like web browsers, may have some form of caching that does not follow DNS rules, for instance, because it may ignore the TTL. So, the recursive resolver does not see all the name resolution activity.)¶

It should be noted that DNS recursive resolvers sometimes forward requests to other recursive resolvers, typically bigger machines, with a larger and more shared cache (and the query hierarchy can be even deeper, with more than two levels of recursive resolvers). From the point of view of privacy, these forwarders are like resolvers except that they do not see all of the requests being made (due to caching in the first resolver).¶

At the time of writing, almost all this DNS traffic is currently sent unencrypted. However, there is increasing deployment of DNS over TLS (DoT) [RFC7858] and DNS over HTTPS (DoH) [RFC8484], particularly in mobile devices, browsers, and by providers of anycast recursive DNS resolution services. There are a few cases where there is some alternative channel encryption, for instance, in an IPsec VPN tunnel, at least between the stub resolver and the resolver. Some recent analysis on the service quality of encrypted DNS traffic can be found in [dns-over-encryption].¶

Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp]. This has practical consequences when considering encryption of the traffic as a possible privacy technique. Some encryption solutions are only designed for TCP, not UDP, although new solutions are still emerging [RFC9000] [DPRIVE-DNSOQUIC].¶

Another important point to keep in mind when analyzing the privacy issues of DNS is the fact that DNS requests received by a server are triggered for different reasons. Let's assume an eavesdropper wants to know which web page is viewed by a user. For a typical web page, there are three sorts of DNS requests being issued:¶

Primary request:

This is the domain name in the URL that the user typed, selected from a bookmark, or chose by clicking on a hyperlink. Presumably, this is what is of interest for the eavesdropper.¶

Secondary requests:

These are the additional requests performed by the user agent (here, the web browser) without any direct involvement or knowledge of the user. For the Web, they are triggered by embedded content, Cascading Style Sheets (CSS), JavaScript code, embedded images, etc. In some cases, there can be dozens of domain names in different contexts on a single web page.¶

Tertiary requests:

These are the additional requests performed by the DNS service itself. For instance, if the answer to a query is a referral to a set of name servers and the glue records are not returned, the resolver will have to send additional requests to turn the name servers' names into IP addresses. Similarly, even if glue records are returned, a careful recursive server will send tertiary requests to verify the IP addresses of those records.¶

It can also be noted that, in the case of a typical web browser, more DNS requests than strictly necessary are sent, for instance, to prefetch resources that the user may query later or when autocompleting the URL in the address bar. Both are a significant privacy concern since they may leak information even about non-explicit actions. For instance, just reading a local HTML page, even without selecting the hyperlinks, may trigger DNS requests.¶

Privacy-related terminology is from [RFC6973]. This document obsoletes [RFC7626].¶

from Hacker News https://ift.tt/3hYX4Tt