Chapter 9 Application Layer, DNS Professor Rick Han University of Colorado at Boulder rhan@cs.colorado.edu

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

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

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

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

Domain Name Service (DNS) Translate/resolve a name into an IP address www.cs.colorado.edu -> 128.138.242.195 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

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

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

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

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 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@cs.colorado.edu , so cs.colorado.edu has to be translated into an IP address Prof. Rick Han, University of Colorado at Boulder

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

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

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 = www.cs.colorado.edu Value = IP address Type specifies how Value is interpreted, Value=A => Value is IP address Prof. Rick Han, University of Colorado at Boulder

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

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

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

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

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

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

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

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