Securing DNS

Environments

White Paper by FusionLayer, Inc. December 2015

Copyright©2018FusionLayerAllrightsreserved.Nopartofthispublicationmaybereproduced,storedin a retrieval system, or transmitted, in any form or by any means,electronic,mechanical,photocopying,recording,orotherwise,withoutthepriorpermissionofthecopyrightowners.SecuringDNSEnvironmentsbyFusionLayer,December20188Anycommentsrelatingtothematerialcontainedinthisdocumentmaybesubmittedto:

FusionLayer,Inc.

Keilaranta1,02150Espoo,Finland.

orbyemailto:

info@fusionlayer.com

SECURING DNS ENVIRONMENTS

1

TheInternetwasdesignedwithscalabilityandavailabilityinmind.Atthetime,securityandsafetyofthenetworkinfrastructurewasnotaspressinganissueasitistoday.ThemajorityofpublicandprivatesectorDNSenvironmentsarestillnotDNSSECenabled.

1. IntroductionThe venerablemilitary strategist, GeneralKarl vonClausewitz once suggestedthat possible engagements should be regarded as real ones because of theirconsequences[1].Withtheemergenceofmodernwarfarestrategiesthatactivelyutilizecyberspacetactics,vonClausewitz’smessageisjustascurrenttodayasitwas200yearsago.TheInternetwasoriginallydevelopedwithavailabilityandscalabilityinmind.Atthetime,securityandsafetyofthenetworkinfrastructurewasnotaspressinganissueasitistoday.Asaresult,manymissioncriticalnetworkservices,suchastheDomainNameSystem(DNS)providingname-to-IP-addressresolutionserviceinTCP/IPbasednetworks,haveinherentstructuralvulnerabilitiesintheirprotocol,makingthemeasytargetsforcyberattacksunlessappropriatecountermeasureshavebeentakenpriortotheirdeployment.WheneverahumanreadabledomainnameisusedtoconnecttoanapplicationoveraTCP/IPbasednetwork,DNScomesintoplay.Yetdespiteitsfundamentalrole, the insecuredesignof theDNSprotocolmakes this corenetwork serviceprone to man-in-the-middle, DNS cache poisoning and other similar forms ofmalicious attacks. Due to their nature, these attacks can go undetected forsignificantperiodsoftimewhiledirectingtraffictofraudulentsites.Thisallowstheattackertotamperwiththenameresolutionprocess, facilitatingpharmingattemptsandblockingofselectedservicesatacriticalmoment.ToaddresssomeofthevulnerabilitiesintheDNSprotocolandmitigateanumberof the security issues associated with it, the networking industry has beenworking on developing, fine-tuning and adopting DNS Security Extension(DNSSEC)sinceatleast1993.Whileitsdeploymenthasbeengainingmomentuminthelastnumberofyears,inparticularwiththeRootZonebeingsignedon15thJuly 2010, the fact is that the majority of public and private sector DNSenvironmentsarestillnotDNSSEC-enabled.The reasons for such a lukewarm response to the wide-scale deployment ofDNSSECcouldbethat1) deploying DNSSEC introduces network complexities and operational

challengesthatareyettobeclearlyaddressedand2) DNSSEC alone does not solve all the DNS security problems and instead

should be deployed alongside other measures so as to address a widerspectrumofcyberattacks.

Ontheotherhand,whilesecuritymeasuressuchasthedeploymentofDNSSEC,areeffective in theirown right in improving the trust in theprotocol, to trulyincreasenetworksecurityandeliminatethepossibilityof

SECURING DNS ENVIRONMENTS

2

TheoriginalDNSinfrastructuralenhancementsenvisionedin1983byPaulMockapetris,thefatherofDNS,arestillwaitingotberolledout.

humanerror,DNSmanagementprocessesshouldbeautomated.Inaddition,thishastobetakenonestepfurtherandtheautomatedDNSservicesshouldbevirtualized;soastoyetincreasenetworksecurityandefficiencywhileimprovingdisasterrecoverytactics. In thiswhite paper,we focus on our patent-pendingDNS software appliance-based solution [2], FusionLayer DNS, which automates DNSmanagement andadministrationprocesseswhileaddressingitssecurityissuesoutofthebox.Themainadvantagesofourapproacharesummarizedbelow:1. It provides a simple and secure DNSSEC solution that also includes other

securitymeasures,whichtogetherimproveDNSandnetworksecurity.

2. It automates and streamlines DNS management processes eliminating thepossibility of human error, which is one of the main causes of networkdowntime.

3. The solution, delivered as a virtualization-ready software appliance [3],introducesanewlevelofplatformindependence,asitcanbeinstalledandrunoneitheravirtualmachineorothercomputingplatformalreadyinuse.

2. The Basics of the Domain Name System (DNS) TheDomainNameSystem(DNS)playsamissioncritical role inTCP/IP-basedcommunications. DNS is a hierarchically distributed database used to mapdomainnamestoIPaddresses(nameresolution)andviceversa[4].AllIP-baseddevicesregardlessoftheirusageandlocationrelyontheaccuracyandintegrityofDNSintheirinteraction.In1983,PaulMockapetrisintroducedtheDNSstandardbasedonanarchitecturedesignedwithscalabilityandavailability inmind,with theexpectation that itsinfrastructurewouldbe improvedovertime[5].Theexistingvulnerabilities inthe DNS infrastructure, which weaken the security and trust in TCP/IPcommunications,havebeenwidelyrecognizedsincethelate1990s[6]-[7].Whilethenetworkingcommunities’effortsinaddressingtheseissuesculminatedintheintroduction of DNS Security Extensions (DNSSEC) in 1999, the originalinfrastructureenhancementsenvisionedbyMockapetrisin1983,arestillwaitingtoberolledout.Figure 1 depicts how a local recursive DNS server responds to a query for“foo.example.com”domain.Asthefirststep,theDNSserverchecksitslocalcachetoseeifanentryforthisdomainalreadyexists,storedbasedonasimilarearlierquery.Ifitdoesnot,theserverinitiatesaniterativequeryprocess,startingwiththeroot’sauthoritativeDNSserver,untiliteitherresolvestheIPaddress for the domain name or establishes that the requested domain nameentrydoesnotexist.Ateachpoint,anexternalauthoritativeDNSserverreceivingthequeryfromthelocalrecursiveDNSserver,either:

SECURING DNS ENVIRONMENTS

3

1)respondswithanIPaddressfortherequesteddomainnameifitisauthoritativefor thatzone,2)answerswithadelegationtoanotherauthoritativeDNSserverlocatedclosertotherequesteddomainnameintheDNShierarchy,or3)providesanegativeresponseifananswerto(1)or(2)isnotknown.OncethelocalrecursiveDNSserverhasobtainedanIPaddressthroughthisprocess,itupdatesitscachewiththeentryandforwardstheresponsetotheresolver.

Figure 1: The DNS name resolution procBINDisthemostwidelyusedDNSimplementationontheInternetbuthassomemajorsecurity,administrativeandmanagementshortcomings.

3. BIND and DNS Automation BINDisbyfarthemostwidelyusedDNSimplementationontheInternet.Ontheotherhand,sinceitisbasedonunsupportedopensourcesoftware,ithastobemaintainedandpatchedmanually.UsingBINDforDNSserviceshassomemajorsecurity,administrativeandmanagementshortcomings[8].1. Thelackofadministrativetoolsformanagingday-to-dayDNSroutines,leads

toinputerrorsandDNSdatacorruptionresultinginnetworkdowntime.2. Softwareupdatesandsecuritypatcheshave tobe implementedmanually,

whichisextremelytime-consumingandtedious.

3. TheabsenceofacentralmanagementtoolmeansthatitisimpossibletokeeptrackoftheIPaddressusageacrosstheorganization’snetworkortomonitoruseactivitiesandchangesmadewithintheDNSenvironment.

4. Allserverbackups,synchronizationanddisasterrecoveryactivitieshaveto

bedonemanually,whichincreasesthetimetorecovery.

The solution to these problems is to fully automate DNS management and

SECURING DNS ENVIRONMENTS

4

administrativeroutines.Inpractice,thiswouldmeancentralizingandstreamliningDNSmanagementprocess,providingautomaticdatavalidationandpatchupdatesandimprovingnetworkavailabilityanddisasterrecoverymeasures.All thiswillleadtoamoresecureandstableDNSservice.

4. Secure Architecture of FusionLayer DNS Software Appliance

Inthissection,wefocusontheissueofDNSsecurityandintroducesomeofthesecurityprinciples,whichhavebeenincorporatedinourDNSsoftwareappliance,FusionLayerDNS.Figure2representsthebasicarchitectureofFusionLayerDNS.IthasbeenbuiltonaLinuxoperatingsystem,whichhasbeenspecificallyhardenedandoptimizedforDNSuse.Inordertotrulyenhancethelevelofnetworksecurity,wehaveimplementedvarioussecuritymeasuresnotonlyinthedesignprinciplesbutalsoat theapplicationand theOS level.The threeprinciplesof “Defence inDepth”[9],“LeastPrivilege”[10]and“DefaultDeny”formthefoundationofourDNSsoftwareappliance.

DefenceinDepthistheconceptofprotectingacomputernetworkwithaseriesofdefencemechanismssuchthatifonefails,anotherwillalreadybeinplacetoblockan attack. In practice, this has meant including such measures as encryptedconnections,in-hostfirewalls,IntrusionDetection/PreventionSystems(IDS/IPS)[11],runningserviceswithsecureconfigurations,hardeningtheOSandperiodicbackups.TheIDS/IPSincludedinFusionLayerDNS;asdepictedinFigure3,isinfactthenoveltyofourapproachthathasproventobequiteeffectiveinincreasingDNSsecurity.

SECURING DNS ENVIRONMENTS

5

Figure 3: IntrusionDetection/Prevention System (IDS/IPS) deployed in FusionLayer DNS.

The principle of Least Privilege is concernedwith granular user privileges andrights.Theideabehindthisprincipleistograntasminimalprivilegesaspossibleto permit a legitimate action, thereby enhancing the protection of data andfunctionalityfromfaultsandmaliciousbehavior.Inpractice,thismeansthatinourDNSsoftwareappliancearchitecture,DNSservicesarenotrunasroot,theuser-interfaceandshellaccesshavemultiplelevelsofuseraccountsandeachuserhasspecificrightsandrestrictedprivileges.

TheprincipleofDefaultDenydemandsthatanythingthatisnotexplicitlyallowedisdenied,regardlessofwhetheritisrelatedtoaccess,privileges,security-relatedattributes or other functions. In practice, this involves having a firewall whichblocksallbutexplicitlyallowedconnections,explicitlypermittingshellaccessforusers,disablingallbutnecessaryservicesandremovingallbutnecessarypackages.

ThethreesecurityprinciplesformthebackboneofFusionLayerDNS.WefurtherstrengtheneditsarchitecturebyincorporatingvarioussecuritymeasuressuchasDNSSEC,whichisdiscussedinthenextsection.

SECURING DNS ENVIRONMENTS

6

6. Examples of Malicious Attacks Against DNS Servers

InthisSection,wepresenttwoexamplesofmaliciousattacksagainstDNSServersandtheirconsequences.Figure4depictstheflowofcommunicationsbetweentheclient and the server while a man-in-the-middle or cache poisoning attach isunderway.Oneofthemainobjectivesofaman-in-the-middleattackistoeavesdropon the communication between the servers and forge the responses to DNSqueries, directing Internet traffic to fraudulent sites. Meanwhile, in order toincreaseefficiency,decreasenetworktrafficandimproveresponsetime,recursiveDNSserverstemporarilycachethenameresolutionresponsestheyhaveobtainedforaperiodoftimereferredtoasthe

Figure 4: Vulnerabilities of the DNS protocol.

Time-To-Live(TTL).CachepoisoningoccurswhenfraudulentDNSdataisprovidedandcachedinarecursivenameserver.Asaresultofcachepoisoning,all futurequeriestothe“poisoned”recursiveDNSserverwouldbedirectedtothefraudulentsiteuntiltherecord’sTTLhasexpired.

Figure 5: Asymmetric cryptography and digital signature.

SECURING DNS ENVIRONMENTS

7

7. Mitigating Threats with DNSSEC

DNSSEChasbeendesignedtosolvesomeofthesecurityproblemsassociatedwiththeDNSprotocol.Withthehelpofdigitalsignatures[12],DNSSEChelpsassurethatthedatareceivedhas infactoriginatedfromtheauthorizedsourceandthatthemessage has not been tampered with in any way while travelling through thenetwork. It also provides authenticated denial of existence, proving that therequesteddomainnameentrydoesnotexist.Havingsaidthat,DNSSECdoesnotprotecttheconfidentialityofthedata,nordoesitpreventDenialofService(DoS)attacks.Assuch,inordertofurtherincreasethetrustinInternetandmitigatethelattertwothreats,inFusionLayerDNSwedeployDNSSECalongsideSecureSocketLayer (SSL) technology [13] and Intrusion Detection/Prevention Systems(IDS/IPS).

DNSSECfunctionsbyrequiringDNSzonedatatobesignedinordertoassuretheauthenticityofthenameresolutionprocess.ItsimplementationissimilartoPublicKeyInfrastructure(PKI)andreliesonasymmetriccryptographicalgorithm,whichisrepresentedinFigure5.Inasymmetriccryptography,apairofprivateandpublickeysisusedtoencryptanddecryptamessage.Theownerofthekeysuseshis/herprivatekeytoencryptthemessagetobesent.Thereceiver,ontheotherhand,usesthepublickeyofthesender,whichhe/shehadobtainedpreviously,todecryptthemessagereceived.Amessageencryptedwithaprivatekeycanonlybedecryptedwith its corresponding public key and as such this approach can prove theauthenticityofthesourcefromwhichthedataoriginated.Figure5alsooutlineshowPKIcanbeusedtoprovetheintegrityofthemessagereceived,assuringthatthedatahasnotbeenmodifiedwhileintransit.

Figure6representstheflowofcommunicationsforanameresolutionprocesswithDNSSECenabled.InordertodeployDNSSEC,eachchilddomaincreatesapairofpublic/privatekeysandparticipatesinthechainoftrustbyuploadingitspublickeytoitsparent’sdomainandhavingitverified.Thisinformationisstoredintheparent zone’s Delegation Signer (DS) record and is forwarded alongside anyresponsetotherecursivenameserver.Thechilddomainwouldthenuseitsprivatekeytosignallzonedataforwhichit

SECURING DNS ENVIRONMENTS

8

is authoritative. After receiving any response, the recursive DNS server wouldcompare thepublic key of the child zone, contained in theDNSKEY record andreceivedwiththeresponse,againsttheDSrecordoftheparent’szonereceivedinthepreviousresponse,toconfirmthatthepublickeysentbythechildzoneisinfactcorrect.Therecursivenameserverwouldthenuse thisverifiedDNSKEYtodecrypttheDNSSECsignaturecontainedintheRRSIGrecordinordertoverifytheauthenticityandoriginoftheresponse.Itwouldthenfollowonwiththequeryandrepeat theprocessuntil either the IP addressof the requesteddomainname isresolvedoritreceivesanauthenticateddenialofexistencereplywhichindicatesthattherequesteddomainnameentrydoesnotexist.

Figure 6: DNS name resolution with DNSSEC enabled.

AlthoughthetheorybehindDNSSECisrelativelystraightforward,implementingitintroducessomeoperationalchallengesaslistedbelow.

1. Whenzonesaresigned,thenumberofresourcerecordsgrowsbyafactorof

4-5,increasingtheamountofdatathathastobemanaged.Inreturn,thiswillincreasetheamountofnetworktraffic,althoughnotsignificantlyenoughtowarrantspecialmeasure.

2. Whensigned,formerlystaticDNSentrieswillbecomedynamicbecausethe

privatekeysusedtosignthezoneshavetoberolledoveratregularintervals.According to DNSSEC Operational Practices [14], it is recommended thatzonesigningkeysarerolledoveronceeverymonth.Thispracticeisaimedatincreasingthelevelofsecuritybypreventingtheftandbruteforceattacksonprivatekeys.

SECURING DNS ENVIRONMENTS

9

3. As signed zones contain resource records that are effectively very long keys, managing the keys manually becomes more error-prone. This is due to the fact that as the key length grows, so does the possibility of human error while manually inputting, updating and managing the keys.

Figure 7: Manual implementation of DNSSEC,

Figure 7 depicts the steps that have to be taken in order to manually deployDNSSEC. As elaborated above, it is these operational challenges of manuallyimplementingDNSSEC that havepreventedmanyorganizations fromdeployingDNSSECintheirnetwork.Assuch,deployingDNSSEC,oneitherexternalorinternalnetworks,isaprocessthatgreatlybenefitsfromautomation.Inthenextsection,we elaborate on the criteria necessary to successfully deploy a secure DNSenvironmentwithDNSSECenabledusingsoftwareappliances.

8. Countering Predatory Practices in DNS Environments

To successfully deploy a DNS environment that addresses the forms of cyberattacksdiscussedinthispaper,wehaveidentifiedthreekeycriteriathatshouldbemet.

1. ThedeployedDNSserviceshouldsupportDNSSECandincludeautomated

key management functionality used in the authentication of the nameresolutionprocess.

2. ItshouldincludeSecureSocketLayer(SSL)technologyandbuiltinIntrusion

Detection/ProtectionSystem(IDS/IPS)providingprotectionagainstDenialofServiceattacks.

3. To improve network performance, security and availability, DNS services

shouldbebasedonadedicatedandoptimizedserverstackwith

SECURING DNS ENVIRONMENTS

10

JustenoughOperatingSystem(JeOS)[15]usedtominimizethenumberofattackvectors.

Combining DNSSEC with the methodology described above has numerousadvantages. Firstly, it improves the reliability and availability of core networkserviceswhilereducingoperatingexpenses.Secondly,whendeployedbasedonthesecurityprinciplesdiscussedpreviously,thisapproachisproventobeextremelyeffectiveinmitigatingpredatorypracticesdiscussedinthispaper.Thirdly,thefactthatFusionLayerDNSisdistributedasasoftwareappliancemeansthatitcouldbedeployedeitheronavirtualmachineoranyx86-basedhardwareplatformalreadyin use. This platform independence supports recent trend towards cloudcomputing initiatives that reduce computing costs. Finally, instead of requiringdedicatedphysicalservers,ourapproachallowsnumerousinstancesofsoftwareappliances to be consolidated as virtual machines on any computing platformalreadyinuseandthushelpsreducethenumberofphysicalservesrequired.

9. Conclusion

DNS is one of the core services necessary for network connectivity. Despite itsmissioncriticalrole,itsinherentdesignhasmadeitaneasytargetfornumerousformsofcyberattacks.DNSSECwasdevelopedasaprotocolthatmitigatessomeofthesecurityissuesassociatedwithDNS.Itssuccessfuldeploymentthoughrequiresautomation;bothintermsofinstallationandmanagementprocesses.Atthesametime,tobetrulyeffectiveinimprovingDNSsecurity,DNSSEChastobedeployedincombinationwithothersecuritymeasurestoaddressawiderspectrumofcyberattacks.

Inthiswhitepaper,weintroducedFusionLayerDNS,whichisdevelopedbasedonamethodologythataddressesDNSsecurityissuesoutofthebox.FusionLayerDNSprovidesasimpleandsecureDNSsolutiondesignedbasedonstringentsecurityprinciples which meets the standard requirements of today’s networkingenvironments.Ithasalreadybeendeployedinvariousorganizationsworldwide,both in public and private sector networks in all industry verticals, creatingsignificantcostsavingwhileintroducinganenhancedlevelofnetworksecurity.

SECURING DNS ENVIRONMENTS

11

About FusionLayer FusionLayer streamlines cloud and applicationdelivery innext generationdatacenters. The company’s vendor agnostic technology bridges the gap betweennetwork infrastructure and orchestrated cloud and network functionsvirtualizationworkflows.Forcloudandapplicationdelivery,FusionLayer’snorthboundsolutionfacilitatesNetworkFunctionVirtualization(NFV)andprovidesunifiednetworkvisibilityandreporting. The company’s southbound solution, for network infrastructure,enables multivendor DNS and DHCP administration coupled with networkmonitoringandreservationmanagementforSoftwareDefinedNetworking(SDN).Altogether, FusionLayer’s solutions fully support both IPv4 and IPv6environments. Nine out of 10 of theworld's largest service providers leverageFusionLayer.

SECURING DNS ENVIRONMENTS

12

References

1. CarlVonClausewitz, Colonel F.N.Maude and J.J. Graham, “OnWar”, p.152,WilderPublication,2008.

2. WIPO, IP Services, (WO/2007/107634) “Applianced Domain Name Server”,

http://www.wipo.int/pctdb/en/wo.jsp?WO=2007107634 3. Ganguly,J.Yin,H.Shaikh,D.Chess,T.Eilem,R.Figueiredo,J.Hansom,A.MohindraandG.Pacifici,

“Reducingcomplexityofsoftwaredeploymentwithdeltaconfiguration”,Proceedingsofthe10thIFIP/IEEEInternationalSymposiumonIntegratedNetworkManagement,pp.729-732,Munich,Germany,May2007.

4. P.Mockapetris,“Domainnames–conceptsandfacilities”,InternetRFC1034,November1987.5. S. Lawson, “Inventor looks to DNS’s past, future”, Computerworld June

2003,www.computerworld.com.au/article/70040/inventor_looks_dns_past_future/

6. S.M.Bellovin,“Usingdomainnamesystemforsystembreak-ins”,Proceedingsofthe5thUsenixSecuritySymposium,SaltLakeCity,UT,1995.

7. R. Chandramouli and S. Rose, “Secure Domain Name System (DNS) deployment guide –

recommendations of the National Institute of Standards and Technology”, Sponsored by theDepartmentofHomelandSecurity,April2010.

8. P.Vixie,“DNSandBINDsecurityissues”,Proceedingsofthe5thUsenixSecuritySymposium,SaltLakeCity,UT,1995.

9. L. Smith, “Understanding concepts in thedefence indepth strategy”, Proceedingsof IEEE37th

InternationalCarnahanConferenceonSecurityTechnology,pp.8-16,2003.10. N. Jing-xuan, H. Hong-jun, L. Li, L. Peng andD. Li-ming, “Discussion onminimizing file access

privilege”,ProceedingsofInternationalConferenceonMultimediaandInformationTechnology,p.801,2008.

11. J.McHugh,A.ChristieandJ.Allen,“Defendingyourself:theroleofintrusiondetectionsystems”,

IEEESoftware,Vol.17,Is.5,PP.42-51,September/October2000.12. H. L. Kesterson, “Digital signatures, whom do you trust?” IEEE Proceedings of Aerospace

Conference,Vol.4,p.159,February1997.13. A.C,Weaver,“SecureSocketsLayer”,Computer,Vol.39,Issue4,pp.88-90,April2006.14. O. Kolkman andW.Mekking, “DNSSEC operational practices, Version 2”, RFC 4641 (Proposed

Standard),September2006.http://www.ietf.org/rfc/rfc4641.txt

15. D.Geer,“TheOSfacesabravenewworld”,Computer,Vol.42,Issue10,pp.15-17,October2009.