Oblivious DNS: Practical Privacy for DNS Queries
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Oblivious DNS: Practical Privacy for DNS Queries
Paul Schmitt, Anne Edmundson, Nick Feamster
Princeton University
arXiv:1806.00276v1 [cs.NI] 1 Jun 2018
Abstract the DNS requires the user to place tremendous trust in DNS
operators, who can see all of the DNS queries that a user
Every Internet communication typically involves a Domain issues. Whether the operator is an Internet service provider
Name System (DNS) lookup for the destination server that (ISP) or a third party is less concerning than the fact that
the client wants to communicate with. Operators of DNS re- some single operator can observe and retain this sensitive
cursive resolvers—the machines that receive a client’s query information. This paper presents a system, called ODNS,
for a domain name, resolve it to a corresponding IP ad- which attempts to solve this problem.
dress, and ultimately return the IP address to the client—can
Figure 1a illustrates the basic operation of conventional
learn significant information about client activity. Past work,
DNS, as well as the privacy vulnerabilities that it introduces
for example, indicates that DNS queries reveal information
for every Internet user. Typically, when a client generates
ranging from web browsing activity to the types of devices
a request for a domain, such as foo.com, the client’s stub
that a user has in his or her home (and the extent to which
resolver first contacts its recursive DNS resolver. Assum-
they are being used). Recognizing the privacy vulnerabili-
ing that no answers for the domain are cached, the recur-
ties associated with DNS queries, various third parties have
sive sends the query to the root nameserver, which refers
created alternate DNS services that obscure a user’s DNS
the recursive to the top-level domain (TLD) server for .com,
queries from his or her Internet service provider. Yet, these
which in turn returns a referral to the authoritative server
systems merely transfer trust to a different third party. We
for foo.com, which ultimately returns the IP address for the
argue that no single party should be able to associate DNS
server that the client is seeking to connect with.
queries with a client IP address that issues those queries. To
This behavior means that DNS queries and responses are
this end, we present Oblivious DNS (ODNS), which intro-
viewable as plaintext at the recursive resolver. As a result,
duces an additional layer of obfuscation between clients and
they can reveal significant information about the Internet
their queries. To do so, ODNS uses its own authoritative
destinations that a user or device is communicating with. For
namespace; the authoritative servers for the ODNS names-
example, the domain names themselves reveal the websites
pace act as recursive resolvers for the DNS queries that they
that a user visits. Additionally, in the case of smart-home
receive, but they never see the IP addresses for the clients
Internet of Things (IoT) devices, DNS queries may reveal
that initiated these queries. We present an initial deployment
the types of devices in user homes. Previous work has also
of ODNS; our experiments show that ODNS introduces min-
demonstrated that DNS lookups can identify the websites
imal performance overhead, both for individual queries and
that a user is visiting even when they are using an anonymiz-
for web page loads, and is compatible with existing DNS in-
ing service such as Tor [16]. Recursive DNS resolver oper-
frastructure.
ators can readily associate and track client identities (i.e., IP
addresses) along with information about their DNS queries,
1 Introduction creating a fundamental point of privacy risk.
A user’s Internet Service Provider (ISP) often operates the
Almost all communication on the Internet today starts with a user’s default recursive DNS resolver, giving the ISP poten-
Domain Name System (DNS) lookup. Before communicat- tially extraordinary access to DNS query information. To
ing with any Internet destination, a user application typically mitigate this risk, several entities, including Google, Cloud-
first issues a Domain Name System (DNS) lookup, which flare [36], and Quad9 [32] operate “open” recursive DNS re-
takes a domain name (e.g., google.com) and returns an IP solver services that anyone can use as an alternative to their
address for the server that the client should contact. Today, ISP’s DNS recursive resolver. Yet, when a user switches to
1
such an alternate DNS recursive resolver, the privacy prob- server. The stub resolver must take an existing DNS query,
lem isn’t solved; rather, the user must then trust the operator encrypt it, and append a ODNS-specific domain to ensure
of the open recursive instead of their ISP. Essentially, the that the query is forwarded to the ODNS authoritative DNS
user must decide whether they trust their ISP or some other server. The ODNS authoritative DNS server decrypts the
organization—some of which are even in the business of col- queries and must also act as a recursive DNS resolver, ul-
lecting data about users. timately retrieving the DNS record that corresponds to the
Other approaches have layered encryption on top of DNS. client’s initial query. We implement this functionality in a
For example, DNS-over-TLS [21], DNS-over-DTLS [33], prototype stub resolver and DNS authoritative server in Go.
and DNS-over-HTTPS [20] send DNS queries over an en- ODNS’s privacy enhancements come at a performance cost.
crypted channel, which prevents an eavesdropper between Our trace-driven evaluation shows that any individual un-
the client and the recursive resolver from learning the con- cached DNS lookup is slower due to two factors: 1) our
tents of a DNS lookup but does not prevent the recur- cryptographic operations add roughly two milliseconds to
sive resolver itself from linking queries and IP addresses. the lookup time; and 2) the round-trip time between the client
DNSCurve uses elliptic curve cryptography to encrypt DNS and the authoritative server is added for each lookup. We
requests and responses; it also authenticates all DNS re- mitigate the impact of round-trip time latency by designing
sponses and eliminates any forged responses [6]. DNSCrypt ODNS to use anycast. Ultimately, our evaluation shows that
encrypts and authenticates DNS traffic between a client and the performance overhead on web page load times is negli-
a recursive resolver [12]. Neither of these approaches pre- gible. Additionally, we reduce the traffic burden placed on
vent the recursive resolver from observing DNS queries and existing recursive resolvers by implementing a cache at the
responses. stub resolver.
This work takes a different tack: Instead of merely shift-
ing the trust anchor from an ISP to some other third party, 2 DNS Background
we seek to prevent a recursive DNS resolver from ever asso-
ciating IP addresses with the queries they make. To do so, The domain name system is the hierarchical, decentralized
we design, implement, and deploy Oblivious DNS (ODNS), infrastructure responsible for translating between domain
which (1) obfuscates the queries that a recursive resolver sees names and the associated information that is necessary for
from the clients that issue DNS queries; and (2) obfuscates data connectivity [28,29]. Clients, such as Internet browsers,
the client’s IP address from upper levels of the DNS hier- issue DNS queries to find the IP address of a server that
archy that ultimately resolve the query (i.e., the authorita- contains content the user requests. Typically, for a given
tive servers). ODNS operates in the context of the existing DNS request, there are up to five DNS servers that can be
DNS protocol, allowing the existing deployed infrastructure involved in resolving information for a domain name with
to remain unchanged. ODNS decouples client identity from each server playing a different role (Figure 1a): 1) stub re-
queries by leveraging the behavior of the global DNS sys- solver or ”client”; 2) recursive resolver; 3) root nameserver;
tem itself. A client sends an encrypted query to a recursive 4) top level domain (TLD) nameserver; and 5) authoritative
resolver, which then forwards the query to an authoritative nameserver.
DNS server that can resolve ODNS queries. The recursive Stub resolvers are lightweight processes included in oper-
resolver never sees the DNS domain that the client queries, ating systems and are the first step toward resolving queries
and the ODNS authoritative server never sees the IP address for all lookups for the OS. They initiate DNS queries to
of the client. the larger infrastructure, typically toward a recursive re-
ODNS provides benefits for both the recursive resolver solver. The recursive resolver will inspect the query and
operators as well as users of the system. The rich informa- check whether there is a cached answer, if so, the response
tion available at the recursive resolver can make operators the is returned to the stub. If the answer is not cached, the re-
targets of data requests. ODNS reduces the information that cursive will then act on the stub’s behalf to find the answer.
operators are able to know as they are unable to know the If the query is not cached and includes a domain for which
domains that clients query, making them less-valuable tar- the recursive server does not already know the address for
gets. In essence, the operators are oblivious to their client’s the domain’s authoritative nameserver it will query the root
requests. Likewise, users of ODNS benefit in that they are and/or the TLD servers to find the authoritative server IP ad-
no longer required to trust that their ISP has their best inter- dress. The root server will respond to a query with the ap-
ests at heart. Instead, users can be assured that all non-local propriate TLD nameserver for that domain (e.g., the .com
DNS infrastructure is unable to link their IP address with TLD server for a foo.com query). The recursive server will
their querying behavior. query the TLD server, which will in turn respond with the IP
We design ODNS to be immediately deployable alongside address of the authoritative nameserver for the domain. The
existing DNS infrastructure. ODNS requires small changes recursive server will then connect to the authoritative name-
to a client’s stub resolver, as well as to the authoritative DNS server, the final authority for translating a domain name to
2(a) In a typical DNS lookup, a recursive resolver sees DNS (b) Overview of interacting components in ODNS.
queries and responses, as well as the client IP addresses that
issue the queries.
Figure 1: Conventional DNS architecture compared with ODNS architecture.
an IP address. The portion of the DNS namespace that an 3.1 ODNS Overview
authoritative server is responsible for is known as a “zone”.
Figure 1b summarizes the ODNS design. ODNS operates
similarly to conventional DNS, but alters two components:
(1) each client runs a modified stub resolver; and (2) ODNS
DNS privacy implications. DNS traffic can reveal per- runs an authoritative name server that also acts as a recursive
sonal information about users’ browsing behavior as well as DNS resolver for the original DNS query:
the types of devices in a network. The vantage point pro-
• The client’s stub resolver obfuscates domain that the
vided at the recursive resolver gives the operator of the DNS
client is requesting (via symmetric encryption), result-
resolver visibility into the IP addresses that query various
ing in the recursive resolver being unaware of the re-
domain names, which may be ultimately linked to individual
quested domain.
devices, sets of devices, or user identity.
• The recursive resolver separates the clients’ identities
Additionally, recursive resolvers can pass information
from their obfuscated requests that are forwarded on to
about the user to the entities at higher levels in the DNS hier-
the ODNS authoritative server.
archy using the EDNS0 client subnet option. EDNS0 client
subnet is a draft RFC [9] whereby recursive resolvers include • The authoritative name server for ODNS decrypts
the client subnet as part of the DNS query when querying au- queries and is unable to learn who is requesting specific
thoritative nameservers. The intent of client subnet is to al- domains.
low for DNS and content providers to utilize the client infor- Operators of recursive DNS resolvers see individual IP ad-
mation to create more informed responses (i.e., route users dresses and with the fully qualified domain name that ac-
to replicas of content they are closest to). The EDNS0 client companies the query. Operators of authoritative resolvers
subnet extension has privacy implications because it reveals may also be able to learn information about the client if
the IP address that issued the initial DNS query to the au- the recursive uses one of the extensions to DNS, such as
thoritative server. EDNS0 Client Subnet. EDNS0 can reveal information about
the user’s IP address or subnet to authoritative DNS servers
higher in the DNS hierarchy (not only recursive DNS re-
solvers). ODNS hides a client’s IP address from the authori-
3 Oblivious DNS (ODNS) tative name servers at different levels of the DNS hierarchy.
The recursive DNS resolver can learn the client IP address,
This section describes the design of ODNS. ODNS prevents but it never sees the domains that it queries. ODNS requires
an adversary from linking each DNS query with the IP ad- the client to use a custom local stub resolver, which hides the
dress that issued the query. We assume that an adversary requested domain from the recursive resolver. The ODNS
can (1) eavesdrop on communications between clients and stub resolver, which runs at the client, encrypts the original
recursive resolvers, and between recursive resolvers and au- DNS query and the key used for encryption before it appends
thoritative name servers; (2) request data (using a subpoena a ODNS-specific domain (e.g., .odns) to the query, which
or warrant) from any number of DNS operators; or (3) access causes the recursive resolver to forward the encrypted do-
data and logs (e.g., query logs) at any DNS server. main name on to the ODNS authoritative server. The recur-
3ODNS Name Recursive Anycasted ODNS
Client Stub Recursive Authoritative Servers Client & Stub Resolver Authoritative Servers
(1) Client
generates Stub generates
query www.foo.com?? request for
special.odns
(2) Stub generates k, special.odns ??
encrypts domain with
k, encrypts k with
authoritative's public
key special.odns ??
{www.foo.com}k, kPK
{www.foo.com}k, kPK
Closest auth
(3) Authoritative decrypts
server
k with private key,
responds with
decrypts domain with k
its name
www.foo.com??
Self-certifying PK.odns PKauth
www.foo.com
1.2.3.4
Self-certifying PK.odns PKauth
{www.foo.com}k (4) Authoritative
{www.foo.com}k {1.2.3.4}k encrypts domain with k,
{1.2.3.4}k encrypts IP with k Stub stores PKauth
and uses it to
www.foo.com (5) Stub decrypts encrypt session
1.2.3.4 domain and IP address keys on
subsequent
queries
Figure 2: ODNS protocol.
Figure 3: ODNS protocol for key distribution and selecting
the optimal authoritative server.
sive DNS resolver receives the request from the client stub,
but cannot identify the genuine domain. It queries the ap-
propriate TLD nameserver and forwards the request to the 3. The authoritative server for ODNS queries decrypts the
ODNS authoritative server. session key, which it uses to decrypt the domain in the
When an ODNS authoritative DNS server receives a DNS query.
query, it 1) decrypts the symmetric key used to encrypt the 4. The authoritative server forwards a recursive DNS re-
domain; and 2) decrypts the domain with the symmetric key; quest to the appropriate name server for the original
and 3) acts as a conventional recursive resolver for the de- domain, which then returns the answer to the ODNS
crypted domain.1 Once an answer is obtained, the ODNS server.
authoritative server encrypts the response and places it in an
5. The ODNS server returns the answer to the client’s re-
additional resource record (also known as an OPT) in the re-
cursive resolver.
sponse. The authoritative server returns response to the orig-
inal recursive DNS resolver, which in turn sends the response Other authoritative DNS servers see incoming DNS requests,
to the client. As explained by the use of session keys, the re- but these only see the IP address of the ODNS authorita-
cursive resolver cannot learn the domains a client requests, tive resolver, which effectively proxies the DNS request for
despite being able to learn who the client is. the original client. The client’s original recursive resolver
can learn the client’s IP address, but cannot learn the domain
names in the client’s DNS queries.
3.2 Sending and Receiving ODNS Queries
Figure 2 shows the various steps involved in answering a
3.3 Replication and Privacy-Preserving
client’s DNS request, which proceeds as follows:
Key Distribution
1. When a client generates a DNS request, the local stub The ODNS authoritative server performs the role of both a
resolver generates a symmetric session key, encrypts the typical authoritative server and a recursive resolver. Thus,
domain name with the session key, encrypts the session the ODNS authoritative server may ultimately face higher
key with the authoritative server’s public key, and ap- traffic volume. Additionally, the authoritative server is re-
pends the ODNS domain (e.g., .odns) to the encrypted sponsible for, and must expect, queries for pseudorandom
query. ({www.foo.com}k .odns.) The stub also appends hostnames within its zone. Thus, the authoritative may be
the session key encrypted under the ODNS authoritative susceptible to DDoS attacks as it must attempt to decrypt all
server’s public key ({k}PK ) queries that it receives. We must thus design ODNS to miti-
2. The client sends the query to the recursive resolver, gate the possible high query volumes.
which then sends it to the authoritative name server for
ODNS.
Scalability and performance using anycast. We repli-
1 Forsimplicity, we say that this authoritative server is for .odns do- cated the ODNS authoritative server in several geographical
mains, but any DNS domain can run an authoritative ODNS server. locations. All replicas are assigned to both an anycast IP
4address as well as a unique unicast IP address. Using any- 1.0
Cumulative Fraction of Queries
cast, all servers that share the IP address are able to answer
a query. The anycast address is advertised to TLD server as 0.8
the nameserver (NS) records for the ODNS domain. When ECC, 16-byte AES, binary
0.6 ECC, 32-byte AES, binary
a recursive sends a DNS query to the ODNS authoritative ECC, 16-byte AES, base64
server, the query will be routed by BGP to an authoritative ECC, 32-byte AES, base64
0.4 RSA 1024, 16-byte AES, binary
server that is nearby (according to wide-area routing). Ad- RSA 1024, 32-byte AES, binary)
ditionally, because the recursive resolver (an open resolver) 0.2 RSA 1024, 16-byte AES, base64
RSA 1024, 32-byte AES, base64)
often also uses anycast, both the recursive and the ODNS DNS QNAME Limit
0.0
authoritative server should be the best choices based on the 100 200 300 400 500
client’s network connectivity without revealing the client’s ODNS QNAME Length (bytes)
location.
Figure 4: Encrypted QNAME lengths using different cryp-
tographic primitives.
Key distribution. Use of anycast and multiple authorita-
tive replicas introduce a key distribution challenge. Recall
that the ODNS stub server uses the public key of the au- QNAME length. We initially attempted to transmit our en-
thoritative server to encrypt session keys in ODNS queries. crypted domain queries in additional resource records (RR)
Based on best practices, we cannot share public / private key- section of a DNS message (known as an OPT). However,
pairs across all of the replicated authoritative servers. Like- in practice we discovered that recursive resolvers strip addi-
wise, to preserve user privacy the key distribution must be tional records. Therefore, we use the QNAME field to trans-
done in a way that the authoritative server never learns the mit both the encrypted domain query as well as the asym-
identity (i.e., IP address) of a client stub. This disquali- metrically encrypted session key as the QNAME field is pre-
fies out-of-band key exchange as proposed in [17]. Instead, served while passing through recursive resolvers. A DNS
we leverage the DNS infrastructure itself to distribute keys QNAME field consists of 4 sets of 63 bytes, which limits
while maintaining privacy. We define a “special” query (e.g., both the key size and encryption scheme used.
special.odns) that we use to select a specific authoritative We investigate combinations of the required cryptographic
server as well as distribute the appropriate public key. primitives (symmetric AES encryption for domains, asym-
Figure 3 shows this process process. The client’s stub metric encrpytion for symmetric keys) and the resulting
resolver sends a special ODNS query to the recursive re- QNAME lengths to assess the suitability of the QNAME
solver, which will in turn use the anycast address to locate field with regard to ODNS’s encryption scheme. We cal-
the nearest authoritative server. The authoritative that re- culate total QNAME lengths for all query records in an ex-
ceives the query responds with an OPT record that includes a ample query list used for testing DNS server performance2 .
self-certifying name [2, 27], such that the name of the server The list contains 6.8M queries and we calculate the lengths
is derived from the public key itself and is associated with using both binary and base64 encoding. Figure 4 shows
an instance of the authoritative nameserver listening on the the results. We see that both 1024-bit RSA and ECC using
unique unicast IP address, and the authoritative server’s pub- Curve25519 tend to result in query lengths that are well be-
lic key. The recursive returns this response to the client’s stub low the 252-byte limit. However with the use of base64 and
resolver. Subsequent ODNS queries at the stub append the RSA-based asymmetric encryption the likelihood of generat-
unique name of the authoritative that responded to the spe- ing an invalid QNAME is increased. For this reason, ODNS
cial query, which means that the requests will all reach the uses 16-byte AES session keys and encrypts the session
same server and the client encrypts queries using the appro- keys using the Elliptic Curve Integrated Encryption Scheme
priate public key. A client can perform this process at regular (ECIES) [22]. In our prototype deployment, which uses
intervals to update the authoritative server that is responsible base64 encoding, we discovered that 0.6% of the queries in
for resolving its queries. the list had lengths that exceeded this limit
To allow the ODNS prototype to operate in conjunc-
tion with the deployed DNS infrastructure, we designed
the ODNS stub resolver to fall back to conventional DNS
3.4 Practical Challenges lookups whenever plaintext QNAME fields that result in
ciphertext QNAMEs that are larger than the maximimum
Backward compatibility. To reduce barriers to deploy-
field size. To preserve privacy, queries that result in invalid
ment, must be backwards-compatible with existing infras-
QNAME lengths will receive SERVFAIL errors in the de-
tructure, as changes to the DNS system occur over long time
ployed version of ODNS.
scales. Thus, we design ODNS to avoid any changes at the
recursive resolvers, root nameservers, or TLD nameservers. 2 http://wwwns.akamai.com/queryfile-example-current.gz
5EDNS0 solver between the ODNS stub and the authoritative server
Open Recursive Resolver (IP) 0x20
Client Subnet must not use 0x20-bit encoding, as it would render decryp-
Google (8.8.8.8) 7 tion impossible. Table 1 shows the public recursive resolvers
Dyn (216.146.35.35) 7
that currently implement 0x20. Note that 0x20-bit encoding
Fourth Estate (45.77.165.194) 7
does not pose a challenge for binary-encoded queries, which
GreenTeamDNS (81.218.119.11) 7
Cloudflare (1.1.1.1) 7 are commonly supported in real-world infrastructure [17].
Verisign (64.6.64.6) 7
Quad9 (9.9.9.9) Caching. ODNS caches queries at the ODNS authoritative
Level3 (209.244.0.3) server. As the ODNS authoritative server is essentially an
OpenDNS Home (208.67.222.222)
extra recursive resolver in the system, the ODNS author-
Norton ConnectSafe (199.85.126.10)
itative server simply acts as the shared cache, in lieu of
Comodo Secure DNS (8.26.56.26)
DNS.WATCH (84.200.69.80)
the shared cache that would ordinarily exist at the ISP re-
SafeDNS (195.46.39.39) cursive resolver. This pushes caching further into the sys-
FreeDNS (37.235.1.174) tem, decreasing the time to conduct a look up for the do-
Hurricane Electric (74.82.42.42) main from the perspective of the authoritative server. In
Ultra (156.154.71.1) addition to caching at the authoritative server, ODNS can
also cache DNS responses at the stub resolver; while this
Table 1: Open recursive resolvers with EDNS0 client subnet may provide some caching benefits on a per-client basis,
and 0x20-bit encoding enabled. it does not provide cross-client caching benefits. It is im-
portant to note that caching at the recursive resolver would
not provide any performance enhancement for the client in
EDNS0 Client Subnet. As discussed in Section 2, the this system. Each DNS query is encrypted with a new ses-
EDNS0 client subnet option allows upstream authoritative sion key k, thus two DNS queries for the same domain do
nameservers to learn the IP subnet of clients issuing queries. not appear the same to these resolvers ({www.foo.com}k1 6=
To achieve the intended privacy benefits of ODNS, the client {www.foo.com}k2 ); therefore, if the resolver cached the re-
subnet option should not be used. We intend to require in sponse for {www.foo.com}k1 , it would never see a cache hit
an upcoming proposed ODNS specification that recursive re- for that entry because subsequent lookups for www.foo.com
solvers that receive ODNS queries must not include EDNS0 appear as a different URL. We explore the implications on
client subnet as they perform the recursive lookup. Alter- caching and the recursive resolver in Section 4.5.
natively, ODNS stub resolvers can maintain a list of recur-
sive providers that use EDNS0 client subnet, and avoid using
those resolvers. ODNS Ingress / Egress Vulnerability. An adversary with
To better understand real-world usage of the EDNS0 client sufficient visibility might be able to view both the encrypted
subnet option, we performed an experiment to discover pub- ODNS queries and the subsequent plaintext queries originat-
licly available recursive resolvers that have the option en- ing from the ODNS authoritative server. Such a case could
abled. We operate authoritative nameservers for the do- also arise if both the stub and the authoritative use the same
main obliviousdns.com and collect pcaps of queries that recursive resolver for lookups. ODNS can avoid these is-
reach the authoritative server. Queries are initiated by us- sues in two straightforward ways: 1) ODNS can inspect the
ing dig against a list of 16 popular publicly available recur- source of incoming queries and maintains rules to avoid us-
sive resolvers. Overall, we find that only four of the six- ing the same service for the plaintext query; and 2) authorita-
teen resolvers implement EDNS0 client subnet, as shown tive servers can simply repeat the same actions as the stub by
in Table 1. Several popular recursive resolvers do not cur- encrypting the encrypted query again (i.e., behavior akin to
rently implement EDNS0 client subnet (such as Cloudflare’s Tor). This second option introduces a performance penalty
1.1.1.1 or Quad9’s 9.9.9.9). as the number of ODNS hops increases; we do not study this
particular tradeoff in this paper.
0x20-bit Encoding. 0x20-bit encoding is a scheme in-
tended to thwart DNS poisoning attacks by altering the .odns Top-Level Domain. In our examples we discuss the
QNAME field in queries to a mix of uppercase and lowercase use of a new top-level domain specifically for the use of
(e.g., www.foo.com to wWW.FoO.CoM) [10]. This technique in- ODNS. In reality, TLDs are challenging and costly to pro-
creases the difficulty of cache poisoning as the attacker must cure, requiring extensive time and effort. Due to these bar-
guess the mixed-case QNAME. The ODNS prototype en- riers, we have implemented and evaluated our prototype
codes the encrypted domain and session keys using base64, while using the registered domain obliviousdns.com. This
which results in a character set including both upper and low- long DNS domain currently consumes more of the already-
ercase letters. Therefore, for our purposes, the recursive re- limited QNAME field with our appended domain name.
61000 1.0
Cumulative Fraction of Requests
Stub Authoritative Conventional DNS
800 0.8 ODNS
600
Time ( s)
0.6 1.0
400
0.4
200
0.2 0.5
0 100 500 2000
0.0
S)
)
)
)
)
)
)
ES
IES
ES
IES
ES
ES
0 5 10 15 20 25 30 35 40
AE
(A
(A
(A
r (A
EC
EC
y(
Resolution time (ms)
in
er
ain
we
y(
y(
Ke
ma
sw
om
Ke
ke
ns
ion
An
Do
tA
td
pt
pt
ss
pt
cry
pt
cry
p
p
Se
cry
cry
cry
cry
De
En
De
De
En
te
Figure 6: Additional latency running ODNS compared with
En
ra
ne
conventional DNS.
Ge
Function
Figure 5: Overhead of different cryptographic operations 4.1 Microbenchmarks
performed in the ODNS protocol.
Cryptographic overhead. We first investigate the over-
head introduced by each of the cryptographic operations
Widespread adoption of ODNS could lead us to acquire a that occur in an ODNS lookup. We benchmark the individ-
new TLD in the future or select a shorter ODNS-specific do- ual operations performed in the ODNS protocol to attribute
main. overhead to different parts of the protocol. The results of
these microbenchmarks are shown in Figure 5. We see that
the symmetric operations using AES result in relatively lit-
3.5 Implementation tle overhead at both the stub and the authoritative servers.
The asymmetric operations using ECIES are more costly and
For experimentation and prototyping, we implement a proto- contribute to the majority of the total overhead of ODNS.
type of the ODNS stub and the ODNS authoritative server in However, even the most costly operation, asymmetrically en-
Go. We built this functionality as extensions to an existing crypting the key using ECIES, takes less than 1 ms due to
Go DNS library [15]. This implementation choice allowed the relatively high performance of elliptic-curve cryptogra-
us to rapidly prototyping our design and to quickly test var- phy. Additionally, we anticipate further improvements are
ious features. A future implementation could use a popular attainable using optimized cryptographic libraries, whereas
DNS resolver such as Knot or Unbound. our prototype uses standard libraries.
We use a hybrid encryption scheme and leverage well-
known cryptographic primitives in ODNS to balance privacy
with storage requirements. For ODNS requests, the stub ODNS protocol overhead. We next compare the latency
generates a 16-byte AES symmetric key. This key encrypts introduced by ODNS for each query to that of conventional
the plaintext request from the user. The AES session key is DNS by using the dig command to issue DNS queries. To
then asymmetrically encrypted using the ODNS authoritative single out ODNS protocol overhead that isn’t impacted by
server’s public key with ECIES [22] using Curve25519 [5]. network latency between servers, we install both the ODNS
Elliptic-curve cryptography allows ODNS to reap the per- stub and authoritative servers onto a single machine. We
formance benefits of elliptic curves and take advantage of query the Alexa Top 10,000 domains with ODNS’s function-
the smaller key sizes needed to provide equivalent security ality both enabled and disabled to compare lookup latencies.
as other public-key implementations. The results of this are shown in Figure 6; we can see that
the use of ODNS results in longer query resolution times,
but generally follows the same trend as conventional DNS.
4 Evaluation Overall, the median resolution time for conventional DNS
is 6.03 ms, while the median time for ODNS resolutions is
In this section, we study the performance of ODNS in terms 7.53 ms. The overhead difference corroborates the crypto-
of both 1) the overhead on individual lookups; 2) the impact graphic overhead witnessed above. The additional latency
of using ODNS when loading many popular websites; and can be attributed to the stub and authoritative server process
3) the implications on existing infrastructure. functions.
7NYC Conventional DNS (1.1.1.1)
Conventional DNS (9.9.9.9)
Conventional DNS (8.8.8.8)
ODNS Georgia
4.5ms ODNS
Authoritative
ODNS New York
Client Browser
Server
1.0 RTT to New York (4.5 ms)
RTT to Georgia (19 ms)
Cumulative Fraction of Requests
Atlanta
Recursive Resolver 0.8
19ms
ODNS Stub 0.6
Resolver
0.4 1.0
Figure 7: Deployment Setup.
0.2
0.5
It may appear that the default recursive server’s process to 150 500 2000
0.0
reach the authoritative server is too short, as traditional DNS 0 20 40 60 80 100
literature describes the recursive lookup process as includ- Resolution time (ms)
ing the root and TLD servers before reaching the authorita-
tive server for a domain. In reality, recursive servers cache Figure 8: ODNS performance with servers located in Geor-
TLD and authoritative nameserver addresses. The result is gia and New York.
that the recursive server only goes through the first two steps
of the recursive procedure once to learn the address of the
ODNS authoritative server that is responsible for the ODNS of 8.8.8.8 and 9.9.9.9, ODNS tends to result in lower laten-
zone. Subsquent ODNS queries are immediately directed to cies when using the nearby authoritative server in New York.
the authoritative server from the recursive with no delay. It is evident that the network round trip time between the
stub and the authoritative server is present for every ODNS
query. Clearly, the overhead is significantly less when the
4.2 Query Latency in the Wide-Area authoritative server is closer to the client.
Given these results, ODNS does not appear to introduce
Figure 7 shows our deployed evaluation setup. We test
significant overhead when resolving domains provided that
ODNS using a client in the New York City metropolitan
the RTT between the client and the authoritative server re-
area, running the ODNS stub resolver running on the same
mains reasonable. As described in Section 3.3, ODNS au-
local machine, communicating with its default recursive re-
thoritative servers are replicated and use anycast IP addresses
solver. We operate two ODNS authoritative servers for
in order to provide scalability and achieve desirable laten-
obliviousdns.com: one located in the New York area, and
cies. Schmidt et al. [11] investigated the performance of
another in Georgia. We examine the benefit of caching and
real-world anycast systems and determined that a system de-
operating as a recursive resolver at the authoritative server as
ployed in only 12 locations around the world can result in
well as using existing DNS resolvers without a cache at the
relatively low latency for a global client base. Therefore, we
authoritative.
anticipate that a fully-deployed ODNS would result in ac-
ceptable lookup latencies for any user.
Wide-area Latency. We evaluate ODNS’s query overhead
to that of conventional DNS while interacting with real-
world DNS infrastructure. We perform DNS queries for the 4.3 Macrobenchmarks
Alexa Top 10,000 domains using both ODNS with two au- Web Page Load Time. Next, we explore how ODNS
thoritative servers — functionally equivalent — in two dif- would affect a typical Internet user’s browsing experience
ferent locations: Georgia and New York City. Recall that by evaluating the overhead of a full page load; a full page
the client and stub resolver are also located in the New York load consists of not only conducting a DNS lookup for the
City area. To evaluate the effect of the authoritative server’s page, but also fetching the page, and conducting any subse-
geographic proximity to the client, we measure the overhead quent DNS lookups for embedded objects and resources in
using each of the authoritative servers. the page. We fetch a selection of popular web pages from
In this experiment, we warm a cache at the authoritative the Alexa top sites list in the United States3 using ODNS
server using a sample domain query trace provided for use with an authoritative server in New York as well as con-
with resperf, a popular DNS performance testing tool. Fig- ventional DNS. We browse to each site 30 times using the
ure 8 shows the results; we can see that ODNS queries com-
pare favorably to the popular open resolvers, and in the case 3 https://www.alexa.com/topsites/countries/US
850 DNS
Page Load Time (s) 10
1
0
800 Conventional DNS
ODNS
600
TTFB (ms)
400
200
0
tw ing.c co
go ter.c m
ase rg
ins igs .com
ne m.c rg
tum ok.c m
wik gle om
m
tw .com
cra iply h.tv
tfli om
fac eba .com
lin blr om
yo edin com
am be m
az .com
gu m
d m
espb.com
ya dit.c m
ho om
ny live om
es m
om
cn .com
it o
eb y.co
ipe .co
utu .co
im on.co
im r.co
red n.co
tim .co
ch dia.o
ra .o
b t.
o.c
n.c
d itc
tag list
k .
x
o
o
Figure 9: Page load times and time-to-first-byte for various web pages using ODNS and conventional DNS. The left bars in the
figure represent conventional DNS and the right bars represent the time it takes using ODNS.
chrome webdriver and record HAR files for each browsing connecting to CDN servers that are suboptimal in terms of
session. We then take the mean values for each site. The top performance. We investigate the time-to-first-byte (TTFB)
graph of Figure 9 shows the results. The left bars in the fig- values for every object on each site from our traces. This
ure represent total page load time using conventional DNS, value illustrates the difference in terms of distance to con-
and the right bars represent the time it takes using ODNS. tent when using ODNS versus traditional DNS. The bottom
The portion of each bar that is shaded in black illustrates the graph in Figure 9 shows the TTFB distributions for each
percent of page load time that is attributable to DNS lookups. site, with conventional DNS on the left and ODNS on the
We see that there is generally not a significant difference in right. These results help explain the page load times we
page load time between ODNS and conventional DNS be- witness for several sites. For example, reddit.com and ny-
cause DNS lookups contribute relatively little time to the en- times.com both achieve lower TTFBs using ODNS, mean-
tire page load process. In some cases, ODNS load times are ing they were directed to content servers that are closer than
actually shorter than loading a page with conventional DNS4 . those resolved with conventional DNS. The ODNS page load
Given these overall results, we believe that the end-user web times for those sites were faster when using ODNS. Like-
experience will not be greatly impacted using ODNS. wise, when ODNS results in higher TTFBs such as with
instagram.com, we see longer page load times. This in-
sight motivates widespread deployment of ODNS authorita-
Web Page Time-to-First-Byte. CDNs distribute content
tive servers and the use of anycast. These techniques should
to many locations to achieve low latency for users as they
allow for both low latencies to the authoritative as well as
connect to nearby copies of requested content. A concern
maintaining content localization benefits.
when using ODNS is that, for a given lookup, the loca-
tion of the authoritative server will appear to be the location
of a user, thus localization techniques may result in users 4.4 Operating as a Recursive or a Stub at the
4 We investigated the performance for live.com to understand how ODNS Authoritative Server
could drastically outperform conventional DNS. It appears that page loads
were rather different when using ODNS versus conventional DNS. We A critical performance aspect of conventional DNS is
found that ODNS usage resulted in loading 7 fewer javascript objects from caching—specifically caching DNS responses at the recur-
a different optimizely.com CDN. It appears that the ODNS runs were
directed to a cached bundle of javascript, whereas conventional DNS runs
sive resolver. As mentioned previously, ODNS essentially
were directed to individual javascript objects from a different optimizely prevents any caching benefits at the recursive resolver as
CDN location. each client generates its own session keys, but allows caching
9ODNS New York Client (1.1.1.1)
ODNS New York Client (9.9.9.9) 8
ODNS New York Client (8.8.8.8)
ODNS New York Recursive 7
1.0 6
Queries (millions)
Cumulative Fraction of Requests
5
0.8
4
0.6 3
0.4 1.0 2 ODNS Cache Hits
1 Recursive Cache Hits
0.2
Recursive Cache Misses
0.5 0
150 500 2000 0 10 20 30 40 50 60 70 80 90 100
0.0 Percent ODNS Users
0 20 40 60 80 100
Resolution time (ms)
Figure 12: Effect of ODNS usage on recursive DNS traffic.
Figure 10: Effects of operating our own cache at the author-
itative server in New York compared with using third-party
resolvers. overall. These results lead us to conclude that the authori-
tative server can perform well as either a recursive resolver
ODNS Georgia Client (1.1.1.1) itself, or as a client relying on third-party recursive resolvers
ODNS Georgia Client (9.9.9.9) provided they perform well in the location that the authorita-
ODNS Georgia Client (8.8.8.8)
ODNS Georgia Recursive tive server resides. In cases where disk storage is costly, the
authoritative can use a high-performance third-party resolver
1.0
such as Cloudflare and gain the benefits of caching without
Cumulative Fraction of Requests
0.8
incurring a large latency penalty. If the choice is made to use
a third-party service at the authoritative server, care must be
0.6 taken to ensure that the same third-party service is not used
by both the ODNS stub and the ODNS authoritative server,
0.4 1.0 as such behavior could allow the third-party service to cor-
relate timing between encrypted ODNS queries and subse-
0.2 quent plaintext queries from the authoritative server.
0.5
150 500 2000
0.0
0 20 40 60 80 100
Resolution time (ms) 4.5 Impact on Recursive DNS Infrastructure
Figure 11: Effects of operating our own cache at the author- As discussed, ODNS usage results in the inability to cache
itative server in Georgia compared with using third-party re- responses at the recursive resolver as each query using a dif-
solvers. ferent symmetric key will be unique. Caching plays a critical
role in the overall performance of DNS infrastructure; there-
for, we investigate the potential DNS traffic implications at a
at both the stub resolver and at the authoritative server. To recursive resolver with varying levels of ODNS usage. Like-
evaluate the effect of caching at the authoritative server on wise, if ODNS results in a significant DNS traffic increase
ODNS’s performance, we measure the overhead of ODNS at the recursive resolver, widespread usage may be discour-
where the authoritative caches and acts as a second recur- aged.
sive resolver, and compare it to the overhead of ODNS using For this experiment, we simulate a caching recursive re-
third party upstream recursive resolvers and their associated solver as well as a user population using real-world traces
caches. We warm the cache using a DNS query trace gen- collected in October 2017 from a fiber-to-the-home network
erated for usage with resperf. Figures 10 and 11 show the in Cleveland, Ohio [1]. The trace consists of roughly 8 mil-
results for the authoritative servers in New York and Geor- lion type A DNS queries from anonymized clients. Each
gia, respectively. We see that Cloudflare’s 1.1.1.1 service anonymous client is assigned to a single simulated recursive
achieves the best results as they appear to have cache hits for resolver. For each run we randomly assign a fixed percent of
roughly 80% of requests. Interestingly, we find that ODNS the user population to be ODNS users. The ISP, as well as
with a warmed cache outperforms both Quad9 and Google all ODNS stubs include caches that have no size limits.
10The results of the simulation are shown in Figure 12. We vacy characteristics that the protocol promises.5 In contrast
see that ODNS usage causes a relatively modest increase of to ODNS and EncDNS, most proposed DNS privacy mech-
cache misses at the recursive. However, we see that as the anisms are protecting against an adversary, but not a DNS
percent of ODNS users increases, the overall DNS traffic operator. Castillo-Perez and Garcia-Alfaro evaluate privacy-
load on the recursive resolver decreases. For instance, with a preserving DNS mechanisms, but show that they need ad-
network consisting of 20% ODNS clients, the overall num- ditional measures to enhance their security [8]. Similarly,
ber of queries that reach the recursive resolver is reduced by Query Name Minimization is a proposal that limits what
16.3%. This is due to the presence of a cache at the stub re- name servers see in DNS queries, but a recursive resolver’s
solvers. These results are consistent with Jung et al.’s obser- operator still learns the domain requested and the corre-
vation [24] that caching can provide significant benefits for sponding client who requested the domain [7]. Researchers
even a single user. Overall, our simulation shows that ODNS have also pointed out how aspects of current (operational)
will reduce the traffic burden on the recursive infrastructure. DNS, such as prefetching, have privacy implications [25,34].
Federrath et al. introduced a DNS anonymity service that
employs broadcasting popular hostnames and low-latency
mixes for requesting less popular domains; unlike ODNS,
5 Related Work this proposed DNS anonymity service is a clean-slate archi-
tecture and requires fundamental changes to the DNS infras-
In this section, we describe related work on DNS privacy. We tructure [14].
discuss various infrastructure for protecting user privacy in
DNS, ranging from alternate open resolvers to virtual private DNS Security. Protocols to secure DNS include DNS-
networks. In general, these systems involve simply changing over-TLS [21], DNSSEC [4], and T-DNS [37]. DNS-over-
the trusted third party who resolves DNS on behalf of the TLS protects the privacy of the domain being requested in
client, rather than decoupling the DNS query from the IP transit, but does not prevent a recursive resolver’s operator
address that issued the query. from learning both the client who issued the request and the
content of the request. Some work has analyzed DNSSEC in
more detail; Osterweil et al. develop SecSpider to monitor
Alternate DNS Resolvers. Quad9 provides both security and detect errors in the DNSSEC deployment [31]. While
and privacy features for DNS. Quad9 uses IBM X-Force there have been many attacks on DNS, the adoption of DNS
threat intelligence data at the recursive resolver to prevent security protocols is very limited; Herzberg and Shulman
a client from accessing a malicious site [32]. Although this highlight some of the issues with retrofitting security into
recursive resolver does not store or distribute the DNS data DNS [18]. Researchers have also combined DNSSEC fea-
passing through, it still allows a DNS operator to observe tures with BIND DNS software to implement a system that
this data. Once such information is retained, of course, it prioritizes the integrity and availability of DNS [23]. Re-
may become vulnerable to other threats to user privacy, in- cent research has also seen the introduction of new frame-
cluding data requests from law enforcement. Cloudflare re- works for monitoring DNS in the hopes of detecting at-
cently released 1.1.1.1, which is a privacy-focused con- tacks [19, 26].
sumer DNS recursive resolver; it supports both DNS-over-
TLS and DNS-over-HTTPS, and also offers the feature of Virtual Private Networks and Tor. Systems to protect
query name minimization [36]. While 1.1.1.1 only logs user privacy include Virtual Private Networks (VPNs) and
data for 24 hours at the recursive resolver (for debug pur- Tor. Unfortunately, many VPN providers send unencrypted
poses), it is still susceptible to a malicious DNS operator (or DNS queries to the client’s ISP, and all VPN providers would
other adversary) saving that information before it is purged. be able to associte DNS queries and responses with an indi-
Furthermore, even though a DNS operator who aims to pro- vidual client IP address. VPNGate uses different VPNs to
tect user privacy may purge this information periodically, a contol where a client appears to be located [30], but even
user has no guarantee that information that an operator learns this approach does not prevent operators of DNS recursive
might be retained, for operational or other purposes. resolvers from learning the domains being requested. The
VPN operators themselves also still have complete informa-
tion about the domains and the IP addresses that are querying
them.
Privacy-preserving DNS. EncDNS protects the confiden-
5 Additionally, EncDNS code has been made publicly available for any-
tiality of DNS messages in transit and from a DNS opera-
one to use; however, in our analysis, we found that key exchange is not
tor [17]; however, EncDNS suffers from several shortcom- addressed, and a client’s public key is sent directly within a DNS query,
ings, including the inability to share keys without using an offering an identity associated with the client to both the recursive and au-
out-of-band method directly, resulting in a breach of the pri- thoritative servers.
11Tor uses layered encryption and a three-hop circuit to sign impacts client performance in two ways. First, as dis-
provide client anonymity [13]. Using Tor would not pro- cussed in Section 4.1, the cryptographic operations result in
vide the same protections as ODNS because DNS is con- additional latency for each query totaling up to roughly 1 ms
ducted at the last hop of the three-hop circuit and is con- at the stub. Additionally, the use of unique session keys for
ducted however that machine is configured. Additionally, each query renders caching, even for identical queries from
the owner and operator of that machine (as well as the lo- a single user, at the recursive resolver impossible. To ease
cal resolver’s operator) can learn what content is being re- these challenges, session keys could be re-used for some pe-
quested. More recently, researchers have analyzed how DNS riod of time by the stub. In cases where keys are reused,
works in Tor and found that fingerprinting attacks can be per- the potential for cache hits at the recursive resolver exists for
formed based on DNS data [16]. The Tor Project has also de- multiple identical queries by clients with the same combina-
signed and implemented onion services/domains (previously tion of symmetric key and public key of the ODNS author-
hidden services), which provide server anonymity; onion do- itative server. However, excessive key re-use may leave the
main lookup does not use DNS, but can only be accessed via keys vulnerable to attack. Thus, cost / benefit analysis per-
Tor and suffers from usability issues [3]. Recent work has taining to key reuse must be done prior to implementing the
highlighted how onion domain name leakages are a source feature. We leave this for future exploration.
of privacy leakage as well [35].
Denial of service attacks. ODNS’s authoritative DNS
servers cannot check the incoming IP address of queries,
6 Discussion
which could facilitate Denial of Service attacks. To defend
Striping queries across multiple recursives. The client’s against DoS attacks, the client’s stub resolver can append
local stub resolver typically forwards DNS queries on to the bytes that indicate the DNS query is sent from an ODNS-
client’s recursive resolver, but ODNS supports forwarding participating client stub resolver. The authoritative can then
the DNS queries on to open resolvers. ODNS can stripe DNS check for these bytes and verify that it was sent via ODNS
queries across the many available open resolvers, which prior to decryption.
helps increase the privacy of the client because the recursive
resolver does not see all (obfuscated) DNS queries from the 7 Conclusion
client. If striping is enabled, then each open resolver only
sees some portion of each client’s obfuscated queries. DNS queries can reveal personal information such as brows-
ing patterns as well as types of devices and allow DNS
Policy-based traffic routing. There may be scenarios resolvers to associate such information with client IP ad-
where ODNS users would prefer to control the geographic dresses. Users are required to place trust in their recursive
location where their ODNS authoritative resides rather than DNS resolver. Privacy-focused, third party DNS resolvers
for the selection to be based on anycast routing. For in- simply shift the trust without alleviating the fundamental in-
stance, a user may wish to avoid an authoritative in a coun- formation exposure. In this work, we present ODNS, a sys-
try that they suspect may eavesdrop on their traffic. ODNS tem that separates client IP address from DNS queries, re-
can be extended to support such policy-based routing. To moving the need for trust altogether as no DNS infrastruc-
accomplish this, the authoritative servers could include loca- ture outside of the user network is able to obtain both pieces
tion codes in their names (e.g., US.odns or UK.odns). Users of information. ODNS is designed to be fully-compatible
could configure their stubs to select specific locations to act with existing DNS infrastructure and requires only minimal
as their authoritative servers. However, such usage would changes. Our evaluation of ODNS reveals that latency over-
come at a performance cost as the specified authoritative head is minimal, performance for user web traffic is accept-
server may not result in the lowest latency. This scenario able, and minimal impact on recursive resolver traffic.
is akin to using a VPN to ingress and egress onto the Internet We are seeking to move forward with this work to deploy
from a trusted location. We leave the implementation of this in-the-wild. In the near term, we are working toward sub-
funcationality for future work. mission of an IETF Internet-Draft for ODNS and are imple-
menting its functionality into commercial DNS server code
Session key re-use. In our current design, the ODNS stub bases. Long-term, we are exploring widespread deployment
generates unique session keys for each DNS query. This de- of ODNS authoritative servers with the cooperation of an op-
erator of an existing global anycast network.
12References [18] H ERZBERG , A., AND S HULMAN , H. Retrofitting security
into network protocols: The case of DNSSEC. IEEE Internet
[1] A LLMAN , M. Case Connection Zone DNS Transactions, Computing 18, 1 (Jan 2014), 66–71.
2011–2017. http://www.icir.org/mallman/data.html.
[19] H ESSELMAN , C., M OURA , G. C., DE O LIVEIRA S CHMIDT,
[2] A NDERSEN , D. G., BALAKRISHNAN , H., F EAMSTER , N., R., AND T OET, C. Increasing DNS security and stability
KOPONEN , T., M OON , D., AND S HENKER , S. Accountable through a control plane for top-level domain operators. IEEE
internet protocol (AIP). SIGCOMM Comput. Commun. Rev. Communications Magazine 55, 1 (2017), 197–203.
38, 4 (Aug. 2008), 339–350.
[20] H OFFMAN , P., AND M C M ANUS , P. DNS queries
[3] A PPELBAUM , J., AND M UFFETT, A. The ”.onion” special-
over HTTPS (DOH). Internet-draft, May 2018.
use domain name. RFC 7686, October 2015.
http://www.ietf.org/internet-drafts/draft-
[4] A RENDS , R., AUSTEIN , R., L ARSON , M., M ASSEY, D., ietf-doh-dns-over-https-08.txt.
AND ROSE , S. DNS security introduction and requirements.
[21] H U , Z., Z HU , L., H EIDEMANN , J., M ANKIN , A., W ES -
RFC 4033, March 2005. http://www.rfc-editor.org/
SELS , D., AND H OFFMAN , P. Specification for DNS over
rfc/rfc4033.txt.
transport layer security (TLS). RFC 7858, May 2016.
[5] B ERNSTEIN , D. J. Curve25519: New Diffie-Hellman speed
records. In Public Key Cryptography - PKC 2006 (Berlin, [22] IEEE standard specifications for public-key cryptography -
Heidelberg, 2006). amendment 1: additional techniques. IEEE Std 1363a-2004
(Amendment to IEEE Std 1363-2000) (Sept 2004).
[6] B ERNSTEIN , D. J. DNSCurve: Usable security for DNS.
https://dnscurve.org, 2009. [23] JALALZAI , M., S HAHID , W., AND I QBAL , M. DNS security
challenges and best practices to deploy secure DNS with digi-
[7] B ORTZMEYER , S. DNS query name minimisation to improve
tal signatures. In Applied Sciences and Technology (IBCAST),
privacy. RFC 7816, March 2016.
2015 12th International Bhurban Conference on (2015).
[8] C ASTILLO -P EREZ , S., AND G ARCIA -A LFARO , J. Evalu-
ation of two privacy-preserving protocols for the DNS. In [24] J UNG , J., S IT, E., BALAKRISHNAN , H., AND M ORRIS ,
Information Technology: New Generations, 2009. ITNG’09. R. DNS performance and the effectiveness of caching.
Sixth International Conference on (2009). IEEE/ACM Transactions on Networking 10, 5 (Oct 2002),
589–603.
[9] C ONTAVALLI , C., VAN DER G AAST, W., L AWRENCE , D.,
AND K UMARI , W. Client subnet in DNS queries. RFC 7871, [25] K RISHNAN , S., AND M ONROSE , F. DNS prefetching and
May 2016. its privacy implications: when good things go bad. In Pro-
ceedings of the 3rd USENIX conference on Large-scale ex-
[10] DAGON , D., A NTONAKAKIS , M., V IXIE , P., J INMEI , T.,
ploits and emergent threats: botnets, spyware, worms, and
AND L EE , W. Increased DNS forgery resistance through
more (2010), USENIX Association, pp. 10–10.
0x20-bit encoding: Security via leet queries. In Proceedings
of the 15th ACM Conference on Computer and Communica- [26] M ARCHAL , S., F RANOIS , J., WAGNER , C., S TATE , R., D U -
tions Security (Alexandria, Virginia, USA, 2008), CCS ’08. LAUNOY, A., E NGEL , T., AND F ESTOR , O. DNSSM: A
[11] DE O LIVEIRA S CHMIDT, R., H EIDEMANN , J., AND large scale passive DNS security monitoring framework. In
K UIPERS , J. H. Anycast latency: How many sites are 2012 IEEE Network Operations and Management Symposium
enough? In Passive and Active Measurement (Sydney, Aus- (April 2012), pp. 988–993.
tralia, 2017). [27] M AZI ÈRES , D., K AMINSKY, M., K AASHOEK , M. F., AND
[12] D ENIS , F., AND F U , Y. DNSCrypt. https:// W ITCHEL , E. Separating key management from file system
dnscrypt.info/, 2015. security. In Proceedings of the Seventeenth ACM Symposium
[13] D INGLEDINE , R., M ATHEWSON , N., AND S YVERSON , P. on Operating Systems Principles (Charleston, South Carolina,
Tor: The second-generation onion router. Tech. rep., Naval USA, 1999), SOSP ’99.
Research Lab Washington DC, 2004. [28] M OCKAPETRIS , P. Domain names - concepts and facilities.
[14] F EDERRATH , H., F UCHS , K.-P., H ERRMANN , D., AND STD 13, November 1987. http://www.rfc-editor.org/
P IOSECNY, C. Privacy-preserving DNS: analysis of broad- rfc/rfc1034.txt.
cast, range queries and mix-based protection methods. In Eu- [29] M OCKAPETRIS , P. Domain names - implementation and
ropean Symposium on Research in Computer Security (2011). specification. STD 13, November 1987. http://www.rfc-
[15] G IEBEN , M. DNS library in go. https://github.com/ editor.org/rfc/rfc1035.txt.
miekg/dns, 2018. [30] N OBORI , D., AND S HINJO , Y. VPN gate: A volunteer-
[16] G RESCHBACH , B., P ULLS , T., ROBERTS , L. M., W IN - organized public VPN relay system with blocking resistance
TER , P., AND F EAMSTER , N. The effect of DNS on tor’s for bypassing government censorship firewalls. In Proceed-
anonymity. CoRR abs/1609.08187 (2016). ings of the 11th USENIX Symposium on Networked Systems
[17] H ERRMANN , D., F UCHS , K.-P., L INDEMANN , J., AND Design and Implementation (NSDI 14) (Seattle, WA, 2014),
F EDERRATH , H. EncDNS: A lightweight privacy-preserving pp. 229–241.
name resolution service. In European Symposium on Re-
search in Computer Security (Wroclaw, Poland, 2014).
13You can also read
