Introduction
The domain name system (DNS) is an essential protocol used for naming and addressing of resources in private networks and on the public Internet. In private networks as well as the public Internet, DNS is usedamong other purposesfor mapping domain names to IP addresses. In private networks, however, one does not need to use a delegated top level domain (TLD) for naming hosts and services, and can use pseudo-TLDs, TLDs that are only recognizable within the private network. For example, pseudo-TLDs such .i2p, .onion, and .exit, among others, have been used as a standard suffix for naming services in various private networks. Among them, .onion has been used as the standard pseudo-TLD for naming hidden services in Tor. Queries initiated in the Tor network to .onion second level domains (SLDs) are routed within the Tor network, to aid the goal of hidden services, and are not intended for external use. If one is to query a .onion domain in the public DNS infrastructure, the query will be answered with an NXDOMAIN response ( i.e., nonexistent domain) from the root, because .onion is not delegated in the root DNS zone. In reality, under no circumstances, a private network query should be allowed in the public DNS infrastructure.
However, reality somewhat differs: it has been recently reported and systematically demonstrated [], calling for further exploration.
Given the special nature of some of the pseudo-TLDs like .onion, special considerations need to be taken into account to prevent their leakage. For example, given that .onion names are used for querying hidden services, an eavesdropper on the DNS resolution system (on various links) can associate the .onion query with a user, or reduce the potential number of users associated with that query to a tractable set size, thus breaching the privacy of the user. Roughly speaking, the privacy leakage here means that the adversary will be able to tell that a user
(the set of all users) is interested in
(a query among all queries), or a user
(where
) is interested in q , where (potentially)
. Here we are assuming that the adversary is residing on the public Internet, and does not have any control over the private network ( i.e., Tor).
To address this real scenario of leakage, Appelbaum and Muffet proposed in RFC 7686 [] the special use .onion domain name, and various best practice recommendations of blocking of .onion strings (hidden service addresses) at (i) the stub (browser), (ii) recursive, and (iii) authoritative resolvers (among other equally important best practice recommendations). The hope is that the deployment of such recommendations will improve the privacy of the users using Tor in general and hidden services in particular. No work, however, is done to assess the validity of such hope under any settings, let alone realistic deployment scenarios.
Contributions. In this paper we set out to analyze the privacy implications of blocking of the leaked DNS queries as a mean of improving the privacy of users. We initiate for such study by formalizing the adversary of a DNS system as a collection of capabilities on various links in the DNS resolution structure, as informally argued by Mohaisen and Mankin []. We use a well-defined advantage of the adversary to quantify the breached privacy of users over their queries with and without blocking and under various deployment scenarios captured by a parameterized model. We find out that while a universal deployment of such blocking strategies will naturally result in a great privacy benefit to users, such universal deployment is unlikely to happen immediately. As a result, a realistic analysis is drawn from partial deployment, in which we highlight the consequence of shared infrastructure like the DNS resolution system: the privacy of an individual does not only depend on his actions but also the actions of other users. In other words, we highlight scenarios where blocking by some users would make the matters worse for others who do not block.
Organization. The organization of the rest of this paper is as follows. In Sect. we draw concluding remarks.
Background
Domain Names and their Resolution. The DNS is a hierarchical naming system by design []), one of 13 root name servers is queried for the address of com those servers operate in anycast setting, where queries are routed to the geographically closest server among them. Upon receiving the address of com s authoritative name server, it is queried for the address of the authoritative name server of example , and so forth until the IP of the resource of interest for the full domain name is returned. In the plain DNS ( i.e., no security in place), a query for a name that does not exist is answered by NXDOMAIN response. Such response could be returned at any round of resolution of a hierarchical name, including by the root name server.
Resolution System. The above resolution procedure is only conceptual and does not take into account DNS optimizations geared towards improving the response time and manageability of the DNS resolution process by incorporating other entities. In particular, the DNS resolution system typically consists of three entities: stub resolvers (also called clients), recursive resolvers , and authoritative name servers (to simplify the analysis, one could view the authoritative name servers collectively as one of such servers). The stub resolver resides on the host, and forwards queries on behalf of a user to the recursive resolver, which is responsible for the iterative process of resolution above by querying the various authoritative name servers for addresses of names in a full domain name. The recursive resolver may also have caching capabilities , thus improving the latency for subsequent requests of previously resolved domain names.