The Internet Domain Name System Hari Balakrishnan 6.829 Fall 2002Goals • DNS architecture  How DNS works • DNS uses  Mail  Content Distribution Networks (CDNs) • DNS Performance  How well does it work?  Why does it work?Why naming? • Level(s) of indirection between a resourceand its location • Convenience  For apps  For humans  Autonomous organizational operation (real-world) • Examples  DNS, search engines, intentional names,…  Virtual memory, DHTs,…DNS architecture • Two major components  Name servers: Information repositories  Resolvers: Interface to client programs • Stub resolver as libraries • Forwarding name servers that proxy for stubs • DNS name space • Resource records • Database distribution  Zones  Caching • Datagram-based protocolDNS name space • Organized as a variable-depth rooted tree • Each node in tree has associated label  Label = variable-length string of octets  Case-insensitive • DNS name of node = path from node to root  E.g., nms.lcs.mit.edu. (“.” separates labels)  [email protected]. (left of “@” is a single label, to theright are four labels) • No implicit semantics in tree structure in general  Except for IN-ADDR.ARPA domain used for reverse lookups • Design tuned for administrative delegation of thename space (more on this in a bit)Resource Records (RRs) • Data in DNS structured using RRs • Idea is to help both apps and DNS itself • Classes are orthogonal to each other  IN, ISO, CHAOS, XNS,… (pretty much only INtoday!) • Each class has a set of types; new types canbe added, but require standardization • Example IN types  A, NS, MX, PTR, CNAME, …Example • dig www.google.com www.google.com. 162 IN A 216.239.53.100 google.com. 345579 IN NS ns3.google.com. google.com. 345579 IN NS ns4.google.com. google.com. 345579 IN NS ns1.google.com. google.com. 345579 IN NS ns2.google.com. • dig www.google.com –t MX www.google.com. 86210 IN MX 20 smtp2.google.com. • What are the #s in the second column? • What’s the number next to the MX answer? • Advantage of one RR per type, versus single RR with multiple values?Database distribution • Two distribution mechanisms  Zones  Caching • Separation invisible to user/application • Zone = complete description of a contiguous section of the DNS name space  Stores RRs for labels  And pointers to all other contiguous zones  Zone divisions can be made anywhere in the name spaceZone logistics • Persuade parent organization to delegate a subzone consisting of a single node  E.g., persuade lcs.mit.edu. to delegate nms.lcs.mit.edu (the delegated node is “nms”)  Persuade com. to delegate label “cnn” to me • New zone can grow to arbitrary size and further delegated autonomouslyZone owner’s responsibilities • Authoritatively maintain the zone’s data • Arrange for replicated name servers for the zone  Typically, zone data is maintained in a master file andloaded into a primary (master) server  Replicated servers use TCP-based zone transfers specifiedin DNS protocol to refresh their data • A name server authoritative for a zone does not have to be in that zone (great idea) • A name server can handle any number of zones,which don’t have to be contiguous • Example: dig cnn.com.  cnn.com. 600 IN NS twdns-02.ns.aol.comCaching • Each name server aggressively cacheseverything it can • Only control on caching: TTL field  An expired TTL requires a fresh resolution  Each RR has its own TTL • Low TTL values reduces inconsistencies, allows for dynamic name-to-RR mappings • Large TTL values reduce network and serverloadExample resolution • Suppose you want to lookup A-record for www.lcs.mit.edu. and nothing is cached Root server .edu server mit.edu server lcs.mit.edu server Local DNS proxy App Stub resolver 1 Recursive resolution Iterative resolution 2 3 4 5Caching • In reality, one almost never sees the chain ofrequest-response messages of previous slide • NS records for labels higher up the tree usually havelong TTLs • E.g., the google.com example from before • But what about cnn.com? cnn.com. 600 IN NS twdns-02.ns.aol.com • Not a problem twdns-02.ns.aol.com. 3600 IN A 152.163.239.216 ns.aol.com. 3553 IN NS dns-02.ns.aol.com. • Cache not only positive answers, but also stuff thatdoes not existCommunication protocol • Normal request response uses a UDP-based datagram protocol with retransmissions • Retry timer is configurable, typically 4 or 8 seconds • Often, retries are extremely persistent (many times) • Use transaction ID field to disambiguate responses • Key point: App using DNS is typically decoupled from the DNS resolver making recursive queries! • Zone transfers use TCP (bulk data, rather than RPC-style comm.)Definitions • gethostbyname() is a lookup • Local DNS server makes one or more queries(recursive resolution) • Each contacted server responds with a response • A response could be a referral, to gosomeplace else • A response that is not a referral is an answerPerformance study motivation • How well does DNS work today?  Scalability  Robustness  Protocol • Which of its mechanisms are actually useful?  Hierarchy  Caching • DNS is being put to new uses: Is that likely to cause problems?  Load-balancing  Content Distribution NetworksSuspicion • DNS in WAN traffic traces  14% of all packets (estimate) in Danzig et al. 1990 8% in 1992  5% in NSFNET (1995)  3% in 1997 (MCI traces, 1997) •But…  18% of all “flows” in 1997  1 out of 5 flows is a DNS flow??? • But yet, the DNS seems to work OK  Because of caching is traditional view • Low-TTL bindings have important benefits  Load-balancing  MobilityAnalysis: Two Data Sets • MIT: Jan 2000 (mit-jan00) & Dec 2000 (mit-dec00)  All DNS traffic at LCS/AI border and all TCP SYN/FIN/RST  Protocol analysis & cache simulations • KAIST, Korea: May 2001 (kaist-may01)  All DNS traffic at border and some TCP SYN/FIN/RST  Protocol analysis & cache simulations • Key insight: Joint analysis of DNS and its driving workload (TCP connection) can help understand what’s going onMIT LCS/AI Topology External network Collection machine