Internet and Intranet Protocols and Applications Lecture 5 Application Protocols: DNS February 20, 2002 Joseph Conron Computer Science Department New York.

Internet and Intranet Protocols and Applications

Lecture 5

Application Protocols: DNS

February 20, 2002

Joseph Conron

Computer Science Department

New York University

[email protected]

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

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