dns performance and the effectiveness of...
TRANSCRIPT
1
DNS PerformanceandtheEffectivenessof CachingJaeyeonJung,Emil Sit, Hari Balakrishnan,Member, IEEE, andRobertMorris
Abstract—This paper presentsa detailed analysisof tracesof DNS andassociatedTCP traffic collectedon the Internet links of theMIT Laboratoryfor Computer Scienceand the Korea Advanced Institute of ScienceandTechnology(KAIST). The first part of the analysis details how clients attheseinstitutions interact with the wide-areadomain namesystem,focusingon performanceand the prevalenceof failur esand errors. The secondpartevaluatesthe effectivenessof DNS caching.
In the most recentMIT trace, 23% of lookups receive no answer; theselookups account for more than half of all traced DNS packets sincequerypacketsare retransmitted overly persistently. About 13% of all lookupsre-sult in ananswerthat indicatesanerror condition. Many of theseerrors ap-pear to be causedby missinginverse(IP-to-name) mappingsor NS recordsthat point to non-existentor inappropriate hosts. 27% of the queriessentto the root nameservers result in sucherrors.
The paper alsopresentsthe resultsof trace-driven simulations that ex-plore the effect of varying TTLs and varying degreesof cachesharing onDNS cachehit rates. Due to the heavy-tailed nature of nameaccesses,re-ducing the TTLs of address(A) recordsto aslow asa few hundredsecondshaslittle adverseeffecton hit rates,and little benefit is obtained fr om shar-ing a forwarding DNS cacheamongmore than 10 or 20 clients. Thesere-sultssuggestthat the performanceof DNSis not asdependenton aggressivecachingas is commonly believed, and that the widespreaduseof dynamic,low-TTL A-recordbindings should not degradeDNSperformance.
Keywords—DNS,Measurement,Performance,Caching, Internet
I . INTRODUCTION
The DomainNameSystem(DNS) is a distributeddatabasemappingnamesto network locations, providing informationcritical to the operationof most Internetapplicationsandser-vices. As a global service,DNS must be highly scalableandoffer goodperformanceunderhigh load. Any failuresandde-lays in nameresolutionwould easily result in delaysthat arevisible to endusers.
It is widely believedthat two factorscontribute to the scala-bility of DNS: hierarchicaldesignaroundadministratively del-egatednamespaces,and the aggressive useof caching. Bothfactorsreducethe load on the root servers at the top of thenamespacehierarchy, while successfulcachingreducesclient-perceiveddelaysandwide-areanetwork bandwidthusage.TheDNS cachingdesignfavors availability over freshness. AnyDNS server or client maymaintaina cacheandanswerqueriesfrom that cache,allowing the constructionof hierarchiesofsharedcaches.Theonly cachecoherencemechanismthatDNSprovidesis thetime-to-livefield (TTL), whichgovernshow longanentrymaybecached.
Prior to theyear2000,theonly large-scalepublishedstudyofDNS performancewasby Danziget al. in 1992[1]. Danzig’sstudyfoundthatalargenumberof implementationerrorscausedDNS to consumeabouttwenty timesmorewide-areanetworkbandwidththan necessary. However, sincethen, DNS imple-mentationshave changedaswell asDNS usagepatterns.For
Thisresearchwassponsoredby DefenseAdvancedResearchProjectsAgency(DARPA) andthe SpaceandNaval WarfareSystemsCenterSanDiego undercontractN66001-00-1-8933.
The authors are with the MIT Laboratory for Computer Science, 200TechnologySquare,Cambridge,MA 02139USA (e-mail:[email protected],[email protected],[email protected],[email protected]).
example, the World Wide Web has becomethe bulk of traf-fic. Correspondingly, contentdistributionnetworks(CDNs)andpopularWebsitesnow useDNS asa level of indirectionto bal-anceloadacrossservers,provide fault tolerance,or routeclientrequeststo servers topologicallycloseto the clients. BecausecachedDNSrecordslimit theefficacy of suchtechniques,manyof thesemultiple-server systemsuseTTL valuesassmall asafew secondsor minutes.Anotherexampleis in mobilenetwork-ing, wheredynamicDNS togetherwith low-TTL bindingscanprovide the basisfor hostmobility supportin the Internet[2],[3]. Theseusesof DNS all conflictwith caching.
One concreteway to estimatethe effectivenessof DNScachingis to observe the amountof DNS traffic in the wide-areaInternet. Danzig et al. report that 14% of all wide-areapacketswereDNSpacketsin 1990,comparedto 8%in 1992.In1995,the correspondingnumberfrom a studyof the NSFNETby Frazerwas5% [4]; a 1997studyof the MCI backbonebyThompsonet al. reportedthat 3% of wide-areapacketswereDNS related[5]. This downwardtrendmight suggestthatDNScachingis working well.
However, theseresultsshouldbe put in perspective by con-sideringthem relative to network traffic as a whole. Thomp-son’sstudyalsoshowedthatDNSaccountsfor 18%of all flows(wherea flow is definedasa uni-directionaltraffic streamwithuniquesourceanddestinationIP addresses,portnumbersandIPprotocolfields). If oneassumesthatapplicationstypically pre-cedeeachTCPconnectionwith a call to thelocalDNS resolverlibrary, this suggestsa DNS cachemissrateof a little lessthan25%. However, by 1997, most TCP traffic consistedof Webtraffic, which tendsto producegroupsof aboutfour connectionsto thesameserver [6]; if oneassumesoneDNS lookupfor ev-ery four TCPconnections,the“session-level” DNS cachemissrateappearsto becloserto 100%.While anaccurateevaluationrequiresmorepreciseconsiderationof thenumberof TCPcon-nectionspersessionandthenumberof DNSpacketsperlookup,this quick calculationsuggeststhatDNS cachingis not very ef-fectiveat suppressingwide-areatraffic.
Theseconsiderationsmake a thoroughanalysisof the effec-tivenessof DNS cachingis especiallyimportant.Thus,this pa-perhastwo goals.First, it seeksto understandtheperformanceandbehavior of DNSfrom thepointof view of clientsand,sec-ond,it evaluatestheeffectivenessof caching.
A. Summaryof Results
In exploring DNS performanceandscalability, we focusonthefollowing questions:
1. What performance,in termsof latency and failures, doDNS clientsperceive?
2. How doesvarying the TTL and degreeof cachesharingimpactcachingeffectiveness?
Thesequestionsareansweredusinga novel methodof ana-lyzing tracesof TCPtraffic alongwith the relatedDNS traffic.
2
To facilitatethis, we capturedall DNS packetsandTCP SYN,FIN , andRST packetsat two different locationson the Inter-net. The first is at the link that connectsMIT’ s LaboratoryforComputerScience(LCS) andArtificial IntelligenceLaboratory(AI) to therestof theInternet.Thesecondis at a link thatcon-nectstheKoreaAdvancedInstituteof ScienceandTechnology(KAIST) to the restof the Internet. We analyzetwo differentMIT datasets,collectedin Januaryand December2000, andoneKAIST datasetcollectedin May 2001.
Onesurprisingresultis thatmostlookupsarenotsuccessfullyanswered.23%of all clientlookupsin themostrecentMIT tracefail to elicit any answer. In thesametrace,13%of lookupsre-sult in an answerthat indicatesan error. Most of theseerrorsindicatethat the desirednamedoesnot exist. While no singlecauseseemsto predominate,inverselookups(translatingIP ad-dressesto names)oftencauseerrors,asdoNSrecordsthatpointto non-existentservers.
DNS servers also appearto retransmitoverly aggressively.Thequerypacketsfor theseunansweredlookups,includingre-transmissions,accountfor more than half of all DNS querypacketsin the trace. Loopsin nameserver resolutionaccountareparticularlybad,causinganaverageof 10querypacketssentto thewide areafor each(unanswered)lookup. In contrast,theaverageansweredlookupsendsabout1.3querypackets.Loopsaccountfor 3%of all unansweredlookups.
We have also beenable to observe changesin DNS usagepatternsandperformance.For example,thepercentageof TCPconnectionsmadeto nameswith low TTL valuesincreasedfrom12%to 25%betweenJanuaryandDecember2000,probablydueto the increaseddeploymentof DNS-basedserver selectionforpopularsites.Also, while mediannameresolutionlatency waslessthan100 ms, the latency of the worst 10% grew substan-tially betweenJanuaryandDecember2000.
The other portion of our study concernscachingeffective-ness. The relationshipbetweennumbersof TCP connectionsandnumbersof DNS lookupsin the MIT tracessuggeststhatthe hit rate of DNS cachesinside MIT is between80% and86%. This includesclient andapplicationcaches,includingthecachingdoneby Web browserswhenthey openmultiple TCPconnectionsto thesameserver. However, wefind thatthedistri-bution of namesis Zipf-lik e,which immediatelylimits theeventheoreticaleffectivenessof caching.
The capturedTCP traffic helpsusperformtrace-drivensim-ulationsto investigatetwo importantfactorsthataffect cachingeffectiveness:(i) theTTL valueson namebindings,and(ii) thedegreeof aggregationdueto sharedclient caching. Our trace-driven simulationsshow that A recordswith 10-minuteTTLsyield almost the samehit ratesas substantiallylonger TTLs.Furthermore,wefind thatacachesharedby asfew astenclientshasessentiallythe samehit rate asa cachesharedby the fulltracedpopulationof over 1000clients. This is consistentwiththeZipf-lik edistributionof names.
TheseresultssuggestthatDNS works aswell asit doesde-spite ineffective A-record caching,and that the current trendtowardsmore dynamicuseof DNS (and lower TTLs) is notlikely to beharmful. On theotherhand,we find thatNS-recordcachingis critical to DNS scalabilityby reducingload on theroot servers.
Therestof this paperpresentsour findingsandsubstantiatestheseconclusions.SectionII presentsanoverview of DNS andsurveyspreviouswork in analyzingits performance.SectionIIIdescribesour traffic collection methodologyand somesalientfeaturesof our data. SectionIV analyzesthe client-perceivedperformanceof DNS,whileSectionV analyzestheeffectivenessof cachingusingtrace-driven simulation. We concludewith adiscussionof ourfindingsin SectionVI.
I I . BACKGROUND
In this section,we presentan overview of DNS andsurveyrelatedwork.
A. DNSOverview
Thedesignof theInternetDNSis specifiedin [7], [8], [9]. Wesummarizetheimportantterminologyandbasicconceptshere.
The basic function of DNS is to provide a distributeddatabasethat maps between human-readablehost names(suchas chive.lcs.mit.edu ) and IP addresses(suchas18.31.0.35 ). It also providesother important informationaboutthe domainor host, including reversemapsfrom IP ad-dressesto host namesand mail-routing information. Clients(or resolvers) routinely query nameservers for valuesin thedatabase.
TheDNS namespaceis hierarchicallyorganizedsothatsub-domainscanbe locally administered.Theroot of thehierarchyis centrallyadministered,andserved from a collectionof thir-teen(in mid-2001)root servers. Sub-domainsaredelegatedtootherserversthatareauthoritativefor their portionof thenamespace.Thisprocessmayberepeatedrecursively.
At the beginning of our study, mostof the root serversalsoserved the top-level domains,suchas .com . At the end, thetop-level domainswerelargelyservedby aseparatesetof abouta dozendedicated“generictop-level domain”(gTLD) servers.
Mappingsin theDNSnamespacearecalledresourcerecords.Two commontypesof resourcerecordsareaddressrecords(Arecords)and nameserver records(NS records). An A recordspecifiesaname’sIP address;anNSrecordspecifiesthenameofa DNS server thatis authoritative for a name.Thus,NSrecordsareusedto handledelegationpaths.
Sinceachieving good performanceis an importantgoal ofDNS, it makesextensive useof cachingto reduceserver loadandclient latency. It is believedthatcacheswork well becauseDNS datachangesslowly and a small amountof stalenessistolerable. On this premise,many serversarenot authoritativefor mostdatathey serve, but merelycacheresponsesandserveaslocal proxiesfor resolvers. Suchproxy serversmayconductfurther querieson behalfof a resolver to completea query re-cursively. Clientsthatmakerecursivequeriesareknown asstubresolvers in theDNS specification.On theotherhand,a querythat requestsonly what the server knows authoritatively or outof cacheis calledan iterativequery.
Figure 1 illustratesthesetwo resolutionmechanisms.Theclientapplicationusesastubresolverandqueriesa localnearbyserver for a name(saywww.mit.edu ). If this server knowsabsolutelynothingelse,it will follow the stepsin the figure toarriveat theaddressesfor www.mit.edu . Requestswill beginatawell-known rootof theDNShierarchy. If thequeriedserver
3
�����
����� ��� ��� ����� ���� ������� � � � !� "
# � $ %!���� $ ��" � & ��')( ��� � " �� "
*�+�,.- /)+�- ,
# � $ % ��$ % $ 0��
��� � �� � " !� "1 � 2��� � " �� "
354 6� � " !� "
78 98: ;< => ?
@ 1 A � � ��%!� BC�D� � $ %!��� � " !� "�E � ".%�2�2!" � � �D� E�F�F�F 1 G & � 1 � 2!�H 1 # � $ %!� '�( ��� � " �� ".2!� � � I�J �CB�I�� FLK!%!� BC��" � � � 1�D� � ��" � E � " ��� �)% 1 � 2!��� � " !� "M 1 6 0C� 1 � 2!��� � " �� "D" � E � " �D� �)% I 3 4 6 � � " !� "N 1 6 0C� 354 6 � � " !� "�" � � ��� IC2���F)& � 05%!I�%!2�2�" � � �O 1 6 0C��� � $ %!��� � " �� "�$ %!$ 0C� �D" � � ��� IC� �
PQ
R
ST
Fig. 1. Exampleof aDNS lookupsequence.
hasdelegatedresponsibilityfor aparticularname,it returnsare-ferral response,whichis composedof nameserverrecords.Therecordsarethesetof serversthathave beendelegatedresponsi-bility for thenamein question.Thelocalserverwill chooseoneof theseserversandrepeatits question.This processtypicallyproceedsuntil a server returnsananswer.
Cachesin DNSaretypically notsize-limitedsincetheobjectsbeing cachedare small, consistingusually of no more than ahundredbytesperentry. Eachresourcerecordis expiredaccord-ing to thetime setby theoriginatorof thename.Theseexpira-tion timesarecalledTimeTo Live(TTL)values.Expiredrecordsmustbe fetchedafreshfrom the authoritative origin server onquery. Theadministratorof a domaincancontrolhow long thedomain’srecordsarecached,andthushow longchangeswill bedelayed,by adjustingTTLs. Rapidlychangingdatawill have ashortTTL, tradingoff latency andserver loadfor freshdata.
To avoid confusion,theremainderof thispaperusestheterms“lookup,” “query,” “response,” and“answer”in specificways.Alookuprefersto theentireprocessof translatingadomainnamefor a client application.A queryrefersto a DNS requestpacketsentto a DNS server. A responserefersto a packet sentby aDNS server in reply to a querypacket. An answeris a responsefrom a DNS server that terminatesthe lookup,by returningei-ther the requestedname-to-recordmappingor an error indica-tion. Valid responsesthatarenot answersmustbereferrals.
This means,for example,thata lookupmayinvolvemultiplequeryandresponsepackets. The queriesof a lookup typicallyask for the samedata,but from differentDNS servers; all re-sponsesbut thelastone(theanswer)aretypically referrals.Thisdistinctioncanbeseenin Figure1; thepacketsin steps1–4areall partof the samelookup (drivenby the requestfrom theap-plication); however, eachsteprepresentsa separatequeryandresponse.
B. RelatedWork
In 1992,Danziget al. presentedmeasurementsof DNS traf-fic ata rootnameserver [1]. Theirmainconclusionwasthatthemajorityof DNStraffic is causedby bugsandmisconfiguration.They consideredtheeffectivenessof DNSnamecachingandre-transmissiontimeoutcalculation,andshowedhow algorithmstoincreaseresilienceledto disastrousbehavior whenserversfailedor whencertainimplementationfaultswere triggered. Imple-mentationissueswere subsequentlydocumentedby Kumaretal., who note that many of theseproblemshave beenfixed in
morerecentDNSservers[10]. Danzigetal. alsofoundthatonethird of wide-areaDNS traffic that traversedthe NSFnetwasdestinedto oneof the(at thetime)sevenrootnameservers.
In contrastto Danziget al.’s work, our work focuseson an-alyzing client-sideperformancecharacteristics.In the process,wecalculatethefractionof lookupsthatcausedwide-areaDNSpacketsto besent,andthe fraction thatcauseda root or gTLDserver to becontacted.
In studiesof wide-areatraffic in general,DNS is often in-cludedin the traffic breakdown [4], [5]. As notedin SectionI,the high ratio of DNS to TCP flows in thesestudiesmotivatedour investigationof DNS performance.
It is likely thatDNS behavior is closelylinkedto Webtrafficpatterns,sincemost wide-areatraffic is Web-relatedandWebconnectionsare usually precededby DNS lookups. One re-sult of Web traffic studiesis that the popularitydistribution ofWebpagesis heavy-tailed[11], [12], [13]. In particular, Breslauet al. concludethat the Zipf-lik e distribution of Web requestscauseslow Webcachehit rates[11]. Wefind thatthepopularitydistribution of DNS namesis alsoheavy-tailed, probablyasaresultof the sameunderlyinguserbehavior. It is not immedi-atelyclearthatDNS cachesshouldsuffer in thesameway thatWeb cachesdo. For example,DNS cachesdo not typically in-cur cachemissesbecausethey run out of capacity. DNS cachemissesareinsteaddrivenby therelationshipbetweenTTLs se-lectedby the origin andthe interarrival time betweenrequestsfor eachnameat the cache. DNS cacheentriesarealsomorelikely to be reusedbecauseeachcomponentof a hierarchicalnameis cachedseparatelyseparatelyand also becausemanyWebdocumentsarepresentundera singleDNS name.Despitethesedifferences,we find that DNS cachesaresimilar to Webcachesin their overalleffectiveness.
A recentstudyby Shaikhet al. shows the impactof DNS-basedserver selectionon DNS [14]. This studyfinds that ex-tremelysmall TTL values(on the orderof seconds)aredetri-mentalto latency, andthatclientsareoftennot closein thenet-work topologyto thenameserversthey use,potentiallyleadingto sub-optimalserver selection.In contrast,our studyevaluatesclient-perceivedlatency asafunctionof thenumberof referrals,andanalyzesthe impactof TTL andsharingon cachehit rates.We alsostudythe performanceof the DNS protocolandDNSfailuremodes.
Wills andShangstudiedNLANR proxy logs andfound thatDNSlookuptimecontributedmorethanonesecondto approxi-mately20%of retrievalsfor theWebobjectson thehomepageof largerservers.They alsofoundthat20%of DNSrequestsarenot cachedlocally [15], which we considera large percentagefor the reasonsexplainedbefore. Cohenand Kaplanproposeproactivecachingschemesto alleviatethelatency overheadsofsynchronouslyrequestingexpiredDNS records[16]; their anal-ysis is alsoderivedfrom NLANR proxy log workload. Unfor-tunately, proxy logsdo not capturetheactualDNS traffic; thusany analysismustrely on on measurementstakenafter thedatais collected.This will not accuratelyreflectthenetwork condi-tions at the time of the request,andthe DNS recordscollectedmayalsobenewer. Our dataallows us to directly measuretheprogressof the DNS lookup as it occurred. Additionally, ourdatacapturesall DNS lookupsand their relatedTCP connec-
4
tions,not just thoseassociatedwith HTTPrequests.
HuitemaandWeerahandimeasuredDNS latency throughthegethostbyname() interface over a period of 15 months,startingfrom April 1999.For their study, 29%of DNS lookupstook longerthan2 secondsto get an answer[17]. In compari-sion,our studyshows thatbetween10%and24%lookupsgivethis much latency. Thesenumbersdiffer becauseour latencynumbersdo not includelatency experiencedbetweentheclientapplicationandthelocal nameserver which is includedin theirdata.Naturally, DNSlatency is alsoaffectedby theconnectivityandtheperformanceof thenetwork atthepointof measurement.
Brownlee et al. collected DNS traffic at F.root-servers.net , and showed that over 14% of the observedquery load wasdue to bogusqueries;their paperprovidesananalysisof theloadandataxonomyof thecausesof errors[18].Errors include repeatedqueriesgeneratedfrom samesourcehost,queriesfor non-existenttop level domainnames,andmal-formedA queries.Someof theseareobservedin our tracesandarelisted in sectionIV-C. In particular, we foundthatbetween15%and27%of thelookupssentto root nameserversresultedin negativeresponses.
Another study by the sameauthorsshow passive measure-mentsof the performanceof root and gTLD servers as seenfrom their campusnetwork usingNeTraMet meters[19]. Thepaperpresentsresponsetime, requestrateandrequestlossrateof theroot andgTLD serversseenat thetracednetwork. Theirresponsetimesindicatethe latency betweena singlequeryandresponse,ascomparedto our latencieswhich cover the entirelookup process. Their methodologyis also targettedto mea-sureoverall performance.In contrast,our analysesconsidertheentireDNSpacketheaderandpayloadto revealamorecompre-hensiveview of DNS behavior.
I I I . THE DATA
Ourstudyis basedonthreeseparatetraces.Thefirst two werecollectedin JanuaryandDecember2000respectively, at thelinkthatconnectstheMIT LCS andAI labsto therestof theInter-net.At thetimeof thestudy, therewere24internalsubnetworkssharingtherouter, usedby over 500usersandover 1200hosts.The third tracewascollectedin May 2001at oneof two linksconnectingKAIST to therestof theInternet.At thetimeof datacollectiontherewereover1000usersand5000hostsconnectedto the KAIST campusnetwork. The traceincludesonly inter-nationalTCP traffic; KAIST sendsdomestictraffic on a paththat wasnot traced. However, the tracedoesincludeall exter-nal DNS traffic, domesticandinternational:the primary nameserver of the campus,ns.kaist.ac.kr , wasconfiguredtoforward all DNS queriesto ns.kreonet.re.kr along aroutethatallowedthemto betraced.Figure2 shows theconfig-urationsof thetwo networks.
The first trace,mit-jan00 , wascollectedfrom 2:00 A .M .on3 January2000to 2:00A .M . on10January2000;thesecond,mit-dec00 , was collectedfrom 6:00 P.M . on 4 Decemberto 6:00 P.M . on 11 December2000. The third set, kaist-may01, wascollectedat KAIST from 5:00 A .M . on 18 May to5:00A .M . on 24 May 2001.All timesareEST.
Collection
Subnet #2machine
Subnet #1
Subnet #3
Subnet #24
Router
MIT LCS and AI
External network
(a) MIT LCS: Thereare24 internalsubnetworks shar-ing theborderrouter.
Collectionmachine
ns.kreonet.re.krHPCNet
Router B
Router A ns.kaist.ac.kr
traffic
Domestic traffic
KAIST campusInternational
(b) KAIST: The collection machine is located at apoint that capturesall DNS traffic, but only interna-tional traffic of other types. This becausethe pri-mary KAIST nameserver, ns.kaist.ac.kr , for-wards all DNS queries through the traced link tons.kreonet.re.kr .
Fig. 2. Schematictopologyof thetracednetworks.
A. CollectionMethodology
We filteredthetraffic observedat thecollectionpoint to pro-ducea datasetusefulfor our purposes.As many previousstud-ies have shown, TCP traffic (and in particular, HTTP traffic)comprisesthe bulk of wide-areatraffic [5]. TCP applicationsusuallydependon the DNS to provide the rendezvousmecha-nismbetweentheclient andtheserver. Thus,TCPflowscanbeviewedasthemajordriving workloadfor DNSlookups.
In ourstudy, wecollectedboththeDNStraffic andits drivingworkload.Specifically, we collected:
1. OutgoingDNS queriesandincomingresponses,and2. OutgoingTCP connectionstart (SYN) andend(FIN and
RST) packetsfor connectionsoriginating insidethetracednetworks.
In themit-jan00 trace,only thefirst 128bytesof eachpacketwere collectedbecausewe were unsureof the spacerequire-ments. However, becausewe found that someDNS responseswerelongerthanthis,wecapturedentireEthernetpacketsin theothertraces.
Thetracecollectionpointsdo not captureall client DNS ac-tivity. Queriesansweredfrom cachesinsidethetracednetworksdo not appearin the traces.Thusmany of our DNS measure-mentsreflectonly thoselookupsthatrequiredwide-areaqueriesto be sent. Sincewe correlatethesewith the driving workloadof TCPconnections,we canstill draw someconclusionsaboutoverallperformanceandcachingeffectiveness.
In additionto filtering for usefulinformation,we alsoelimi-natedinformationto preserve user(client) privacy. In theMIT
5
traces,any userwho wishedto be excludedfrom the collec-tion processwasallowedto do so,basedon an IP addresstheyprovided; only threehostsoptedout, andwereexcludedfromall our traces. We alsodid not capturepacketscorrespondingto reverseDNS lookups(PTR queries)for a small numberofnameswithin MIT, onceagainto preserve privacy. In addition,all packetswererewritten to anonymizethesourceIP addressesof hostsinsidethetracednetwork. This wasdonein a pseudo-randomfashion—eachsourceIP addresswasmappedusingakeyed MD5 cryptographichashfunction [20] to an essentiallyunique,anonymizedone.
Our collection software was derived from Minshall’stcpdpriv utility [21]. tcpdpriv anonymizes libpcap -formattraces(generatedby tcpdump ’spacketcapturelibrary).It cancollecttracesdirectlyor post-processthemaftercollectionusinga tool suchastcpdump [22]. We extendedtcpdprivto supporttheanonymizationschemedescribedabove for DNStraffic.
B. AnalysisMethodology
WeanalyzedtheDNStracesto extractvariousstatisticsaboutlookupsincluding the numberof referralsinvolvedin a typicallookupandthe distribution of lookup latency. To calculatethelatency in resolvinga lookup,we maintaina sliding window ofthelookupsseenin thelastsixty seconds;anentry is addedforeachquerypacket from an internalhostwith a DNS queryIDdifferentfrom any lookupin thewindow. Whenanincomingre-sponsepacket is seen,thecorrespondinglookupis foundin thewindow. If theresponsepacket is ananswer(asdefinedin Sec-tion II-A), thetimedifferencebetweentheoriginalquerypacketandtheresponseis thelookuplatency. Theactualend-userDNSrequestlatency, however, is slightly longerthanthis, sinceweseepacketsin mid-flight. If the responseis not an answer, weincrementthe numberof referralsof the correspondinglookupby one,andwait until thefinal answercomes.To keeptrackofthenameserverscontactedduringa lookup,we maintaina listof all theIP addressesof nameserversinvolvedin theresolutionof thelookup.
This methodcorrectly capturesthe list of serverscontactedfor iterative lookups, but not for recursive lookups. Mostlookupsin theMIT tracesareiterative; we eliminatedthesmallnumberof hostswhich sentrecursive lookupsto nameserversoutsidethe tracednetwork. The KAIST tracescontainmostlyrecursive lookupssentto a forwarding server just outsidethetracepoint;hence,while wecanestimatelowerboundsonnameresolutionlatency, we cannotderive statisticson thenumberofreferralsor thefractionof accessesto a top-level server.
C. Data Summary
TableI summarizesthebasiccharacteristicsof our datasets.We categorizelookupsbasedon theDNS codein the responsethey elicit, asshown in rows 3-6 of TableI. A lookupthatgetsa responsewith non-zeroresponsecodeis classifiedasa neg-ative answer, asdefinedin the DNS specification[8], [23]. Azero answeris authoritative and indicatesno error, but hasnoANSWER, AUTHORITY, or ADDITIONAL records[10]. A zeroanswercanarise,for example,whenan MXlookup is donefora namethat hasno MXrecord,but doeshave otherrecords.A
TABLE II
PERCENTAGE OF DNS LOOKUPS FOR THE POPULAR QUERY TYPES.
mit-jan00 mit-dec00 kaistA 60.4% 61.5% 61.0%PTR 24.6% 27.2% 31.0%MX 6.8% 5.2% 2.7%ANY 6.4% 4.6% 4.1%
lookupis answeredwith successif it terminateswith a responsethat hasa NOERRORcodeandoneor moreANSWERrecords.All otherlookupsareareconsideredunanswered.
Clientscanmake a variety of DNS queries,to resolve host-namesto IP addresses,find reverse-mappingsbetweenIP ad-dressesand hostnames,find mail-recordbindings,etc. Therearetwentyquerytypesdefinedin theDNSspecification[8]. Ta-bleII liststhefour mostfrequentlyrequestedquerytypesin eachof our traces. About 60% of all lookupswere for hostname-to-addressA recordsandbetween24% and31% were for thereversePTRbindingsfrom addressesto hostnames.
Although mostansweredA lookupsare followed by a TCPconnectionto the host IP addressspecifiedin the returnedre-sourcerecord, thereare somenotableexceptions. Thesefallinto two maincategories:first, thereareDNS A lookupswhicharenot driven by TCP connectionsandsecond,thereareTCPconnectionswhich arenot precededby DNS lookups. We ex-cludedboth of theseclassesof queriesfrom our analysisandsimulations.
Roughly50%of theDNS lookupsat MIT arenot associatedwith any TCP connection.We believe thatabout20%of thesecorrespondto UDP flows but unfortunately, our datadoesnotincludeany recordof UDP flows. Approximately, 15%of theseA lookupsarefor nameservers,suggestingperhapsthat thereisa disparitybetweentheTTL valuespeopleusefor A recordsasopposedto NSrecords.Also, roughly10%of all lookupsaretheresultof an incomingTCPconnection:somesystemswill do aPTR lookup for an IP addressandthenverify that the nameiscorrectby doinganA lookupfor theresultof thePTR. Finally,asmallpercentageof theselookupsarerelatedto reverseblack-listssuchasrbl.maps.vix.com . This is aservicedesignedto allow mail serversto refusemail from known spammers.
Approximately 20% of TCP connectionsfall into the sec-ond class. Here, the dominantcauseis the establishmentofftp-data connections:the LCS network hostsseveral pop-ular FTP serverswhich resultsin a fairly largenumberof out-going dataconnections.Othercausesincludehard-codedandhand-enteredaddressesfrom automatedservicesrunwithin LCSsuchasvalidator.w3.org . Finally, mail serverstypicallylookupMXinsteadof A records.
Oneof the major motivationsfor our work was the ratio ofDNS lookupsto TCPconnectionsin the wide-areaInternet,asdescribedin SectionI. Thedatain TableI (rows 9 and15) al-low usto estimatethis ratio for thetracedtraffic, astheratio ofthe numberof TCP connectionsto the numberof successfullyansweredlookupsthatareA records.Thesenumbersareshownfor eachtracein row 16, suggestinga DNS cachehit ratio (forA-records)for theMIT tracesof between80%and86%.As ex-
6
TABLE I
BASIC TRACE STATISTICS. THE PERCENTAGES ARE WITH RESPECT TO TOTAL NUMBER OF LOOKUPS IN EACH TRACE.
mit-jan00 mit-dec00 kaist-may011 Dateandplace 00/01/03-10,MIT 00/12/04-11,MIT 01/05/18-24,KAIST2 Total lookups 2,530,430 4,160,954 4,339,4733 Unanswered 595,290(23.5%) 946,308(22.7%) 873,514(20.1%)4 Answeredwith success 1,627,772(64.3%) 2,648,025(63.6%) 1,579,852(36.4%)5 Negative answer 281,855(11.1%) 545,887(13.1%) 1,834,942(42.2%)6 Zeroanswer 25,513(1.0%) 20,734(0.5%) 51,165(1.2%)7 Total iterative lookups 2,486,104 4,107,439 396,0388 Answered 1,893,882 3,166,353 239,8749 A lookupswith follow-up TCPconnections 496,802 941,081 817,93710 Totalquerypackets 6,039,582 10,617,796 5,326,52711 Distinct secondlevel domains 58,638 84,490 78,32212 Distinct fully-qualified names 263,984 302,032 219,14413 Distinct internalquerysources 221 265 40514 Distinct externalnameservers 48,537 61,776 8,11415 TCPconnections 3,619,173 4,623,761 6,337,26916 #TCP: #valid A answers 7.28 4.91 7.7517 Distinct TCPclients 978 1,216 8,60518 Distinct TCPdestinations 47,427 140,293 32,716
0
10
20
30
40
50
60
70
80
90
100
1 10 100 1000 10000
CD
FU
Latency (ms)
mit-jan00 mit-dec00
kaist-may01
Fig. 3. Cumulative distribution of DNS lookuplatency.
plainedin SectionI, this hit rateis not particularlyhigh, sinceit includesthe cachingdoneby Web browserswhenthey openmultiple connectionsto thesameserver.
IV. CLIENT-PERCEIVED PERFORMANCE
Thissectionanalyzesseveralaspectsof client-perceivedDNSperformance.We startby discussingthe distribution of time ittook clients to obtain answers. We then discussthe behaviorof theDNS retransmissionprotocolandthesituationsin whichclient lookupsreceive no answer. We alsostudythe frequencyandcausesof answersthatareerror indicationsandthe preva-lenceof negative caching. Finally, we look at interactionsbe-tweenclientsandroot/gTLD servers.
A. Latency
Figure3 shows thecumulativeDNS lookuplatency distribu-tion for our datasets. The medianis 85 ms for mit-jan00and 97 ms for mit-dec00 . Worst-caseclient latenciesbe-camesubstantiallyworse—thelatency of the90th-percentilein-creasedfrom about447 ms in mit-jan00 to about1176msin mit-dec00 . In the kaist-may01 data,about35% oflookupsreceive responsesin lessthan10 msandthemedianis42ms.TheKAIST tracehasmorelow-latency lookupsthanthe
0
10
20
30
40
50
60
70
80
90
100
1 10 100 1000 10000 100000
CD
FU
Latency (ms)
0 referral1 referral2 referrals
overall
Fig. 4. Latency distribution vs. numberof referralsfor themit-dec00 trace.
MIT tracesbecausetherequestedresourcerecordis sometimescachedatns.kreonet.re.kr , whichis closeto theprimarynameserver for the campus(seeFigure 2(b)). However, theworst50%of theKAIST distribution is significantlyworsethanthatof MIT. Many of thesedatapointscorrespondto lookupsofnamesoutsideKorea.
Latency is likely to be adverselyaffectedby the numberofreferrals. Recall that a referraloccurswhena server doesnotknow theanswerto aquery, but doesknow (i.e., thinksit knows)wheretheanswercanbefound. In thatcase,it sendsa responsecontainingoneor moreNS records,and the agentperformingthe lookup mustsenda query to oneof the indicatedservers.TableIII shows the distribution of referralsper lookup. About80%of lookupsareresolvedwithout any referral,which meansthey getananswerdirectly from theserverfirst contacted,whileonly a tiny fraction(0.03%–0.04%for MIT) of lookupsinvolvefour or morereferrals.
Figure4 shows thelatency distribution for differentnumbersof referralsfor themit-dec00 dataset.For lookupswith onereferral,60% of lookupsareresolved in lessthan100 ms andonly 7.3%of lookupstake morethan1 second.However, morethan95%of lookupstakemorethan100ms,and50%takemorethan1 second,if they involve two or morereferrals.
7
TABLE III
PERCENTAGE OF LOOKUPS INVOLVING VARIOUS NUMBERS OF REFERRALS.
THE NUMBER OF LOOKUPS USED IN THIS ANALYSIS FOR EACH TRACE IS
SHOWN IN ROW 8 OF TABLE I . THE AVERAGE NUMBER OF QUERIES TO
OBTAIN AN ANSWER, NOT COUNTING RETRANSMISSIONS, WAS 1.27, 1.2,
AND 1.2, RESPECTIVELY.
mit-jan00 mit-dec00 kaist-may010 74.62% 81.17% 86.09%1 24.07% 17.86% 10.43%2 1.16% 0.87% 2.10%3 0.11% 0.07% 0.38%VXW
0.04% 0.03% 1.00%
0
10
20
30
40
50
60
70
80
90
100
1 10 100 1000 10000 100000
CD
FU
Latency (ms)
NS cache hitNS cache miss
Fig. 5. Distributionof latenciesfor lookupsthatdoanddonot involve queryingrootservers.
To illustrate the latency benefitsof cachedNS records,weclassifyeachtracedlookupaseithera hit or amissbasedon thefirst servercontacted.Weassumeamissif thefirst querypacketis sentto oneof theroot or gTLD serversandelicits a referral.Otherwise,we assumethat thereis a hit for an NS recordin alocal DNS cache.About 70%of lookupsin theMIT tracesarehits in this sense.Figure 5 shows the latency distribution foreachcase. It shows that cachingNS recordssubstantiallyre-ducestheDNSlookuplatency eventhoughit mayinvolvesomereferralsto completethe lookup. CachedNS recordsareespe-cially beneficialbecausethey greatlyreducetheloadontherootservers.
B. Retransmissions
This sectionconsiderslookupsthat result in no answer, andlookupsthatrequireretransmissionsin orderto elicit ananswer.This is interestingbecausethetotal numberof querypacketsismuchlargerthanthetotal numberof lookups;theprevioussec-tion (andTableIII) show thattheaveragenumberof querypack-etsfor asuccessfullyansweredqueryis 1.27(mit-jan00 ), 1.2(mit-jan00 ), and1.2 (kaist-may01 ). However, theaver-agenumberof DNS querypackets in the wide-areaper DNSlookupis substantiallylargerthanthis.
We cancalculatethis ratio, Y , asfollows. Let the total num-ber of lookupsin a tracebe Z , of which [ are iteratively per-formed. This distinction is useful becauseour traceswill notshow retransmissionsgoingout to thewideareafor someof the
TABLE IV
UNANSWERED LOOKUPS CLASSIFIED BY TYPE.
mit-jan00 mit-dec00Zeroreferrals 139,405(5.5%) 388,276(9.3%)Non-zeroreferrals 332,609(13.1%) 429,345(10.3%)Loops 123,276(4.9%) 128,687(3.1%)
Z]\][ recursive lookups.Let thenumberof querypacketscor-respondingto retransmissionsof recursive lookupsbe ^ . Let_
bethetotal numberof querypacketsseenin thetrace.Then,` Za\a[cbedfYg[ih _ \j^ or Ykhmlnd ` _ \aZo\j^fb�pg[ . Thevaluesof Z , [ , and
_for thetracesareshown in rows 2, 7, and10 of
TableI.The valueof Y is relatively invariantacrossour traces:2.40
for mit-jan00 ( ^qhsr Wet uwvwx ), 2.57for mit-dec00 ( ^qhl xet�Wyugx ), and2.36for kaist-may01 ( ^zh W{Wcx|t r~}{� ). Noticethat in eachcaseY is substantiallylargerthantheaveragenum-berof querypacketsfor asuccessfullyansweredlookup.This isbecauseretransmissionsaccountfor a significantfractionof allDNS packetsseenin thewide-areaInternet.
A queryingnameserverretransmitsaqueryif it doesnotgetaresponsefrom thedestinationnameserver within a timeoutpe-riod. This mechanismprovidessomerobustnessto UDP packetlossor server failures. Furthermore,eachretransmissionis of-ten targetedat a differentnameserver if oneexists,e.g.,a sec-ondaryfor the domain. Despiteretransmissionsandserver re-dundancy, about24%of lookupsin theMIT tracesand20%ofin theKAIST tracesreceivedneitherasuccessfulanswernoranerrorindicationasshown in thethird row of TableI.
We breakthe unansweredlookupsinto threecategories,asshown in TableIV. Lookupsthat elicited zero referrals corre-spondto thosethatdid not receiveevenonereferralin response.Lookups that elicited one or more referralsbut did not leadto an eventualanswerareclassifiedasnon-zero referrals. Fi-nally, lookupsthatled to loopsbetweennameserverswherethequerieris referredto a setof two or morenameserversforminga queryingloop becauseof misconfiguredinformationareclas-sified as loops. We distinguishthe zero referrals andnon-zeroreferrals categoriesbecausetheformerallows us to isolateandunderstandtheperformanceof theDNS retransmissionmecha-nism.Wedonot reportthisdatafor kaist-may01 sincemostlookupsin that tracewererecursively resolved by a forwarderoutsidethetracepoint.
The packet load causedby unansweredqueriesis substan-tial for two reasons:first, the ratherpersistentretransmissionstrategy adoptedby many queryingnameservers,andsecond,referralloopsbetweennameservers.
On average,eachlookup that elicited zero referralsgener-atedaboutfivetimes(in themit-dec00 trace)asmany wide-areaquerypacketsbeforethequeryingnameserver gave up,asshown in Figure6. Thisfigurealsoshowsthenumberof retrans-missionsfor queriesthatwereeventuallyanswered(thecurvesat the top of the graph)—over 99.9%of the answeredlookupsincurredatmosttwo retransmissions,andover90%involvednoretransmissions.What is especiallydisturbingis that the frac-tion of suchwastedquery packets increasedsubstantiallybe-
8
0
20
40
60
80
100
0 2 4 6 8 10 12 14
CD
FU
Number of retransmissions
mit-jan00 (Answered)mit-dec00 (Answered)
mit-jan00 (Zero referral)mit-dec00 (Zero referral)
Fig. 6. Cumulative distributionof numberof retransmissionsfor answered(top-mostcurves)andunansweredlookups.
tweenJanuaryandDecember2000; in the mit-jan00 trace,theworst5% of unansweredlookupscaused6 retransmissions,while they caused12 retransmissionsin themit-dec00 trace.
Giventhat thequeriescorrespondingto theselookupsdo notelicit a response,and that mostqueriesthat do get a responsegetonewithin asmallnumber(two or three)of retransmissions,we concludethatmany DNS nameserversaretoo persistentintheir retry strategies. Our resultsshow that it is betterfor themto giveupsooner, aftertwo or threeretransmissions,andrely onclientsoftwareto decidewhatto do. Interestingly, between12%(mit-jan00 ) and19%(mit-dec00 ) of unansweredlookupsdid notseeany retransmissions.Thissuggestseitherthatthere-solverwasnotsetto retransmitor wasconfiguredwith atimeoutlongerthanthe60 secondwindow we usedin ouranalysis.
Figure7 showstheCDFsof thenumberof querypacketsgen-eratedfor the non-zero referrals and loopscategoriesof unan-sweredlookups.As expected,thenon-zeroreferrals(which donot have loops)did not generateasmany packetsasthe loops,which generatedon averageabouttenquerypackets.Althoughunansweredlookupscausedby loopscorrespondto only about4.9% and 3.1% of all lookups, they causea large numberofquerypacketsto begenerated.
This analysisshows that a large fraction of the tracedDNSpacketsarecausedby lookupsthatendupreceiving noresponse.For example,mit-dec00 included3,214,646lookupsthatre-ceived an answer;the previous sectionshowed that the aver-agesuch lookup sends1.2 query packets. This accountsfor3,857,575querypackets.However, TableI shows that thetracecontains10,617,796querypackets. This meansthat over 63%of the tracedDNS query packets were generatedby lookupsthatobtainedno answer!Thecorrespondingnumberfor mit-jan00 is 59%.Obviously, someof thesewererequiredto over-comepacket losseson Internetpaths.Typical averagelossratesare between5% and10% [6], [24]; the numberof redundantDNSquerypacketsobservedin ourtracesis substantiallyhigherthanthis.
C. NegativeResponses
As shown in TableI, between10%and42%of lookupsresultin anegativeanswer. Mostof theseerrorsareeitherNXDOMAINor SERVFAIL. NXDOMAINsignifiesthat the requestednamedoesnot exist. SERVFAIL usually indicatesthat a server is
0
20
40
60
80
100
10 20 30 40 50 60 70 80 90 100
CD
FU
Number of referrals
mit-jan00 (Non-zero referrals)mit-dec00 (Non-zero referrals)
mit-jan00 (Loops)mit-dec00 (Loops)
Fig. 7. Too many referralsof thelookupsin loops: this graphcomparescumu-lative distributionsof numberof referralsfor the lookupsthat causeloopsandthatcausenon-zero referrals.
supposedto be authoritative for a domain,but doesnot have avalid copy of the databasefor thedomain;it mayalsoindicatethattheserverhasrun out of memory.
TableV shows the ten mostcommonnamesthat resultedinNXDOMAINresponsesin the mit-jan00 and mit-dec00 .The largest causeof theseerror responsesare inverse(in-addr.arpa ) lookupsfor IP addresseswith no inversemap-pings.
For mit-jan00 , in-addr.arpa accountedfor 33,272out of 47,205distinct invalid names,and79,734of the194,963total NXDOMAINresponses.Similarly, for mit-dec00 , in-addr.arpa accountedfor 67,568out of 85,353distinct in-valid names,and250,867of the 464,761total NXDOMAINre-sponses.Othersignificantcausesfor NXDOMAINresponsesin-cludeparticularinvalid namessuchasloopback , andNSandMXrecordsthat point to namesthat do not exist. However, nosinglenameor eventypeof nameseemsto dominatetheseNX-DOMAINlookups.
SERVFAILs accountedfor 84,906of the answersin mit-jan00 (out of 4,762distinctnames)and61,498of theanswersin mit-dec00 (out of 5,102 distinct names). 3,282 of thenamesand24,170of thelookupswereinverselookupsin mit-jan00 , while 3,651of the namesand 41,465of the lookupswere inverselookups in mit-dec00 . Most of the lookupswereaccountedfor by a relatively smallnumberof names,eachlookedup a largenumberof times;presumablytheNS recordsfor thesenamesweremisconfigured.
D. NegativeCaching
In this section,we touch on the issueof negative cachingwhichwasformalizedin 1998[23]. Thelargenumberof NXDO-MAIN duplicateresponsessuggeststhat negative cachingmaynotbeworkingaswell asit couldbe. In orderto studythisphe-nomenonbetter, we analyzedtheerror responsesto understandtheir causes.A summaryof this analysisis shown in TableVI.
We do not know theactualcausefor mostof thenegative re-sponses.Many appearto be typosof correctnames.Themostclearcauseof a NXDOMAINresponseis a reverselookupfor anaddressthatdoesnot havea reversemapping.Thereareseveralothersmallbut noticeablecausesof negative answers.Reverseblack-list lookups,describedin SectionIII, make up the next
9
TABLE V
THE TEN MOST COMMON NAMES THAT PRODUCED NXDOMAINRESPONSES
IN THE MI T- J AN00 TRACE (TOP) AND THE MI T- DEC00 TRACE
(BOTTOM ). A TOTAL OF 194,963 LOOKUPS PRODUCED NXDOMAININ
MI T- J AN00 ; 47,205 DISTINCT NAMES WERE INVOLVED. A TOTAL OF
464,761 LOOKUPS PRODUCED NXDOMAININ MI T- DEC00 ; 85,353
DISTINCT NAMES WERE INVOLVED.
Lookups Namemit-jan00
7,368 loopback5,200 ns1.cvnet.com3,078 jupiter.isq.pt2,871 shark.trendnet.com.br2,268 213.228.150.38.in-addr.arpa1,913 mail.geekgirl.cx1,887 swickhouse.w3.org1,642 ns3.level3.net1,547 mickey.payne.org1,377 239.5.34.206.in-addr.arpa
mit-dec0026,308 33.79.165.208.in-addr.arpa11,503 195.70.45.111,270 195.70.35.3410,271 112.221.96.206.in-addr.arpa9,440 104.196.168.208.in-addr.arpa5,772 110.221.96.206.in-addr.arpa5,290 216.4.7.226.ehomecare.com5,235 216.4.7.227.ehomecare.com4,137 auth01.ns.u.net3,317 ns.corp.home.net
Cause mit-jan00 mit-dec00Non-existentname 82,459(42%) 150,066(32%)No reversemapfor PTR 79,725(41%) 249,236(54%)No RBL (or similar) entry 11,552(6%) 36,955(7%)Loopback 7,368(4%) 11,310(2%)Otherone-wordnames 4,785(3%) 9,718(2%)Invalid charactersin query 1,549(1%) 5,590(1%)
TABLE VI
BREAKDOWN OF NEGATIVE RESPONSES BY CAUSE AS PERCENTAGE OF
ALL NEGATIVE RESPONSES.
largestclassof queriescausingnegative responses.A numberof misconfiguredserversforwardqueriesfor the nameloop-back , insteadof handlingit locally. It might be a reasonableheuristicfor serversnever to forwardthis andotherqueriesthatdo not include multiple labelswhen resolvingqueriesfor theInternetclass.
However, we found that the distribution of namescausinganegative responsefollows a heavy tailed distribution as well.Thus,thehit rateof negativecachingis alsolimited.
TABLE VII
THE TOTAL NUMBER OF LOOKUPS THAT CONTACTED ROOT AND GTLD
SERVERS, AND THE TOTAL NUMBER OF NEGATIVE ANSWERS RECEIVED.
THE PERCENTAGES ARE OF THE TOTAL NUMBER OF LOOKUPS IN THE
TRACE.
mit-jan00 mit-dec00RootLookups 406,321(16%) 270,413(6.4%)RootNegativeAnswers 59,862(2.3%) 73,697(1.7%)gTLD Lookups 41,854(1.6%) 353,295(8.4%)gTLD NegativeAnswers 2,676(0.1%) 16,341(0.3%)
E. Interactionswith RootServers
TableVII shows thepercentageof lookupsforwardedto rootandgTLD serversandthe percentageof lookupsthat resultedin a negative answer. We observe that15%to 18% of lookupscontactedroot or gTLD serversandthepercentageslightly de-creasedbetweenJanuaryandDecember2000. This wasprob-ably causedby an increasein the popularityof popularnames(seeSectionV andFigure9), which decreasedDNS cachemissrates. The tablealsoshows that load on root servershasbeenshifted to gTLD serversover time. The gTLD serversat endof 2000 were servingmore than half of all top-level domainqueries.
Between15% and 27% of the lookups sent to root nameservers resultedin negative responses.Most of theseappearto be mis-typednames(e.g. prodiy.net ), barehostnames(e.g. loopback or loghost ), or othermistakes(e.g. in-dex.htm ). It is likely that many of theseare automaticallygeneratedby incorrectly implementedor configuredresolvers;for example,themostcommonerror loopback is unlikely tobe enteredby a user. Note that the numberof theselookupsresultingin negative answersremainsroughly the sameduring2000,but becauseof theshift to gTLDs, therelativepercentageof theselookupshasincreased.
V. EFFECTIVENESS OF CACHING
The previous sectionsanalyzedthe collectedtracesto char-acterizethe actualclient-perceived performanceof DNS. ThissectionexploresDNS performanceundera rangeof controlledconditions,usingtrace-drivensimulations.Thesimulationsfo-cuson thefollowing questionsin thecontext of A-records:
1. How useful is it to shareDNS cachesamongmany clientmachines?Theanswerto this questiondependson theex-tentto whichdifferentclientslook up thesamenames.
2. What is thelikely impactof choiceof TTL on cachingef-fectiveness?Theanswerto this questiondependson local-ity of referencesin time.
We start by analyzingour tracesto quantify two importantstatistics: (i) the distribution of namepopularity, and (ii) thedistribution of TTL valuesin the tracedata. Thesedetermineobservedcachehit rates.
A. NamePopularity andTTLDistribution
To deducehow the popularityof namesvariesin our clienttraces,weplot accesscountsasafunctionof thepopularityrank
10
1
10
100
1000
10000
100000
1e+06
1 10 100 1000 10000 100000
Acc
ess
coun
ts
Object number
full namealpha = 0.90583
(a)Full name
1
10
100
1000
10000
100000
1e+06
1 10 100 1000 10000 100000
Acc
ess
coun
ts
Object number
second level domain namealpha = 1.11378
(b) Secondlevel domainname
Fig. 8. Domainnamepopularityin themit-dec00 trace.
TABLE VIII
POPULARITY INDEX � FOR THE TAIL OF THE DOMAIN NAME
DISTRIBUTION.
mit-jan00
mit-dec00
kaist-may01
Fully-qualified 0.88 0.91 0.94Second-level 1.09 1.11 1.18
of aname,first consideringonly “fully qualifieddomainnames.”Thisgraph,onalog-logscale,is shownin Figure8(a).To under-standthebehavior of thetail of this distribution,andmotivatedby previousstudiesthatshowedthatWebobjectpopularityfol-lows aZipf-lik edistribution [11], werepresenttheaccesscountasa function �|pg��� , where � is termedthepopularity index. Ifthis is a valid form of thetail, thena straightline fit throughthetail would be a goodone,andthe negative of the slopewouldtell uswhat � is. This straightline is alsoshown in the figure,with �f���|� }|l .
We also considerwhetherthis tail behavior changeswhennames are aggregated according to their domains. Fig-ure 8(b) shows the correspondinggraph for second-level do-main names,obtainedby taking up to two labelsseparatedbydots of the name; for example, foo.bar.mydomain.comandfoo2.bar2.mydomain.com wouldbothbeaggregatedtogetherinto thesecond-level domainmydomain.com . The �for this is greaterthanone,indicatingthatthetail fallsoff a littlefasterthanin thefully qualifiedcase,althoughit is still apower-law. Theslopescalculatedusinga least-squarefit for eachtraceareshown in TableVIII. 1
Figure9 illustratestheextentto which lookupsareaccountedfor by popularnames. The ^ -axis indicatesa fraction of themostpopulardistinct names;the � -axis indicatesthe cumula-tive fraction of answeredlookupsaccountedfor by the corre-sponding mostpopularnames.For example,themostpopular10% of namesaccountfor morethan68%of total answersfor�
Wecalculatedtheleast-squarestraightline fit for all pointsignoringthefirsthundredmostpopularnamesto moreaccuratelyseethetail behavior.
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
Fra
ctio
n of
req
uest
s
Fraction of query names
mit-jan00 mit-dec00
kaist-may01
Fig. 9. Cumulative fractionof requestsaccountedfor by DNSname,mostpop-ular first. Thepopularnamesappearto have becomeevenmorepopularinDecember2000comparedto January2000,althoughthey arenot necessar-ily thesamenames.
0
10
20
30
40
50
60
70
80
90
100
1 10 100 1000 10000 100000
CD
FU
TTL (sec)
1 day
1 hour
ANS
Fig. 10. TTL distribution in themit-dec00 trace.
eachof the threetraces.However, it alsohasa long tail, andalargeproportionof namesthatareaccessedpreciselyonce.Forinstance,out of 302,032distinct namesinvolved in successfulA lookupsin mit-dec00 , therewere138,405uniquenamesaccessedonly once,whichsuggeststhata significantnumberofroot querieswill occurregardlessof thecachingscheme.
Figure 10 shows the cumulative distribution of TTL valuesfor A andNSrecords.NSrecordstendto havemuchlongerTTL
11
0
10
20
30
40
50
60
70
80
90
100
1 10 100 1000 10000 100000
CD
FU
TTL (sec)
5 minutes
15 minutes
1 hour
1 daymit-jan00mit-dec00
kaist-may01
Fig. 11. TTL distribution weightedby accesscountsfor mit-jan00 , mit-dec00 andkaist-may01 traces.
valuesthanA records.Thishelpsexplainwhyonly about20%ofDNSresponses(includingbothreferralsandanswersin TableI)comefrom arootor gTLD server. If NS recordshadlowerTTLvalues,essentiallyall of theDNS lookuptraffic observedin ourtracewould have goneto a root or gTLD server, which wouldhave increasedtheloadon themby a factorof aboutfive. GoodNS-recordcachingis thereforecritical to DNS scalability.
Figure 10 shows how TTL valuesare distributed, but doesnot considerhow frequentlyeachnameis accessed.If it turnsout (as is plausible)that the morepopularnameshave shorterTTL values,thenthecorrespondingeffect on cachingwould beevenmorepronounced.Figure11showstheTTL distributionofnames,weightedby the fraction of TCP connectionsthatweremadeto eachname. We show this for both mit-jan00 andmit-dec00 , anddraw two key conclusionsfrom this. First, itis indeedthe casethat shorter-TTL namesaremorefrequentlyaccessed,which is consistentwith the observation that DNS-basedload-balancing(the typical reasonfor low TTL values)makessenseonly for popularsites.Second,the fractionof ac-cessesto relatively short(sub-15minute)TTL valueshasdou-bled(from 12%to 25%)in 2000from oursite,probablybecauseof theincreaseddeploymentof DNS-basedserverselectionandcontentdistribution techniquesduring2000.
B. Trace-drivenSimulationAlgorithm
To determinethe relative benefitsof per-client and sharedDNS cachingof A-records,we conducteda tracedriven simu-lationof cachebehavior underdifferentaggregationconditions.First, we pre-processedthe DNS answersin the traceto formtwo databases.The“namedatabase”mapsevery IP addressap-pearingin an A answerto thedomainnamein the correspond-ing lookup. The “TTL database”mapseachdomainnametothe highestTTL appearingin an A recordfor thatname.Afterbuilding thesedatabases,thefollowing stepswereusedfor eachsimulationrun.
1. Randomlydivide the TCP clients appearingin the traceinto groupsof size � . Give eachgroup its own simulatedsharedDNS cache,asif thegroupshareda singleforward-ing DNSserver. Thesimulatedcacheis indexedby domainname,and containsthe (remaining)TTL for that cachedname.
2. For each new TCP connectionin the trace, determine
0
20
40
60
80
100
10 20 30 40 50 60 70 80 90 100
Hit
rate
(%
)�
Group size
mit-jan00 mit-dec00
kaist-may01
Fig. 12. Effect of thenumberof clientssharingacacheoncachehit rate.
which client is involved by looking at the “inside” IP ad-dress;let that client’s groupbe � . Use the outsideIP ad-dressto index into the namedatabaseto find the domainname� thattheclientwouldhavelookedupbeforemakingtheTCPconnection.
3. If � exists in � ’s cache,and the cachedTTL hasnot ex-pired,recorda “hit.” Otherwise,recorda “miss.”
4. On a miss,make anentry in � ’s cachefor � , andcopy theTTL from theTTL databaseinto the � ’s cacheentry.
At theendof eachsimulationrun, thehit rateis thenumberof hits dividedby thetotal numberof queries.
This simulationalgorithmis driven by the IP addressesob-served in the traced TCP connections,rather than domainnames,becauseDNS queriesthathit in local cachesdo not ap-pear in the traces. This approachsuffers from the weaknessthat multiple domainnamesmay mapto the sameIP address,assometimesoccursat Web hostingsites. This maycausethesimulationsto overestimatethe DNS hit rate. The simulationalsoassumesthateachclient belongsto a singlecachinggroup,which maynot betrueif a clientusesmultiple local forwardingDNS servers. However, becauseDNS clients typically queryservers in a strictly sequentialorder, this may be a reasonableassumptionto make.
C. Effectof SharingonHit Rate
Figure12 shows the hit ratesobtainedfrom the simulation,for a rangeof differentcachinggroupsizes.Eachdatapoint istheaverageof four independentsimulationruns. With a groupsizeof 1 client (no sharing),the averageper-connectioncachehit rateis 71%for mit-dec00 . At theoppositeextreme,if all1,216tracedclientssharea singlecache,theaveragehit rateis89%for mit-jan00 . However, mostof thebenefitsof sharingareobtainedwith asfew as10 or 20 clientspercache.
The fact that domainnamepopularityhasa Zipf-lik e distri-butionexplainstheseresults.A smallnumberof namesareverypopular, andeven small degreesof cachesharingcantake ad-vantageof this. However, the remainingnamesare large innumberbut areeachof interestto only a tiny fractionof clients.Thusverylargenumbersof clientsarerequiredbeforeit is likelythat two of them would wish to look up the sameunpopularnamewithin its TTL interval. Most cacheablereferencestothesenamesarelikely to besequentialreferencesfrom thesameclient, which areeasilycapturedwith per-client cachesor even
12
theper-applicationcachesoftenfoundin Webbrowsers.
0
20
40
60
80
100
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Hit
rate
(%
)�
TTL (sec)
group size = 1group size = 25
group size = 978
(a)mit-jan00
0
20
40
60
80
100
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Hit
rate
(%
)�
TTL (sec)
group size = 1group size = 25
group size = 1216
(b) mit-dec00
0
20
40
60
80
100
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000
Hit
rate
(%
)�
TTL (sec)
group size = 1group size = 25
group size = 8605
(c) kaist-may01
Fig. 13. Impactof TTL onhit rate.
D. Impactof TTLon Hit Rate
The TTL valuesin DNS recordsaffect cacheratesby lim-iting the opportunitiesfor reusingcacheentries. If a name’sTTL is shorterthanthe typical inter-referenceinterval for thatname,cachingwill notwork for thatname.Oncea name’sTTLis significantlylongerthantheinter-referenceinterval, multiplereferencesarelikely to hit in thecachebeforetheTTL expires.Therelevantinterval dependsonthename’spopularity:popularnameswill likely becachedeffectivelyevenwith shortTTL val-ues,while unpopularnamesmaynot benefitfrom cachingeven
with very long TTL values.In turn,a name’spopularityamongagroupof clientsthatshareacacheis to someextentdeterminedby thenumberof clientsin thegroup.
To gaugethe effect of TTL on DNS cachehit rate,we per-form simulationsusing a small modificationto the algorithmdescribedin SectionV-B. Insteadof usingTTL valuestakenfrom the actualDNS responsesin the traces,thesesimulationssetall TTL valuesto specificvalues. Figure13 shows the re-sults,with onegraphfor eachof the threetraces. Eachgraphshowsthehit rateasafunctionof TTL. Sincetheresultsdependon thenumberof clientsthatshareacache,eachgraphincludesseparatecurvesfor per-client caches,groupsof 25 clientspercache,andonecachesharedamongall clients. We usea groupof size25 becauseSectionV-C showedthat for theactualTTLdistribution observedin our traces,a groupsizeof 25 achievesessentiallythe samehit-rateasthe entireclient populationag-gregatedtogether.
As expected,increasingTTL valuesyield increasinghit rates.However, theeffectonthehit rateis noticeableonly for TTL val-ueslessthanabout1000seconds.Mostof thebenefitof cachingis achievedwith TTL valuesof only asmallnumberof minutes.This is becausemostcachehits areproducedby singleclientslooking up thesameserver multiple timesin quick succession,a patternprobablyproducedby Web browsersloading multi-ple objectsfrom thesamepageor usersviewing multiple pagesfrom thesameWebsite.
A simple model helps formalize this intuitive explanation.Supposethereare � distinctnames(or IP addresses,assumingthatthey areone-to-one)observedin atracein whichthereare �TCPconnectionsin all. Supposeall nameshave thesameTTL,�
. As time progresses,lookupsaremadeprior to TCPconnec-tions at varioustimesaccordingto the connectioninter-arrivaldistribution. If thecacheis emptyat time 0, andonelooksat atime window of duration
�, the missrateis equalto � � . What
we show is that if � is themeaninter-arrival time betweentwoconsecutiveconnectionsto thesameIP addressin thetrace,thenthemissrateis equalto �� .
By definition, ��h�� ��C��� � � � � where � � is the probability ofa connectionin the tracegoing to IP address¡ , and � � is theaverageinter-arrival time betweenconnectionsto address¡ . If� � is theexpectednumberof connectionsin thetracethatwentto address¡ , then � � h¢� � p£� . Therefore�¤h¥� ��C��� �w¦ � ¦� .
Now,� hz� � � � , which implies that �§h¨� ��C��� � �©h � �� .
This impliesthatthemissrate, � � is in factequalto �� .This suggeststhat the missrate is an increasingfunction of
the averageinter-arrival time betweenconnectionsto the sameIP address,where the averageis computedacrossthe entiretraceweightedby the numberof appearancesof eachaddress.Figure14 shows the cumulative distribution for outgoingTCPconnectioninter-arrivals—it is a heavy-tailed Paretodistribu-tion and hasan “infinite” mean. The dotted line is ª ` �«b�hl¬�~� ` l\ ®¯�°¬±�² ³ � b which is fitted to the underlyingdataset. Inthreecases,� is lessthan1 andtherefore,theexpectationof aninter-arrival requestdurationis unbounded.What this meansisthat essentiallyall hits in the cachearrive in closesuccession,andaretypically generatedwhenbrowsersinitiatemultiplecon-nectionsto anaddress.
Theseresultssuggestthatgiving low TTL valuesto A records
13
0
10
20
30
40
50
60
70
80
90
100
1 10 100 1000 10000 100000 1e+06 1e+07 1e+08 1e+09
CD
F´
Interarrival time (ms)
mit-jan00F(x)
(a)mit-jan00 ( �¶µ¸·º¹ » ¼º½�¾¿µj» » ¼ )
0
10
20
30
40
50
60
70
80
90
100
1 10 100 1000 10000 100000 1e+06 1e+07 1e+08 1e+09
CD
F´
Interarrival time (ms)
mit-dec00F(x)
(b) mit-dec00 ( �¶µ¸·º¹ » Àº½�¾¿µ¸Á5Â÷ )
0
10
20
30
40
50
60
70
80
90
100
1 10 100 1000 10000 100000 1e+06 1e+07 1e+08 1e+09
CD
F´
Interarrival time (ms)
kaist-may01F(x)
(c) kaist-may01 ( �¶µj·º¹ ¼5£½.¾Äµ¸Å » )Fig. 14. Cumulative distributionsfor TCPconnectioninter-arrivals.
will not significantlyharmhit rates.Thus,for example,the in-creasinglycommonpracticeof usinglow TTL valuesin DNS-basedserverselectionprobablydoesnot affecthit ratesmuch.
In general,cachingof A recordsappearsto have limited ef-fectivenessin practiceand in potential. Even eliminating allA-recordcachingwould increasewide-areaDNS traffic by atmosta factorof four, almostnoneof which would hit a root orgTLD server. Eliminatingall but per-client cachingwould littlemorethandoubleDNStraffic. Thisevidencefavorsrecentshiftstowardsmoredynamic(andlesscacheable)usesof DNS, suchasmobile host location trackingandsophisticatedDNS-basedserverselection.
Thediscussionaboveappliesto A-records,specificallyfor A-recordsfor namesthat do not correspondto nameservers fordomains.It is not a goodideato make the TTL valueslow onNS-records,or for A-recordsfor nameservers.On thecontrary,doingsowould increasethe loadon theroot andgTLD serversby abouta factorof fiveandsignificantlyharmDNSscalability.
VI . CONCLUSION
Thispaperhaspresenteda detailedanalysisof tracesof DNSandassociatedTCPtraffic collectedon theInternetlinks of theMIT Laboratoryfor ComputerScienceandtheKoreaAdvancedInstitute of ScienceandTechnology. We analyzedthe client-perceived performanceof DNS, including the latency to re-ceiveanswers,theperformanceof theDNS protocol,thepreva-lenceof failuresanderrors,andtheinteractionswith root/gTLDservers.We conductedtrace-drivensimulationsto studytheef-fectivenessof DNS cachingasa functionof TTL anddegreeofcachesharing.
A significant fraction of lookups never receive an answer.Further, DNSserver implementationscontinueto beoverly per-sistentin thefaceof failures.While mostsuccessfulanswersarereceived in at most2–3 retransmissions,failurestodaycauseamuchlargernumberof retransmissionsandthuspacketsthattra-versethewide-area.For instance,in themostrecentMIT trace,23% of lookupsreceive no answer;theselookupsaccountformorethanhalf of all tracedDNS packetsin thewide-areasincethey areretransmittedquitepersistently. In addition,about13%of all lookupsresult in a negative response.Many of thesere-sponsesappearto be causedby missing inverse(IP-to-name)mappingsor NSrecordsthatpoint to non-existentor inappropri-atehosts.We alsofoundthatover a quarterof thequeriessentto therootnameserversresultin suchfailures.
Our trace-drivensimulationsyield two findings.First, reduc-ing theTTLs of address(A) recordsto aslow asa few hundredsecondshaslittle adverseeffect on hit rates.Second,little ben-efit is obtainedfrom sharinga forwardingDNS cacheamongmorethan10 or 20 clients. This is consistentwith the heavy-tailednatureof accessto names.This suggeststhat theperfor-manceof DNS is not asdependenton aggressive cachingasiscommonlybelieved, and that the widespreaduseof dynamic,low-TTL A-record bindings should not degradeDNS perfor-mance. The reasonsfor the scalability of DNS are due lessto the hierarchicaldesignof its namespaceor goodA-recordcaching(asseemsto bewidely believed);rather, thecacheabil-ity of NS-recordsefficiently partitionthenamespaceandavoidoverloadingany singlenameserver in theInternet.
ACKNOWLEDGMENTS
Wearegratefulto GarrettWollmanandMary Ann Ladd,whorun thenetwork infrastructureat MIT LCS, for facilitating thiscollection processand for their prompt help at varioustimes.We thank Dorothy Curtis for help with datacollection. Thisstudywould not have beenpossiblewithout thecooperationofthe LCS and AI Lab communitiesat MIT. We are grateful toHeonkyu Park and Taejin Yoon who helpedcollect tracesatKAIST. We thankSarahAhmedandDavid Andersenfor use-ful discussions,Nick Feamsterfor several commentson draftsof this paper, andJenniferRexford for helpful suggestions.
14
REFERENCES
[1] P. Danzig,K. Obraczka,andA. Kumar, “An Analysisof Wide-AreNameServer Traffic: A Studyof the InternetDomainNameSystem,” in ProcACM SIGCOMM, Baltimore,MD, Aug. 1992,pp.281–292.
[2] A. SnoerenandH. Balakrishnan,“An End-to-EndApproachto HostMo-bility,” in Proc.6th ACM MOBICOM, Boston,MA, Aug. 2000,pp.155–166.
[3] J. Loughney andJ. Yu, RoamingSupportwith DNS, July 2000, Internet-Draft draft-loughney-enum-roaming-00.txt; expiresJanuary2001.Avail-able from http://www.ietf.org/internet-drafts/draft-loughney-enum-roaming-00.txt .
[4] K. Frazer, “NSFNET: A Partnership for High-SpeedNetworking,”http://www.merit.edu/merit/archive/nsfnet/fina l.report/ , 1995.
[5] K. Thompson,G. Miller, and R. Wilder, “Wide-areaTraffic PattternsandCharacteristics,” IEEE Network, vol. 11, no. 6, pp. 10–23,Novem-ber/December1997.
[6] H. Balakrishnan,V. Padmanabhan,S. Seshan,M. Stemm,andR. Katz,“TCP Behavior of a Busy WebServer: AnalysisandImprovements,” inProc. IEEE INFOCOM, SanFrancisco,CA, Mar. 1998,vol. 1, pp. 252–262.
[7] P. Mockapetris, Domain Names—Conceptsand Facilities, Nov. 1987,RFC1034.
[8] P. Mockapetris,Domainnames—ImplementationandSpecification, Nov.1987,RFC1035.
[9] P. MockapetrisandK. Dunlap, “Developmentof theDomainNameSys-tem,” in Proc.ACM SIGCOMM, Stanford,CA, 1988,pp.123–133.
[10] A. Kumar, J. Postel,C. Neuman,P. Danzig,andS. Miller, CommonDNSImplementationErrorsandSuggestedFixes, Oct.1993,RFC1536.
[11] L. Breslau,P. Cao,L. Fan,G. Phillips, andS. Shenker, “On the implica-tionsof Zipf ’s law for webcaching,” TechnicalReportCS-TR-1998-1371,Universityof Wisconsin,Madison,Apr. 1998.
[12] M. CrovellaandA. Bestavros,“Self-similarity in WorldWideWebTraffic:EvidenceandPossibleCauses,” IEEE/ACM Transactionson Networking,vol. 5, no.6, pp.835–846,Dec.1997.
[13] A. Wolman,G. Voelker, N. Sharma,N. Cardwell,A. Karlin, andH. Levy,“On thescaleandperformanceof cooperative webproxycaching,” in 17thACM SOSP, KiawahIsland,SC,Dec.1999,pp.16–31.
[14] A. Shaikh,R. Tewari, andM. Agrawal, “On the Effectivenessof DNS-basedServer Selection,” in Proc.IEEE INFOCOM, April 2001.
[15] C. Wills and H. Shang, “The Contribution of DNS Lookup CoststoWeb Object Retrieval,” Tech. Rep. TR-00-12, WorcesterPolytechnicInstitute, July 2000, http://www.cs.wpi.edu/˜cew/papers/tr00-12.ps.gz .
[16] E. CohenandH. Kaplan, “Proactive Cachingof DNS Records:Address-ing a PerformanceBottleneck,” in Proc. Symp.on Applicationsand theInternet(SAINT), SanDiego,CA, January2001.
[17] C. HuitemaandS.Weerahandi,“InternetMeasurements:theRisingTideandtheDNSSnag,” in 13thITC SpecialistSeminar, Sept.2000.
[18] N. Brownlee,kc claffy, andE. Nemeth, “DNS Measurementsat a RootServer,” in 15thUSENIXSystemsAdministration Conference, Dec.2001.
[19] N. Brownlee,kc claffy, andE. Nemeth, “DNS Root/gTLD PerformanceMeasurements,” in Proc.GlobeCom, Nov. 2001.
[20] R. Rivest,TheMD5 Message-DigestAlgorithm, April 1992,RFC1321.[21] G. Minshall, “Tcpdpriv,” http://ita.ee.lbl.gov/html/
contrib/tcpdpriv.html , Aug. 1997.[22] V. Jacobson,C. Leres,and S. McCanne, “tcpdump,” http://www.
tcpdump.org/ .[23] M. Andrews, NegativeCaching of DNSQueries(DNSNCACHE), Mar.
1998,RFC2308.[24] V. Paxson, “End-to-EndInternetPacket Dynamics,” in Proc. ACM SIG-
COMM, Cannes,France,Sept.1997,pp.139–152.