Internet ProtocolsFall 2005

Lectures 19 DNS

Andreas Terzis

Outline

• DNS– Design– DNS Vulnerabilities– DNS Misconfigurations

CS 349/Fall05 2

DNS: History

• Initially all host-addess mappings were in a file called hosts.txt (in /etc/hosts)– Changes were submitted to SRI by email– New versions of hosts.txt ftp’d periodically

from SRI– An administrator could pick names at their

discretion

CS 349/Fall05 3

DNS History (cont.)

• As the internet grew this system broke down because:– SRI couldn’t handled the load– Names were not unique– Many hosts had inaccurate copies of

hosts.txt• Internet growth was threatened!

– DNS was born

CS 349/Fall05 4

Basic DNS Features

• Hierarchical namespace– as opposed to original flat namespace

• Distributed storage architecture– as opposed to centralized storage (plus

replication)

• Client--server interaction on UDP Port 53– but can use TCP if desired

CS 349/Fall05 5

Naming Hierarchy

CS 349/Fall05 6

• “Top Level Domains” are at the top• Depth of tree is arbitrary (limit 128)• Domains are subtrees

– E.g: .edu, berkeley.edu, eecs.berkeley.edu

• Name collisions avoided– E.g. berkeley.edu and berkeley.com can

coexist, but uniqueness is job of domain

root

edu com gov mil org net uk

berkeley mit

fretc.

eecs sims

argus

Host names are administered hierarchically

root

edu com gov mil org net uk fr

berkeley mit

eecs sims

argus

root

edu com gov mil org net uk fr

berkeley

eecs sims

A zone corresponds to an administrative authority that is responsible for that portion of the hierarchy

eecs controls names: x.eecs.berkeley.eduberkeley controls names: x.berkeley.edu and

y.sims.berkeley.eduCS 349/Fall05 7

Server Hierarchy

• Each server has authority over a portion of the hierarchy– A server maintains only a subset of all names

• Each server contains all the records for the hosts in its zone– might be replicated for robustness

• Each server needs to know other servers that are responsible for the other portions of the hierarchy– Every server knows the root– Root server knows about all top-level domains

CS 349/Fall05 8

DNS Name Servers

• Local name servers:– Each ISP (company) has local default name server– Host DNS query first goes to local name server

• Authoritative name servers:– For a host: stores that host’s (name, IP address)– Can perform name/address translation for that host’s

name • Can also do IP to name translation, but won’t

discuss

CS 349/Fall05 9

What's in the zone's master file:

1. data that defines the top node of the zone – including a list all the servers for the zone

2. authoritative data for all nodes in the zone– all RRs for all of the nodes from the top node to leaf

nodes(that are outside of any subzone)3. data that describes delegated subzones

– Domain name, owner, etc4. “glue data”: IP address(es) for subzone's name

server(s)

CS 349/Fall05 10

cs.jhu.edu

jhu.edu

DNS: Root Name Servers

• Contacted by local name server that can not resolve name

• Root name server:– Contacts authoritative

name server if name mapping not known

– Gets mapping– Returns mapping to local

name server• ~ Dozen root name servers

worldwide

CS 349/Fall05 11

Simple DNS Exampleroot name server

Host whistler.cs.cmu.eduwants IP address of www.berkeley.edu

1. Contacts its local DNS server, mango.srv.cs.cmu.edu

2. mango.srv.cs.cmu.educontacts root name server, if necessary

3. Root name server contacts authoritative name server,ns1.berkeley.edu, if necessary

CS 349/Fall05 12

requesting hostwhistler.cs.cmu.edu

authorititive name serverns1.berkeley.edu

local name servermango.srv.cs.cmu.edu

23

45

1 6

www.berkeley.edu

Example of Recursive DNS Query

Root name server:• May not know authoritative

name server• May know intermediate

name server: who to contact to find authoritative name server?

Recursive query:• Puts burden of name

resolution on contacted name server

• Heavy load?

requesting hostwhistler.cs.cmu.edu

www.berkeley.edu

root name server

local name servermango.srv.cs.cmu.edu

1

23

4 5

6

authoritative name serverns1.berkeley.edu

intermediate name server(edu server)

7

8

CS 349/Fall05 13

Example of Iterated DNS Query

CS 349/Fall05 14

Iterated query:• Contacted server

replies with name of server to contact

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

requesting hostwhistler.cs.cmu.edu

www.berkeley.edu

root name server

local name servermango.srv.cs.cmu.edu

1

2

34

67

authoritative name serverns1.berkeley.edu

intermediate name server(edu server)

5

8

iterated query

DNS Records

• Four fields: (name, value, type, TTL)

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

• Type = NS: – name = domain– value = name of dns server for domain

CS 349/Fall05 15

DNS Records (cont’d)

• Type = CNAME:– name = hostname– value = canonical name

• Type = MX:– name = domain in email address– value = canonical name of mail server

CS 349/Fall05 16

DNS protocol, messages

Name, type fieldsfor a query

RRs in responseto query

records forauthoritative servers

additional “helpful”info that may be used

identification: 16 bit # for query, reply to query uses same #flags: query or reply

recursion desired recursion availablereply is authoritative

CS 349/Fall05 17

DNS as Indirection Service

• Can refer to machines by name, not address– not only easier for humans– also allows machines to change IP addresses without

having to change way you refer to machine• Can refer to machines by alias

– www.berkeley.edu can be generic web server– but DNS can point this to particular machine that can

change over time• But, this flexibility applies only within domain!

CS 349/Fall05 18

Special Topics

• DNS caching– improve performance by saving results of previous

lookups• DNS “hacks”

– return records based on requesting IP address• dynamic DNS

– allows remote updating of IP address for mobile hosts

• DNSSEC

CS 349/Fall05 19

DNS Vulnerabilities

• Original DNS design focused on data availability – DNS zone data is replicated at multiple servers.– A DNS zone works as long as one server is

available.• DDoS attacks against the root must take out 13 root

servers.

• But the DNS design included no authentication.– Any DNS response is generally believed.– No attempt to distinguish valid data from invalid.

• Just one false root server could disrupt the entire DNS.

CS 349/Fall05 20

A Simple DNS Attack

Caching DNS Server

www.darpa.mil A?

CS 349/Fall05 21

Sanjoy’sLaptop www.darpa.mil

A 128.9.128.127

Root DNS Server

mil DNS Server

Dan’s Laptop

Easy to observe UDP DNS query sent to well known server on well known port.

www.darpa.mil A 192.5.18.19

First response wins. Second response is silently dropped on the floor.

darpa.mil DNS Server

A More Complex Attack

Bell Labs Caching Server

CS 349/Fall05 22

ns.attacker.com

Query www.attacker.com

Response www.attacker.com A 128.9.128.127attacker.com NS ns.attacker.comattacker.com NS www.google.comns.attacker.com A 128.9.128.2www.google.com A 128.9.128.127

Query www.google.com

www.google.com= 128.9.128.127

Any Bell Labs Laptop Remote attacker

The Problem in a Nutshell

• Resolver can not distinguish between valid and invalid data in a response.

• Idea is to add source authentication– Verify the data received in a response is equal to

the data entered by the zone administrator.– Must work across caches and views.– Must maintain a working DNS for old clients.

CS 349/Fall05 23

Authentication DNS Responses

• Each DNS zone signs its data using a private key.– Recommend signing done offline in advance

• Query for a particular record returns:– The requested resource record set.– A signature (SIG) of the requested resource record set.

• Resolver authenticates response using public key.– Public key is pre-configured or learned via a sequence of key

records in the DNS hierarchy.

CS 349/Fall05 24

Secure DNS Query and Response

Caching DNS Server

www.darpa.mil

End-user www.darpa.mil = 192.5.18.195

Plus (RSA) signature by darpa.milAttacker can not forge this answer without the darpa.mil private key.

Authoritative DNS Servers

Challenge: add signatures to the protocolmanage DNS public keys

CS 349/Fall05 25

Important Properties of DNS

Administrative delegation and distributed server architecture results in:

• Easy unique naming

• Fate sharing for network failures

• Reasonable trust model

CS 349/Fall05 26

Study of DNS Robustness

• Classify DNS operational errors:– Study known errors – Identify new types of errors

• Measure their pervasiveness• Quantify their impact on DNS

– Availability – Performance

CS 349/Fall05 27

Infrastructure RRs

CS 349/Fall05 28

foo.com. NS ns1.foo.com.foo.com. NS ns2.foo.com.foo.com. NS ns3.foo.com.

foo.com. NS ns1.foo.com.foo.com. NS ns2.foo.com.foo.com. NS ns3.foo.com.

foo.com

com ns1.foo.com. A 1.1.1.1ns2.foo.com. A 2.2.2.2ns3.foo.com. A 3.3.3.3

ns1.foo.com. A 1.1.1.1ns2.foo.com. A 2.2.2.2ns3.foo.com. A 3.3.3.3

•NS Resource Record:–Provides the names of a zone’s authoritative servers–Stored both at the parent and at the child zone

•A Resource Record–Associated with a NS resource record–Stored at the parent zone (glue A record)

What Affects DNS Availability

• Name Servers:– Software failures – Network failures – Scheduled maintenance tasks

• Infrastructure Resource Records:– Availability of these records– Configuration errors

CS 349/Fall05 29

Lame Delegation

CS 349/Fall05 30

com

foo

foo.com. NS A.foo.com.foo.com. NS B.foo.com.

A.foo.com

A.foo.com. A 1.1.1.1B.foo.com. A 2.2.2.2

2) DNS error code-- 1 RTT perf. penalty

3) Useless referral-- 1 RTT perf. penalty

4) Non-authoritativeanswer (cached)

1) Non-existing server -- 3 seconds perf. penalty

B.foo.com

Lame Delegation Results

CS 349/Fall05 31

Lame Delegation Results

CS 349/Fall05 32

0.06 sec

0.4 sec3 sec

50%

Summary of Results

• DNS operational errors are widespread• DNS operational errors affect availability:

– 50% of the servers lost– less than 99.9% availability

• DNS operational errors affect performance:– 1 or even 2 orders of magnitude

• DNS system robustness lower than user perception– Due to protocol design, not just due to operator

errors

CS 349/Fall05 33