程序代写代做代考 database cache dns comp0023-lecture6-dns

comp0023-lecture6-dns

The Domain Name System

Stefano Vissicchio
UCL Computer Science

COMP0023

Today

1.  The Domain Name System (DNS)

2.  A Brief Word on DNS Security

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

•  But a single server, manually updated, doesn’t scale
– 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

•  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

.

com. uk. edu.

cmu.edu. mit.edu.ac.uk.

ucl.ac.uk.

Root:

Top-level
Domains (TLDs):

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?

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

E NASA Mt View, CA
F Internet SoPware
ConsorQum,
Palo Alto, CA
(and 37 other locaQons)

I Autonomica, Stockholm (plus
29 other locaQons)

K RIPE London (plus 16 other locaQons)

M WIDE Tokyo
plus Seoul, Paris,
San Francisco

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)

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

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

E NASA Mt View, CA
F Internet SoPware
ConsorQum,
Palo Alto, CA
(and 37 other locaQons)

I Autonomica, Stockholm (plus
29 other locaQons)

K RIPE London (plus 16 other locaQons)

M WIDE Tokyo
plus Seoul, Paris,
San Francisco

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)

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 com TLD
– 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:

www.scholarly.edu?

Answer: www.scholarly.edu A 10.0.0.1

www.scholarly.edu?

Referral: .edu NS 10.2.3.1

Client NS

NS Client

Recursive:

Iterative:

server may ask other
servers if it doesn’t
know the answer

server will reply with
what it does know

Local NS Does Clients’ Work

1.  Client’s resolver makes
recursive query to local
NS

2.  Local NS processing:
–  Local NS sends iterative

queries to other NS’s
–  or finds answer in cache

3.  Local NS responds with
answer to client’s
requestClients

Root NS

TLD NS

Authorita9ve NS

Local
NS

Local NS Does Clients’ Work

1.  Client’s resolver makes
recursive query to local
NS

2.  Local NS processing:
–  Local NS sends iterative

queries to other NS’s
–  or finds answer in cache

Local NS responds with
answer to client’s request

Clients

Root NS

TLD NS

Authorita9ve NS

Local
NS

Local NS Does Clients’ Work

Clients

Root NS

TLD NS

Authorita9ve NS

Local
NS

1.  Client’s resolver makes
recursive query to local
NS

2.  Local NS processing:
–  Local NS sends iterative

queries to other NS’s
–  or finds answer in cache

3.  Local NS responds to
client’s request

Example: Lookup for www.scholarly.edu

Client

Local NS
. (root): NS 198.41.0.4

www.scholarly.edu?

Client

Local NS
. (root): NS 198.41.0.4

. (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?

Example: Lookup for www.scholarly.edu

Client

Local NS
. (root): NS 198.41.0.4

. (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.

Example: Lookup for www.scholarly.edu

Client

Local NS
. (root): NS 198.41.0.4

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: NS 156.154.100.3

edu.: NS 192.5.6.30

Example: Lookup for www.scholarly.edu

www.scholarly.edu?

Contact 192.5.6.30 for edu.

Client

Local NS
. (root): NS 198.41.0.4

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: NS 156.154.100.3

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: 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

edu.: NS 192.5.6.30

www.scholarly.edu?

Example: Lookup for www.scholarly.edu

Client

Local NS
. (root): NS 198.41.0.4

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: NS 156.154.100.3

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: 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

edu.: NS 192.5.6.30

www.scholarly.edu? Contact 12.35.1.1 for scholarly.edu.

scholarly.edu.: NS 12.35.1.1

Example: Lookup for www.scholarly.edu

Client

Local NS
. (root): NS 198.41.0.4

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: NS 156.154.100.3

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: 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

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

scholarly.edu.: NS 12.35.1.1

www.scholarly.edu?

Example: Lookup for www.scholarly.edu

Client

Local NS
. (root): NS 198.41.0.4

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: NS 156.154.100.3

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: 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

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?

www.scholarly.edu.: A 12.35.51.30

Example: Lookup for www.scholarly.edu

scholarly.edu.: NS 12.35.1.1

Client

Local NS
. (root): NS 198.41.0.4

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: NS 156.154.100.3

. (root) authority 198.41.0.4
edu.: NS 192.5.6.30
no.: NS 158.38.8.133
uk.: 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

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

scholarly.edu.: NS 12.35.1.1

29

Recursive query

•  Less burden on client

•  More burden on nameserver
–  has to return answer to

query

•  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

Recursive vs. Iterative Queries

30

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

•  RR includes: (name, type, value, time-to-live)

DNS Stores Resource Records

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 starting 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 after TTL expires

Reverse Mapping (IP to Hostname)

•  How do we translate IP addresses into corresponding
hostnames?
– Why do we care to? Troubleshooting, security, spam

•  IP address already has natural “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

Query ID opcode TC Z rcode AA QR RD RA

Source port Dest port

UDP length UDP cksum

DesQnaQon IP

Source IP IP header

UDP header

DNS payload

DNS Server State

UDP socket listening on port 53

Client
10.0.0.1

Client
10.0.0.2

TLD NS
10.2.0.1

11 opcode TC Z rcode AA QR RD RA

11001 53
UDP length UDP cksum

10.0.0.3
10.0.0.1

22 opcode TC Z rcode AA QR RD RA

22002 53
UDP length UDP cksum

10.0.0.3
10.0.0.2

Local NS
10.0.0.3

TLD NS
10.1.0.1

DNS Server State

UDP socket listening on port 53

Client
10.0.0.1

Client
10.0.0.2

TLD NS
10.2.0.1

11 opcode TC Z rcode AA QR RD RA

11001 53
UDP length UDP cksum

10.0.0.3
10.0.0.1

22 opcode TC Z rcode AA QR RD RA

22002 53
UDP length UDP cksum

10.0.0.3
10.0.0.2

23001 opcode TC Z rcode AA QR RD RA

33001 53
UDP length UDP cksum

10.1.0.1
10.0.0.3

23002 opcode TC Z rcode AA QR RD RA

33002 53
UDP length UDP cksum

10.2.0.1
10.0.0.3

Local NS
10.0.0.3

TLD NS
10.1.0.1

DNS Server State

UDP socket listening on port 53

Client
10.0.0.1

Client
10.0.0.2

TLD NS
10.2.0.1

11 opcode TC Z rcode AA QR RD RA

11001 53
UDP length UDP cksum

10.0.0.3
10.0.0.1

22 opcode TC Z rcode AA QR RD RA

22002 53
UDP length UDP cksum

10.0.0.3
10.0.0.2

23001 opcode TC Z rcode AA QR RD RA

33001 53
UDP length UDP cksum

10.1.0.1
10.0.0.3

23002 opcode TC Z rcode AA QR RD RA

33002 53
UDP length UDP cksum

10.2.0.1
10.0.0.3

Local NS at least needs to keep state associating
Query ID à which query (if any)

Local NS
10.0.0.3

TLD NS
10.1.0.123001

opco
de

T
C Z

rcod
e

A
A

Q
R

R
D
R
A

53 33001
UDP length UDP cksum

10.0.0.3
10.1.0.1

23002 opcode TC Z rcode AA QR RD RA

53 33002
UDP length UDP cksum

10.0.0.3
10.2.0.1

DNS Resource Record (RR) in Detail

type: determines the meaning of
rdata

class: always IN (Internet)

rdata: data associated with the
RR

name (variable length)

type

class

4l

0 1 5 6 7 8 9
1
0 1 4 2 5 3 4 2 3

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

Authority secQon

AddiQonal secQon

RR
RR

RR

RR

RR

RR

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)

1
0

Query ID

qdcount

opcode TC Z rcode
A
A

Q
R

R
D

R
A

ancount

nscount

arcount

0 1 5 6 7 8 9 1 4 2 5 3 4 2 3

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.  The Domain Name System (DNS)

2.  A Brief Word on DNS Security

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.  Redirect victim’s web traffic to rogue servers

2.  Redirect victim’s email to rogue email servers (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

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?

How can you know you’re getting correct data?

Today, you can’t (though if site is HTTPS, that helps).
One day, hopefully: DNSSEC extensions to DNS

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. IN A

;; ANSWER SECTION:
www.foobar.com. 300 IN A 212.44.9.144

;; AUTHORITY SECTION:
foobar.com. 600 IN NS dns1.foobar.com.
foobar.com. 600 IN NS google.com.

;; ADDITIONAL SECTION:
google.com. 5 IN A 212.44.9.155

A foobar.com machine, not google.com Evidence of the aQack disappears
5 seconds later!

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. IN A

;; ANSWER SECTION:
www.foobar.com. 300 IN A 212.44.9.144

;; AUTHORITY SECTION:
foobar.com. 600 IN NS dns1.foobar.com.
foobar.com. 600 IN NS google.com.

;; ADDITIONAL SECTION:
google.com. 5 IN A 212.44.9.155