Chapter 9 Application Layer, DNS

1
Chapter 9Application Layer, DNS

• Professor Rick Han
• University of Colorado at Boulder
• rhan_at_cs.colorado.edu

2
Announcements

• Read Sections 9.1 - 9.2, Skip 9.3
• HW 4 on Web, tcpdump possibility
• Midterm graded 3 out of 4 problems, partially
  finished grading last problem
• hand back April 4
• Next, Application Layer

3
Recap of Previous Lecture

• SACK-TCP
• Use TCP Options to extend TCP Header to provide
  Selective ACKs
• At most 3 non-contiguous blocks
• Higher throughput than GBN TCP Reno
• If one side of connection doesnt support SACK,
  then fall back to cumulative ACKs
• TCP Extensions Timestamp
• Removes retransmission ambiguity, easy RTT calc.,
  protects against wraparound
• Window Scale for LFNs
• SACK

4
Recap of Previous Lecture (2)

• Wireless TCP
• Wireless fading causes congestion backoff Wrong
  response
• Split Connection Solution
• Doesnt isolate wired conn. from wired losses
• Link Layer Solution
• Poor interaction with TCP
• Snoop TCP
• TCP-aware link layer solution
• At basestation,
• cache unACKnowledged TCP packets
• suppress duplicate ACKs back to sender while
  performing local retransmissions

5
Recap of Previous Lecture (3)

• Snoop TCP Key advantages
• Preserves end-to-end semantics
• Only soft state in basestation easy to migrate,
  loss of soft state merely returns TCP to its
  default poor performance over wireless
• No transport termination or TCP code in base
  station

6
Domain Name Service (DNS)

• Translate/resolve a name into an IP address
• www.cs.colorado.edu -gt 128.138.242.195
• Binding of a name to a value
• What are examples of an address translation
  service weve already studied?
• DHCP MAC -gt IP address
• ARP IP address -gt MAC
• These solutions are
• Confined in/near a local area network LAN
• DHCP Client queries server
• ARP Client queries a destination peer

7
DNS (2)

• A DNS name translation service should provide at
  least global translation input any name, get out
  an IP address
• Can we reuse concepts from DHCP/ARP to provide
  global name translation?
• DHCP Client queries DHCP server architecture (via
  relay) useful theme
• Local LAN focus?
• No, need wide area naming system
• DHCP uses a somewhat distributed rather than a
  centralized architecture useful theme

8
DNS (3)

• What are drawbacks of a centralized architecture,
  i.e. all DNS clients query a central DNS server
  for name resolution?
• Single point of failure, not robust
• Traffic volume overwhelms central point, doesnt
  scale well
• Thus, design DNS to provide
• Robust,
• Scalable,
• Global name translation/resolution

9
DNS (4)

• Where have we seen scalable systems before?
• IP Routing hierarchical BGP routing
  above/between OSPF and RIP AS domains
• Also, hierarchical directory naming in operating
  systems follow a tree structure
• Hierarchy is key to scalability
• Hierarchical distribution of processing
• Early Internet had a flat distribution scheme of
  UNIX /etc/hosts.txt file to all hosts single
  point of failure, and easily overwhelmed
• Hierarchical naming
• Flat name space would be quickly unsupportable,
  e.g. think how large your home directory would
  become if confined to 1 directory

10
DNS (5)

• DNS is an application-layer protocol that runs on
  top of UDP port 53
• Commonly employed by other application-layer
  protocols such as HTTP, SMTP, and FTP
• http Web browser translates www.cs.colorado.edu
  into IP address, so http can set up a TCP
  connection to Web server
• Email SMTP program wants to send to
  rhan_at_cs.colorado.edu , so cs.colorado.edu has to
  be translated into an IP address

11
DNS Hierarchical Name Space
root
edu
uk
com
net
org
gov, mil, etc.
colorado
bu
mit
ucb
gwu
cs
ece
anchor
12
DNS Hierarchical Name Space (2)

• Names are hierarchical
• anchor.cs.colorado.edu starts from root with edu,
  then colorado, then cs, then anchor
• File systems start from the opposite direction
  /home/users/rhan/Misc
• Higher level names specify domains edu, com,
  gov, mil, org, and net
• Names become human-readable
• Names become unique and global

13
DNS Name Servers

• DNS Servers assume responsibility for certain
  subtrees or zones in name hierarchy
• DNS as a hierarchy of name servers
• Scalable! processing is distributed via
  hierarchy
• Each name server keeps a database of resource
  records binding names to IP addresses
• ltName, Value, Type, Class, TTLgt
• Name www.cs.colorado.edu
• Value IP address
• Type specifies how Value is interpreted, ValueA
  gt Value is IP address

14
DNS Name Servers (2)

• When Type NS, then the Value field stores the
  address of another name server
• Each name server can point at other name servers,
  constructing a hierarchy of name servers
• Types of DNS Name Servers
• Root highest level of hierarchy
• Local Name Server lowest level of hierarchy
• Authoritative Name Server final name server
  that answers DNS request, translating name to IP
  address
• A name server can be both local and authoritative

15
DNS Root Name Servers

• Responsible for root zone
• Approx. dozen root name servers worldwide
• Currently a-m.root-servers.net
• Local name servers contact root servers when they
  cannot resolve a name
• Configured with well-known root servers

Courtesy Srini Seshan
16
DNS Name Resolution

• Each host has a resolver
• UNIX clients will typically call gethostbyname()
  to initiate a DNS name lookup
• Typically a library that applications can link to
• Local name servers hand-configured (e.g.
  /etc/resolv.conf)
• Name servers
• Typically responsible for a zone in the hierarchy
• Local servers
• Do lookup of distant host names for local hosts
• Typically answer queries about local zone

17
DNS Lookup Example
root edu DNS server
www.cs.cmu.edu
www.cs.cmu.edu
NS cmu.edu
cmu.edu DNS server
Local DNS server
NS cs.cmu.edu
Client
cs.cmu.edu Authoritative DNS server
wwwIPaddr
Courtesy Srini Seshan
18
Lookup Methods

• Iterative
• Server responds with as much as it knows
  (iterative)
• Recursive
• Server goes out and searches for more info on
  behalf of requestor (recursive)
• Only returns final answer or not found
• Impact on caching? workload?
• Local server typically does recursive
• Root/distant server does iterative

19
DNS Iterated Queries

• Recursive query
• Puts burden of name resolution on contacted name
  server
• Heavy load?
• Iterative query
• Contacted server replies with name of server to
  contact
• I dont know this name, but ask this server

root name server
2
iterated query
3
4
7
5
6
authoritative name server dns.cs.umass.edu
1
8
requesting host surf.eurecom.fr
gaia.cs.umass.edu
20
DNS Caching

• DNS responses are cached
• Quick response for repeated translations
• Often cache for 2 days
• DNS negative queries are cached
• Cache that the host could not be resolved
• Cached data periodically times out
• Lifetime (TTL) of data controlled by owner of
  data
• TTL passed with every record

21
DNS Reliability

• DNS servers are replicated to achieve robustness
• Name service available if at least one replica is
  up
• Queries can be load balanced between replicas
• Root servers are replicated at least a dozen
• Each name server has a primary and secondary
  backup
• Secondary replicas periodically update primary
  name servers entire database via a zone
  transfer protocol over TCP
• See RFC 2182 Selection and Operation of
  Secondary DNS Servers