Transcript 3rd Edition: Chapter 2

DNS: Domain Name System
People have many identifiers:
SSN, name, passport number
Internet hosts, routers have identifiers, too:
IP address (32 bit) - used for addressing datagrams
“name”, e.g., www.yahoo.com - used by humans
Domain Name System:
Distributed database implemented in hierarchy of many
name servers
Application-layer protocol host, routers, name servers to
communicate to resolve names (address/name translation)
DNS is core Internet function, implemented as
application-layer protocol
Complexity at network’s “edge”
2: Application Layer
1
DNS
DNS services
Hostname to IP address translation and vice versa
Host aliasing – canonical and alias names
Mail server aliasing
Load distribution – e.g. replicated Web servers:
set of IP addresses for one canonical name
Why not centralize DNS?
Single point of failure
Traffic volume
Distant centralized database
Maintenance
2: Application Layer
2
Distributed, Hierarchical Database
Root DNS Servers
.com DNS servers
yahoo.com
amazon.com
DNS servers DNS servers
.org DNS servers
pbs.org
DNS servers
.edu DNS servers
poly.edu
umass.edu
DNS serversDNS servers
Client wants IP for www.amazon.com
A straightforward strategy:
Client queries a root server to find .com DNS server
Client queries .com DNS server to get amazon.com DNS
server
Client queries amazon.com DNS server to get IP address
for www.amazon.com
2: Application Layer
3
DNS: Root name servers
Contacted by local name server that can not
resolve name
Root name server:
Returns mapping of the domain server to local name server
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also Los Angeles)
d U Maryland College Park, MD
k RIPE London (also Amsterdam,
g US DoD Vienna, VA
Frankfurt)
i Autonomica, Stockholm (plus 3
h ARL Aberdeen, MD
j Verisign, ( 11 locations)
other locations)
m WIDE Tokyo
e NASA Mt View, CA
f Internet Software C. Palo Alto,
CA (and 17 other locations)
13 root name
servers worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA
2: Application Layer
4
TLD and Authoritative Servers
Top-level domain (TLD) servers:
responsible for com, org, net, edu, etc, and all toplevel country domains uk, fr, ca, jp.
Network solutions maintains servers for .com TLD
Educause for .edu TLD
Authoritative DNS servers:
organization’s DNS servers, providing authoritative
hostname to IP mappings for organization’s servers
(e.g., Web and mail).
Can be maintained by organization or service provider
2: Application Layer
5
Local Name Server
Does not strictly belong to DNS hierarchy
Each ISP (residential ISP, company, university)
has one
Also called “default name server”
When a host makes a DNS query,
query is sent to its local DNS server
Acts as a cache
If no record for this query,
forwards query into hierarchy
Caches replies
2: Application Layer
6
Example
root DNS server
2
Host titan.cis.udel.edu
wants IP address for
lever.cs.ucla.edu
3
4
TLD DNS server
.edu
5
local DNS server
dns.udel.edu
1
8
requesting host
7
6
authoritative DNS server
dns.ucla.edu
titan.cis.udel.edu
lever.cs.ucla.edu
131.179.192.136
2: Application Layer
7
Recursive queries
root DNS server
recursive query:
puts burden of name
resolution on
contacted name
server
heavy load?
iterated query:
2
3
7
6
TLD DNS server
.edu
local DNS server
dns.udel.edu
contacted server
1
8
replies with name of
server to contact
“I don’t know this
name, but ask this requesting host
titan.cis.udel.edu
server”
5
4
authoritative DNS server
dns.ucla.edu
lever.cs.ucla.edu
131.179.192.136
2: Application Layer
8
DNS: caching and updating records
Once (any) name server learns mapping,
it caches this mapping
Cache entries timeout (disappear)
after some time
TLD servers typically cached in local name
servers
 Thus root name servers are not often visited
Update/notify mechanisms under design by IETF
RFC 2136
http://www.ietf.org/html.charters/dnsind-charter.html
2: Application Layer
9
DNS resource records (RR)
RR format: (name,
Type=A
name is hostname
value is IP address
Type=NS
name is domain
(e.g. foo.com)
value is hostname of
authoritative name
server for this domain
value, type, ttl)
Type=CNAME
name is alias name for some
“canonical” (the real) name
www.ibm.com is really
servereast.backup2.ibm.com
value is canonical name
Type=MX
value is name of mailserver
associated with name
And more!
2: Application Layer
10
DNS resource records (RR)
mycompany.com
IN
SOA
nameserv.mycompany.com
root.mymachine.mycompany.com
(1999112701 ; Serial number
10800 ; Refresh in seconds
3600 ; Retry in seconds
604800 ; Expire
86400) ; Minimum TTL
mycompany.com
IN
NS
nameserv.mycompany.com.
mycompany.com
IN
MX
10 mailserv.mycompany.com
nameserv.mycompany.com IN
A
10.1.0.100
mailserv.mycompany.com
IN
A
10.1.0.4
www.mycompany.com
IN
CNAME
webhost1.mycompany.com
A
10.1.0.13
webhost1.mycompany.com IN
2: Application Layer
11
DNS protocol, messages
DNS protocol has query and reply messages, both
with same message format
16 bit number for query,
reply to query uses same
number
flags:




query or reply
recursion desired
recursion available
reply is authoritative
2: Application Layer
12
DNS protocol, messages
Name, type fields
for a query
RRs in response
to query
records for
authoritative servers
additional “helpful”
info that may be used
2: Application Layer
13
Inserting records into DNS
Example: just created startup “Network Utopia”
Register name networkuptopia.com at a registrar
(e.g., Network Solutions)
Need to provide registrar with names and IP addresses of
your authoritative name server (primary and secondary)
Registrar inserts following RRs into the com TLD server:
(networkutopia.com NS dns1.networkutopia.com)
(networkutopia.com NS dns2.networkutopia.com)
(dns1.networkutopia.com A 212.212.212.1)
(dns2.networkutopia.com A 212.212.212.3)
At dns1.networkutopia.com put in more information
for various hosts
How do people get the IP address of your Web site?
2: Application Layer
14
Try out DNS!
nslookup www.microsoft.com
Server:
Address:
127.0.0.1
127.0.0.1#53
Non-authoritative answer:
www.microsoft.com
canonical name = toggle.www.ms.akadns.net
toggle.www.ms.akadns.net canonical name = g.www.ms.akadns.net
g.www.ms.akadns.net canonical name = lb1.www.ms.akadns.net
Name: lb1.www.ms.akadns.net
Address: 207.46.199.30
Name: lb1.www.ms.akadns.net
Address: 207.46.225.60
Name: lb1.www.ms.akadns.net
Address: 207.46.18.30
Name: lb1.www.ms.akadns.net
Address: 207.46.19.30
2: Application Layer
15
Try out DNS!
nslookup www.yahoo.com
Server:
Address:
127.0.0.1
127.0.0.1#53
Non-authoritative answer:
www.yahoo.com canonical name = www.yahoo.akadns.net.
Name: www.yahoo.akadns.net
Address: 68.142.226.56
Name: www.yahoo.akadns.net
Address: 68.142.226.33
Name: www.yahoo.akadns.net
Address: 68.142.226.35
Name: www.yahoo.akadns.net
Address: 68.142.226.37
Name: www.yahoo.akadns.net
Address: 68.142.226.38
2: Application Layer
16
Try out DNS!
nslookup –debug www.yahoo.com
-> www.yahoo.akadns.net
internet address = 68.142.226.53
QUESTIONS:
-> www.yahoo.akadns.net
www.yahoo.com, type = A, class = IN
internet address = 68.142.226.56
ANSWERS:
AUTHORITY RECORDS:
-> www.yahoo.com
-> akadns.net
canonical name = www.yahoo.akadns.net.
nameserver = use1.akadns.net.
-> akadns.net
-> www.yahoo.akadns.net
nameserver = use9.akadns.net.
internet address = 68.142.226.34
-> akadns.net
-> www.yahoo.akadns.net
nameserver = usw5.akadns.net.
internet address = 68.142.226.36
-> akadns.net
-> www.yahoo.akadns.net
nameserver = asia5.akadns.net.
internet address = 68.142.226.43
-> akadns.net
-> www.yahoo.akadns.net
nameserver = asia9.akadns.net.
internet address = 68.142.226.45
-> akadns.net
-> www.yahoo.akadns.net
nameserver = eur4.akadns.net.
-> akadns.net
internet address = 68.142.226.47
nameserver = eur5.akadns.net.
-> www.yahoo.akadns.net
-> akadns.net
internet address = 68.142.226.52
nameserver = usc4.akadns.net.
2: Application Layer
17
P2P file sharing
Alice runs P2P client application such as Kazaa
on her notebook computer
Intermittently connects to Internet; gets new IP
address for each connection
Asks for “Hey Jude”
Application displays peers that have a copy
Alice chooses one of the peers, Bob.
File is copied from Bob’s PC to Alice’s notebook: HTTP
While Alice downloads, other users uploading other
songs from Alice.
Alice’s application is both a Web client and a
transient Web server.
All peers are servers = highly scalable!
2: Application Layer
18
Centralized directory
Bob
centralized
directory server
1
Original “Napster” design
peers
1
1) when peer connects, it informs
central server:
 IP address
 content
2) Alice queries server for “Hey Jude”
3) Server tells Alice which users
(including Bob) have the file
4) Alice requests file from Bob
4
1
2/3
1
Alice
2: Application Layer
19
Problems with centralized directory
Single point of failure
Performance
bottleneck
Copyright
infringement
file transfer is
decentralized, but
locating content is
highly centralized
2: Application Layer
20
Query flooding: Gnutella
Fully distributed
No central server
Public domain protocol
Many Gnutella clients implementing protocol
Overlay network is a graph:
edge between peer X and Y if there’s a TCP
connection
Edge is not a physical link
All active peers and edges form overlay net
Given peer will typically be connected with < 10
overlay neighbors
2: Application Layer
21
Gnutella: protocol
Query message
sent over existing TCP
connections
Peers forward
Query message
QueryHit
sent over
reverse
Query
path
File transfer:
HTTP
Query
QueryHit
QueryHit
Scalability:
limited scope
flooding
2: Application Layer
22
Gnutella: Peer joining
1.
2.
3.
4.
5.
Joining peer X must find some other peer in
Gnutella network: use list of candidate peers
X sequentially attempts to make TCP with peers
on list until connection setup with Y
X sends Ping message to Y; Y forwards Ping
message.
All peers receiving Ping message respond with
Pong message
X receives many Pong messages. It can then
setup additional TCP connections
2: Application Layer
23
Exploiting heterogeneity: KaZaA
Each peer is either a
group leader or assigned
to a group leader.
TCP connection between
peer and its group leader.
TCP connections between
some pairs of group
leaders.
Group leader tracks the
content in all its
children.
ordinary peer
group-leader peer
neighoring relationships
in overlay network
2: Application Layer
24
KaZaA: Querying
Each file has a hash and a descriptor
Client sends keyword query to its group leader
Group leader responds with matches:
For each match: metadata, hash, IP address
If group leader forwards query to other group
leaders, they respond with matches
Client then selects files for downloading
HTTP requests using hash as identifier sent to peers
holding desired file
2: Application Layer
25
KaZaA tricks
Limitations on simultaneous uploads
Request queuing
Incentive priorities
Parallel downloading
For more info:
J. Liang, R. Kumar, K. Ross, “Understanding KaZaA,”
(available via cis.poly.edu/~ross)
2: Application Layer
26