Figure 1: Domain resolution process with a recursive resolver
2 Threat Model and Mechanisms
In this section, we first give an overview of how domain
names are translated into addresses using DNS. Then we
introduce our threat model of DNSIntercept, with a tax-
onomy of interception paths according to our observa-
tion. Finally, we discuss the potential interceptors and
their behaviors.
2.1 Domain Resolution Process
DNS is a hierarchical naming system organized to han-
dle domain resolutions at different levels. At the top of
the hierarchy is DNS root which manages Top-Level Do-
mains (TLD) resolutions. Second-Level Domains (SLD)
are delegated to resolvers below DNS root. Consisting
of labels from all domain levels, a fully qualified domain
name (FQDN) specifies its exact location in the DNS
hierarchy, from its lowest level to root. As a example,
www.example.com is an FQDN, and its corresponding
TLD and SLD are com and example.com.
When a client requests resolution of a domain, the res-
olution is typically executed by a recursive DNS resolver
at first, which can be either assigned by ISP or specified
by Internet users. Illustrated in Figure 1, the recursive
resolver iteratively contacts root, TLD and SLD name-
servers to resolve a domain name, and eventually returns
the answer to the client. Therefore, intercepting DNS
traffic to a recursive resolver directly affects the domain
resolution process for users.
2.2 Threat Model
Figure 2 presents our threat model. We assume that
users’ DNS resolution requests are monitored by on-path
devices. These on-path devices are able to intercept and
selectively manipulate the route of DNS requests (e.g.,
by inspecting destinations and ports) which are sent to re-
cursive resolvers like public DNS servers originally. The
on-path devices either redirect or replicate the requests
to alternative resolvers (typically, local DNS resolvers),
which perform the standard resolution process. Finally,
before responses are sent from alternative resolvers back
to clients, the sources are replaced with addresses of the
Figure 2: Threat model
Figure 3: Four DNS resolution paths (request shown only)
original resolvers. Therefore, from a client’s perspective,
DNS responses appear to come from the original DNS
resolvers according to their source addresses, making the
actual interception behaviors difficult to be discerned.
By default, in order to handle DNS requests, Internet
users are assigned with local DNS resolvers by ISPs. In
the mean time, users reserve the right to specify their
preferred recursive resolvers to launch DNS requests (in
particular, public DNS servers). However, our study
shows that, for users using designated DNS servers, not
only does DNSIntercept violate the will of users, but it
also can bring in security issues.
Scope of study. We aim to measure and characterize
DNSIntercept through large-scale data analysis. We
focus on how DNS resolution paths between clients and
well-known public DNS resolvers are tampered. Other
types of network traffic manipulation mechanisms, such
as BGP prefix hijacking [51] and unauthorized manipu-
lation of DNS root servers [27], which have been system-
atically studied before, are not considered in our study.
Taxonomy of DNS resolution paths. In this study, we
classify the mechanisms of DNS resolution into four cat-
egories, based on how the resolution path is constructed
during the stage of the request. Except for Normal res-
olution, all the other three scenarios are regarded as
DNSIntercept. Figure 3 presents the paths of DNS re-
quests in the four DNS resolution mechanisms.
• Normal resolution. The resolution strictly follows the
standard process. A DNS query sent by client only
reaches the specified resolver, without being modified
by any on-path device. The specified resolver per-
forms the resolution by contacting authoritative name-
servers if the resolution is not cached.
• Request redirection. The original DNS query sent to
USENIX Association 27th USENIX Security Symposium 1115