The Domain Name System
Stefano Vissicchio UCL Computer Science
COMP0023
Today
1. The Domain Name System (DNS)
2. ABriefWordonDNSSecurity
A name indicates what we seek. An address indicates where it is. A route indicates how we get there.
Jon Postel
3
Hostnames vs. IP Addresses
• Hostnames
– Mnemonic name used by humans
– Variable length, full alphabet of characters – Provide little (if any) information about location – Examples: www.cnn.com and www.bbc.co.uk
• IP addresses
– Numerical address used by routers
– Fixed length, binary number (e.g., 128.16.64.1) – Hierarchical, related to host location
4
ARPAnet, 1977
5
Looking Up IP Addresses Before the DNS
• Per-host file named hosts.txt
– Flat namespace: each line is an IP address and a name – SRI (Menlo Park, California) kept the master copy
– Everyone else downloads regularly
• Butasingleserver,manuallyupdated,doesn’tscale – Always a little out of date – name collisions!
– Traffic implosion (lookups and updates)
– Single point of failure
• Need a distributed and hierarchical collection of servers
DNS is a Wide-Area Distributed Database
Goals:
• Scalability and decentralized maintenance
– DNS is the biggest DB in the world! • Robustness
• Global scope
– names mean the same thing everywhere
• Don’t need all of ACID – Atomicity
– Strong consistency
• Do need: Performance for queries and distributed updates
Default answer to all systems problems:
If it doesn’t scale, add hierarchy.
If it doesn’t go fast enough, add a cache.
8
Domain Name System (DNS)
Hierarchical name space divided into zones
– Zones distributed over a collection of DNS servers
Hierarchy of DNS servers
– Root servers (identity hardwired into other servers) – Top-level domain (TLD) servers
– Authoritative DNS servers
To perform translations of names from/to IP addresses – Local DNS servers located near clients (for caching!) – Resolver software running on clients
DNS Namespace is Hierarchical
Root:
.
Top-level Domains (TLDs):
com. uk.
ac.uk. ucl.ac.uk.
edu.
mit.edu.
cmu.edu.
• Hierarchy of servers follows hierarchy of DNS zones • Zone is contiguous section of namespace
– e.g., complete tree, single node, or subtree
• Set of nameservers answers queries for names within zone
– Nameservers must store names and links to other servers in tree
DNS has Many Uses
• Hostname to IP address translation
• IP address to hostname translation (reverse lookup)
• Host name aliasing allows other names for a host – Can be arbitrarily many aliases
– Alias host names point to canonical hostname
• Mail server location
– Lookup zone’s mail server based on zone name
• Content distribution networks
– Load balancing among many servers with different
IP addresses
– Complex, hierarchical arrangements are possible
DNS Root Nameservers
• 13 root servers (see h4p://www.root-servers.org) – Named A through M
• Does this scale?
E NASA Mt View, CA F Internet SoPware
ConsorQum,
Palo Alto, CA
(and 37 other locaQons)
A Verisign, Dulles, VA
C Cogent, Herndon, VA (also Los Angeles, NY, Chicago)
D U Maryland College Park, MD G US DoD Vienna, VA
H ARL Aberdeen, MD
J Verisign (21 locaQons)
K RIPE London (plus 16 other locaQons)
I Autonomica, Stockholm (plus 29 other locaQons)
M WIDE Tokyo plus Seoul, Paris, San Francisco
B USC-ISI Marina del Rey, CA L ICANN Los Angeles, CA
DNS Root Nameservers
• 13 root servers (see h4p://www.root-servers.org) – Named A through M
• Each server really cluster of servers (some geographically distributed), replication via IP anycast
E NASA Mt View, CA F Internet SoPware
ConsorQum,
Palo Alto, CA
(and 37 other locaQons)
A Verisign, Dulles, VA
C Cogent, Herndon, VA (also Los Angeles, NY, Chicago)
D U Maryland College Park, MD G US DoD Vienna, VA
H ARL Aberdeen, MD
J Verisign (21 locaQons)
K RIPE London (plus 16 other locaQons)
I Autonomica, Stockholm (plus 29 other locaQons)
M WIDE Tokyo plus Seoul, Paris, San Francisco
B USC-ISI Marina del Rey, CA L ICANN Los Angeles, CA
TLD and Authoritative Servers
Top-level domain (TLD) servers
– Responsible for com, org, net, edu, etc, and all top- level country domains: uk, fr, ca, jp
– Network Solutions maintains servers for comTLD – Educause for edu TLD
Authoritative DNS servers
– An organization’s DNS servers, providing authoritative information for organization’s servers
– Can be maintained by organization or service provider
Local Name Servers
• Do not strictly belong to hierarchy
• Each ISP (company, university) has one
– Also called default or caching name server
• Any local DNS server does work for hosts
– Receives queries from end hosts
– Forwards each query into hierarchy • Acting as proxy
– Return the query’s response to the hosts
DNS in Operation
• Most queries and responses are UDP datagrams • Two types of queries:
Recursive:
NS
server may ask other servers if it doesn’t know the answer
Iterative:
Client
www.scholarly.edu?
Referral: .edu NS 10.2.3.1
NS
server will reply with what it does know
www.scholarly.edu?
Client
Answer: www.scholarly.edu A 10.0.0.1
Local NS Does Clients’ Work
Root NS
1. Client’sresolvermakes recursive query to local NS
2. LocalNSprocessing: – Local NS sends iterative
queries to other NS’s
– or finds answer in cache
3. LocalNSrespondswith answer to client’s request
Local NS
TLD NS
Authorita9ve NS Clients
Local NS Does Clients’ Work
Root NS
1. Client’sresolvermakes recursive query to local NS
2. LocalNSprocessing: – Local NS sends iterative
queries to other NS’s
– or finds answer in cache Local NS responds with answer to client’s request
Local NS
TLD NS
Authorita9ve NS Clients
Local NS Does Clients’ Work
Root NS
1. Client’sresolvermakes recursive query to local NS
2. LocalNSprocessing: – Local NS sends iterative
queries to other NS’s
– or finds answer in cache
3. LocalNSrespondsto client’s request
Local NS
TLD NS
Authorita9ve NS Clients
Client
www.scholarly.edu?
Example: Lookup for www.scholarly.edu
Local NS
. (root): NS 198.41.0.4
Client
Example: Lookup for www.scholarly.edu
. (root) authority 198.41.0.4 edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: NS 156.154.100.3
www.scholarly.edu?
Local NS
. (root): NS 198.41.0.4
Example: Lookup for www.scholarly.edu
. (root) authority 198.41.0.4 edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: NS 156.154.100.3
www.scholarly.edu? Contact 192.5.6.30 for edu.
Client
Local NS
. (root): NS 198.41.0.4
Example: Lookup for www.scholarly.edu
. (root) authority 198.41.0.4 edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: NS 156.154.100.3
www.scholarly.edu? Contact 192.5.6.30 for edu.
Client
Local NS
. (root): NS 198.41.0.4
edu.: NS 192.5.6.30
Example: Lookup for www.scholarly.edu
. (root) authority 198.41.0.4
edu.: no.: uk.:
NS 192.5.6.30
NS 158.38.8.133 NS 156.154.100.3
edu. authority 192.5.6.30 scholarly.edu.:NS 12.35.1.1 pedanQc.edu.: NS 19.31.1.1
Client
www.scholarly.edu?
Local NS
. (root): NS 198.41.0.4
edu.: NS 192.5.6.30
Example: Lookup for www.scholarly.edu
edu.: no.: uk.:
NS 192.5.6.30
NS 158.38.8.133 NS 156.154.100.3
. (root) authority 198.41.0.4
Client
www.scholarly.edu?
. (root): NS 198.41.0.4
edu.: NS 192.5.6.30
scholarly.edu.: NS12.35.1.1
edu. authority 192.5.6.30 scholarly.edu.:NS 12.35.1.1 pedanQc.edu.: NS 19.31.1.1
Contact 12.35.1.1 for scholarly.edu.
Local NS
Example: Lookup for www.scholarly.edu
. (root) authority 198.41.0.4
edu.: no.: uk.:
NS 192.5.6.30
NS 158.38.8.133 NS 156.154.100.3
edu. authority 192.5.6.30 scholarly.edu.:NS 12.35.1.1 pedanQc.edu.: NS 19.31.1.1
Client
scholarly.edu.: NS12.35.1.1
www.scholarly.edu?
Local NS
. (root): NS 198.41.0.4
edu.: NS 192.5.6.30
scholarly.edu. authority 12.35.1.1 www.scholarly.edu.: A 12.35.2.30 imap.scholarly.edu.: A 12.35.2.31
Example: Lookup for www.scholarly.edu
edu.: no.: uk.:
NS 192.5.6.30
NS 158.38.8.133 NS 156.154.100.3
. (root) authority 198.41.0.4
edu. authority 192.5.6.30 scholarly.edu.:NS 12.35.1.1 pedanQc.edu.: NS 19.31.1.1
Client
scholarly.edu.: NS12.35.1.1
www.scholarly.edu?
Local NS
. (root): NS 198.41.0.4
edu.: NS 192.5.6.30
scholarly.edu. authority 12.35.1.1 www.scholarly.edu.: A 12.35.2.30 imap.scholarly.edu.: A 12.35.2.31
www.scholarly.edu.: A 12.35.51.30
Example: Lookup for www.scholarly.edu
. (root) authority 198.41.0.4
edu.: no.: uk.:
NS 192.5.6.30
NS 158.38.8.133 NS 156.154.100.3
edu. authority 192.5.6.30 scholarly.edu.:NS 12.35.1.1 pedanQc.edu.: NS 19.31.1.1
www.scholarly.edu.: A 12.35.51.30
Client
scholarly.edu.: NS12.35.1.1
scholarly.edu. authority 12.35.1.1 www.scholarly.edu.: A 12.35.2.30 imap.scholarly.edu.: A 12.35.2.31
Local NS
. (root): NS 198.41.0.4
edu.: NS 192.5.6.30
Recursive vs. Iterative Queries
Recursive query
• Less burden on client
• More burden on nameserver
– has to return answer to quer y
• Most root and TLD servers will not answer
– Local name server answers recursive query
Iterative query
• More burden on client
• Less burden on nameserver
– simply refers query to another server
29
DNS Stores Resource Records
• RR includes: (name, type, value, time-to-live)
Type = A (address) name is hostname value is IP address
Type = NS (name server) name is domain (e.g.
cs.ucl.ac.uk)
value is hostname of
authoritative name server for this domain
Type = CNAME
name is an alias for some
“canonical” (real) name e.g. www.cs.ucl.ac.uk is really
cms.cs.ucl.ac.uk
value is canonical name
Type = MX (mail exchange) value is name of mail server
associated with domain name pref field discriminates between
multiple MX records
30
Example: Recursive Query, Step 1
“Glue” record
Example: Recursive Query, Step 2
“Glue” record
Example: Recursive Query, Step 3
DNS Caching
• Performing all these queries takes time
– And all this before actual communication takes place – e.g., one-second latency before star ting Web download
• Caching can greatly reduce overhead
– TLD servers very rarely change
– Local DNS server often has the information cached for popular sites, as they are visited often
• How DNS caching works
– DNS servers cache responses to queries
– Responses include a Time-To-Live (TTL) field – Server deletes cached entry afterTTL expires
Reverse Mapping (IP to Hostname)
• How do we translate IP addresses into corresponding hostnames?
– Why do we care to? Troubleshooting, security, spam
• IPaddressalreadyhasnatural“quad”hierarchy:12.34.56.78
• But: IP address has most significant hierarchy element on the left, while www.cnn.com has it on the right
• Idea: reverse the quads = 78.56.34.12, and look that up in the DNS
– Top-level domain convention: in-addr.arpa
– So lookup is for 78.56.34.12.in-addr.arpa
DNS Protocol
• Most queries and responses via UDP, server port 53
IP header
UDP header DNS payload
Source IP
DesQnaQon IP
Source port
Dest port
UDP length
UDP cksum
Query ID
QR opcode
A
CT
DR
AR
Z
rcode
DNS Server State
UDP socket listening on port 53
10.0.0.1
10.0.0.3
Client 10.0.0.1
Client 10.0.0.2
ACTDRAR
TLD NS 10.1.0.1
TLD NS 10.2.0.1
11001
53
UDP length
UDP cksum
11
QRopco de
Z
rcod e
Local NS 10.0.0.3
10.0.0.2
10.0.0.3
22002
53
UDP length
UDP cksum
22
QRopco de
ACTDRAR
Z
rcod e
DNS Server State
UDP socket listening on port 53
10.0.0.1
10.0.0.3 11001 53
UDP length UDP cksum
10.0.0.3
10.1.0.1 33001 53
Client 10.0.0.1
Client 10.0.0.2
UDP length UDP cksum opco rcod
TLD NS 10.1.0.1
TLD NS 10.2.0.1
QopcoATRR rcod R ACDA Z
23001 QR de ACTDRAR Z e
11de e
10.0.0.2 10.0.0.3
Local NS 10.0.0.3
10.0.0.3
10.2.0.1 33002 53
UDP length UDP cksum
QopcoATRR rcod 23002 R de ACDA Z e
22002
UDP length
22
53
UDP cksum
QopcoATRR rcod R de ACDA Z e
DNS Server State
Client 10.0.0.1
Client 10.0.0.2
UDP length UDP cksum UDP lengthopcoUDP ckrscuodm
TLD NS 10.1.0.1
TLD NS 10.2.0.1
UDP socket listening on port 53
10.0.0.1
10.0.0.3 11001 53
UDP length UDP cksum
10.0.0.2 10.0.0.3
22002
UDP length
22
53
UDP cksum
QopcoATRR rcod R de ACDA Z e
UDP length UDP cksum
QopcoATRR rcod R ACDA Z
rcod 23001 R de ACDA Z e
11de e
Local NS
10.2.0.1 101.0.0.03.3
5130.2.0.133002
10.0.0.3
Local NS at least needs to keep state associating Query IDàwhich query (if any)
10.0.0.3
10.1.0.1 10.1.0.1
10.0.0.3 33001 53
53 33001
23001 QR de ACTDRAR Z e QopcoATRR
33002 53
QopcoATRR rcod UDP length URDP cAkCsDuAmZ
23002 de e QopcoATRR rcod
23002 R de ACDA Z e
DNS Resource Record (RR) in Detail
type: determines the meaning of rdata
class: always IN (Internet)
rdata: data associated with the RR
0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5
name (variable length)
type
class
4l
rdlength
rdata (variable length)
DNS Protocol Message
Query and reply messages have identical format
Question section:
query for name server
Answer section:
RRs answering the question
Authority section:
RRs that point to an authoritative NS
Additional section: “glue” RRs
Header
QuesQon secQon
Answer secQon
RR RR
Authority secQon
RR RR
AddiQonal secQon
RR RR
Query ID
QR
opcode
A
CT
DR
AR
Z
rcode
qdcount 1
ancount 0
nscount
arcount
DNS Protocol Header Query ID: 16-bit identifier shared
between query, reply
Flags word
– QR: query (0) or response (1) – opcode: standard query (0)
– AA: authoritative answer
– TC: truncation
– RD: Recursion desired
– RA: Recursion available
– Z: (reserved and zeroed)
– rcode: response code; ok (0)
0123456789 12345
qdcount: number of question entries (QEs) in message
ancount: number of RRs in the answer section
nscount: number of RRs in the authority section
arcount: number of RRs in the additional section
All problems in computer science can be solved
by another level of indirection…
Except for the problem of too many layers of indirection.
David Wheeler
45
DNS Load Balancing
• Essentially, DNS is the Internet’s indirection infrastructure
• Big companies want to load balance requests across many servers or datacentres.
– Can reply with lots of IP addresses in one A record.
– Only gets you so far.
• DNS is not required to be globally consistent!
– Give different answers depending on who asks. – Ugly hack, but very widely used.
46
Today
1. TheDomainNameSystem(DNS) 2. ABriefWordonDNSSecurity
Open Recursive Servers
DNS servers should not recurse except for local clients. – used to not be a problem.
– got misused – DNS amplification attack
• Attacker sends small query to DNS server: – Spoofs source address of request to be that of
intended victim
– DNS server recurses, builds big response packet, sends it to victim
– repeat from many bots, thousands of times per second
48
Implications of Subverting DNS
1. Redirectvictim’swebtraffictorogueservers
2. Redirectvictim’semailtorogueemailservers(MX records in DNS)
Security Problem #1:“Coffee Shop”
As you sip your latte and surf the Web, how does your laptop find
google.com?
Answer: it asks the local DNS nameserver
• Which is run by the coffee shop or their contractor
• And can return to you any answer they please
• Including a “man in the middle” site that forwards your query to Google, gets the reply to forward back to you, yet can change anything they wish in either direction
• How can you know you’re getting correct data?
Security Problem #1:“Coffee Shop”
As you sip your latte and surf the Web, how does your laptop find
google.com?
Answer: it asks the local DNS nameserver
• Which is run by the coffee shop or their contractor
• And can return to you any answer they please
• Including a “man in the middle” site that forwards your How can you know you’re getting correct data?
query to Google, gets the reply to forward back to you, yet can change anything they wish in either direction
Today, you can’t (though if site is HTTPS, that helps).
One day, hopefully: DNSSEC extensions to DNS • How can you know you’re getting correct data?
Security Problem #2: Cache Poisoning
Suppose you are evil and you control the name server for foobar.com. You receive a request to resolve www.foobar.com and reply:
;; QUESTION SECTION:
;www.foobar.com.
;; ANSWER SECTION:
www.foobar.com.
;; AUTHORITY SECTION:
foobar.com.
foobar.com.
;; ADDITIONAL SECTION:
google.com.
IN A
300 IN A 212.44.9.144
600 IN NS dns1.foobar.com.
600 IN NS google.com.
5 IN A 212.44.9.155
Evidence of the aQack disappears 5 seconds later!
A foobar.com machine, not google.com
DNS Cache Poisoning (cont’d)
• OK, but how do you get the victim to look up www.foobar.com in the first place?
• Perhaps you connect to their mail server and send
– HELO www.foobar.com
– Which their mail server then looks up to see if it corresponds to your source address (anti-spam measure)
• Note, with compromised name server we can also lie about PTR records (address → name mapping)
– e.g., for 212.44.9.155 = 155.44.9.212.in-addr.arpa return google.com (or whitehouse.gov, or whatever)
• If our ISP lets us manage those records as we see fit, or we happen to directly manage them
(Partial) Fix: Bailiwick Checking
• DNS resolver ignores all RRs not in or under the same zone as the question
• Widely deployed since ca. 1997
• Other attacks remain (e.g., Kaminsky’s poisoining)
;; QUESTION SECTION:
;www.foobar.com.
;; ANSWER SECTION:
www.foobar.com.
;; AUTHORITY SECTION:
foobar.com.
foobar.com.
;; ADDITIONAL SECTION:
google.com.
IN A
300 IN A 212.44.9.144
600 IN NS dns1.foobar.com.
600 IN NS google.com.
5 IN A 212.44.9.155