prexopendns

ContentRetrievalusingCloud-basedDNSRavishKhosla,SoniaFahmy,Y.
CharlieHuPurdueUniversityEmail:{rkhosla,fahmy,ychu}@purdue.
eduAbstract—Cloud-computingsystemsarerapidlygainingmo-mentum,providingexiblealternativestomanyservices.
WestudytheDomainNameSystem(DNS)service,usedtoconverthostnamestoIPaddresses,whichhashistoricallybeenprovidedbyaclient'sInternetServiceProvider(ISP).
Withtheadventofcloud-basedDNSproviderssuchasGoogleandOpenDNS,clientsareincreasinglyusingtheseDNSsystemsforURLandothernameresolution.
Performancedegradationwithcloud-basedDNShasbeenreported,especiallywhenaccessingcontenthostedonhighlydistributedCDNslikeAkamai.
Inthiswork,weinvestigatethisproblemindepthusingAkamaiasthecontentproviderandGoogleDNSasthecloud-basedDNSsystem.
Wedemonstratethattheproblemisrootedinthedisparitybetweenthenumberandlocationofserversofthetwoproviders,anddevelopanewtechniqueforgeolocatingdatacentersofcloudproviders.
Additionally,weexplorethedesignspaceofmethodsforcloud-basedDNSsystemstobeeffective.
Client-side,cloud-side,andhybridapproachesarepresentedandcompared,withthegoalofachievingthebestclient-perceivedperformance.
OurworkyieldsvaluableinsightintoAkamai'sDNSsystem,revealingpreviouslyunknownfeatures.
I.
INTRODUCTIONTheDomainNameSystem(DNS)[13]–mostlyusedtoconvertnamestoIPaddresses–isanintegralserviceintheInternet.
ThenameresolutionservicehasbeentraditionallyofferedbyInternetServiceProviders,withserversclosetotheclient[9](referredtoaslocalDNS).
DNSisoftenusedbyContentDistributionNetworks(CDNs)toredirectclientstothenearestdatacenter[11],[17].
Hence,whenthelocalDNSserverqueriesCDNssuchasAkamaitoidentifycontentservers,theCDNsreturnserversclosetothelocalDNS,whichinmostcasesiscloseenoughtotheclient.
Withtheemergingtrendofcloudcomputing,ahostofservicesincludingDNSarebeingofferedbythecloud,e.
g.
Google[6]andOpenDNS[15].
ThesecloudDNSservicesnotonlyprovidefastDNSresolutionduetolargercaches,butmayalsoprovidesecuritybenets,protectingagainstDNScachepoisoningandDenial-of-Service(DoS)attacks[6].
However,therecanbepotentiallyhighlatenciesbetweentheclientandtheresolvedservers,degradingclientperformance[1].
ThiseffectispronouncedwhenobtainingserversforahighlydistributedCDNsuchasAkamai.
Huangetal.
[9]estimatethattheserverlatencyincreasesbyasmuchas193msatthe95thpercentilewhenusingcloud-basedDNSsystems,comparedtolocalDNS.
Thisisunacceptable,especiallysinceAkamai'snetworkisoftenusedforstreamingvideo.
Akamaiisthedominantcontentprovider,deliveringbe-tweenfteenandthirtypercentofallWebtrafc,reachingmorethan4Terabitspersecond[2].
ThismakestheproblemofremoteAkamaicontentserversreturnedbyusingcloud-basedDNSsystemscritical.
Inthispaper,weinvestigatethisproblemwithacasestudyofAkamai-hostedcontentasaccessedbyclientsusingGoogleDNS.
WerstgeolocatetheGoogleDNSandAkamaiservers.
OneofthekeychallengeswefaceisthatGoogleDNSusesIPanycastandhencethelocationofitsservershostedatGoogledatacenterscannotbefoundusingsimpleIPgeolocation.
WethereforedevelopanoveltechniqueforgeolocatingGoogledatacenters,andndthatGoogle'sDNSserversoftentimesdonotseeclosebyAkamaiservers.
WealsondthattheGoogleDNSserversareplacedmoresparselyaroundtheworldthanAkamai'sservers,yieldingpoorclientperformancewhenaccessingAkamai'scontentusingGoogleDNS.
Wethenpresentandcomparealternativesolutionstotheproblem.
Wepositthatcooperationamongcloudproviders,thosewhichhostcontentandthosewhichhostDNSser-vices,isthebestsolution.
However,intheabsenceofsuchcooperation,wedesignahybridclient-cloudapproachwhichqueriesspecicAkamainameserverswhoseIPaddresshasbeenfoundusingcloudDNS.
WendthattheserversreturnedbythishybridapproachareusuallythesameasthosereturnedbylocalDNS,preservingtheperformanceadvantageoflocalDNS.
OurresultsalsoshedlightontoAkamai'snetwork,demonstratingthatAkamai'sDNSserversdorespondtoqueriesevenwhenaskedoutofturn,albeitafterapotentialdelay.
Thecontributionsofourpaperinclude:Wepresentanovel,lightweightgeolocationtechniqueforlocatingclouddatacenters(SectionII-B).
Weuseourgeolocationtechniquetogaininsightintotheproblemofpoorclientperformanceinaccessingcontentthroughcloud-basedDNS(SectionIV).
Weproposeandcomparesolutionstothisproblem(Sec-tionV).
Wealsopresentahybridclient-cloudapproachthataclientcanuseintoday'sInternet.
Therestofthepaperisorganizedasfollows.
SectionIIprovidesanoverviewofDNSsystemsofAkamaiandGoogle.
SectionIIIdenestheproblemwhileSectionIVinvestigatesthecausesofthisproblem.
WecomparevarioussolutionstotheprobleminSectionV.
WesummarizerelatedworkinSectionVIandconcludeinSectionVII.
II.
CLOUD-BASEDDNSSYSTEMSWenowstudyDNSsystemsoftwodifferentkindsofclouds:Akamai'sCDNandGoogle'sDNS.
2A.
AkamaiDNSPrimerAkamaiusestwolevelsofDNSserverstoredirectclientstotheclosestcontentserver[17].
WeuseanexampleofaniterativeDNSquerytoillustratethestepsinvolved(Figure1).
SupposeaclientqueriesitslocalDNSforvideos.
buy.
com.
EitherthelocalDNSknowstheanswerfromitscache,oritqueriestoplevelandAkamaiDNSserversandreturnsthecanonicalname(CNAME)videos.
buy.
com.
edgesuite.
net.
TheclientthenqueriesthelocalDNSforthisCNAMEandreceivesanotherCNAMEa1507.
b.
akamai.
net.
Wenowusethecommanddig+trace[5]fromtheclienttofollownameserverreferralsduringresolution,whileeliminatingcaching.
Theclientqueriesthetopleveldomainserverj.
root-servers.
netfora1507.
b.
akamai.
net,whichreturnsalistofnameserversoutofwhichtheclientchoosesc.
gtld-servers.
netandqueriesit,whichgivesalistofAkamai'stoplevelnameservers.
Theclientchooseszh.
akamaitech.
netforqueryinthenextstep,whichreturnsAkamaisecondlevelnameserverswhoseIPaddressisdependentupontheclient'slocation(i.
e.
,proximity-aware).
Overall,thereareninesecondlevelnameserversforthisCNAME,fromn0b.
akamai.
netton8b.
akamai.
net.
Theclientthenchoosesn3b.
akamai.
net,queryingitfora1507.
b.
akamai.
netandobtainsthecontentserver149.
165.
180.
191.
Fig.
1.
StepstakenbyaclientinobtainingcontentserverforanAkamai-hostedwebsiteInourexperiments,westartwithknownAkamaiCNAMEslikea1507.
b.
akamai.
netandobservewhetherchangingthenumber(1507)ortheletter(b)givesusaCNAMEwhichresolvestoanAkamaicontentserver.
Thenumbercorrespondstoachannel[23],whereasthelettercorrespondstothewaychannelsaregrouped.
Usingtheabovetechnique,wediscoverelevenAkamaiCNAMEcategories,listedinTableIwiththeirrespectivenameservers.
Wendthatforeachofthe1WhileAkamaiusuallyreturnstwocontentserversforeachquery,weusetherstoneinthispaper.
categories,channelnumbers0to4094leadtovalidCNAMEs,whichmaptoedgeserversIPswithinthesameClassCsubnetor/24prex.
Sincethereareatmost256IPsinaClassCsubnet,theaveragenumberofchannelsmappingtoanedgeserverisabout16,possiblyforloadbalancingpurposes[23].
TABLEIAKAMAICNAMESSTUDIEDINTHISPAPERWITHTHEIRRESPECTIVENAMESERVERSCNAMEcategoryNameserversx=0to4094,y=0to8forallrowsunlessspeciedotherwisea{x}.
b.
akamai.
netn{y}b.
akamai.
neta{x}.
c.
akamai.
netn{y}c.
akamai.
neta{x}.
f.
akamai.
netn{y}f.
akamai.
neta{x}.
h.
akamai.
netn{y}h.
akamai.
neta{x}.
k.
akamai.
netn{y}k.
akamai.
neta{x}.
l.
akamai.
netn{y}l.
akamai.
neta{x}.
p.
akamai.
netn{y}p.
akamai.
neta{x}.
vmg0.
akastream.
netn{y}vmg0.
akastream.
nety=0to6a{x}.
vmg2.
akastream.
netn{y}vmg2.
akastream.
nety=0to6a{x}.
uqg0.
kamai.
netn{y}uqg0.
kamai.
nety=0to6a{x}.
gi3.
akamai.
netn{y}gi3.
akamai.
netB.
GeolocatingServersintheCloudExtensiveresearchexistsongeolocatingIPaddressesintheInternet[14](adetaileddiscussionofwhichisoutsidethescopeofthispaper).
Inthispaper,weusethecommercialgeolocationtoolGeoIPCityprovidedbyMaxMind[12]togeolocateIPaddresses,whichisaccurateupto25miles.
Usingthisservice,wecaneasilygeolocateAkamaicontentserversandnameserverswithreasonableaccuracy.
Forexample,inFigure1,wegeolocatetheend-server149.
165.
180.
19toBloomington,Indiana,whichisfoundtobe85milesawayfromourclientIPwithaGeo-RTT[10]of1ms,whichmatchesthemeasuredRTTof1.
5ms.
However,GoogleDNS[6]usesIPanycastandbothofitsDNSIPaddressesresolvetoMountainView,California.
ThisdemonstratesthedifcultyofgeolocatingGoogle'sdatacenters,whichhostGoogleDNSservers[4].
Oneofthesolutionstothisproblemispresentedin[9],whichrequiresaninfrastructuresetupandispassive,waitingforclientstovisitapopularwebsite.
Incontrast,wedesignanovellightweightactivetechniqueforgeolocatingGoogledatacenters.
Werun1000traceroutes(runningfor12hours)totheGooglePublicDNSIP8.
8.
8.
8from575PlanetLab[19]nodes.
WedeneVGDNS,whichistheVirtualGoogleDNSIP,asthelasthoprightbeforetheGoogleDNSIPinthetraceroutes.
WeverifythattheseIPsindeedbelongtoGoogleusingBGProutingtablesfromRouteViews[24].
WecollectallsuchVGDNSIPsacrossthetraceroutesfromPlanetLabnodesandobtain1477uniqueIPaddresses,with46uniquelocations.
TogeolocateGoogledatacenters,weusehierarchicalclusteringalgorithms[26]toclusterthe46uniqueVGFElocationsusingMatlab.
WecomputethedistancebetweentwolocationsusingHaversineFormula[22].
andclusterthemusingthe3agglomerativecompletelinkclusteringtechnique[26],using50milesasthecutoffdistancebetweenclusters.
SincetheaccuracyofMaxMindis25miles,twoIPsatthesamelocationcanbenomorethan50milesapart.
Thisgives40clustersoutofthe46uniquelocations.
Intheabsenceofgroundtruth,thisnumbercannotbevalidated.
However,itissufcientforexplainingthecloudinteractionsinthispaper(SectionIV).
ForlocatingAkamaidatacenters,wegeolocatethecontentserversobtainedbyPlanetLabclients,astheyresolve11randomAkamaiCNAMEs(oneeachfromeachrowofTableI)throughlocalaswellascloud-basedDNS(1000iterationseach).
Weobtain3223uniqueIPaddresses,whichgeolocateto260uniquelocationsand123clusters.
WepointoutthattwoidenticalexperimentsuncoveraboutthreetimesasmanyAkamaidatacentersasGoogle,indicatingmoreextensivepresenceofAkamai,comparedtoGoogle.
III.
THEPROBLEMTheproblemweareinvestigatinginthisworkisthehighlatencytotheAkamaicontentserversthataclientisredirectedtowhenusingcloud-basedDNSsystems.
Figure2illustratesanexampleoftheproblem.
WeusetheCNAMEa1507.
b.
akamai.
net(SectionII-A),andresolveitusinglocalDNSandGoogleDNS.
Wechooseacasewherebothreso-lutionsseemtoproceedexactlythesameasfarastheDNSservernamesareconcerned.
However,asFigure2shows,theactualserverIPaddressesandtheirlatenciesfromtheclientaredifferent,withtheGoogleDNSsufferingbecauseAkamaireturnstheIPaddressesofthenameserverandcontentserverwhichareclosetotheGoogledatacenter.
Thisproblemhasbeendocumentedin[1],[9].
WenowquantitativelydemonstratetheexistenceofthehighlatencyAkamaiserverstotheclientwhencloud-basedDNSisused.
AsmentionedinSectionII-A,eachofthe4095CNAMEsinacategoryofTableImapto256contentserverswithinthesame/24prex.
WerandomlyselectnCNAMEssuchthatweexpecttoseeall256edgeservers,withntobedetermined.
Thisproblemisequivalenttoball-selectionproblem,whichhasbeensolvedin[21]and,usingtheirresultinourcontext,wendn=1568.
AddinginthecaseswithknownCNAMEs,(e.
g.
a1507.
b.
akamai.
netforvideos.
buy.
com),weobtain1571CNAMEspercategoryofTableI,whichweuseforallexperimentsbelow.
WeprobetheCNAMEsusingthelocalDNSofeachofthe575PlanetLabnodesandthenusingGoogleDNS.
WemeasurethequalityofserversreturnedbypingingtheserverswiththreeICMPechorequestpacketsandnotingtheminimumRTT,whichreducesRTTinationduetonetworkcongestiontoacertainextent.
Weusethistechniqueforlatencymeasurementthroughoutthispaper.
ForeachCNAMEcategory,wecomputethemeandifferenceinlatencybetweentheclientandtheserverresolvedthroughcloud-basedDNSandlocalDNS,consideringthedifferentservercasesonly.
ThismeanlatencyinationisaveragedacrossallCNAMEcategoriesandthenacrossallnodes.
Ourresultsshowthattheaveragelatencyinationis14.
15msforGoogleDNS,whichis720.
5%in(a)ResolutionthroughlocalDNS,indicatingIPsandtheRTTsfromclient(b)ResolutionthroughGoogleDNS,indicatingIPsandtheRTTsfromclientFig.
2.
ComparisonofDNSlookupofa1507.
b.
akamai.
netthroughlocalDNSandGooglePublicDNSpercentageterms.
Whiletheabsolutelatencyinationnumbersdonotseemextremelylarge,theyaresignicantforvideostreaminganddynamiccontentapplications.
WeplottheCDFoflatencyandpercentagelatencyinationforatypicalCNAMEinFigure3.
TheCDFiscomputedwithonedatapointperPlanetLabnode.
Thereareafewcasesforwhichtheinationisnegative.
However,suchcasesareinfrequentandarelikelycausedbylargedistancesbetweentheclientandlocalDNS[9].
Theresultsalsoshowthatthelatencyinationhasaheavytail.
Whiletheaverageinationisaround15ms,around17%oftheclientsexperienceinationofmorethan1000%.
IV.
CAUSESToidentifythecausesoflatencyination,for1000it-erationsrunfromPlanetLabnodes,werecordthenodeIPC,VGDNSIPG,andtheAkamaiserverIPcorrespondingtoCNAMEa1507.
b.
akamai.
net,obtainedthroughlocalDNS(serverA)andthroughGoogleDNS(serverA′).
WethengeolocatethesefourIPaddressesandcomputethegeographi-caldistancebetweentheclientCandtheAkamaiserveritisredirectedtoA,gCA.
WealsocomputethedistancebetweentheVGDNSIPGandtheAkamaiserveritisredirectedtoA′,400.
10.
20.
30.
40.
50.
60.
70.
80.
91-150-100-50050100150200250300350FrequencyDifferencebetweenlatencyofserverresolvedthroughGoogleDNS&localDNS(ms)(a)CDFoflatencyinationwhenusingGoogleDNSasobservedbyaclient00.
10.
20.
30.
40.
50.
60.
70.
80.
91010002000300040005000600070008000FrequencyPercentagedifferenceinlatencytoGoogleDNSserverw.
r.
t.
LocalDNS.
server(%)(b)CDFofpercentagelatencyinationwhenusingGoogleDNSasobservedbyaclientFig.
3.
Quantifyingperformancedegradationusingcloud-basedDNSw.
r.
t.
localDNSforCNAMEa{x}.
c.
akamai.
netgGA′.
TheresultsarecombinedacrossiterationsandacrossnodestoobtainmediangCAas643miles.
ThemediangGA′is2683miles,whichissubstantiallyhigherthangCA.
TheCDFofthesetwodistancesisshowninFigure4.
WeobservejumpsatdiscretedistancesinFigure4(b),becauseofthesmallnumberofdatacenterlocations,whichwillcausesomeiterationstobegroupedtogether.
TheplotsshowthatGoogleDNSseesanAkamaiserverwhichismuchfartherawayfromitthanaclientseeingacorrespondingAkamaiserver.
Wealsocompute,foreachiteration,thepercentagediffer-enceofgGA′w.
r.
t.
gCAandndthemediantobe101%,whichimpliesthatgGA′istwiceasmuchasgCAinthemediancase.
ThisresultisinterestingassumingAkamaidoesnotdiscriminateamongclients.
ThisimpliesthateveniftheclientwascolocatedwiththeGoogleDNSserver,itwouldstillattainlowerperformancethananaverageInternetclient.
Wecontendthatthisisduetotworeasons.
First,Googleperformsprefetchingofnameresolutions[6],whichdoesnotworkwellforAkamai-hosteddynamiccontent,whichchangesnameresolutionsinamatterofseconds[17].
Second,GoogleasacloudisspreadoutoversignicantdistancesandmayshareitsDNSresolutionsamongitsdatacenters.
Asaresult,itmaynotnecessarilyqueryAkamai'sserverfromtheDNSserverwhichresolvesclientrequests.
00.
10.
20.
30.
40.
50.
60.
70.
80.
91020004000600080001000012000FrequencyDistancebetweenclientandAkamaiserver(miles)(a)CDFofgCA,thegeographicaldistancebetweenClientandAkamaiserverresolvedthroughlocalDNS00.
10.
20.
30.
40.
50.
60.
70.
80.
91020004000600080001000012000FrequencyDistancebetweenGoogleVDNSandAkamaiserverresolvedthroughit(miles)(b)CDFofgGA′,thegeographicaldistancebetweenVGDNSandAkamaiserverresolvedthroughGoogleDNSFig.
4.
ComparingdistancesofAkamaicontentserversfromtheresolutionnodeforclientandGoogleDNSInourexperiments,wecomputethemediangCG,whichisthedistancebetweentheclientandtheVGDNSIPaddress.
tobe5374miles.
WealsocomputethepercentagedifferenceofgCGw.
r.
t.
gCAforeachiterationandndthistobe88%inthemediancase,showingthatAkamaiserversareusuallylocatedclosertotheclientthanGoogleDNSservers.
ThisfurtherindicatesthatGoogle'sDNSpresenceissparseintheworld,asshownbyresultsofSectionII-Band[9].
Coupledwiththesub-optimalAkamaiserversseenbyGooglenodes,thisleadstosignicantlypoorerperformanceofclientsinaccessingAkamaicontentthroughGoogleDNS.
V.
SOLUTIONSWenowexplorethesolutionspaceofhowaclientcanbestusecloud-basedDNStoaccesscontenthostedbyAkamai.
WesummarizethesolutionsinTableII.
A.
ChangestoDNSApossiblesolutionisbasedonaproposalinitiatedbyGoogleresearchers(seeIETFdraft[3]).
ThisproposalrequireschangestotheDNSrequestsandrepliesbyallowingrecursiveDNSresolverstoexposeaportionoftheclientIPaddresstoAkamai'sCDNnetwork,whichitmayuseforreturning5TABLEIISOLUTIONSFOROBTAININGGOODCLIENTPERFORMANCEWHENACCESSINGAKAMAI-LIKECONTENTUSINGCLOUD-BASEDDNSSolutionProsConsChangestoDNSbyrevealingclientIPtoAkamaitherebyenablingittodetermineitsclosestservertotheclientCorrectSolutionTheneedforcompletedeploymentacrosstheInternetandensuringbackwardcompatibilitywithexistingDNSIncreasingDNSdatacentersSomeperformanceimprovementexpectedInfrastructurespendingandnoguaranteeofim-provedperformanceCooperationamongcloudsBestsolutionwithvaryingdegreesofcooperationpossibleAgreementsandtrustsetupHybridclient-cloudapproachGoodresolvedserverperformanceRequiresclienttopotentiallywaitforresolution.
Thetechniquebasedonreverse-engineeringAka-maiistemporaryasitdependsonAkamaiimple-mentation.
aclient-optimizedserver.
Theprimarydrawbackofthisap-proachisthatitrequireschangestotheDNSprotocolwhichmaynotbeuniversallyadopted.
B.
CooperationamongCloudsWepositthatthebestsolutionistohavecloud-basedDNSproviderssuchasGooglecooperatewithCDNslikeAkamai,similartoASpeering.
Variousdegreesofcooperationarepossible,fromwhereGooglewillhavetheresponsibilityofselectinganAkamaireplica(similartoDONAR[16])towhereGoogleDNSforwardsclientrequeststoAkamaiservers(similarto[3]).
Theprimarydrawbackofthistechniqueisthatitrequiresagreementsandtrustbetweencloudproviders,whichmaybedifculttoestablishintherealworld.
C.
IncreasingDNSDataCentersYetanothersolutioncanbeforcloud-basedDNSproviderssuchasGoogletoemploymanysatellitedatacenters[25].
ThisimpliesthatanycastroutingwillredirectaclienttoacloserDNSserverwhichperhapswillseeanAkamaiservercloseenoughtotheclient.
However,thissolutioninvolvesasignicantinvestmentfromDNSproviders.
Moreover,thisdoesnotsolvetheissueofGoogleseeingfartherAkamaiserversthananormalclientduetoprefetching(SectionIV).
D.
HybridApproachThesolutionspresentedabovearenotdeployedintoday'sInternet.
Hence,wepresentahybridclient-cloudapproachthataclientcanusetoidentifylow-latencyAkamaicontentserverswhilepreservingthesecurityandoutsourcingbenetsofcloud-basedDNS.
Inthehybridapproach,theclientqueriestheAkamaisecond-levelnameserverdirectly,whichwillcauseaclosebycontentservertobereturned.
TheclientobtainstheIPaddressoftheappropriateAkamainameserverusingcloud-basedDNS.
Figure5showsthesameexampleasFigure2butusingthishybridapproach.
TheclientqueriesGoogleDNSforobtainingtheIPaddressofn7b.
akamai.
net,whichitthenqueriesfortheCNAMEobtainingthecontentserver,thesameasthatreturnedbylocalDNSinFigure2(a).
ThisisahybridsolutionbecauseitinvolvestheuseofcloudDNStoresolvethenameserverIPandalocalsolutiontoquerytheIPdirectlytoobtaincontentservers.
Thissolutioncanbeimplementedasapatchfortheclient-sideDNSsoftware.
ItsonlyoverheadisunexpectedbutinfrequentDNSqueriestoAkamainameservers,whichshouldbetolerablegivenimprovedclientperformancewhileaccessingAkamaicontent.
Fig.
5.
ExampleofahybridapproachforlookingupAkamaicontentserversusingGoogleDNS,showingIPsandtheRTTsfromclientAkeyaspectofthissolutionisthattheclientneedstoknowthenameoftheAkamaisecond-levelnameserver,e.
g.
,n7b.
akamai.
net.
Thiscanbebuiltintotheclient-sideDNSsoftware,sinceAkamaiusespredictablenameservernames.
Forexample,aCNAMEofa{x}.
{z}.
akamai.
netwillhavethenameservern{y}{z}.
akamai.
netwithyrangingfrom0to6(TableI).
Anameserverwithanyvalueofywillworkandonecanevenchooseyrandomlyforloadbalancingpurposes.
Analternatewaytondthenameofthenameserveristhroughtheauthoritysectionofadig[5],ortodoadig+tracefortheCNAMEusingcloud-basedDNSasthedefaultDNS(assumingtheclientwishestotakeadvantageofitssecurityfeatures).
Thisrevealsthenameofthenameserver.
OurresultsindicatethatqueryinganAkamainameserver,providedbycloud-basedDNS,mayormaynotreturnacontentserverIPaddress.
Incaseitdoesnot,itreturnsaCNAMElikea1.
b.
akamai.
net.
0.
1.
cn.
akamaitech.
net.
How-ever,iftheclientretriesthequeryaftersometime,itisusuallysuccessfulandreceivesanIPaddresswhichisthesameastheoneitwouldhavereceivedhaditqueriedusinglocalDNS.
ThisindicatesanAkamaicontentserverreturnedtoaclientisindependentoftheAkamainameserverqueried.
Thisiswhatmakesthishybridapproachsuccessful.
WealsondthattheremaybeaslightdelaybeforeanarbitraryAkamainame6serverresolvesaCNAME.
ThisdelayismostlikelyduetobackgroundinformationsharingamongvariousAkamainameservers,presumablywiththoseclosetotheclient.
Wendthetypicaldelaytobelessthan15seconds(whichwasourretryperiod),exceptforaparticularCNAMEwheretheresolutiondoesnotsucceed.
Afewsecondsdelayisanacceptablesetuppenaltyforatypicallong-livedAkamaisession.
WeconductameasurementstudysimilartoSectionIVtoinvestigatetheeffectivenessofthehybridapproach.
Wendthatthehybridapproachreducesthemedian(mean)latencytoacontentserverbyaround7.
5ms(12.
7ms)ascomparedtotheserverobtainedthroughGoogleDNS.
Thesenumbersarewithin1msoftheactuallatencyinationcausedbyusingcloud-basedDNSasopposedtolocalDNS(SectionIII).
WealsondthatthehybridapproachreturnsthesameserveraslocalDNSin45.
1%ofthecases.
ThisisexpectedsinceAkamaireturnstwocontentserversandwechoosetherstoneasthecontentserverreturned,resultinginarounda50%match.
Whentheserversaredifferent,wendthelatencydifferencebetweentheserversreturnedbythehybridtechniqueandthelocalDNSislessthanahundredthofamillisecond.
ThisshowsthatthehybridapproachreturnsessentiallythesameserversasthelocalDNS,avoidinglatencyinationduetocloudDNS.
VI.
RELATEDWORKAgeretal.
[1]comparecloud-basedDNSsystems.
WhiletheyshowthatthecontentserversreturnedbycloudDNScanbeindifferentASesfromtheclient,theydonotinvestigatecausesandsolutionstotheproblem.
Cloud-basedDNSsys-temsarestudiedfromadatacenterperspectivein[9],demon-stratingnon-optimalclientredirectionusingcloud-basedDNS.
However,theydonotstudyadeeplydistributedCDNlikeAkamaiwhichhandlesdynamiccontent.
Severalstudieshaveinvestigateddatacenterperformance[10],[20].
TheWhyHightool[10]diagnoseshighlatencytoGoogle'sdatacentersandndscausesrelatedtointer-domainrouting,howevereffectivesolutionsarenotproposed.
Therehasbeensignicantwork[16],[7],[8],[18]onGlobalTrafcManagement(GTM).
GTMtechniquesredirectaclienttotheclosestdatacenter;however,thisonlyenablestheclienttoreachtheclosestcloud-basedDNSserver,whichisnotenoughtoensurethatgoodqualitycontentserversarereturnedtotheclient.
VII.
CONCLUSIONSANDFUTUREWORKCloudDNSsystemssufferfrompoorperformancewhenaclientaccessesdynamiccontenthostedonhighlydistributedCDNssuchasAkamai.
Inthispaper,wehaveanalyzedthereasonsforperformancedegradationaclientseeswhenusingcloud-basedDNSsuchasGoogleDNStoaccessAkamai-hostedcontent.
WegeolocatedGoogledatacentersusinganoveltechniquebasedonactivemeasurements.
OurresultsshowthatsparseplacementofGoogleDNSserversalongwithprefetchingarelikelytoblameforsub-optimalcontentserversreturnedbyGoogleDNS.
Wediscussedseveralsolutionstothisproblem,andpositedthatcooperationamongcloudsisthebestsolution.
However,sincenosuchsolutionisdeployedtoday,wepresentedahybridclient-cloudapproachwhichreturnsserverscomparabletolocalDNS.
Ourworkraisesimportantquestionsaboutthefuturecloud-basedInternet,specicallythecooperationamongcloudsandwhichservicesshouldbemigratedintothecloud.
Asfuturework,weplantosimulatedifferentsolutionstogainabetterunderstandingoftheiradvantagesanddisadvantages.
REFERENCES[1]B.
Ager,W.
Muehlbauer,G.
Smaragdakis,andS.
Uhlig.
ComparingDNSResolversintheWild.
InIMC,pages15–21,November2010.
[2]Akamai.
AkamaiCustomerStories.
http://www.
akamai.
com/html/customers/index.
html,RetrievedDecember2011.
[3]C.
ContavalliandW.
vanderGaastandS.
LeachandD.
Rodden.
ClientIPinformationinDNSrequests.
IETFInternetDraftdraft-vandergaastedns-client-ip-00.
txt,Jan2010.
[4]DataCenterKnowledge.
GoogleDataCenterFAQ.
http://www.
datacenterknowledge.
com/archives/2008/03/27/google-data-center-faq/,March2008.
[5]die.
net.
dig(1)-Linuxmanpage.
http://linux.
die.
net/man/1/dig,RetrievedDecember2011.
[6]Google.
GooglePublicDNS.
http://code.
google.
com/speed/public-dns/,RetrievedDecember2011.
[7]J.
S.
GwertzmanandM.
Seltzer.
Thecaseforgeographicalpush-caching.
InHotOSV,1995.
[8]C.
Huang,N.
Holt,Y.
A.
Wang,A.
Greenberg,J.
Li,andK.
W.
Ross.
ADNSreectionmethodforglobaltrafcmanagement.
InUSENIXATC,2010.
[9]C.
Huang,D.
A.
Maltz,A.
Greenberg,andJ.
Li.
PublicDNSsystemandglobaltrafcmanagement.
InINFOCOM,2011.
[10]R.
Krishnan,H.
V.
Madhyastha,S.
Srinivasan,S.
Jain,A.
Krishnamurthy,T.
Anderson,andJ.
Gao.
Movingbeyondend-to-endpathinformationtooptimizeCDNperformance.
InIMC,pages190–201,2009.
[11]T.
Leighton.
ImprovingperformanceontheInternet.
CommunicationsoftheACM,6(6):20–29,October2008.
[12]MaxMind.
MaxMindGeoIPCityDatabase.
http://www.
maxmind.
com/app/city,July2011.
[13]P.
Mockapetris.
Domainnames-implementationandspecication.
RFC1035,November1987.
[14]J.
A.
MuirandP.
C.
V.
Oorschot.
InternetGeolocation:EvasionandCounterevasion.
ACMComput.
Surv.
,42:4:1–4:23,December2009.
[15]OpenDNS.
OpenDNSBasic.
http://www.
opendns.
com/solutions/household/,RetrievedApril2011.
[16]P.
WendellandJ.
W.
JiangandM.
J.
FreedmanandJ.
Rexford.
DONAR:decentralizedserverselectionforcloudservices.
InSIGCOMM,pages231–242,2010.
[17]J.
Pan,Y.
T.
Hou,andB.
Li.
AnoverviewofDNS-basedserverselectionsincontentdistributionnetworks.
ComputerNetworks,43(6):695–711,2003.
[18]C.
Partridge,T.
Mendez,andW.
Milliken.
RFC1546.
HostAnycastingService.
http://www.
ietf.
org/rfc/rfc1546.
txt,November1993.
[19]PlanetLab.
PlanetLab.
http://www.
planet-lab.
org/,RetrievedDecember2011.
[20]M.
Saxena,U.
Sharan,andS.
Fahmy.
AnalyzingVideoServicesinWeb2.
0:AGlobalPerspective.
InNOSSDAV,May2008.
[21]ThomasM.
Sellke.
HowManyIIDSamplesDoesitTaketoSeealltheBallsinaBoxTheAnnalsofAppliedProbability,5(1):294–309,February1995.
[22]R.
W.
Sinnott.
Virtuesofthehaversine.
SkyandTelescope,68(2):159,1984.
[23]A.
SuandA.
Kuzmanovic.
ThinningAkamai.
InIMC,pages29–42.
ACM,2008.
[24]UniversityofOregon.
RouteViewsProject.
http://www.
routeviews.
org/.
[25]Y.
A.
Wang,C.
Huang,J.
Li,andK.
W.
Ross.
Estimatingtheperfor-manceofhypotheticalcloudservicedeployments:Ameasurement-basedapproach.
InINFOCOM,2011.
[26]IanH.
WittenandEibeFrank.
DataMining:Practicalmachinelearningtoolsandtechniques.
MorganKaufmann,SanFrancisco,2ndedition,2005.