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

The DNS Hierarchy T7.25 A portion of the domain name space

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: zones T7.28 Division of name space into zones

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 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 host surf.eurecom.fr root name server authoritative name server dns.umass.edu local name server dns.eurecom.fr

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 host surf.eurecom.fr root name server local name server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.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 server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.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 questionsnumber of answer RRs number of authority RRsnumber of additional RRs Questions (variable number) Answer RRs (variable number) Authority RRs (variable number) Additional RRs (variable number) Name, type fields for a query RRs in reponse to query records for authoritative 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 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