SC250

Computer Networking I

Application Layer: Domain

Name System (DNS)
Prof. Matthias Grossglauser
LCA/I&C

http://lcawww.epfl.ch

1
Today's objectives

Domain Name System (DNS)
 Background and motivation
 Name space
 DNS architecture
 DNS protocol
 nslookup command

2
Background and Motivation

3
Application layer

Host Router Host

Application Application

Transport Transport

Network Network Network

Link/Physical L/P L/P Link/Physical

4
 DNS: Domain Name System

People: many identifiers:  Domain Name System:
 SSN (CH: AVS), name,  distributed database
passport # implemented in hierarchy of

Internet hosts, routers: many name servers
 application-layer protocol
 IP address (32 bit) - used
host, routers, name servers
for addressing datagrams
to communicate to resolve
 “name”, e.g., names (address/name
gaia.cs.umass.edu - used translation)
by humans  note: core Internet


How to map between IP function, implemented as
addresses and names? application-layer protocol
 complexity at network’s

“edge”

5
Early ARPANET: hosts.txt

Centralized file containing entire name-address mapping
 updated and disseminated every few days

NET : 127.0.0.0 : LOOPBACK :

NET : 128.2.0.0 : CMU-NET :
NET : 128.3.0.0 : LBL-IP-NET1 :
NET : 128.4.0.0 : DCNET :
NET : 128.6.0.0 : RUTGERS :
NET : 128.7.0.0 : EKONET :
NET : 128.8.0.0 : UMDNET :
NET : 128.9.0.0 : ISI-NET :
NET : 128.11.0.0 : BBN-CRONUS :
NET : 128.12.0.0 : SU-NET :
....
HOST : 26.1.0.205 : STEWART-EMH1.ARMY.MIL : VAX-11/750 : VMS :TCP/TELNET,TCP/FTP :
HOST : 26.0.0.206 : GORDON.MT.DDN.MIL : C/30 : TAC : TCP,ICMP :
HOST : 26.14.0.206 : NETPMSA-CHARL4.NAVY.MIL : WANG-VS100 : VSOS ::
HOST : 26.29.0.207, 137.209.8.2, 137.209.51.1, 137.209.18.2 : OAKLAND-IP.DDN.MIL ::::
HOST : 26.0.0.210 : BARKSDALE.MT.DDN.MIL : C/30 : TAC : TCP,ICMP :
HOST : 26.0.0.211 : LORING.MT.DDN.MIL : C/30 : TAC : TCP,ICMP :
6
Problems with centralized approach

Scalability

with n names -> n2 work

Single point of failure
 e.g., if file is corrupted, entire Arpanet would collapse

Cumbersome
 updating, regular downloads, installing file
 Collisions
 no mechanism to avoid allocating same name multiple times

Consistency
 “view” of network not always the same

7
DNS: decentralized approach
 Distributed database
 relation name - IP address
 clear delegation of authority – who owns parts of namespace,
who updates the database?
 scales well
 name servers
 primary, secondary - authoritative data
 cache - non-authoritative data
 resolver:
 gethostbyname()
 gethostbyaddr()
 Hierarchical name space
 similar to Unix pathnames, but reversed
 unix: /usr/local/bin/emacs

 DNS: tudor.eecs.berkeley.edu

8
DNS overview
 DNS offers one distributed world-wide database
 distributed according to the zone concept: every zone has a
master file describing all records under the zone’s authority
 name servers hold their part of the database
 for one zone, at least two name servers have the zone
information, copied from master file
– exam p l e: stisun1.epfl.ch, stisun2.epfl.ch;
dns1.ethz.ch, dns2.ethz.ch
 zone information held by the name server is called
authoritative data
 one name server may hold zone data for one or more zones
 zone data contains pointers to name servers holding
authoritative data for subzones
 Root servers
 13 servers distributed all over the world
 any primary server needs to know their addresses

9
Name Space

10
Name and address spaces

Sample name 
Sample IP address
 tudor.eecs.berkeley.edu  128.32.43.249
 Hierarchical  Hierarchical
 least specific to the right  least specific to the left
(“edu”) (“128”)

Mainly useful to humans 
Mainly useful to machines
 human-readable reference  machine-readable
to hosts, networks, email reference to hosts and
domains, etc. networks

Size (virtually) unlimited 
Size limited
 variable-size names,  short, fixed-sized addresses
human readable to maximize efficiency

11
 Name space: domain name tree
root
top level
generic domains domains country domains

arpa com edu gov mil net org ch … us … za

in-addr 2nd level ethz epfl

domains
128 ibm ee lrcsuns ssc
178 tik
zurich
156
www
24
24.156.178.128.in-addr.arpa lrcsuns.epfl.ch

 every node on the tree represents one or a set of

resources
 every node on the tree has a label (lrcsuns) and a
domain name (lrcsuns.epfl.ch)
12
DNS names

Node
 label <= 63 characters (letters, digits, and -)
 case-insensitive
 Name
 list of labels separated by .
 www.epfl.ch. (fully qualified domain name)

 lcawww (local name - evaluated with respect to the

local domain)

Analogous to unix file names
 /usr/local/bin/emacs (root of tree to the left)
 www.trustmymail.com (root of tree to the right)

13
DNS names

Hierarchical naming authority
 top level: ICANN (Internet Corporation For Assigned Names
and Numbers)
 any organization can apply to become authority for a
subdomain, e.g.:
 SWITCH for ch. and li.

 EPFL for epfl.ch.

 any authority can create subdomains and delegate recursively

unilaterally

14
DNS Architecture

15
 DNS name servers

Why not centralize DNS? 
No server has all name-to-
 single point of failure IP address mappings
 traffic volume  Local name servers:
 distant centralized  each ISP, company has
database local (default) name server
 maintenance  host DNS query first goes
 doesn’t scale! to local name server

Authoritative name server:
 for a host: stores that
host’s IP address, name
 can perform name/address
translation for that host’s
name

16
 root name
DNS example 1 server

host surf.eurecom.fr
2 4
wants IP address of 5 3
gaia.cs.umass.edu
1. contacts its local DNS
server, dns.eurecom.fr
2. dns.eurecom.fr contacts local name server authorititive name server
dns.eurecom.fr dns.umass.edu
root name server, if
necessary 1 6
3. root name server contacts
authoritative name
server, dns.umass.edu, if
requesting host
necessary surf.eurecom.fr
gaia.cs.umass.edu

17
 root name
DNS example 2 server


Root name server:
2 6
 may not know 3
7
authoritative name
server
 may know
intermediate name
local name server intermediate name server
server: who to dns.eurecom.fr dns.umass.edu
contact to find 5
4
authoritative name 1 8
server
authoritative name server
dns.cs.umass.edu
requesting host
surf.eurecom.fr

gaia.cs.umass.edu

18
 root name
DNS example 3 server


recursive query: i t er at ed
2
 puts burden of 3
qu er y
name resolution on
contacted name 4
server 7
 heavy load?
local name server intermediate name server

iterated query: dns.eurecom.fr dns.umass.edu
 contacted server 1
5 6
8
replies with name
of server to authoritative name server
contact dns.cs.umass.edu
 “I don’t know this requesting host
surf.eurecom.fr
name, but ask this
server” gaia.cs.umass.edu

19
Name management
 Zone = a connected subset of nodes
 property: a zone has one single node closest to the root =
top node, used to name the zone
 name authority matches zone boundaries:
names and subzones, can be created and deleted by the
authority responsible for a zone; examples:
– zurich.ibm.com is a subzone of ibm.com
– zone zurich.ibm.com. has authority delegation from
ibm.com.
 at least 1 name server per zone (port 53)
primary, secondary - copy of the primary
/etc/resolv.conf: nameserver 128.178.15.7
domain epfl.fr
replication - secondary servers
cache - data kept for 1 day

20
Zones and domains
delegation
“”

com org

edu
edu zone

berkeley stanford mit

edu domain

21
Zones and domains

Domains: 
Zones:
 subtrees of the name space  nodes in name tree under
single administrative
control
 domain x.y.z contains all  zone x.y.z does not contain
nodes below x.y.z those nodes below x.y.z for
which the zone delegates
to another zone
 independent of delegation  delegation relationships
relationships define its boundaries

22
Zones and domains
“”

com org

edu

berkeley stanford mit

edu zone

edu domain
23
Zones and domains
“”

com org

edu

berkeley stanford mit

edu zone

edu domain
24
 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

a NSI Herndon, V A
c PSInet Herndon, V A k RIPE London

d U M aryland College Park, M D i NORDUnet Stockholm

g DISA V ienna, V A
m W IDE Tokyo
h A RL A berdeen, M D
e NA SA M t V iew, CA j NSI (TBD) Herndon, VA
f Internet Software C. Palo Alto,
CA

13 root name
servers
b USC-ISI M arina del Rey, CA
l ICA NN M arina del Rey, CA
worldwide

25
DNS Protocol

26
 Iterative query
delos.imag.fr. A?

root NS
ask name server d1

…
delos.imag.fr. A ?
d1 NS

129.88.38.94
my NS

129.88.38.94

delos.imag.fr. A ?


Note: servers usually issue iterative queries to other
servers 27
 Recursive query

delos.imag.fr.A ?
root NS
129.88.38.94

129.88.38.94 A? delos

my NS d1 NS

129.88.38.94

delos.imag.fr.A ?


Note: resolvers always issue recursive queries to their
local nameservers 28
 1 2
stisun1 3 root
lrcsuns name name

Example:
resolver server 4 server

Query
6
5

Processing
watson
1 query, RD=yes ibm.com.
question = “www.zurich.ibm.com. A”

2,4 query, RD=no

question = “www.zurich.ibm.com. A”

3 answer
question = “www.zurich.ibm.com. A”
answer = ““
autority= “ibm.com. NS watson.ibm.com.
NS ns.austin.ibm.com.
NS ns.almaden.ibm.com.“
additional=“watson.ibm.com. A 192.35.232.34
ns.austin.ibm.com. A 129.34.139.4
ns.almaden.ibm.com A 198.4.83.134“

5,6 answer
question = “www.zurich.ibm.com. A”
answer = “www.zurich.ibm.com. A 193.5.61.131“

29
 Reverse mapping IP-address to name

Question:
 How can we find the name(s) that an IP address corresponds to?

Answer:
 Conceptually, just search through all resource records and find
the ones that match

How to do this in a distributed way?

Key observation:
 IP address space is also hierarchical
 ...but this hierarchy has nothing to do with naming hierarchy
 Example: tinycorp get IP addresses 100.101.102.0-

100.101.102.255 from their ISP, and the name

“tinycorp.com” from an ICANN-accredited registrar

Solution:
 build an additional domain that maintains this mapping:
in-addr.arpa 30
in-addr.arpa domain for reverse lookups
“”

Mapping IP=1.2.3.4
 look up 4.3.2.1.in-addr.arpa arpa

in-addr

0 1 255

0 2 255

0 3 255

0 4 255

31
 Pointer query: IP address back to name

94.38.88.129.in-addr.arpa. PTR ?

root NS
ask d1

94.38.88.129.in-addr.arpa. PTR ?
d1 NS

delos.imag.fr.
my NS

delos.imag.fr.

94.38.88.129 PTR ?

32
Performance and robustness


Replication
 multiple servers with identical zone data
 load balancing and failover
 Caching: once (any) name server learns mapping,
it caches, i.e., remembers, this mapping
 cache entries timeout (disappear) after some time:
TTL (time to live) defined by authoritative name
server
 reduce traffic by creating “shortcuts” in walking down
the tree

33
Replication
 Zone data is replicated
 primary server holds master file on disk
 secondary servers poll primary servers (ex: every 3
hours)
 using the SERIAL field in the zone data
 copying is called zone transfer; uses TCP (queries usually
use UDP)
 changes in zone data by system manager:
 update master file
 signal primary name server to reload; new value of
SERIAL field automatically created
 secondary servers will discover the change
automatically
 zone data in secondary servers is authoritative

34
Server selection

How does a name server select among multiple potential
servers in a lookup?
 we'd like to use “close” servers
 example: neste.com name servers + RTTs (from ping):

nestle.com nameserver = ns2.nesusa.com. RTT=200ms

nestle.com nameserver = dns2.nestec.ch. RTT= 30ms
nestle.com nameserver = ns1.nesusa.com RTT=200ms

Solution:
 name server measures RTT of queries it sends to servers
 over time, it will converge to using the closest and best
performing of potential servers

35
Caching: request for
tudor.eecs.berkeley.edu
root
server

edu.

“ask NS for berkeley.edu”

berkeley.
local NS edu.

“ask NS for eecs.berkeley.edu”

eecs.
berkeley.
resolver edu.

36
Caching: subsequent request for
tudor.eecs.berkeley.edu
root
local NS cache: server
edu NS 100.101.102.103
berkeley.edu NS 104.105.106.107
eecs.berkeley.edu NS 108.109.110.111
tudor.eecs.berkeley.edu A 112.113.114.115
edu.

berkeley.
local NS
edu.

eecs.
berkeley.
resolver edu.

37
Caching: subsequent request for
xyz.eecs.berkeley.edu
root
local NS cache: server
edu NS 100.101.102.103
berkeley.edu NS 104.105.106.107
eecs.berkeley.edu NS 108.109.110.111
tudor.eecs.berkeley.edu A 112.113.114.115
edu.

berkeley.
local NS
edu.

eecs.
berkeley.
resolver edu.

38
 Details of a query
IP dest addr = 129.178.15.7
protocol = UDP
lrcsuns source port = 1267 dest port = 53 stisun1
DNS message =
header = query,
application
question = (QNAME=“disun3.epfl.ch.” QTYPE=A)
program
DNS query 2
name 3 DNS answer name
resolver server
IP dest addr = 129.178.156.24
protocol = UDP
source port = 53 dest port = 1267
DNS message =
header = response, AA
question = (QNAME=“disun3.epfl.ch.” QTYPE=A)
answer = (disun3.epfl.ch. TTL=86400 TYPE=A 128.178.79.9)

zone data (authoritative data)

resolv.conf RR type
A = IPv4 addr
nameserver 129.178.15.7 disun3.epfl.ch. 86400 A 128.178.79.9
AAAA = IPv6 addr
nameserver 129.178.15.8 in-inr.epfl.ch. 86400 A 128.178.156.1
domain epfl.ch 86400 A 128.178.182.5

cached data (non-authoritative data)

Resource Records (RRs)
keyed by domain names ezinfo.ethz.ch. 1770 A 129.132.2.72

39
DNS records
DNS: distributed db storing resource records (RR)
RR format: (name, value, type,ttl)

 Type=A  Type=CNAME
 name is hostname  name is alias name for some
 value is IP address “canonical” (the real) name
www.ibm.com is really
 Type=NS
servereast.backup2.ibm.com
 name is domain (e.g.
 value is canonical name
foo.com)
 value is IP address of  Type=MX
authoritative name
server for this domain
 value is name of
mailserver associated with
name
40
DNS protocol, messages

DNS protocol:
 query and reply messages, both with same message
format
 usually uses UDP: query+reply fit in single packet, delay
important, reliability handled by DNS itself

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

 recursion desired

 recursion available

 reply is

authoritative 41
 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

42
nslookup command

43
nslookup: look up a host

$ nslookup www.zurich.ibm.com
Server: stisun1.epfl.ch
Address: 128.178.15.8
Non-authoritative answer:
Name: www.zurich.ibm.com
Address: 193.5.61.131

 Origin of information
 “non-authoritative”: from some NS's cache
 “authoritative”: from (one of the) authoritative servers

44
nslookup: look up nameserver

$ nslookup -querytype=NS zurich.ibm.com 129.34.139.4

Server: watson.ibm.com
Address: 129.34.139.4
zurich.ibm.com nameserver = ns1.zurich.ibm.ch
zurich.ibm.com nameserver = watson.ibm.com
ns1.zurich.ibm.ch internet address = 193.5.61.131
watson.ibm.com internet address = 129.34.139.4

45
nslookup: reverse mapping IP->name

$ nslookup -querytype=PTR 193.5.61.131

Server: stisun1.epfl.ch
Address: 128.178.15.8
131.61.5.193.in-addr.arpa name = uetliberg.zurich.ibm.ch
61.5.193.in-addr.arpa nameserver = ns1.zurich.ibm.ch
61.5.193.in-addr.arpa nameserver = scsnms.switch.ch
61.5.193.in-addr.arpa nameserver = swidir.switch.ch
ns1.zurich.ibm.ch internet address = 193.5.61.131
scsnms.switch.ch internet address = 130.59.10.30
scsnms.switch.ch internet address = 130.59.1.30
swidir.switch.ch internet address = 130.59.72.10

46
nslookup: other points

Interactive and noninteractive modes
 Interactive: session with its own prompt, issue commands
 Noninteractive: everything from command line (like preceding
examples)

Can behave like a resolver or like a name server
 e.g., can issue both recursive (like resolver) or iterative
(usually done by name servers) queries

Option to see query and response messages
 debug option

47
 DNS: summary

Hierarchical name space
 natural way to delegate portions of the space
 natural way to distribute mapping functionality
 Name servers all over the world

Scalable
 distribution and authority delegation
 caches for efficiency (reduce traffic)
 replication for fault tolerance (server outage)

One of the key features of the Internet
 ...and key source of problems (e.g., delay)!

Most popular implementation: BIND

Recent trends:
 DNS increasingly used for sophisticated tasks it was not
originally designed for, e.g., load-balancing among web servers
 security 48