Internet and Intranet Protocols and Applications
Lecture 5
Application Protocols: DNS
February 20, 2002
Joseph Conron
Computer Science Department
New York University
DNS: Domain Name System
• Internet hosts are identified by:– IP address (32 bit) - used for addressing
datagrams– “name”, e.g., sparky.cs.unyu.edu - used by
humans
• How to map between IP addresses and name ?
DNS: in the beginning...
• When the Internet was ARPANET, a simple text file hosts contained names and IP Addresses.
• As the number of hosts grew, this approach was unacceptable.– hosts file became too big
– worse, host naming conflicts occurred
• To deal with this, the Domain Name System was conceived (RFC 1034, 1035)
DNS: the basic idea...
• Divide the name space in domains (.edu, .gov, country, etc.)
• Allocate servers to handle each domain.
• Further subdivide each domain as needed– for example, .edu domain has servers for nyu,
yale, etc.
• So, the name space is represented by a tree
DNS: name servers
• To avoid problems with single server, the DNS name space is divided into zones
• Each zone holds some part of the name tree and some server that acts as the “authority” for that zone.
• Usually, one authoritative server and some number of secondary name servers.
DNS: Resolvers
• Each host has a resolver– Typically a library that applications can use– Local name servers hand-configured (e.g.
/etc/resolv.conf)– Can be full resolvers (have a cache) or stub
resolvers (just the library functions)
DNS name servers: types
• local name servers:– each ISP, company has local (default) name server
– host DNS query first goes to local name server
• authoritative name server:– can perform name/address translation for that host’s
name (it is the AUTHORATIVE name server)
– By definition, an authoritative name server for a given host always has the name to IP address mapping for that host in its database (not cache!)
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
DNS: name resolution algorithm
• Consult local DNS, if name known and valid, done. Else local DNS ...
• Consults root server, if name known and valid, done. Else root server ...
• Consults authoritative server for hostname– this process is repeated until name is resolved (or not!)
– results are passed back to each requestor
– known as recursive query
DNS: example query - find linda.cs.yale.edu
1. Send query to local DNS for cs.vu.nl
2. Send query to Edu name server
3. Send query to Yale name server
4. Send query to cs name server at Yale
5 - 8. Results flow back
DNS: another example
host surf.eurecom.fr wants IP address of gaia.cs.umass.edu
1. Contacts its local DNS server, dns.eurecom.fr
2. dns.eurecom.fr contacts root name server, if necessary
3. root name server contacts authoritative name server, dns.umass.edu, if
necessary requesting hostsurf.eurecom.fr
root name server
authoritative name serverdns.umass.edu
local name serverdns.eurecom.fr
1
23
4
5
6
DNS: yet another example!
Root name server:• may not know
authoritative name server
• may know intermediate name server: who to contact to find authoritative name server
requesting hostsurf.eurecom.fr
root name server
local name serverdns.eurecom.fr
1
23
4 5
6
authoritative name serverdns.cs.umass.edu
intermediate name serverdns.umass.edu
7
8
DNS: recursive vs. iterated queries
recursive query:• puts burden of name
resolution on contacted name server
• heavy load?
iterated query:• contacted server replies
with name of server to contact
• “I don’t know this name, but ask this server” requesting host
surf.eurecom.fr
root name server
local name serverdns.eurecom.fr
1
23
4
5 6
authoritative name serverdns.cs.umass.edu
intermediate name serverdns.umass.edu
7
8
iterated query
Caching in DNS
• Server always caches answers
• Host can cache answers
• cache entries timeout (disappear) after some time (ttl)
• Caching– Improves efficiency– Eliminates unnecessary search– Works well because high locality of reference
DNS Database
• Composed of resource records (RR)
• Each record has a type field that gives the semantics of name and value
• ttl is the time to live of the record in seconds
RR format: (name, value, type,ttl)
DNS: Reliability
• DNS servers are replicated– Name service available if one replica is up
– Queries can be load balanced between replicas
• UDP used for queries– Need reliability so, why not TCP?
– Try alternate servers on timeout
– Exponential back-off when retrying same server
– Same identifier for all queries
– Don’t care which server responds
DNS: RR Types A, NS
• Type=A – name is hostname– value is IP address
– most important record type!
• Type=NS– name is domain (e.g. foo.com)– value is IP address of authoritative name server for
this domain
DNS: RR Types CNAME, MX
• Type=CNAME– name is an alias name for some “canonical”
(the real) name– value is canonical name
• Type=MX– value is hostname of mail server associated
with name– example: mail.com = ?
DNS: RR Types PTR, SOA
• Type=PTR (pointer)– name is canonical IN-ADDR.ARPA domain
address– value is host name
• Type=SOA (start of authority)– Names host as server for zone– Value contains update parameters
DNS: protocol, messages
DNS protocol : query and reply messages, both with same message format
msg header (12 bytes)• identification: 16 bit # for query, reply to query uses same
#
• flags:
– query or reply
– recursion desired
– recursion available
– reply is authoritative
DNS: request/reply message format
identification flags
number of questions number of answer RRs
number of authority RRs number of additional RRs
Questions (variable number)
Answer RRs (variable number)
Authority RRs (variable number)
Additional RRs (variable number)
Name, type fields
for a queryRRs in
reponseto query
records forauthoritative servers
additional “helpful”info that may be
used
DNS Questions
• If DNS uses UDP, how do:– Replies get back to requestors?– Resolvers handle simultaneous requests?– We differentiate “no such host” from network
errors?
DNS Inverse Lookup
• Inverse lookup:– given an IP address, find the host name
• Problem:– How is this done without enduring
horrendously long searches?
DNS Inverse Lookup
• The problem in more detail:
– The Domain Name System provides for a mapping of symbolic names to IP addresses. These names are organized in a hierarchical name space.
– While it is a simple matter in principle to search the database for an IP address given its symbolic name because this hierarchical structure, the inverse process cannot follow the hierarchy.
DNS Inverse Lookup
• How is it done? RFC 1035– The Internet uses a special domain to support gateway location
and Internet address to host mapping. The domain root is at IN-ADDR.ARPA.
– Domain names in IN-ADDR.ARPA domain have up to four labels in addition to the IN-ADDR.ARPA suffix.
– Each label represents one octet of an Internet address.
– DNS database contains PTR resource records• PTR are pointers from an address to a name
– Example 15.20.122.128.in-addr.arpa = who?
– Why are the address octets in reverse order?
DNS Zone Transfer
• RFC 1035 requires that every zone must have at least two name servers (WHY?)
• How to keep the zone data consistent for each name server?
• Answer: DNS zone transfer protocol
DNS Zone Transfer Protocol
• SOA record defines “refresh” time
• SOA record defines a “serial” identifier that increases in value whenever the zone data changes.
• Secondary name servers request SOA record from primary whenever “refresh” time expires.
• If “serial” value has changed, then request a transfer of the zone data (RR) via TCP