Chapter 9 Application Layer, DNS Professor Rick Han University of Colorado at Boulder...
-
date post
22-Dec-2015 -
Category
Documents
-
view
230 -
download
5
Transcript of Chapter 9 Application Layer, DNS Professor Rick Han University of Colorado at Boulder...
Chapter 9Application Layer, DNS
Professor Rick HanUniversity of Colorado at Boulder
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
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
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
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
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 [email protected] , so cs.colorado.edu has to be translated into an IP address
Prof. Rick Han, University of Colorado at Boulder
DNS Hierarchical Name Spaceroot
edunetorg ukcom gov, mil, etc….
gwu ucb colorado bu mit
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
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
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
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
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
DNS Lookup Example
ClientLocal
DNS server
root & edu DNS server
cmu.edu DNS server
www.cs.cmu.edu
NS cmu.eduwww.cs.cmu.edu
NS cs.cmu.edu
www=IPaddr
cs.cmu.eduAuthoritative
DNSserver
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 QueriesRecursive 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” requesting host
surf.eurecom.frgaia.cs.umass.ed
u
root name server
local name serverdns.eurecom.fr
1
2
34
5 6authoritative name server
dns.cs.umass.edu
intermediate name serverdns.umass.edu
7
8
iterated query
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
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