The Domain Name System (DNS) and its security

�1

CSU CS557, Spring 2018 Instructor: Lorenzo De Carli

Partly based on the CS457 slides by Indrajit Ray

What is the domain name system?

• Internet use 4- (or 16-) byte binary addresses

• Humans are not very good at remembering those

• Solution: allow pesky humans to use strings

• E.g. “www.cs.colostate.edu"

• Let the domain name system convert strings to IP addresses

!2

Domain Name System• The Domain System consist of:

• An application-layer protocol to translate names to IP addresses (“resolve names”)

• A distributed database to perform the translation (consisting of name servers)

• Almost every networked communication is preceded by a DNS resolution to determine the IP that the user/application intends to reach

!3

DNS resolution

11/6/16

2

DNS Query and Response

Caching DNS Server

End-user

www.colostate.edu A?

www.colostate.edu A is 129.82.64.100

Root DNS Server

Multiple servers for each zone in case any one server fails

13 root servers13 edu servers5 colostate.edu servers

edu DNS Server

colostate.edu DNS Server

Host Names vs. IP addresses• Host names

– Mnemonic name appreciated by humans– Variable length, alphanumeric characters– Provide little (if any) information about location– Examples: www.cnn.com and ftp.eurocom.fr

• IP addresses– Numerical address appreciated by routers– Fixed length, binary number– Hierarchical, related to host location– Examples: 64.236.16.20 and 193.30.227.161

Why Separate Naming and Addressing?

• Names are easier for people to remember– www.cnn.com vs. 64.236.16.20

• Addresses can change underneath– Move www.cnn.com to 64.236.16.20– E.g., renumbering when changing providers

• Name could map to multiple IP addresses– www.cnn.com to multiple replicas of the Web site

• Map to different addresses in different places– Address of a nearby copy of the Web site– E.g., to reduce latency, or return different content

• Multiple names for the same address– E.g., aliases like ee.mit.edu and cs.mit.edu

!4

DNS resolution 11/6/16

2

DNS Query and Response

Caching DNS Server

End-user

www.colostate.edu A?

www.colostate.edu A is 129.82.64.100

Root DNS Server

Multiple servers for each zone in case any one server fails

13 root servers13 edu servers5 colostate.edu servers

edu DNS Server

colostate.edu DNS Server

Host Names vs. IP addresses• Host names

– Mnemonic name appreciated by humans– Variable length, alphanumeric characters– Provide little (if any) information about location– Examples: www.cnn.com and ftp.eurocom.fr

• IP addresses– Numerical address appreciated by routers– Fixed length, binary number– Hierarchical, related to host location– Examples: 64.236.16.20 and 193.30.227.161

Why Separate Naming and Addressing?

• Names are easier for people to remember– www.cnn.com vs. 64.236.16.20

• Addresses can change underneath– Move www.cnn.com to 64.236.16.20– E.g., renumbering when changing providers

• Name could map to multiple IP addresses– www.cnn.com to multiple replicas of the Web site

• Map to different addresses in different places– Address of a nearby copy of the Web site– E.g., to reduce latency, or return different content

• Multiple names for the same address– E.g., aliases like ee.mit.edu and cs.mit.edu

“A” is one type of DNS record, but DNS servers can return several different types of records:• A -> IP address• AAAA -> IPv6 address• …

!5

Advantages of separating naming and addressing

• Main advantage: names are easier to remember

• cnn.com VS 64.236.16.20

• Names make a certain endpoint independent from the IP address

• If cnn.com moves, it can simply change the mapping of cnn.com to a different IP address

• Names can map to multiple/different IP addresses (used for load balancing, localization)

• Enable aliasing (multiple names for same address)

!6

Other solutions

• Initial approach: static mapping between names and IPs, stored in a text file (/etc/hosts)

• Master kept at SRI, Menlo Park, CA

• Obviously does not scale well

!7

Other solutions - II• Can I get by using a single central server?

• Yeah, right!

• Think that more or less every connection…

• …on every host…

• is preceded by a DNS request/response

• No server, no matter how powerful, could sustain this load!

• Also, it would constitute SOP for the whole Internet!

!8

The DNS infrastructure is a distributed system

• Names are hierarchical

• E.g. www.colostate.edu

• Servers are organized hierarchically too!

• Namespace divided in zones

Top-level domain

!9

DNS server hierarchy

11/6/16

4

DNS Root Servers• 13 root servers (see http://www.root-servers.org/)• Labeled A through M

B USC-ISI Marina del Rey, CAL ICANN Los Angeles, CA

E NASA Mt View, CAF Internet Software C. PaloAlto, CA (and 17 other locations)

I Autonomica, Stockholm (plus 3 other locations)

K RIPE London (also Amsterdam, Frankfurt)

m WIDE Tokyo

A Verisign, Dulles, VAC Cogent, Herndon, VA (also Los Angeles)D U Maryland College Park, MDG US DoD Vienna, VAH ARL Aberdeen, MDJ Verisign, ( 11 locations)

Types of DNS Servers• Authoritative DNS servers:

– provide authoritative records for a particular zone (e.g., colostate.edu, cisco.com, edu, uk, etc)

– Can be maintained locally or by a service provider – Top-level domain (TLD) servers:

• Authoritative servers responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp.

• Typically managed professionally• Network solutions maintains servers for com TLD• Educause for edu TLD

• Caching Servers– Accept queries for end hosts, lookup requested data,

and cache answers for later replies.

• Data organized as tree structure

– Each zone is authoritative for its local

data.

• Each zone operates a set of name

servers that contain the zone data

– Change to host.cs.colostate.edu is entered

at cs.colostate.edu servers.

• Tree structure directs queries to the

appropriate name server

– Root knows how to reach edu

– Edu knows how to reach colostate.edu

– Etc.

Root

edu mil ru

darpacolostate milaf

cs andrews

DNS Organization

!10

DNS server hierarchy

11/6/16

4

DNS Root Servers• 13 root servers (see http://www.root-servers.org/)• Labeled A through M

B USC-ISI Marina del Rey, CAL ICANN Los Angeles, CA

E NASA Mt View, CAF Internet Software C. PaloAlto, CA (and 17 other locations)

I Autonomica, Stockholm (plus 3 other locations)

K RIPE London (also Amsterdam, Frankfurt)

m WIDE Tokyo

A Verisign, Dulles, VAC Cogent, Herndon, VA (also Los Angeles)D U Maryland College Park, MDG US DoD Vienna, VAH ARL Aberdeen, MDJ Verisign, ( 11 locations)

Types of DNS Servers• Authoritative DNS servers:

– provide authoritative records for a particular zone (e.g., colostate.edu, cisco.com, edu, uk, etc)

– Can be maintained locally or by a service provider – Top-level domain (TLD) servers:

• Authoritative servers responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp.

• Typically managed professionally• Network solutions maintains servers for com TLD• Educause for edu TLD

• Caching Servers– Accept queries for end hosts, lookup requested data,

and cache answers for later replies.

• Data organized as tree structure

– Each zone is authoritative for its local

data.

• Each zone operates a set of name

servers that contain the zone data

– Change to host.cs.colostate.edu is entered

at cs.colostate.edu servers.

• Tree structure directs queries to the

appropriate name server

– Root knows how to reach edu

– Edu knows how to reach colostate.edu

– Etc.

Root

edu mil ru

darpacolostate milaf

cs andrews

DNS Organization

Authoritative servers (maintain records for

their respective zones)

Top-level domain authoritative servers

Root servers

!11

DNS server hierarchy

• Root servers:

• Provide authoritative records for TLD servers

• TLD servers:

• Provide authoritative records of zones in their subdomains (e.g. the TLD server for .edu has a record for colostate.edu)

!12

Root servers

11/6/16

4

DNS Root Servers• 13 root servers (see http://www.root-servers.org/)• Labeled A through M

B USC-ISI Marina del Rey, CAL ICANN Los Angeles, CA

E NASA Mt View, CAF Internet Software C. PaloAlto, CA (and 17 other locations)

I Autonomica, Stockholm (plus 3 other locations)

K RIPE London (also Amsterdam, Frankfurt)

m WIDE Tokyo

A Verisign, Dulles, VAC Cogent, Herndon, VA (also Los Angeles)D U Maryland College Park, MDG US DoD Vienna, VAH ARL Aberdeen, MDJ Verisign, ( 11 locations)

Types of DNS Servers• Authoritative DNS servers:

– provide authoritative records for a particular zone (e.g., colostate.edu, cisco.com, edu, uk, etc)

– Can be maintained locally or by a service provider – Top-level domain (TLD) servers:

• Authoritative servers responsible for com, org, net, edu, etc, and all top-level country domains uk, fr, ca, jp.

• Typically managed professionally• Network solutions maintains servers for com TLD• Educause for edu TLD

• Caching Servers– Accept queries for end hosts, lookup requested data,

and cache answers for later replies.

• Data organized as tree structure

– Each zone is authoritative for its local

data.

• Each zone operates a set of name

servers that contain the zone data

– Change to host.cs.colostate.edu is entered

at cs.colostate.edu servers.

• Tree structure directs queries to the

appropriate name server

– Root knows how to reach edu

– Edu knows how to reach colostate.edu

– Etc.

Root

edu mil ru

darpacolostate milaf

cs andrews

DNS Organization

!13

DNS Caches

• Most users do not directly contact authoritative servers for any resolution

• Instead, they contact a local DNS cache (e.g. provided by their ISP)

• The local DNS takes care of contacting the appropriate servers in the network, cache the resolved IP address, and forward it to the requesting client

!14

DNS resolution

11/6/16

5

Using DNS

• Local DNS server (“default name server”)– Usually near the end hosts who use it– Local hosts configured with local server (e.g.,

/etc/resolv.conf) or learn via DHCP• Client application

– Extract server name (e.g., from the URL)– Do gethostbyname() to trigger resolver code

• Server application– Extract client IP address from socket– Optional gethostbyaddr() to translate into name

requesting hostMy laptop

Authoritative root DNS server

local DNS caching server

1

2

4

5

6

authoritative ucla.eduDNS serverns.ucla.edu

78

AuthoritativeTLD DNS server

3

Types of Queriesrecursive query:• puts burden of name

resolution on contacted name server

• heavy load?• Query 1 is recursive

iterated query:• contacted server replies

with name of server to contact

• “I don’t know this name, but ask this server”

• Queries 2,4, and 6 are iterative

DNS Caching• Performing all these queries takes time

– And all this before the actual communication takes place– E.g., 1-second latency before starting Web download

• Caching can substantially reduce overhead– The top-level servers very rarely change– Popular sites (e.g., www.cnn.com) visited often– Local DNS server often has the information cached

• How DNS caching works– DNS servers cache responses to queries– Responses include a “time to live” (TTL) field– Server deletes the cached entry after TTL expires

• Recursive/iterative queries

• Recursive query: the contacted DNS resolver takes the burden of performing the resolution process

• Iterative query: the contacted DNS server replies with name of another server to contact

• “I don’t know this name, but ask this server”

Who has cs.ucla.edu?

Who has edu?

Who has ucla.edu?

Who has cs.ucla.edu?

!15

11/6/16

5

Using DNS

• Local DNS server (“default name server”)– Usually near the end hosts who use it– Local hosts configured with local server (e.g.,

/etc/resolv.conf) or learn via DHCP• Client application

– Extract server name (e.g., from the URL)– Do gethostbyname() to trigger resolver code

• Server application– Extract client IP address from socket– Optional gethostbyaddr() to translate into name

requesting hostMy laptop

Authoritative root DNS server

local DNS caching server

1

2

4

5

6

authoritative ucla.eduDNS serverns.ucla.edu

78

AuthoritativeTLD DNS server

3

Types of Queriesrecursive query:• puts burden of name

resolution on contacted name server

• heavy load?• Query 1 is recursive

iterated query:• contacted server replies

with name of server to contact

• “I don’t know this name, but ask this server”

• Queries 2,4, and 6 are iterative

DNS Caching• Performing all these queries takes time

– And all this before the actual communication takes place– E.g., 1-second latency before starting Web download

• Caching can substantially reduce overhead– The top-level servers very rarely change– Popular sites (e.g., www.cnn.com) visited often– Local DNS server often has the information cached

• How DNS caching works– DNS servers cache responses to queries– Responses include a “time to live” (TTL) field– Server deletes the cached entry after TTL expires

A slight issueHow the heck do I get to this guy?

Who should I ask?

Solution: the addresses of the 13 root servers are typically

hardcoded in name resolution software

!16

DNS caching• Performing all these queries takes time

• And all this is before the communication even takes place

• In order to reduce overhead, caching is used

• Local DNS server caches responses to queries

• Responses include a time to live (TTL) field

• Cached entries are deleted when TTL expires

!17

DNS records

• What are these records anyway?

• The DNS system is a massive distributed database, and the records are the entries of the database

• Record are in the generic format (name, value, type, ttl)

• Records are not just for translating names to IPv4 addresses

!18

DNS record types• Type A: name is hostname, value is IPv4 address

• Type AAAA: name is hostname, value is IPv6 address

• Type CNAME: name is hostname, value is a canonical name for the same host

• E.g. www.ibm.com's canonical name may be servereast.backup2.ibm.com

• Type MX: name is a domain name, value is a mail server for that domain

• Type NS: name is a domain name, value is the name of the authoritative DNS server for that domain

!19

Glue records• Parent zone (e.g. .com) stores authoritative name server for

a child zone (e.g. "myzone.com NS ns.myzone.com")

• However, in order to reach ns.myzone.com I would need to query the authoritative server for myzone.com, which is ns.myzone.com!

• Catch-22

• The solution is to store a glue record in the authoritative name server for the .com zone: “ns.myzone.com A 129.12.37.1”

!20

DNS queries

11/6/16

6

Negative Caching

• Remember things that don’t work– Misspellings like www.cnn.comm and

www.cnnn.com– These can take a long time to fail the first

time– Good to remember that they don’t work– … so the failure takes less time the next

time around

DNS Resource RecordsDNS: distributed db storing resource records (RR)

• Type=NS– name is domain (e.g.

foo.com)– value is hostname of

authoritative name server for this domain

RR format: (name, value, type, ttl)

• Type=A– name is hostname– value is IP address

• Type=CNAME– name is alias name for

some “canonical” (the real) namewww.ibm.com is reallyservereast.backup2.ibm.com

– value is canonical name• Type=MX

– value is name of mailserver associated with name

DNS Messages (1/2)DNS protocol : query and reply messages, both with

same message format

msg header• identification: 16 bit #

for query, reply to query uses same #

• flags:– query or reply– recursion desired – recursion available– reply is

authoritative

!21

DNS queries - II

11/6/16

7

DNS Messages (2/2)

Name, type fieldsfor a query

RRs in reponseto query

records forauthoritative servers

additional “helpful”info that may be used

Reliability

• DNS servers are replicated– Name service available if at least one replica is up– Queries can be load balanced between replicas

• UDP used for queries– Need reliability: must implement this on top of

UDP• Try alternate servers on timeout

– Exponential back-off when retrying same server• Same identifier for all queries

– Don’t care which server responds

Inserting Resource Records into DNS

• Example: just created startup “FooBar”• Register foobar.com at Network Solutions

– Provide registrar with names and IP addresses of your authoritative name server (primary and secondary)

– Registrar inserts two RRs into the com TLD server:• (foobar.com, dns1.foobar.com, NS)• (dns1.foobar.com, 212.212.212.1, A)

• Put in authoritative server dns1.foobar.com– Type A record for www.foobar.com– Type MX record for foobar.com

!22

DNS reliability• DNS servers are replicated

• Name service available if at least one replica is up

• Queries can be load-balanced between replicas

• UDP used for queries

• What if message lost? RFC 1536 recommends retransmission timer w/ RTT estimation and exponential back-off…

• … or try a different server/replica

• Retransmitted queries all carry the same identifier

!23

How are DNS records created?

• Example: company “foobar” wants to register its domain

• Register foobar.com at Network Solutions

• Provide registrar of name and IP address of authoritative name server

• Registrar inserts two records into com TLD server:

• (foobar.com, dns1.foobar.com, NS)

• (dns1.foobar.com, 212.212.212.1, A)

• Company add two records to authoritative server dns1.foobar.com:

• (www.foobar.com, 212.212.212.10, A)

• (foobar.com, mail.foobar.com, MX)

!24

Glue record

DNS security

!25

Security in standard DNS

• Standard DNS messages have limited protection against spoofing

• 16-bit query ID must be repeated in the reply

• The source UDP port is chosen randomly

• Not a very strong protection

!26

Why is the query ID not enough?

• Attack #1: sniffing+spoofing

• As no encryption is applied to DNS messages, any on-path attacker can sniff a query and try to beat the legitimate server by quickly crafting a spoofed answer

DNS cache

Attacker

Legitimate DNS resolver

Legitimate DNS query

Spoofed DNS replyLegitimate DNS reply

!27

Why is the query ID not enough? - II

• What if the attacker can’t observe the query?

• Attack #2: fragmentation

• DNS messages can be larger than a typical MTU (maximal transmission unit)

• If that is the case, they cause IP fragmentation (i.e. the original IP packet is broken into multiple ones)

• Challenge information (UDP port + query ID) is carried in the first fragment

• Attack: force DNS resolver to send requests that typically elicit a large answer; inject packet fragments that are likely to override the actual 2nd fragment of the response

!28

Why is the query ID not enough? - III

• Attack #3: prediction

• Historically, certain DNS resolver implementations used easily predictable source ports and query IDs

• E.g. Bind 9 uses a weak PRNG (LFSR generator): when LSB of transaction ID is 0, there are only 10 possible values for the ID which is going to be generated for the next query

• Enables spoofing DNS replies by sending a burst of fake replies with guessed UDP port/query IDs

!29

DNS cache poisoning

• All attacks above are used to inject fake records into DNS caches

• Every client which request those records will receive poisoned data

• What is the impact of this?

!30

DNS cache poisoning - II

• Can redirect a client to the wrong IP address for a certain domain

• Not so useful if the user expects HTTPS (which is now common)

• Can redirect a client to a different domain using poisoned CNAME records

• Works as long as the user does not realize the domain she reached is not the one she requested

!31

Internet-wide study of DNS Cache Injections

!32

1"2"3"4"5"6"7"8"9"10"11"12"13"14"15"16"17"18"19"20"21"22"23"24"25"26"27"28"29"30"31"32"33"34"35"36"37"38"39"40"41"42"43"44"45"46"47"48"49"50"51"52"53"54"55"56"57"60"61"62"63"64"65"

Internet-Wide Study of DNS Cache InjectionsAmit Klein, Haya Shulman and Michael Waidner

Fraunhofer Institute for Secure Information Technology SITDarmstadt, Germany

Abstract—DNS caches are an extremely important tool, provid-

ing services for DNS as well as for a multitude of applications,

systems and security mechanisms, such as anti-spam defences,

routing security (e.g., RPKI), firewalls. Subverting the security

of DNS is detrimental to the stability and security of the clients

and services, and can facilitate attacks, circumventing even

cryptographic mechanisms.

We study the caching component of DNS resolution platforms

in diverse networks in the Internet, and evaluate injection

vulnerabilities allowing cache poisoning attacks. Our evaluation

includes networks of leading Internet Service Providers and

enterprises, and professionally managed open DNS resolvers. We

test injection vulnerabilities against known payloads as well as

a new class of indirect attacks that we define in this work. Our

Internet evaluation indicates that more than 92% of the Internet’s

DNS resolution platforms are vulnerable to records injection and

can be persistently poisoned.

I. INTRODUCTION

Domain Name System (DNS), [RFC1034, RFC1035], playsa key role in the Internet. However, its significance also madeit a target of attacks, most notably, DNS cache poisoning, [1],[2], [3], [4], [5], [6], [7], [8]. In the course of a DNS cachepoisoning attack, the attacker provides spoofed records in DNSresponses, in order to redirect the victims to incorrect hosts.DNS cache poisoning can facilitate credentials theft, malwaredistribution, censorship and more. DNS cache poisoning at-tacks are known to be practiced by governments, e.g., China,[9], USA with the QUANTUMDNS program [10], as well asby cyber criminals.

The recent wave of cache poisoning vulnerabilities as wellas evidence for attacks against DNS in the wild stimulatedawareness within the operational and research communities,and a number of studies measuring incorrect DNS responses inthe wild were conducted, [11], [12], [13], [14]. Nevertheless,it is not clear how effective the injection of DNS records isand whether, and under what conditions, such records poisonthe caches of victim DNS platforms. In particular, differentresolvers’ software apply different logic when deciding if toaccept and cache the records and if to return them to clients.In this work we perform the first study of caches in popularDNS resolution platforms in the Internet, and evaluate theeffectiveness of records injection different networks, includingnetworks of large Internet Service Providers (ISPs), publicDNS service operators and enterprise networks. The findingsof our study are alarming: 92% of the measured networks arevulnerable to records injection.

Adoption of DNSSEC, [RFC4033-RFC4035], would pre-vent the vulnerabilities. Unfortunately, recently [15] found thatmany domains are signed with vulnerable DNSSEC keys.

Related Work: Prior work studied the impact of cachingin the resolvers on DNS performance and on the latencyperceived by the clients, e.g., [16], [17]. In a recent work,[4], showed that a large fraction of nameservers use cachesfor reducing the requests’ volume and to protect the name-servers from Denial of Service (DoS) and other attacks. [18],measured the client side of the DNS infrastructure, in order toidentify all the actors in DNS resolution platforms that provideopen recursive resolution. In their study Schomp et al used asimilar host discovery technique to the one proposed in [19] –both scanned a fraction of the IPv4 addresses requesting host-names in domains that they owned, and checking for requestsarriving at the nameservers authoritative for those domains. Astudy of approaches for services discovery (including DNS)via scanning of the IPv4 address block was done in [20]. Tooptimise content distribution networks (CDNs) [21] ran a studyof associating DNS resolvers with their clients.

To study ranking assignment by caches on DNS records,[22] applied a ProVerif formal verification program on theformal models of the semantics of 3 DNS resolvers. Recom-mendations for handling records in DNS responses, cachingand returning them to clients were discussed with respect toUnbound DNS software in [23].

Contributions: In this work we perform an extensivestudy of the caches in DNS resolution platforms in well man-aged networks, comprising: (1) ISPs, (2) enterprises and (3)popular networks operating open resolvers. For our data col-lection we utilise three different approaches: (1) a distributedad-network, (2) email servers in networks of popular enter-prises, (3) open resolvers used in popular domains (accord-ing to Alexa websites ranking service, www.alexa.com).Through evaluation and measurements we find that more than92% of the studied networks are vulnerable to at least oneinjection attack resulting in cache poisoning; this breaks downto 97% of the networks operating open resolvers, 74% of theenterprise networks measured via email servers, and 68% ofthe ISPs measured via ad-network.

Our study of records injections uses a comprehensive set ofpayloads, which consists of different combinations of recordsand records’ types in DNS responses and in caches. We alsodefine a new type of payloads which allow indirect injectionof spoofed records for cache poisoning attacks.

Organisation: In Section II we present our study method-ology and data collection. In Section III we define the payloadsthat we use in our evaluation of records injection. In SectionIV we perform Internet evaluation of records injection againstpopular DNS resolution platforms and public DNS services.

INFOCOM 2017 1570302450

1

Viability of cache poisoning attacks

• We have seen broadly how poisoned DNS replies can be successfully submitted

• We have seen the possible consequences of successful DNS cache poisoning

• A relevant question is: if a poisoned DNS reply is successfully submitted, will DNS software accept it?

• This is what the assigned reading focuses on

!33

Discussion of the paper

• Overall idea: establish whether popular DNS caches accept and use poisoned DNS replies

• Observation #1: whether replies are accepted or not may depend on the configuration of the cache software

• Observation #2: even when poisoned records are accepted, they may not be used due to ranking

!34

Experimental methodology

We conclude this work in Section V.

II. METHODOLOGY

In this section we describe the attacker model that weconsider in this work, and the setting that we use for ourstudy and the data collection methodology.

A. Attacker Model

We consider an attacker that can inject valid DNS responsesinto the communication between a victim DNS resolver anda nameserver. Namely, the attacker does not need to guessthe challenge-response authentication parameters, such as thesource port and the DNS transaction identifier (TXID). Weassume that these are either known to the attacker, e.g., ifthe challenge values are not randomised, or that the attackercan guess them efficiently. For instance, a man-in-the-middle(MitM) attacker sees the DNS requests and hence can simplycopy the challenge-response authentication parameters fromthe request to the response. An off-path attacker does notsee the requests, therefore has to guess the challenge val-ues. To that end, the attacker can apply fragmentation [8],which allows to bypass guessing the parameters, or can applydifferent techniques to guess the values, e.g., in vulnerableimplementations or via side-channels, [24], [7].

Since the attacker is assumed to be able to bypass thechallenge authentication (i.e., craft a DNS response with acorrect destination port, TXID and other values), the remainingpart is to provide such records to the victim resolver that wouldbe accepted, cached and provided to the clients. Cachingbehaviour and which records the resolvers return to the clients,both depend on the records that are already in cache, thecaching policies and the trust level that the DNS resolversassign to the records that they receive in responses. Hence theattacker needs to find such records’ sequence, records’ typeand hostnames that would enable the attacker to overwritethe values of the already cached legitimate DNS recordswith spoofed values. For instance, overwriting a legitimate IPaddress of a nameserver or a website with a spoofed one.

B. DNS Resolution Platforms

In our study, we consider a general model of DNS resolutionplatforms, illustrated in Figure 1. The platform consists of a set(232�x) of ingress DNS resolvers which handle DNS queriesfrom the clients, a set of n caches, and a set (232�y) of egressDNS resolvers, which communicate with the nameservers ifthe queries from the clients cannot be satisfied from (one of)the caches. The load balancers apply logic for selection of thecaches to probe, and for selection of an egress resolver’s IPaddress (in case a requested record cannot be satisfied fromcaches).

This infrastructure corresponds to complex platforms suchas Google Public DNS, but can also be abstracted to incor-porate very simple DNS resolution platforms with a single IPaddress which performs both the ingress and egress function-alities and uses a single cache.

Fig. 1. DNS resolution platforms and our caches evaluation infrastructure.

Our test infrastructure in Figure 1 communicates withthe egress resolvers, and uses two set-ups to communicatewith the ingress resolvers: with direct and indirect probers,for triggering the caches study. A direct prober is one thatcan send queries to the ingress resolver directly, whereasindirect uses proxies, such as web browsers or email servers(details follow). Our infrastructure uses a dedicated domain,for simplicity lets assume it is test.example and allocatesa number of subdomains, under test.example, for testingthe caches. We setup a number of nameservers, authoritativefor test.example, and nameservers authoritative for thesubdomains of test.example.

Our implementation uses the Stanford::DNSserver Perl au-thoritative DNS server.

For the purpose of our study we evaluate poisoning therecords of the domain test.example (which is under ourcontrol) and its subdomains. Specifically, we first insert intothe caches the real values of records under test.exampleand then test the caching vulnerabilities. During that phasewe attempt to replace the real values with spoofed ones.For evaluation of injection of spoofed values we set up adedicated infrastructure which ‘simulate’ attacker hosts. Theattacker’s hosts are located on a different network block thenthe test.example infrastructure and use a distinct set of IPaddresses. For instance, we replace an IP address, a.b.c.d, of awebsite under test.example with a malicious IP address6.6.6.6 which is allocated to one of the hosts of the attacker.Then we issue a request to the evaluated DNS platform, sayfor IP address of the website under test.example, andcheck which value we receive in response: the real IP addressa.b.c.d or the poisoned value 6.6.6.6.

C. Data Collection and Statistics

In this section we describe our data collection in DNSresolution platforms in three common networks: (1) networksof popular Alexa domains (www.alexa.com) that operate openrecursive resolvers, (2) networks of Internet Service Providers(ISPs), and (3) networks of popular enterprises.

1) Collecting DNS Platforms with Open Resolvers: Anumber of studies were conducted on open resolvers, e.g.,[18], [12], [25]. The studies scan the IPv4 address block,looking for hosts that serve DNS requests on port 53. However,[19], [26] showed that most such open resolvers are either

2

Direct prober: used when target cache is directly reachable

Indirect probers: used when access to target cache is restricted

Two sets of DNS servers: (i) legitimate authoritative servers, (ii) attack servers (sets are on network

blocks w/ different IP prefixes)

!35

Experimental methodology - II

• Phases:

• 1: Seeding: creation of genuine record in target cache

• 2: Poisoning: attempt to inject poisoned records in target cache

• 3: Verification: check if records of interest contain genuine or injected values

!36

Attack payload example

Test DNS Values in Overrides Auth Direct DefenceName Fields DNS Fields Cached Ref.

1. NS0

Q A? two.test-ns0.TAIL test-ns0.TAIL No No (A)/(B)An two.test-ns0.TAIL A a.b.c.d NSAu test-ns0.TAIL NS ns2.test-ns0.TAIL ns.test-ns0.TAILAd ns2.test-ns0.TAIL A ATTACKER

2. NS0-auth

Q A? two.test-ns0-auth.TAIL test-ns0-auth.TAIL Yes No (A)/(B)An two.test-ns0-auth.TAIL A a.b.c.d NSAu test-ns0-auth.TAIL NS ns2.test-ns0-auth.TAIL ns.test-ns0-auth.TAILAd ns2.test-ns0-auth.TAIL A ATTACKER

3. NS

Q A? ns2.test-ns.TAIL test-ns.TAIL No No (A)An ns2.test-ns.TAIL A ATTACKER NSAu test-ns.TAIL NS ns2.test-ns.TAIL ns.test-ns.TAILAd —

4. NS-auth

Q A? ns2.test-ns-auth.TAIL test-ns-auth.TAIL Yes No (A)An ns2.test-ns-auth.TAIL A ATTACKER NSAu test-ns-auth.TAIL NS ns2.test-ns-auth.TAIL ns.test-ns-auth.TAILAd —

5. NS2

Q A? two.test-ns2.TAIL test-ns2.TAIL No No (A)An two.test-ns2.TAIL A a.b.c.d NSAu test-ns2.TAIL NS ns2.magic-ns2.TAIL ns.test-ns2.TAILAd —

6. NS2-auth

Q A? two.test-ns2-auth.TAIL test-ns2-auth.TAIL Yes No (A)An two.test-ns2-auth.TAIL A a.b.c.d NSAu test-ns2-auth.TAIL NS ns2.magic-ns2-auth.TAIL ns.test-ns2-auth.TAILAd —

7. b4

Q A? two.test-b4.TAIL ns.test-b4.TAIL N/A No (B)An — AAu sub.test-b4.TAIL NS ns.test-b4.TAIL a.b.c.dAd ns.test-b4.TAIL A ATTACKER

8. u1-auth

Q A? two.test-u1-auth.TAIL test-u1-auth.TAIL Yes No (A)/(B)An — NSAu test-u1-auth.TAIL NS ns2.test-u1-auth.TAIL ns.test-u1-auth.TAILAd ns2.test-u1-auth.TAIL A ATTACKER

9. u3-2

Q A? two.test-u3-2.TAIL ns.test-u3-2.TAIL N/A No (B)An two.test-u3-2.TAIL A a.b.c.d AAu test-u3-2.TAIL NS ns.test-u3-2.TAIL a.b.c.dAd ns.test-u3-2.TAIL A ATTACKER

10. u3-3

Q A? two.test-u3-3.TAIL ns.test-u3-3.TAIL N/A No (B)An — AAu test-u3-3.TAIL NS ns.test-u3-3.TAIL a.b.c.dAd ns.test-u3-3.TAIL A ATTACKER

11. u3-4

Q A? two.sub.test-u3-4.TAIL ns.test-u3-4.TAIL N/A No (B)An — AAu sub.test-u3-4.TAIL NS ns.test-u3-4.TAIL a.b.c.dAd ns.test-u3-4.TAIL A ATTACKER

12. w-dnameQ A? two.test-w-dname.TAIL (all).test-w-dname.TAIL N/A No no

An test-w-dname.TAIL DNAME magic-w-dname.TAIL All DNAMEAu — types fromAd — cache

13. w7

Q A? two.test-w7.TAIL ns.test-w7.TAIL N/A No [break]An two.test-w7.TAIL CNAME ns.test-w7.TAIL; A CNAME

ns.test-w7.TAIL A ATTACKER a.b.c.d chainAu/Ad —

14. w8

Q A? ns.sub.test-w8.TAIL ns.test-w8.TAIL N/A No [break]An sub.test-w8.TAIL DNAME test-w8.TAIL; A DNAME

ns.test-w8.TAIL A ATTACKER a.b.c.d chainAu/Ad —

15. dname

Q A? zwei.test-dname.TAIL (all).test-dname.TAIL N/A Yes noAn test-dname.TAIL DNAME magic-dname.TAIL ALL DNAMEAu — types fromAd — cache

16. ak1

Q A? zwei1.test-ak1.TAIL one1.test-ak1.TAIL N/A Yes [break]An zwei1.test-ak1.TAIL CNAME one1.test-ak1.TAIL; ALL CNAME

one1.test-ak1.TAIL CNAME one1.magic-ak1.TAIL TYPES chainAu/Ad —

17. w11

Q A? zwei.one1.test-w11.TAIL one1.test-w11.TAIL N/A Yes (A)An — NSAu one1.test-w11.TAIL NS ns2.magic-w11.TAIL ANYAd —

18. w11bis

Q A? zwei.one1.test-w11bis.TAIL one1.test-w11bis.TAIL N/A Yes (A)/(B)An — NSAu one1.test-w11bis.TAIL NS ns2.test-w11bis.TAIL ANYAd ns2.test-w11bis.TAIL A ATTACKER

TABLE IPAYLOADS FOR DNS RECORDS’ INJECTION. DEFENCES LEGEND: (A) AUTHORITY QUERY FOR NS AFTER REFERRAL; (B) AUTHORITY QUERIES FOR

NAMESERVER IP ADDRESSES.

the browser; for instance, Chrome 48 times-out long beforethe tests are completed (due to a bug which was later fixed inChrome 49).

The results for SMTP are slightly better than for ad-networks. In this set-up, as is the case with browser basedevaluation, indirect access introduces noise and higher failurerates. In particular, local caches (of browsers and operating

systems), as well as lack of control of the timing of the queries,make the evaluation more difficult.

Despite the higher failure rates among ISPs (with ad-nets)and enterprises (with SMTP servers), the fraction of networksthat were found to be vulnerable to at least one injectionpayload is alarmingly high, and the majority of the networksare vulnerable to at least one injection payload. The combined

6

Poisoned (spoofed) answer Record planted during seeding phase

• Broadly, this attack spoofs a CNAME record redirecting the target test-ak1 subdomain to the attack subdomain magic-ak1

• The record is not used until a valid A record for one1.test-ak1.TAIL exists; once that record expires, the poisoned CNAME record becomes active

!37

Results• Vulnerabilities of popular DNS cache softwares

Fig. 2. Evaluation of the cache poisoning payloads against popular DNS software and public DNS services.

Fig. 3. Evaluation of payloads injections against networks in our dataset.

tests (including indirect attacks) across all network populationsexhibit more than 92% success rate.

The DNS platforms typically more than a single cache, wenext explain how our evaluation handles multiple caches.

C. Extension to Multiple Caches

Often DNS resolution platforms use more than one cache,e.g., for efficiency. We show how to extend our study toevaluate DNS platforms with multiple caches. The main ideabehind multiple caches is using multiple number of DNSrequests that would ensure probing all the caches used by agiven DNS resolution platform.

When a resolution platform has more than one cache wecannot guarantee that all the payloads will be evaluated insequence against the same cache. In particular, often thequeries will be distributed among different caches, hence, itcan often happen that the seed would be placed in one cache,and the malicious payload would be directed to another cache.To cope with multiple caches, instead of having the samecache handle the attack cycle (seed ! poison ! validate),we “bombard” with (N ) multiple “parallel” steps of (seed! poison ! check). Namely, during the seeding phase wesend N seeds: s1, s2, ..., sN . Then, during the poisoning phase

we send N instances of the same payload: p1, ..., pN . Finally,we initiate the validate phase requesting the ‘honey’ records:c1, ..., cN .

A prerequisite is that N (number of copies in the attack)is larger than n (number of caches). Specifically, the expectedpart of the n caches that is not covered in N attempts isroughly exp(�N

n ).Overall, if the target DNS resolver is vulnerable, in the last

phase we expect success rate of N · (1 � exp(�Nn ))2; as N

ngrows, this asymptotically reaches N .

Our measurements show that typically the resolution plat-forms in the Internet use more than a single IP addressand more than a single cache. In Figure 4 we plot ourmeasurements for number of caches supported by resolutionplatforms in the three common networks’ populations that westudied. The networks running open resolvers use the leastnumber of caches, 70% have 1 to 2 caches per IP address.About 60% of DNS platforms operated by ISPs use 1-3 caches,and 65% of networks measured via email servers use 1-4caches per ingress IP address.

Fig. 4. The number of caches supported by resolution platforms.

The results in Figures 6 and 7 provide the distribution ofthe number of ingress IP addresses vs. caches for networksoperating open resolvers, enterprise networks and ISPs. The

7

!38

Results - II• Percentage of vulnerable networks per category

Fig. 2. Evaluation of the cache poisoning payloads against popular DNS software and public DNS services.

Fig. 3. Evaluation of payloads injections against networks in our dataset.

tests (including indirect attacks) across all network populationsexhibit more than 92% success rate.

The DNS platforms typically more than a single cache, wenext explain how our evaluation handles multiple caches.

C. Extension to Multiple Caches

Often DNS resolution platforms use more than one cache,e.g., for efficiency. We show how to extend our study toevaluate DNS platforms with multiple caches. The main ideabehind multiple caches is using multiple number of DNSrequests that would ensure probing all the caches used by agiven DNS resolution platform.

When a resolution platform has more than one cache wecannot guarantee that all the payloads will be evaluated insequence against the same cache. In particular, often thequeries will be distributed among different caches, hence, itcan often happen that the seed would be placed in one cache,and the malicious payload would be directed to another cache.To cope with multiple caches, instead of having the samecache handle the attack cycle (seed ! poison ! validate),we “bombard” with (N ) multiple “parallel” steps of (seed! poison ! check). Namely, during the seeding phase wesend N seeds: s1, s2, ..., sN . Then, during the poisoning phase

we send N instances of the same payload: p1, ..., pN . Finally,we initiate the validate phase requesting the ‘honey’ records:c1, ..., cN .

A prerequisite is that N (number of copies in the attack)is larger than n (number of caches). Specifically, the expectedpart of the n caches that is not covered in N attempts isroughly exp(�N

n ).Overall, if the target DNS resolver is vulnerable, in the last

phase we expect success rate of N · (1 � exp(�Nn ))2; as N

ngrows, this asymptotically reaches N .

Our measurements show that typically the resolution plat-forms in the Internet use more than a single IP addressand more than a single cache. In Figure 4 we plot ourmeasurements for number of caches supported by resolutionplatforms in the three common networks’ populations that westudied. The networks running open resolvers use the leastnumber of caches, 70% have 1 to 2 caches per IP address.About 60% of DNS platforms operated by ISPs use 1-3 caches,and 65% of networks measured via email servers use 1-4caches per ingress IP address.

Fig. 4. The number of caches supported by resolution platforms.

The results in Figures 6 and 7 provide the distribution ofthe number of ingress IP addresses vs. caches for networksoperating open resolvers, enterprise networks and ISPs. The

7

!39

Can we do anything about DNS security?

• We have seen that:

• Poisoned DNS replies can be successfully submitted

• DNS caches oftentimes accept and use such requests

• DNS poisoning can have real and damaging consequences for users

• It’s 2017: can we come up with a more secure way to do name resolutions?

!40

DNSSEC

• Goal: secure DNS communications to prevent spoofing

• Broad design principles:

• Provide data integrity (responses cannot be altered in transit)

• Provide proof of authority (the response come from an authoritative server for the domain of interest)

!41

Securing DNS record with DNSSEC

• Example (from Microsoft Technet): DNS records for “contoso.com" domain before and after enabling DNSSEC:

Every record has now been signed

A DNSKEY record (and other related data) has

been created!42

Validation process in a nutshell

• Example (from Microsoft Technet):

When replying to a DNS query, an authoritative server sends both the

requested record and a signature record

DNS cache validates record against signature before

forwarding the reply to the user

!43

Roots of trust• How do we know we can trust DNSKEY records?

• DNSKEY records are signed themselves with a key-signing key (KSK)

• How do we trust KSK records?

• Hash of the KSK is provided to the authoritative nameserver for the parent zone (requester can use the hash to validate the KSK)

• Root of trust goes all the way to the root DNS servers, and…

• … DNSKEY used to sign KSK of these servers is signed in a public ceremony

!44

Key-signing ceremony

Source: https://www.cloudflare.com/dns/dnssec/root-signing-ceremony/

!45

DNSSEC issues

• Broken chain of trust may prevent verification (nearly 20% of popular domain, Dai et al., CANS 2016)

• Wrong or missing records in parent zones

• Hash in parent zone does not match

• DNSSEC records are large and can be used in amplification denial-of-service attacks (not really an issue of DNSSEC, but an issue created by DNSSEC)

!46

Fresh out of the oven: ODNS

• Problem: ISP learns user browsing habits through DNS requests

• Solution: encryption+indirection: add a third-party server so no one can learn the association between user and query

Source: odns.cs.princeton.edu