1. Chapter 9 Application Layer, DNS
Professor Rick Han
University of Colorado at Boulder

2. Prof. Rick Han, University of Colorado at Boulder
Announcements
Read Sections , 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
Prof. Rick Han, University of Colorado at Boulder

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 doesn’t 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
Prof. Rick Han, University of Colorado at Boulder

4. Recap of Previous Lecture (2)
Wireless TCP
Wireless fading causes congestion backoff – Wrong response
Split Connection Solution
Doesn’t 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
Prof. Rick Han, University of Colorado at Boulder

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
Prof. Rick Han, University of Colorado at Boulder

6. Domain Name Service (DNS)
Translate/resolve a name into an IP address
->
Binding of a name to a value
What are examples of an address translation service we’ve already studied?
DHCP: MAC -> IP address
ARP: IP address -> MAC
These solutions are
Confined in/near a local area network LAN
DHCP: Client queries server
ARP: Client queries a destination peer
Prof. Rick Han, University of Colorado at Boulder

7. Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder

8. Prof. Rick Han, University of Colorado at Boulder
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, doesn’t scale well
Thus, design DNS to provide
Robust,
Scalable,
Global name translation/resolution
Prof. Rick Han, University of Colorado at Boulder

9. Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder

10. Prof. Rick Han, University of Colorado at Boulder
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 into IP address, so http can set up a TCP connection to Web server
SMTP program wants to send to , so cs.colorado.edu has to be translated into an IP address
Prof. Rick Han, University of Colorado at Boulder

11. DNS Hierarchical Name Space
root
org
net
edu
com uk
gov, mil, etc….
ucb
colorado bu
mit
gwu cs
ece
anchor
Prof. Rick Han, University of Colorado at Boulder

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
Prof. Rick Han, University of Colorado at Boulder

13. Prof. Rick Han, University of Colorado at Boulder
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:
<Name, Value, Type, Class, TTL>
Name =
Value = IP address
Type specifies how Value is interpreted, Value=A => Value is IP address
Prof. Rick Han, University of Colorado at Boulder

14. Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder

15. Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder
Courtesy: Srini Seshan

16. Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder

17. Prof. Rick Han, University of Colorado at Boulder
DNS Lookup Example
root & edu
DNS server
NS cmu.edu
cmu.edu
DNS server
Local
DNS server
NS cs.cmu.edu
Client
cs.cmu.edu
Authoritative
DNS
server
www=IPaddr
Prof. Rick Han, University of Colorado at Boulder
Courtesy: Srini Seshan

18. Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder

19. DNS: Iterated Queries Recursive query: Iterative query:
Puts burden of name resolution on contacted name server
Heavy load?
Iterative query:
Contacted server replies with name of server to contact
“I don’t know this name, but ask this server”
root name server 2
iterated query 3 4 7
local name server
dns.eurecom.fr
intermediate name server
dns.umass.edu 5 6 1
authoritative name server
dns.cs.umass.edu 8
requesting host
surf.eurecom.fr
gaia.cs.umass.edu
Prof. Rick Han, University of Colorado at Boulder

20. Prof. Rick Han, University of Colorado at Boulder
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
Prof. Rick Han, University of Colorado at Boulder

21. Prof. Rick Han, University of Colorado at Boulder
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 server’s entire database via a “zone transfer” protocol over TCP
See RFC 2182 : Selection and Operation of Secondary DNS Servers
Prof. Rick Han, University of Colorado at Boulder