the impact and importance of dnssec

8/3/2019 The Impact and Importance of DNSSEC

http://slidepdf.com/reader/full/the-impact-and-importance-of-dnssec 1/38

Hardening tHe

internetThe impact and importance of DNSSEC



3

ManageMent SuMMary 5

reading guide 5

1 tHe doMain naMe SySteM: road SignS on tHe internet 7

1.1 PurposeofDNS 7 1.2 History 7

1.3 Thesolution:theDomainNameSystem 7

1.4 ResolvinganIP-address 8

2 WHy tHe doMain naMe SySteM iS inSecure 11

2.1 Introduction 11

2.2 Changingaroadsign 11

2.3 Replacingtheroadsigncompany:theKaminskyattack 12

2.4 PatchingagainstKaminsky 12

2.5 Example:breakingthePiggyBank 13

2.6 HowDNSSECsolvesthisproblem 13

3 WHat iS dnSSec? 15

3.1 Denition 15 3.2 Securitybysigning 15

3.3 Chainsoftrust 15

3.4 Trustanchors 16

3.5 Islandsoftrust 16

3.6 Alternatives 16

4 iMpleMenting dnSSec 18

4.1 Introduction 18

4.2 Timeline 18

4.3 StrategyforrollingoutDNSSECinanorganisation 19

5 concluSionS 21

5.1 DNSSECprovidestrustinDNSresponses 21

5.2 Thereisnoalternativeinthelongterm 21

5.3 ManagingDNSSECisdifferentfrommanagingDNS 21

5.4 Youneedtodoit 21

6 acknoWledgeMentS 22

7 endorSeMentS 23

appendix a terMS and abbreviationS 25

A.1 Terms 25

A.2 Abbreviations 26

appendix b referenceS 27

B.1 Furtherreading 28

appendix c tecHnical diScuSSion of dnSSec 29

C.1 Introduction 29

C.2 DNSSECforresolvers 29

C.3 DNSSECforauthoritativenameservers 30

appendix d outSourcing 34

D.1 Introduction 34

D.2 Divisionofresponsibilities 34

D.3 Protectingagainstvendorlock-in 34

appendix e alternativeS 35

E.1 Introduction 35

E.2 TheDNSarmsrace 35

E.3 TSIGandSIG(0) 35

E.4 DNScurve 36

E.5 IPsec 36

E.6 SSLorTLS 36

table of contentS



4

ManageMent SuMMary

reading guide



5

TheDomainNameSystem(DNS)isoneofthebasic

buildingblocksoftheInternet.Vulnerabilitiesinthe

DNSsystemcanaffectthesecurityoftheentire

Internet.

DNSconvertslogicalnamesforresourcesonthe

InternettoIPaddresses,makingitpossibleforauser

totypealogicalname(suchaswww.surfnet.nl)

ratherthananIPaddress(suchas194.171.26.203).

IthasbeenknownforalongtimethatDNShasa

numberofvulnerabilitiesinitsbasicdesign.However,

arecentexploit(theKaminskyattack,see[5])has

shownhoweasyitistoabusethesevulnerabilities,

leadingtoarenewedsenseofurgencywithinthe

Internetcommunity.

AnextensiontoDNShasbeendevelopedtoaddressitsvulnerabilities:DNSSEC1.AlthoughDNSSEChas

beenavailableforsometimenow,deploymenthas

notyettakenoffonalargescale.This,however,is

changingrapidly,astheneedtosecureDNShasbe-

comemoreapparentbytheKaminskyattack.This

specicattackmayhavebeenmitigated,butothers

arelikelytofollow.

WhileDNSSECdeploymentcanbecomplex,tools

arenowavailablewhichhandlemostofthecom-

plexity,resultinginamorestraightforwardimplemen-

tation.Itstillrequiresanorganisationtomakechan-

gestoitssystemsandtoitsprocessesthough.

Inthelongrun,everyorganisationwillhavetoimple-

mentDNSSEC.However,giventhestageofdevelop-

ments,onlyorganisationswithrelativelyhighlevels

oftechnicalexpertise,likeuniversities,researchcen-

tres,banks,ISPsandsometop-leveldomainadmini-

stratorsarecurrentlyimplementingit.Atthetimeof

writing,anumberoftop-leveldomains2haveimple-

mentedDNSSEC,whilemanyothersareinthepro-

cessofimplementation3.Anyorganisationwithany

kindofITinfrastructureshouldatleastbeplanning

animplementationatsometimeinthenearfuture.

Thiswhitepaperisaimedatdecision-makers,res-

ponsiblefortheITinfrastructure,innon-commercial

institutesandcommercialenterprises.Itexplains,at

anabstractlevel,howthecurrentDNSisvulnerable

andwhatorganisationsshouldbedoingaboutit.

Therstvechaptersgiveahigh-leveloverviewof

thefollowingsubjects:whattheDomainNameSy-

stemisandwhyitwasintroduced;whyitisvulnera-

bletoattacksbydesign;howDNSSECcanaddress

thesevulnerabilities,whatDNSSECis,astrategyfor

deployingDNSSECandnallytheconclusionsofthis

paper.

Theremainderofthedocumentconsistsofseveral

appendicesthatcontainmoredetailedtechnicalin-

formationaboutDNSSEC;theseappendicesareai-

medatDNSadministratorstogivethemageneralin-sightintothetechnicalimplicationsofimplementing

DNSSECwithintheirinfrastructure.

ManageMent SuMMary reading guide

1 DNSSEC: Domain Name System Security Extensions

2 Currently (December 2008) the country top-level domains of

Sweden, Brazil, Bulgaria, the Czech Republic, Puerto Rico, as

well as the .museum top-level domain and the ENUM domain.

3 For example, the US government top-level domain .gov will

implement DNSSEC as of January 1, 2009.



6

tHe doMain naMe SySteM:

road SignS on tHe internet

1



7

1 tHe doMain naMe SySteM: road SignS on tHe internet

1.1 ps dnSToreachacomputer(oranyotherresource)onthe

Internet,someformofaddressingisneeded.Thead-

dresshastobeunique,sothenetworkcanrouteyourrequeststothecorrectdestination.Forthispur-

pose,everycomputerconnectedtotheInternethas

anIPaddress–anumericalidentierwhichrouters

andothernetworkingequipmentcanunderstand.

IPaddresses,however,aremeanttobeusedbyma-

chines,notpeople.Theyarehardtoremember,and

havenologicalstructurepeoplecanrelateto.For

thatreason,Internetresourcesusuallyhavealogical

nameinadditiontoanIPaddress.

InordertotranslatelogicalnamesintoIPaddresses,

atranslationsystemisneeded.Thistranslationsys-temiscalledtheDomainNameSystem(DNS).DNS

translateslogicalnames,suchaswww.s.,into

IPaddresses,suchas194.171.26.2034.

1.2 HsTounderstandtheworkingsoftheDomainName

System,abriefexplanationofitshistoryisneeded.

WhentheInternetwascreated,eachnodeonthe

networkneededtohaveanaddress.Forthispur-

pose,IPaddressesweredened.

EarlyadoptersoftheInternetsoonranintotheprob-

lemofmissingalogicalstructuretolinkcomputer

systemstoIPaddressesandcameupwithasimple

solution:theycreatedalethatmappedanIPad-

dresstoalogicalname.Thislewascalledthe‘hosts’

leasitcontainedalistofhostsconnectedtothe

network.Anexampleofsuchahostsleisshownin

Table1.

Thehostslewasmaintainedandsharedbetween

thesystemadministratorsofthecomputersystems

thatwereconnectedtotheearlyInternet.Butwhen

theInternetstartedtoexpand,itsoonbecameclear

thatthissolutionwouldnotscaletottheneedof

themanynewusersconnectingtothenetwork.

1.3 th s: h dm nmSsm

InresponsetothefastexpansionoftheInternetand

withitanincreaseinIPaddresses,theDomainNameSystem–orDNSforshort–wasintroducedin1983.

Domainnames,andtheDNSsystem,arehierarchical:

thereisarootdomain(representedbyasingledot

“.”),asetoftop-leveldomains,suchas.mor.,

andanynumberoflevelsunderthesetopleveldo-

mains.Figure1showsanexampleofthedomain

namehierarchy.

TheDNStranslateshuman-friendlydomainnames

(suchaswww.s.)intoIPaddressesusedby

computerstolookupitsdestination.

Informationforacertaindomainisstoredonacom-

putersystem,aso-calledauthoritative name server.

Thisnameservermanageswhatiscalleda“ zone”.

Azonecontainsrecords,mappingnamestoresources

–forinstance:thezonefors.containsa

recordthatmapsthenamewwwtotheIPaddress

194.171.26.203.Eachentryinthezoneisadomain

name.

Anameservermayredirectentitiesthatarerequest-

inginformationforaresourcewithinazonetoanoth-

ernameserver.Thisiscalleddelegation.Forin-

stance:thenameserverforthe‘.’zonecan

delegatemanagementofinformationforthe

‘s.’zonetoSURFnet’snameserver.

Thezonecontainingthetopofthehierarchy(the“.”

domain)iscalledtherootzone.Theentriesinthis

zonearethetop-leveldomains.Atthemomentthere

aretwotypesoftop-leveldomains:generictop-level

domains(suchas.mforcompanies, .foredu-

cationalinstitutions,etc.)andcountrycodetop-level

domains(suchas .forTheNetherlands,.forChi-

na,etc.).

f 1 - em h dnS hh

4 Although all the examples in this paper use IPv4 addresses,

the issues are exactly the same for IPv6.

194.171.26.203 www.surfnet.nl

194.171.26.204 tag.surf.nl

194.171.26.205 redactie.surfnet.nl

... ...

t 1 - em hss



8

1.4 rs ip-ssWhathasnotbeendiscussedyetishowausercan

querytheDNStondtheaddressforagivenname.

Todothis,aso-called resolver isused.Ifaresolveris

askedtondtheaddressfor www.s.,itque-

riestheDNStop-down.Thediagrambelowshows

howthisisdone:

Thediagramshowshowaresolvergoesaboutnding

theIPaddress:

1.Theresolverasksoneoftherootnameserversifit

knowstheIPaddressfor www.s..Theserv-

ertellstheresolverthatitdoesn’tknow,butthat

theresolvercanaskoneofthenameserversfor

the.domain.Italsoprovidesthenamesandad-

dressesofthese. nameservers.

2.Theresolverasksoneofthenameserversforthe

.domainifitknowstheIPaddressforwww.s-

..Theservertellstheresolverthatitdoesn’t

know,butthattheresolvercanaskoneofthe

nameserversforthes.domain.Italso

providesthenamesandaddressesofthesename

servers.

3.Theresolverasksoneofthenameserversforthe

s.domainifitknowstheIPaddressfor

www.s..Itrespondsbytellingtheresolver

thatwww.s.isat194.171.26.203.

Thisonlyleavesthequestion:“howdoestheresolver

knowwheretondtherootnameservers?”.Thean-

swertothisissimple:the‘bootstrap’foraDNSre-

solveristheso-calledhints fle.Thislecontainsa

listwiththenamesoftherootnameserverstogether

withtheiraddresses.Regularupdatesofthisleare

madeavailablebyInterNIContheirwebsite5.

5 http://www.internic.net/zones/named.root

f 2 - rs ip ss



9

Insteadofhavingafullyfunctionalresolveroneach

client,itiscommonpracticetoexpeditetheresolving

processtoarecursive name server .Thisrecursive

nameserverallowsclientstorequestanynametobe

resolved.Itthendoesallthe‘hardwork’forthecli-

ent,resolvingthename.Anadditionalbonusisthat

therecursivenameservercanmaintainacacheofanswersthatithasreceived(thusbecominga recur-

sive caching name server ).Theanswerscanbere-

usedwhenanotherclientasksforthesamenameto

beresolved.Allanswersprovidedbynameservers

haveatime-to-live;whenthisperiodexpiresthean-

swerisremovedfromthecache.

Inthiscase,theclienthasonlyaverysimpleresolver

(calleda stub resolver )thatcannotperformthere-

cursivelookupsitself.Thestubresolveriscongured

totalktoarecursive(caching)nameserver.Figure3

belowshowsarecursivecachingnameserverinac-

tion.

Thersttimeaclientrequeststheaddressfor

www.s. (1)theservergoesthroughtheentire

resolvingprocess.Thesecondtime(2),however,it

canre-usetheaddressthathasalreadybeenstored

initscache.

Arecursivecachingnameserveractuallystoresalot

moreinformationinitscachethanjusttheaddress

ofwww.s..Duringtheprocessofresolving

www.s.,italsoencounteredthenamesand

addressesofthenameserversforthe. zoneand

forthes. z.Asaresult,itnowknows

wheretogoforothernameswithinthes.

zone,sothatasubsequentqueryfor

shws.s. canbedirectedstraight

tothes. nameserver.

f 3 - a s h m s



10

WHy tHe doMain naMe

SySteM iS inSecure

2



11

2 WHy tHe doMain naMe SySteM iS inSecure

2.1 iTheDomainNameSystemwasdesignedduringthe

earlyyearsoftheInternet.Duringthiseraallusers

wereacademia,militaryorganisationsandcomputer

enthusiasts,who–ingeneral–couldbetrustednottoabusethenetwork.

Alltheaboveimpliesthatsecuritywasnotoneofthe

maindesigngoalsoftheDomainNameSystem.Asa

consequence,therearevulnerabilitiesinthesystem

(someofwhichareevenbydesign).Themostsigni-

cantvulnerabilityresultsfromthefactthatname

serversqueryeachother,withoutamethodtoverify

thattheresultsaregenuine,orevenoriginatefrom

thepropernameserver.Thisallowsforatypeofat-

tackcalledcache poisoning.

Toillustratetheproblemofcachepoisoning,ananal-ogyisused.AnaptanalogyforDNSistheuseof

roadsigns.Similartoroadsignswhichpointyouin

thedirectionofageographicallocationifyouare

lookingforanaddress,DNSpointsyouintheright

directionifyouarelookingforaspecicInternet

address.

2.2 ch sAswasalreadydescribedinthepreviouschapter,itis

commonpracticeforclientstomakeuseofarecur-

sivecachingnameserverthatdoesallthehardwork

ofresolving,andkeepstheanswersinacacheso

theycanbere-usedforotherclients.MostLANs

haveoneormorerecursivecachingnameservers.

SuchaserveriscontactedbyclientsontheLAN,and

thusitscacheisanidealtoolforreducingthestrain

putontheInternet’sDNSinfrastructure.Thisisawin-

winsituation:clientsgettheirresultsmorequickly,

anddownstreamDNSservershavelessworktodo.

Butimaginethatitwouldbepossibletofoolthere-

cursivecachingnameserverintoacceptingawrong

answerforaqueryithassentdownstream.Thisin-

correctanswerwouldthenendupinitscacheandbe

servedouttoallclientsrequestingthesameaddress

untilthetime-to-liveofthewronganswerrunsout.

Asaresult,userscouldbesenttothewrongbank,or

toawebsitewithmalwareonit;theire-mailscould

besenttothewrongaddressandeventheirtele-

phonecallscouldberedirected.

Thiswouldbetheequivalentofreplacingaroadsignbyanewonepointinginanotherdirection.Andifit’s

donecorrectly,theworstthingisthatuserscan’ttell

thedifferencebetweentherealandthefakeroad

sign.

ThisscenarioisexactlywhatispossibleintheDomain

NameSystematthemoment.Whenaresolversends

outarequest,itispossibleforanattackertosend

wronganswerstotheresolver.Iftheattackerserves

upanacceptableanswerquicklyenough,thenthe

resolverwillacceptthatanswer 6.Therealanswerwill

bediscarded,sincetheresolverhasalreadyreceived

aresponsetoitsrequest.

Nowthisattackisonlypossibleiftheattackereither

interceptstheoriginalrequestorgeneratesthere-

questhimself,andifhesucceedsingivingtheresolver

aspoofedanswerbeforetheauthoritativeserver

does.

f 4 - a s shw wh pb

f 5 - ch s

6 Technically, this involves getting some numbers right, an

excellent – albeit very technical – explanation is given in [15]



12

2.3 r h s m:h kms

Thetroubledoesn’tendthere.Goingbacktothe

roadsignanalogy:whatifitwouldbepossibleto

trickthelocalcouncilintohiringadifferentcompany

forputtinguproadsigns?

Unfortunately,thisispossibleintheDomainName

System.ThisisknownastheKaminskyattack.

Toexplainthisattack,alittlebitmoredetailisneeded.

Inthepreviouschaptertheprocessofresolvingwas

explained.Inthisprocess,nameserverscantellaclient

thattheydon’tknowtheanswerbutredirecttheclient

tolookelsewhere.Theinformationthatissuppliedby

thenameserverisso-called‘authority’information.

Thenameserversays“I’mnotauthoritativeforthe

domainyou’relookingforbutthisotherserveris”.It

thenveryconvenientlysuppliesboththenameand

theaddressforthisauthoritativenameserveraspart

oftheanswertothequery.Thisinformationiscom-

monlyknownas“glue”.Ineffect,theanswertoevery

queryconsistsof3parts:

• Theanswertothequery

(canbeemptyifthequerycannotbeanswered)

• Authorityinformation

(whoisauthoritativeforthedomainbeingqueried)

• Additionalinformation

(theaddressinformationfortheauthoritative

servers)

Itiseasytoseehowthiscanbeabused:theattacker

cantrytoanswerbeforethenameservertowhichthe

requestwassent.Iftheattackersucceeds,hecansup-

plyfalsied“glue”referringallfurtherrequestsforthe

domainthatisbeingsubvertedtohisownnameserv-

ers(i.e.hereplacesthe“additionalinformation”sec-

tionofthereplywithinformationofhisown).

Threethingsareparticularlytroublesomeaboutthis

attack:

• Theattackercancarryoutthisattackatanytime

(insteadofhavingtowaitforcachedrepliesto

timeout).Hesimplyqueriestherecursivecaching

nameserverhewantstosubvertfor(non-exist-

ent)hostnamesheknowsarelikelynottobe

presentinthecache.Heknowsthattheserver

willforwardthisrequestbecausethenameisnot

inthecache,givingtheattackertheopportunity

toinserthisownincorrectanswerswhichwill

thenautomaticallybeenteredinthecache.

• Thisattacksubvertsawholedomaininsteadof

justonehostname.Andanattackerwilltypicallysetalongtime-to-liveonthefalsiedanswer,to

makesureitstaysinthecacheforalongtime.

Becausethewholedomainhasbeensubvertedall

trafctoitcanberedirected,includinge-mail.

• Thisattackcannotbemitigatedbyprotecting

yourwebsiteusingSSL(https).Astheexample

insection2.5willshow,itistrivialforanattacker

toredirectuserstoanSSLsecuredsitethatmay

seemcompletelyvalidfromauser’spointofview.

2.4 ph s kmsTheKaminskyattackwasmadepubliconlyaftera

patchwasavailableforallofthecommonnameserver

software,andalargenumberofcachingnameservers

hadalreadybeenpatched.Thisis,however,notaso-

lutionthatworksforthelongtermsinceitispartof

anarmsracebetweensystemadministratorsandat-

tackers(seealsosectionE.2).Thebasicawinthe

DomainNameSystem–thatthereisnowaytoen-

surethatanswerstoqueriesaregenuine–remains.

Whypatchingisnotthesolutionisbestillustratedby

somenumbers:

• Unpatchedserverscanbepoisonedwithinas

shortatimeas3seconds

• ResearchperformedbyCZ.NIC–thetop-level

domainregistrarfortheCzechRepublic’s.cz

domain–hasshownthatitispossibletopoison

afullypatchedserverwithinonetoelevenhours

Soeventhoughpatchinghelpsdelayanattack–giving

administratorsawarningwindowinwhichtodetect

theattack,forinstanceusingtrafcanalysis–it

showsthatanattackisstillviable.Andsinceanat-

tackerhas“allthetimeintheworld”therearemany

waysinwhichanattackercanmasktheattack,for

instancebyperformingitinsmallburstsfrommany

differenthosts.

f 6 - r h s m



13

2.5 em: h pbTheexampledescribedbelowshowshowinsidious

theKaminskyattackactuallyis.Italsodemonstrates

thatevenanSSLsecuredwebsiteisnotsafe.

AssumethatthereisabankcalledPiggyBank.This

bankprovidesInternetbankingservicestoitscus-tomers.Thebankprovidesalinktoitsonlinebanking

portalthroughitswebpageon

h://www...Normally,whenauser

clicksonthislink,heisredirectedtotheonline

bankingportalhs://m...

NowsupposeanattackerintendstohackPiggyBank’s

on-linebankingsystemandwantstotrickcustomers

intoallowinghimaccesstotheirbankaccounts.Us-

ingtheKaminskyattack,thisisreallystraightforward:

• TheattackerwouldbeginbycopyingPiggyBank’s

websiteandon-linebankingportaltomakesurethattheylookfamiliartothecustomer;

• Thentheattackerwouldsetuphisowndomain,

s-.;

• UsingtheKaminskyattack,hecannowpoison

thecacheofamajorISPdirectingqueriesforthe

.domaintohisownserver;

• Hecannowleaduserstohisownmodiedver-

sionofthePiggyBankwebsite.Thiswebsiteis

identicaltotheoriginal,exceptthatthelink

tohs://m..nowrefersto

hs://m.s-.;

• AnyonecanrequestSSLcerticatesfrommost

suppliersaslongastheycanprovetheyowna

domain.Asourattackerownsthe

s-.domain,hecanrequest

acerticateform.s-. ;

• UserswillenduponanSSLsecuredsite,padlock

present,andallthatlookscompletelyvalidfrom

theirpointofviewwhereasinfacttheyareona

phishingsite.Onlyauserwhonoticesthatthead-

dressbarshowshs://m.s-.

ratherthanhs://m..mightrealise

thatthereissomethingwrong.

HadbothPiggyBankandtheISPusedDNSSEC,then

theresolveroftheISPwouldhavebeenableto

checktheauthenticityofthereplyitgotinresponse

toitsqueriesforinformationinthe.

domain;DNSSECcaneffectivelypreventthisattack

fromtakingplace.

Obviously,thescenarioaboveappliestoanyservice

usingDNS:instantmessaging,e-mail,VoIP,etcetera.

Alloftheseservicescanbesubvertedthroughthe

Kaminskyattack.DeployingDNSSECcanpreventthis

lineofattack.

2.6 Hw dnSSec ss hs mThemaingoalofDNSSECistointroduceauthentica-

tionofanswerstoDNSqueries.Thisisachievedusing

digitalsignatures.Toputitsimply:eachDNSrecordis

signedusingacryptographicalgorithmandresolvers

havethemeanstocheckthesesignaturesthusproving

theauthenticityoftheinformationsupplied.The

cryptographicalgorithmisstrongenoughtoprevent

casualsubversionbyanattacker.ThewayDNSSEC

worksisexplainedinmoredetailinchapter3.

Toputthissolutionintheperspectiveoftheanalogy

ofroadsigns:byusingDNSSECaspecialcodeisprintedoneachroadsignthatcanbecheckedfor

authenticitythusprovingthattheroadsignis

genuineandcanbetrusted.

f 7 - ch h h s



14

WHat iS dnSSec?

3



16

3.4 ts hsAresolverneedstohaveastartingpointforthetrust

chainwhenitwantstovalidateaDNSresponse.Ide-

ally,thechainoftrustwouldstartattherootofthe

domainnamesystem.Unfortunately,therootzoneis

notsignedatthismoment9.Thismeansthatacom-

pletetrustchainfromtherootdownisnotpossible.Anotherissueisthattherecanbegapsinatrust

chain;DNSSECwasexplicitlydesignedtobede-

ployedinsuchamannerthattrustcanstartandend

atanypointinadomainpath.

Thismeansthataresolverwillneedtodecidewhich

trustchainsitisgoingtotrust.Onceithasdecided

this,itneedstoexplicitlytrustthepublicpartsofthe

signingkeysthatformtherootofthesetrustchains.

Thesearecolloquiallycalled“trustanchors”orsecure

entrypoints.

Forexample:ifthetop-leveldomain .isnotsignedbuts.andallthedomainsbelowaresigned,

atrustanchorforaresolverwouldbethepublickey

usedtosignthes.zone.

Similarlytothewayinwhichthehintslementioned

insection1.4providesaresolverwithinformation

abouttherootservers,thesetrustanchorsneedto

beconguredintheresolver.Thisgivestheadminis-

tratoroftheresolverultimatecontrolovertheparties

thataretobetrusted.

Atthetimeofwritingofthiswhitepaper,themajori-

tyoftop-leveldomainsaswellastherootzonere-

mainunsigned.Onlyahandfuloftop-leveldomains

supportDNSSEC.Alargernumberoftop-leveldo-

mainadministratorshaveannouncedthattheyare

goingtosupportDNSSECinthefuture.

3.5 iss sBecausetherootzoneisnotyetsigned,anydomain

currentlydeployingDNSSECwillformanislandof

trust.Thebigdisadvantageofthissituationisthat

anyresolvingpartyhastodecidewhomtotrust(i.e.

whichislands)andwillhavetonegotiatesomeway

ofestablishingtrustinkeymaterialsuppliedbythepartiesitwantstotrust.Figure9belowshowsanex-

ample.

Asitmaybesometimebeforetherootzoneis

signed–andeventhen,becauseofthedeployment

modelitisstillpossibleforislandsoftrusttoexist–it

isdesirabletondameansofestablishing“archipel-

agos”oftrust.Anarchipelagowouldbeacentraloff-

treeentityholdingthetrustanchorsforagroupof

trustislandswhichresolverscandecidetotrust,thus

trustingalltheislandsthatarepartofthearchipela-

go.Amechanismexiststoachievethis,calledDNS-

SECLook-a-sideValidation(DLV,seeFigure10).

3.6 asDNSSECsolvesthebasicsecurityawwithinDNS:

thefactthatanameservercannotknowwhethera

responseitreceivesfromanotherserverisgenuine,

oreventhatitcomesfromtherightserver.Thereare

severalotherinitiativestosecureDNS,butnoneof

thesesolvethisbasicawinascalablemanner.

AppendixEdiscussessomeofthesealternatives.

9 Although initiatives are being undertaken to do this at some

point in the future.

f 9 - iss s

f 10 - ah s s dlv



17

iMpleMenting dnSSec

4



18

4 iMpleMenting dnSSec

4.1 iThischaptergivesahigh-leveloverviewofhowto

implementDNSSEC.Itintroducesapossibletimeline

forDNSSECroll-out.Ahigh-levelstrategyfordeploy-

ingDNSSECwithinanorganisationwillalsobepre-sented.

Adetailedtechnicaldiscussiononhowtoroll-out

DNSSECcanbefoundinAppendixC.

4.2 tmBeforeastrategyforrollingoutDNSSECcanbedis-

cussed,itisimportanttoreectonthecurrentstate

ofaffairs.Atthetimeofwritingofthiswhitepaper,

largescaleadoptionofDNSSEChasnotyettaken

off.Aswasalreadymentionedinsection3.4,howev-

er,thereareindicationsthattheadoptionofDNSSECisgatheringmomentum.Thediagrambelowshowsa

possibletimelineforDNSSECdeploymentacrossthe

Internet,basedonthecurrentsituation:

Thegureshowsfourdistinctphases:

• Phaseoneistheresearchphase11,whichhasal-

readybeencompleted.Thisistheperiodduring

whichresearchersrealisedthatDNSneededtobe

secured,anddevelopedtheDNSSECstandard.

Duringthisphase,somezonesweresignedex-

perimentally.

• Phasetwoistheearly-adoptersphase.Thisisthe

phasewearecurrentlyin.Duringthisphase,ear-

ly-adopterslikeuniversities,researchinstitutions,

banks,somecompaniesandafewtop-leveldo-

mainsstartsigningtheirzonesanddeploying

DNSSEC.Theseearly-adoptersplayanimportantroleingatheringmomentumtoconvincemore

top-leveldomainstostartsupportingDNSSEC.

ThereissomesupportforDNSSECinmajoroper-

atingsystems.Duringthisphase,preparationsare

underwaytosigntherootandtheremainingtop-

leveldomains.

• Phasethreeisthecommodityphase.Having

gainedmomentum,DNSSECtakesoffasamulti-

tudeoftop-leveldomainsstartofferingsupport

forDNSSEC.Majoroperatingsystemsstartsup-

portingDNSSECout-of-the-box.Thenumberof

DNSSECenabledzonesgrowsrapidly.Therootzoneisexpectedtobesignedsomewhereduring

thisphase.

• Phasefouristhelatecomersphase.Thegrowthin

usageofDNSSECdiminishesasthemajorityof

zonesarealreadysigned.Growthisaccountedfor

bylatecomersadoptingDNSSECandbynewdo-

mainsbeingregistered.

f 11 - pss m dnSSec - ss h i

11 This phase started outside of the diagram during the latter part

of the 1990’s



19

4.3.4 S zs

Oncetheresolverinfrastructureisinplace,anorgani-

sationcanstartsigningtheirzonesandpublishing

theDNSSECenabledzonesontheirprimarynameservers.Thisrequiresamoresignicanteffort,as

toolsforsigningzonesare–atthemoment–less

readilyavailableandhaveahigherlearningcurve.

Managingthekeysforzonesigningistoocomplexto

bedonemanually,soasetoftoolsisnecessaryto

automatepartsoftheprocess.Especiallyforsmaller

organisationsand/orthosewithlesstechnicalexper-

tiseitisrecommendedtooutsourcesigningortoin-

vestinaDNSSECsignerappliance–thatis:adedi-

catedmachineinthenetworkthatcanperformall

theimportantsigningfunctionalityout-of-the-box12.

AspartoftheDNSSECdeployment,theorganisationwillhavetoestablishasetofproceduresforkey

managementandroll-over,andensurethatthereare

individualswithintheorganisationresponsiblefor

theseprocedures.IfITfunctionssuchasDNSman-

agementhavebeenoutsourced,someofthesere-

sponsibilitiesmaywellbeincludedintheoutsourced

service.However,theorganisationshouldtakecare

thatthisdoesnotresultinavendorlock-in.Appen-

dixDprovidessomehintsfororganisationswishing

tooutsourcetheseactivities.

4.3 S dnSSec s

4.3.1 Wh s

Soonerorlater,anyorganisationwithanykindofIT

infrastructurewillhavetoimplementDNSSEC.Even

organisationswithoutadomainnameoftheirownwillstillneedtoenableDNSSEC,inordertovalidate

theDNSdatafromotherdomains.

Themostimportantquestionthatneedsansweringis

whentostartrollingoutDNSSEC.Thisdependson

whatroleanorganisationhasinsociety,andonthe

levelofexpertisewithinanorganisation.Basedon

thephasesfromtheprevioussection,somerecom-

mendationsaregivenbelow:

• Inphasetwo(earlyadopters),organisationswith

arelativelyhigh-leveloftechnicalexpertisecan

startrollingoutDNSSEC.Suchorganisationswillincludeuniversities,researchinstitutions,ISPs,

banksandsometop-levelregistrars.Theroleof

theseearlyadoptersissignicant,astheyarethe

onesthatcreatethemomentumforalarge-scale

deploymentofDNSSECacrosstheInternet.Dur-

ingthisphase,toolsarestillmaturing.

• Inphasethree(commodity)almostanyorganisa-

tionshouldbeabletodeployDNSSEC.Toolshave

maturedandarecommonlyavailable.

• Itisnotrecommendedtostartaslateasphase

four(latecomers)asthiswillmakeanorganisa-

tionalikelytargetforattacks.

4.3.2 Wh s wh

TheimplementationofDNSSECwithinanorganisa-

tionactuallyconsistsoftwoseparateactivities:ena-

blingDNSSEConallrecursivecachingnameservers,

andsigningthezonesontheauthoritativename

servers.Theseactivitiescanbeexecutedsequentially.

4.3.3 rs

Anorganisationthatwantstostartdeploying

DNSSECshouldstartbyupdatingorreplacingtheir

recursivecachingnameservers(resolvers).Thereason

forresolvingsecurelyistwofold:

• Itallowsanorganisationtostartvalidating

DNSSECinformationfromzonesthatarealready

DNSSECenabled;

• Withoutit,itisimpossibletovalidateone’sown

zones.

Many(commercially)availableresolversalreadysup-

portDNSSEC,andwillonlyneedanupdateorapa-

rameterchange,aswellasacongurationchangeto

setupthetrust anchors.Otherresolversmayneeda

largerupgradeorareplacement.AppendixCpro-

videsanoverviewofthesesteps,underheadingC.2

“DNSSECforresolvers”.

12 Such appliances are starting to become available on the mar-

ket and there are also open source initiatives for making such

software available such as the OpenDNSSEC project

(http://www.opendnssec.org)



20

concluSionS

5



21

5.1 dnSSec s s dnSsss

Aswasshowninchapter2,DNShasmajorsecurity

issuesthataretherebydesign.DNSSECsolvesthese

issuesbygivingcondenceintheauthenticityofdo-maininformation.Spoongismuchharder,and

cachepoisoningisnolongerathreatwhenDNSSEC

isdeployed.

Noteverybodyhastoparticipateatoncetomake

DNSSECwork–thereisnoneedforabig-bangde-

ployment;thedesignofDNSSECallowsstartingany-

wherewithintheDNShierarchy.Organisationscan

startnow,withoutwaitingforothers.Themoreor-

ganisationsadoptDNSSEC,thestrongeritbecomes.

5.2 th s h mThereisnocrediblealternativetoDNSSEC,atleast

notinthelongterm.TheDNSpatchingarmsrace

thatiscurrentlyongoingisabattlethatwillmost

likelybelostinthelongrun,simplybecausesecurity

wasnotoneofthedesigncriteriawhenDNSwasde-

veloped.Althoughtherearesomealternatives,none

oftheseaddresstheactualproblemofverifyingthe

authenticityofDNSresponses.

ThismeansthatalthoughDNSSECismorecomplex

thanDNS,thereisnootheroptioninthelongrun.

5.3 M dnSSec s mm dnS

Ashasbeenexplainedinthiswhitepaper,different

skillsarerequiredtomanageaDNSSECenabled

zone.Thismayrequiresomechangesinanorganisa-

tionandmayrequireadministratorstoacquiresome

newskills.Itisimportanttonote,however,that

thereisalotofeffortongoingtomakemanaging

aDNSSECenabledzoneeasier.

DNSSECisbecomingeasiereveryday.Appliances

arealreadystartingtoappearonthemarket(includ-

ingopensourceinitiativessuchasOpenDNSSEC).

Toolingisalsomaturingquickly,rapidlymakingit

easiertoautomatemanyofthehardertasksin

DNSSEC.Andrecentlythirdpartieshavestarted

offeringhostedDNSSEC.

5.4 y TomaketheInternetsafer,DNSSECshouldbeadopt-

edbyeveryone.Thus,organisationsmuststartde-

ployingit.ImplementingDNSSECwillenableanor-

ganisationtosecureitsowndomain,andtovalidate

DNSdatafromothers.

5 concluSionS

Startingbyaddressingthechangesrequiredforre-

cursivecachingnameservers,thedeploymentcan

takeoff,andoncesetinmotion,signingzonesisonly

onestepaway.Itisofvitalimportancethattop-level

domainsgetsignedasquicklyaspossible,andthiswillonlyhappenifthestakeholdersinthesedomains

(theorganisationsthathaveasecondleveldomain

underthesetop-leveldomains)adoptDNSSECthem-

selves,thuspavingtheway.Earlyadoptersshouldbe

thoseorganisationsthathavetechnicalskillsavailable,

suchasuniversities,researchcentres,banksand–of

course–ISPs.



22

6 acknoWledgeMentS

SURFnetwouldliketothankthefollowingpeoplefor

theircontributiontothiswhitepaper:

Forco-authoringthewhitepaper:

• PaulBrandofStratix

• RickvanReinofOpenFortress

• DavidYoshikawaofStratix

Forreviewingthewhitepaper:

• JaapAkkerhuisofNLnetLabs

• AnandBuddhevofRIPENCC

• AartJochemofGOVCERT.NL

• PiotrKijewskiofNASK/CERTPolska

• OlafKolkmanofNLnetLabs

• EstherMakaayofSIDN

• KrzystofOlesikofNASK• JeroenvanOsofGOVCERT.NL

• CarolOveresofGOVCERT.NL

• AntoinVerschurenofSIDN

• WouterWijngaardsofNLnetLabs



23

Founded in 1992, the RIPE NCC is an independent,

not-for-prot membership organisation that supports

the infrastructure of the Internet. The most prominent

activity of the RIPE NCC is to act as a Regional Inter-

net Registry (RIR) providing global Internet resources

and related services to a current membership base ofover 6,000 members in 75 countries.

More information about the RIPE NCC is available at:

h://www..

SIDN is responsible for the functional stability and de-

velopment of the .nl Internet domain. As well as regis-

tering and allocating .nl domain names, the organisa-

tion enables Internet users all over the world to

make use of these labels at any given moment. SIDN’s

rapidly growing domain name register now contains

more than three million .nl domain names, which are

the subject subject of almost one million successful

searches a day.

SIDN also plays an active role in the technical, regula-

tory and political development of the Internet, at the

national and international levels

SURFnet develops and operates innovative services

for higher education and the research community. We

focus on network infrastructure, authentication and

authorisation services and multimedia platforms for

online collaboration. About one million end-users ac-

cess our services on a daily basis. SURFnet is part of

SURF, an organisation in which universities, polytech-

nics and research institutions collaborate on ground-

breaking ICT innovations. SURFnet has been a leader

in ICT innovation in The Netherlands for over 20 years.

Theorganisationslistedbelowhavecollaborated

withSURFnettomakethiswhitepaperpossible.

Byendorsingthiswhitepaper,theseorganisations

underlinetheimportanceofDNSSECforthesecurity

oftheInternet:

7 endorSeMentS

“GOVCERT.NL is the Computer Emergency Response

Team of the Dutch government. We work on prevent-

ing and dealing with IT security incidents 24/7. We

support organizations that carry out public tasks such

as government agencies, and work together with vital

sectors, such as water boards and energy companies.

We inform the general public about measures and cur-

rent risks regarding computer and Internet use.

Securing the basics of the Internet must be a priroity

of every organisation relying on trustworthy services

or providing public services on the Internet. The opin-

ion of GOVCERT.NL is that DNSSEC is an important

improvement of the integrity of DNS. Spreading

knowledge and advice about implementing the system

is needed and GOVCERT.NL is happy to endorse this

white paper.”

NLnet Labs is a research and development foundation

that focuses on those developments in Internet tech-

nology where bridges between theory and practical

deployment need to be built; areas where engineering

and standardisation takes place.

Since its foundation in 1999, NLnet Labs has been ac-

tive in DNSSEC standardisation, deployment engineer-

ing, training, and software development. NLnet Labs

developed NSD, an authoritative DNSSEC aware, high

performance name server in used by various root-zone

and top-level domain operators. We have assumed re-

sponsibility for the development of Unbound, a DNS-

SEC aware DNS recursive name server and stub resolv-

er and maintain the ldns and Net::DNS software library

suites.

OpenFortress Digital Signatures is a specialist in cryp-

tography, aiming to develop the general availability of

this useful technology in the form of practical applica-

tions that are easy to use. OpenFortress has keenly

awaited a wide adoption of DNSSEC since 2004.

OpenFortressdigital signatures

*



24

appendiceS



25

appendix a terMS and abbreviationS

a.1 tms

ah

Verifyingtheauthenticityofone’sidentity

ah m s

Anameserverthatisthebasesourceofinformation

aboutacertaindomain;thefactthatanameserveris

authoritativeforacertaindomainisindicatedinthe

so-called“start-of-authority”(SOA)resourcerecord.

d s

Acryptographicoperationbasedonpublickeycryp-

tographyusedtouniquelyprovethatagivenpiece

ofinformationistrustedbytheownerofagivenpri-

vatekey;theauthenticityofadigitalsignaturecan

beveriedusingthecorrespondingpublickey.

dm

AnamespaceintheDomainNameSystem;forin-

stance:surfnet.nl

Hs

Alecontainingthenamesandaddressesoftheroot

nameservers;thisleisdistributedbyInterNICon

theirwebsite.

Hs m

Themeaningfulnamegiventoacomputersystem.

kms

ThecachepoisoningattackontheDomainName

Systempublishedin2008byDanKaminsky.

Seealso:reference[5]

phsh

Identitytheftbyluringuserstoafraudulentwebsite

–usersareenticedtoentertheirprivatedatasuchas

theirusernames,passwordsandcreditcardnumbers

onaspoofedwebsitebyane-mailseeminglyfroma

partytheytrust.

Seealso:h://.w./w/phsh

p h

Anasymmetriccryptographicschemewithtwocom-

plementarykeys:thepublickeyandtheprivatekey.

Asignaturecomputedusingtheprivatekeycanbe

validatedusingthepublickey,converselyapieceof

datacanbeencryptedusingthepublickeyandde-

cryptedusingtheprivatekey.

Seealso: h://.w./w/p-_

h

rs (h) m s

Anameserverthatcanbeusedbyclientstoperform

DNSresolvingtasks;acachingserverwillstoreall

theanswersitreceivestoqueriesandre-usethese

whenappropriate.

rs

ApieceofsoftwarethatusesDNSserverstomapa

DNSnametoanIP-address.

rs UsuallyabbreviatedtoRR;aresourcerecordisanen-

tryintheDomainNameSystem.Thereareseveral

typesofresourcerecord.Themostcommonlyused

onesareArecordsformappinganametoan(IP-)

address.

Seealso:h://.w./w/ls__dnS_

_s

tm--

ThetimeperiodduringwhichananswertoaDNS

queryremainsvalidandcanthusbecached.

ts h

Thetopofatrustchainthatcanbeusedbyvalida-

torsasastartingpointtovalidatetheauthenticityof

asignedDNSrecordatanypointinthetrustchain.

v s

AresolverthatvalidatestheDNSSECsignatureson

theanswersitreceivestoDNSqueries.

v

Apieceofsoftwarethatveriestheauthenticityofa

digitalsignatureusingthepublickeythatwasused

tocreatethesignature.

Z

Acollectionofrelatedresourcerecordsthatisserved

asaunitbyanameserver.

Seealso:h://.w./w/dnS_z

Z w

Theabilitytoretrievethecompletecontentofazone

usingthesequenceofNSECrecordsinazone.



26

a.2 as

bind

BerkeleyInternetNameDomain(acommonlyusedDomainNameServerpackage)

dlvDNSSECLook-asideValidation

dnS

DomainNameSystem

dnSSec

DomainNameSystemSecurityExtensions

ietf

InternetEngineeringTask-Force

(seeh://www..)

ipInternetProtocol

iSp

InternetServiceProvider

kSk

KeySigningKey

lan

LocalAreaNetwork

nSd

NameServerDaemon

(acommonlyusedDomainNameServerpackage)

nSec3

NextSecureversion3,

partoftheDNSSECprotocol

rfc

RequestForComments(anIETFspecication)

SSl

SecureSocketLayer

tcp

TransmissionControlProtocol

tlS

TransportLayerSecurity

udp

UserDatagramProtocol

Wan

WideAreaNetwork

ZSk

ZoneSigningKey



27

appendix b referenceS

[1] WikiPedia:TheDomainNameSystem

h://.w./w/dm_m_ssm

[2] DNSandBIND

PaulAlbitzandCricketLiu,O’ReillyMedia,Inc.,FifthEdition,May26,2006

[3] WikiPedia:DNSSEC

h://.w./w/dnSSec

[4] WikiPedia:Public-KeyCryptography

h://.w./w/p-_h

[5] BlackOps2008:It’sTheEndOfTheCacheAsWeKnowIt

(or64Kshouldbeenoughforanyone)

h://www..m/dMk_bo2k8.

[6] RFC1034:DomainNames–ConceptsandFacilities

h://s../hm/1034

[7] RFC1035:DomainNames–ImplementationandSpecication

h://s../hm/1035

[8] RFC2845:SecretKeyTransactionAuthentication

h://s../hm/2845

[9] RFC4033:DNSSecurityIntroductionAndRequirements

h://s../hm/4033

[10] RFC4034:ResourceRecordsfortheDNSSecurityExtensions

h://s../hm/4034

[11] RFC4035:ProtocolModicationsfortheDNSSecurityExtensions

h://s../hm/4035

[12] RFC4431:TheDNSSECLookasideValidation(DLV)DNSResourceRecord

h://s../hm/4431

[13] RFC4635:HMACSHATSIGAlgorithmIdentiers

h://s../hm/4635

[14] RFC4641:DNSSECOperationalPractices

h://s../hm/4641

[15] AnillustratedguidetotheKaminskyDNSvulnerability

h://www.wz./hs/-ms-s-.hm

[16] ISC’sDNSSEClook-asidevalidationregistry

hs://www.s./ss/

[17] BootstrappingtheadoptionofInternetsecurityprotocols

h://ws2006.s./s/46.



28

b.1 fh Formoreinformationonthevariousaspectsof

DNSSECthereaderisreferredtothefollowingsources:

• th dnSSec sm w-s

h://www.ss.

Thissiteisasourceofup-to-dateinformationabout

DNSSECandthedeploymentofDNSSEConthe

Internet.

• th dnSSec HoW-to nlls

h://www.s./ws/s/

ss/ss_hw.

Atechnicalresourcewithhands-oninformation

aboutconguringasignedzone;examplesarebased

onBIND.

• nic.cZ m h://www..z//513/-ss/

High-levelinformationaboutDNSSEC;containsa

testingwidgetthatshows(usingeitheraredora

greenkey)whetherornotyouarrivedonthepage

fromaDNSSECsecureddomain.



29

appendix c tecHnical diScuSSion of dnSSec

c.1 iThisappendixaddressesthetechnicalandorganisa-

tionalimplicationsofimplementingDNSSECwithina

DNSinfrastructure.Itaddressesboththeissuesfor

resolversaswellasforauthoritativenameservers.

c.2 dnSSec ss

c.2.1 i

DNSSECrequiresresolverstoimplementvalidation

proceduresforDNSSEC.Althoughnotallsoftwareis

equippedwiththeseextracapabilities,themostim-

portantresolversare.WithBIND9itisamatterof

settingafewagsinthecongurationles,andWin-

dowsServer7willalsosupportDNSSECinitsroleas

aresolver.

c.2.2 cm w

Validatingresolversareconguredjustlikeany

cache,butmayneedabitmorecomputingpowerto

performtheirtask,asaresultofthepublickeycryp-

tographyinvolvedinthevalidationprocess.Theadd-

edperformancerequirementisaresultofcentralising

thecryptographicvalidationprocedures(ratherthan

haveeachdesktopcompletethevalidationonits

own)butitdoessaveontotalcomputingeffort,as

validatedresultscanbesharedamongindependent

desktops.ItisimportanttorealisethatdelaysinDNS

areexperiencedasdelays“intheInternet”.Experi-

mentsbytheDNSexpertsatNLnetLabsindicatethat

delaysarenotexpectedtobesevereenoughthat

theywarrantdedicatedcryptographicaccelerator

boardsinvalidatingresolvers.Intheestimated10%

to30%ofqueriesthatcannotbeansweredfromthe

cache,validatingthetrustchainmaycauseasome-

whatslowerresponse,butbearableonahuman

scale.Notethatscalinguponlymeansthatmorehits

aredeliveredfromacache.

c.2.3 S s hs

Withoutgoingintodetailsforspecicapplications,

itisgoodtobeawareoftheneedtoconguretrust

anchors.AswithX.509certicates,DNSSECneedsa

startingpointforitsrelationships(seesections3.3

and3.4).DNSSEChasbeendesignedtosupport

multiplestartingpointsforchainsoftrust.Foreach

oftheseentrypointsintotheDNSSEChierarchy,

thereisaso-calledtrustanchor,whichcomprisesof

DNSKEYrecordsortheirsecurehashesthathave

usuallybeenvalidatedout-of-bandbeforetheyare

trusted.Thenameserversoftwareshouldbecong-

uredtorelyonthesetrustanchors.

IANAhasbeencommissionedtosetupanInterim

TrustAnchorRepositorythatwillhostvalidatingin-

formationforthekeysusedtosigntop-leveldomains

untiltherootzonehasbeensigned.Thisisatempo-

rarysolutionthatwillallowtimefortheresolutionof

thecomplexissuesrelatedtothecentralpositionof

therootzone.

c.2.4 l-s

TheintroductionofDNSSECforaparentzonesuch

asaTLDoraccTLDismoredifcultthansimply

signingone’send-userzones.Thisisaresultofgath-

eringalotofinformation,handlinglotsofkeyrollo-versandamoregeneralresponsibility.Asaresult,

childzonesarelikelytobesignedbeforetheirparent

zones.Asapragmaticsolutiontothisgeneration

gap,atemporaryconstructofDNSSEClook-aside

validation(orDLVforshort,see[12],[16])hasbeen

dened.Insteadofregisteringadomain’sDNSSEC

keyswithaparent,thisworksbyregisteringthemin

anotherdomainthathappenstocollectsuchkeys,

andmakesthemavailableforlook-asidevalidation

Tosetuplook-asidevalidation,thelook-asidedomain

collectsDLVrecords(whicharesimilartotheDS

recordsgeneratedfortheparent,exceptforthere-sourcerecordtype,see[12]formoredetails).Such

recordsarecreatedunderanotherdomain,sothat

theDLVrecordfors.couldbestoredfor

look-asidevalidationunder.s.bycreating

theDLVrecordunders...s..Aresolver

conguredwithatrustanchorfor .s.would

lookupanythingwithoutaDSintheparentasaDLV

recordunderthe.s.domain,andifitnds

oneitwilltreatitinawaysimilartoaDSrecordthat

shouldhavebeenfoundintheparentzone.

SincetheDLVdomainisalsoadomainlikeanyother,

andsinceitisusuallyvalidatedthroughDNSSEC,it

willbenecessarytofollow-uponkeyrolloveratthe

DLVdomain.Thiscanbedonemanually,aboutonce

ayear,oritcanbeautomatedifyourserversoftware

implementsRFC5011,andifthepublisheddomain

alsousesthatstandardtorevokekeysastheyhave

servedtheirusefullife.

c.2.5 S sss

Itcannotbeavoidedthatthesameresolverhandles

bothsecureandinsecuredomains;infact,DNSSECis

sometimesusedtoestablishadomain’sinsecurity.

Validatingresolversmustbeawareofthismixed

world-viewbecauseitwouldbeadramaticfailureif

anattackinthestyleofDanKaminsky’scouldbe

mountedagainstaninsecuredomainandletthatalter

asecuredomain’svalidatedrecords.Ifyouselectre-

solversoftware,pickonethatismature,soyoucan

relyonastrictseparationbetweensecureandinse-

curedata.



30

c.2.6 rs s

Thefollowingpointssumuptheissuesthathelpto

selectavalidatingresolver:

• DoestheresolversupportDNSSEC?

• CantheresolverbeconguredwiththeKSKfor

selecteddomains?• Cantheresolverbeconguredforlook-aside

validation;acceptingtheDLVKSKandsending

DLVrequeststoalook-asidedomain?

• Doestheresolverhavefacilitiestoupdatetrust

anchorsautomatically?(optional)

c.3 dnSSec h m ss

c.3.1 M s z

Inchapter3theconceptofzonesigningwasintro-

duced.Morespecically:theactualinformationbeing

signedaresetsofrelatedResourceRecords,alsocalledRRsets.AnRRsetcomprisesallresource

recordsofonetype,inoneclass,pertainingtoasin-

gleresource(e.g.alladdress(A)recordsintheInter-

net(IN)classforonespecichostname).AnRRset

canconsistofoneorseveralrecords.

Signedzonesshouldnotbemaintainedbyhand,as

thedatainthezonesistoocomplicatedforthat.In-

stead,automatedtoolsshouldbeusedtomanage

thesigningofdatainthezones.

c.3.2 k m mm

C.3.2.1 Algorithms

DNSSECisbasedonpublickeycryptography.RFC

4034(see[10])speciesthatthefollowingcrypto-

graphicalgorithmsmaybeused:

• DSA/SHA-1

• RSA/SHA-1

Fortworeasonsitisrecommendedonlytousethe

RSA/SHA-1algorithm:

• Security:DSAkeysareconstrainedtoamaximum

keylengthof1024bits;thismayimpactthesecu-

rityofDSAkeys

• Performance:SignaturevalidationofDSAsigna-

turesisanorderofmagnitudeslowerthansigna-

turevalidationofRSAsignatures.Thismainlyhas

animpactonvalidatingresolvers.

Inthefutureellipticcurvecryptographyisalsogoing

tobesupportedforDNSSEC.Currently,however,its

usehasnotbeenstandardisedyet.

C.3.2.2Keytypes

ThecurrentoperationalpracticeforDNSSECisto

useatwo-tieredkeymodel:

• AZoneSigningKey(ZSK)isusedtosignRRsets

withinazone

• AKeySigningKey(KSK)isusedtosignZoneSigningKeys

Eachofthesekeyshasitsownspecicproperties:

TheZSKisrelativelyshort-lived;therecommended

useperiodforasingleZSKaccordingtoRFC4641

(see[14])isonemonth.Itisalsorecommendedto

useamoderatekey-sizefortheZSK(intheorderof

magnitudeof1024bits).Thisisnecessaryinorderto

keepthetimeittakestosignazonewithinmanagea-

blelimits.

TheKSKislonger-lived;therecommendeduseperiodforasingleKSKaccordingtoRFC4641is1year.Itis

recommendedtouseaminimumkeysizeof2048bits.

Ifzonesigninghasbeendelegatedbyaparentzone

bymeansofaDSrecord,thenthisDSrecordshould

referencetheKSK.Thismeansthattheparentonly

hastobeinformediftheKSKisupdated.

C.3.2.3Keyrollover

TheKSKandZSKbothhavealimitedperiodofvalid-

ity.Thismeansthatitisnecessarytoperformkey

rolloversatregularintervals.Toallowtimeforinfor-

mationtopropagatethroughtheDNSandtoallow

timeincaseofunscheduledproblemsitisgood

practicetogivesubsequentkeysslightlyoverlapping

validityperiods.Forinstance:thevalidityperiodofa

KSKcouldbe13monthsandthevalidityofaZSK

couldbe1monthplusenoughtimetoletthelongest

TTL-valuesexpire,forinstance1week.

Itisalsogoodpracticetomakethenewkeysavaila-

blebeforetheirvalidityperiodcommences.Anew

KSKshouldideallybeannounced1monthpriorto

keyrolloverandanewZSKshouldideallybean-

nounced1weekpriortokeyrollover 13.Alternatively,it

ispossibletohavenon-overlappingkeyvalidity,but

tohavetemporarilyoverlappingsignaturesonDNS

records.Theformermethodiscalledpre-publication

ofkeys,thelatteristhedouble-signaturemethod.

13 Note: the time intervals given in this section are based on

the current best practice as described in RFC 4641 [14]; these

time intervals are not absolute, sensible variations are possible

and likely.



31

Thediagrambelowshowshowtheseoverlapping

periodscouldworkinpractice:

WheneverakeyrolloveroftheKSKistotakeplace,

theparentzoneshouldbeinformedandshouldbe

suppliedwithanewreferencerecord(calleddelega-

tionsigner,orDS)forthiskey.ThenewKSKshould

notbeusedforsigningofZSKsuntiltheparentzone

hasbeenupdated.

c.3.3 ah s (nSec/

nSec3)

C.3.3.1 Whyauthenticateddenialofexistenceis

necessary

ApracticalaspectofDNSisthatitprovidesanex-

plicitanswerifarequestedresourcerecorddoesnot

exist.Theseexplicitnegativeacknowledgements

avoidretriesandwaitingfortimeouts.Fromasecuri-

typerspective,however,thisintroducesathreatof

denial-of-serviceattacks.

Toavoidsuchattacks,theabsenceofaresource

recordmustbesigned.ButDNSSECworkswithofine

zonesigning,makingitimpossibletopredictany

queryagainstanynameandsignforitsabsence.

C.3.3.2NSECandzonewalking

Thesolutionisnottosignforthenamebeingabsent,

buttosortallnamesinazoneinacanonicalorder

andtosignforstatementslike“afterAcomesC”so

resolverscaninferthatBdoesnotexist.Tofacilitate

this,theNSECresourcerecordwasintroduced(see

[10]).Thisrecordliststhefollowinginformationfora

givenhostname:

• Thenexthostnametobelistedinthezoneac-

cordingtocanonicalordering

• Thetypesofrecordsexistingforthehostname

Asyoucanseethisclearlydenesthatagiven

record“A”isfollowedbyagivenrecord“C”inferring

thatnointermediaterecord“B”canexist.Italsogoes

ontoprovethatforthegivenrecord“A”onlysigned

RRsetsexistofthespeciedtypes.

Soifanameservergetsarequestfor“B”itsimple

respondswiththeNSECrecordfor“A”thusproving

inasecurewaythat“B”doesnotexist.

Along-timeshow-stopperforDNSSEChasbeenthe

lackofprivacyofthisconstruction;ifonegotholdof

thename“A”,itwouldbetrivialtogetalinkfromA

toCbasedontheNSECrecord,fromConecould

thengetalinktoK,fromKtoQetc.untiltheentire

zonehaseffectivelybeenenumerated.Thisiterative

processthatlistsallnamesinazoneiscommonly

called“zonewalking”.AlthoughDNSdataisusually

public14,manyfeltthistobeanunacceptableassault

ontheirprivacyand/ortheirabilitytoconcealexperi-

mentalorprivatesub-domainsfrompublicviewing

(whichwaspossiblebecauseitiscurrentlycommon

practicetodenyzonetransferstoanybutafew

trustedparties).

C.3.3.3 Howtosolvezonewalking:NSEC3

ArecentimprovementtoDNSSECaddressesjustthis

problemintheso-calledNSEC3resourcerecord.This

recordtypedoesnotlinkthenamesinadomain,but

thehashesofsuchnames.Aresponsethatexplains

thatBdoesnotexistunderadomainstartsbycalcu-

latinghash(B)=4323...andndsitspositioninanor-

deredlistofallnamesthatoccurinadomain.Per-

hapshash(Q)=381a...precedesthevalueofhash(B)

andhash(C)=7bbc...mightbethenext.Soanofine-

signedlink“after381a...comes7bbc...”isusedto

provethathash(B)=4323...doesnotoccur.

Key #2

Key is used for signing

Key has been announced but is not yet valid

Key is still valid but no longer used for signing

Key #3

Key #4

Key #1

Rollover #1

Rollover #2

Rollover #3

f 12 - k s

14 There are exceptions to this rule, for instance: private DNS

infrastructures behind a rewall



32

Sincethehashesusedarecryptographic/secure

hashes,itisnotpossibletoderivetheoriginalnames

QandCfromtheirhashes,sotheprivacy(ornon-it-

erability)oftheDNSzoneismaintainedwhileatthe

sametimesupportingtherequiredproofthataname

doesnotexistinthezone.

ThustheNSEC3recordismadeupof3things:

• Thehashofthehostnameitappliesto

• Thetypesofrecordsexistingforthehostname

• Thehashofthenexthostnameinthezonein

hashorder(thezoneissortedfrom0to

MAX(hash)andattheenditwrapsbacktothe

beginning)

So,intheexampleabove,ifanameservergetsare-

questfor“B”itsimplysendsbacktheNSEC3record

forhash(Q)allowingtheresolvertoverifythat“B”

doesnotexistinthegivendomain.Noteverypub-lisherwillpreferNSEC3overNSEC,sothetwowill

probablycontinuetoco-exist.

c.3.4 dm dnS s

NotallaboutDNSSECisglorious.IfDNSrecordsup-

datefrequently,asinsomedynamicusesofDNS,

twoproblemsarise:

• Newdataisnotauthenticateduntilasignatureis

made;

• Olddatamayoataroundasauthenticuntilits

signatureexpires

ThismeansthatDNSSECanddynamicityinDNSare

notanidealcombination.DynamicityforDNSSEC

couldbeimplementedwithshort-livedsignatures,

butthatleadstoalotofadditionalstressonDNS

cachesandresolvers,especiallyiftheyactivelyvali-

datethesignaturesonDNSrecords(whichisthe

mostlikelyinitialroll-outofDNSSEC).Thisisatleast

harmfulforthescalabilityofDNSSEC.

Below,afewproblemsthatareforeseeninexisting

networksarediscussed,aswellassomeproposed

workarounds.

C.3.4.1 LinkingDHCPtoDNSentries

ThemostcommonexampleofdynamicdatainDNS

isthemappingofaxedhostnametoadynamicIP.

WhenacquiringanIPnumberthroughDHCP,ahost

mayprovideahostname,oritshostnamemaybe

knownthankstoaregisteredMACaddress.Many

DHCPserverswillnotonlysupplyanIPleasetosuch

ahost,butwillregisterthemappinginDNSatthe

sametime.

ThedynamicityoftheseIPaddressesisusuallynot

anissue.Otherpartsofthenetwork,notablyrewalls

androuters,alreadyrequirexedIPaddressesfor

exceptionalsystemssuchasservers.Onlytheclient

systems,beingthosethatdonotpublishservices,

aretreatedaspartofauniformsetwithoutfurther

discriminationbasedontheirIPaddresses.

Thismeansthatweexpectthedynamicpartofmap-

pingsfromhostnametoIPaddresstocoverclients,

notservers.Sinceserversmaybecontactedfrom

anywhere,theirmappingisoftenvitaltoprotectwith

DNSSEC,andsincethesemappingsarestaticthat

oughttobenoproblem.Typicalclientsystemswith

theirdynamicname-to-IPmappingscanbeexemptedfromDNSSECprotectionwithoutmuchharm,since

nobodywillwanttocontactthemusingtheirDNS

name.

DNSSECoffersawayoutforsuchsecurityexemp-

tions.Aninsecuresub-domainofaDNSSECdomain

canbeconstructedbyreferringtoasub-domain’s

nameservers,butnotaccompaniedbyakey

reference;forexamplethesecureddomain

hwj. couldhaveasub-domain

.hwj.thatdoesnotsupportDNSSEC

butusesplainDNStomapnamestoIPaddresses.

Toconstructthis,thehwj.zonecontainsNSrecordsforthe .hwj.domain,but

containsnoDSrecord(s)for .hwj.,so

exemptionisexplicitlyveriablebywayofthesigna-

turesontheNSrecordsin hwj..

C.3.4.2DHCPforInternetServiceProviders

AspecicformofthedynamicityinDNSdueto

DHCPconcernsISPs.TheclientsofanISPmaywell

wanttorunservicesonanIPaddressthatisassigned

tothemthroughDHCP,whichmakestheIPaddress

dynamic,atleastintheory.

TheseDHCPassignmentstocableandDSLcustom-

ersareusuallyconstantoveralongperiod,andmay

thereforealmostbetreatedasstaticassignments--

withthesidenotethataproceduremustexisttoal-

terthemmanually.Thisisactuallythesortofsituation

thatDNSSECsupportsquitenicely,bywayofregular

resigningofazone.SettingupanewIPaddressunder

DNSSECisjustsomeextraworkthataddstothepro-

cedureofeditingtheusualDNSrecords.Wedonot

expectthistocausemajorproblemsinpractice.

DHCPleasesareusuallysuppliedforperiodsofa

weekorso,andtheseperiodsmaybesynchronised

withtheregularDNSSECsigningproceduretoeven

avoidtheoccurrenceofsignedfaultydatainDNS.

Intheidealsituation,theISPsignstheirdynamically

assignedrecordswithDNSSEC,andgiventhelong

leasetermfrommostISPsthatwouldnotleadto

scalingproblemsduetooverloadedsecureDNS

caches.Inanycase,ifacustomerofanISPdenes

theirowndomainandpointsittotheISP-suppliedIP

address,itispossibletosignthat;iftheISPisusing

DNSSECitcouldjustbeaCNAMEalias,butiftheISP

doesnotdenesecurerecordsitcouldbeanA

record(whichisformallywrongbutalsoiscommon

practice).

IfanISPdecidesnottosignthedynamicallybound

mappingofnamestoIPaddresses,itcanexplicitly

opt-outforsuchaddresses.Thisisdonewitha

DNSSEC-signedstatementthatasub-domainis



33

unsigned.Validatingresolverscanusethisstatement

toassurethatnobodyissuppressingasignaturebut

thatitissecuretoassumethatnosignatureisavaila-

ble.NotethatISPsfailingtosignthedynamicmap-

pingswillcauseadditionalArecordsincustomer’s

owndomains,soperhapsitisbettertoimplement

DNSSEConISP’sDHCPleases.Itisalsoworthnotingthatthereversetranslation(fromIPtohostname)

couldbesignedatthesametimeastheforward

translation(fromhostnametoIP).

C.3.4.3DynamicallychangingIPv6addresses

Intheinterestofprivacy,Windowshasadefaultfea-

tureunderIPv6toassignarandombottomhalfin

IPv6addresses,andtochangethemregularly.This

protectsagainstvisibilityofone’sMACaddress(in-

cludingthemanufacturercode)inthebottomhalfof

theaddress.Furthermore,sincewithIPv6thereisno

needforNAT,alladdressesarepublicandmaking

long-termaddressesknownontheInternetdoesnotprovidetheby-defaultsecurityofbeingbehindthe

client-onlylterofNAT.SuchdynamicIPaddresses

couldbeaproblemforDNSSECifithadtoupdateits

signatures.Fortunatelyhowever,thisdoesnotseem

tobenecessaryinthesituationsthatwecurrently

anticipate.

DynamicIPv6addressesareintendedforclientside

systems,andcontactingthemnormallyisn’tare-

quirement.Servermachineswilluseamanuallyset

xedIPv6addressoverwhichtheirserviceswillbe

acquired.Suchxedaddressesaresuitableforpubli-

cationinDNS,includingsignatures.

Normalsetupsdonotrequirethelookupofclient

systemsinDNS,sotheyneednotsupportDNSSEC;

butevenclientsystems(can)automaticallycreatea

xedIPv6addressbasedonaMACaddress,making

themsuitableforpublicationinsignedDNS.

Notethatoperatingsystemssupportxedanddy-

namicIPv6addressesatthesametime;itiscommon

practicetohavemultipleIPv6addressesco-existing

ononeinterface.Onlythestaticaddresseswouldend

upinDNS,withDNSSECprotection.Thedynamic

addresses,iftheyoccurinDNSatall,canbeinan

unsignedsub-domain,andDNSSECcanexplicitly

opt-outthatsub-domain.

C.3.4.4Dynamicsigninginnameservers

TheproblemsofsigningdynamiccontentinDNS

stemfromthecurrentpracticeofoff-linesigning.

FutureversionsofBIND–themostcommonlyused

softwareforDNSservers–aremostlikelygoingto

supporton-linesigning.Microsoftisalsoworkingon

DNSSECsupportforWindowsServer2008R2and

forWindowsServer7;itislikelythatthesewillalso

supporton-linesigningsincethiswouldberequired

forActiveDirectory.



34

appendix d outSourcing

d.1 iFormostorganisations,managingtheITinfrastruc-

tureisnotpartoftheircorebusiness.Inorderto

maintainaprofessionalITservice,theytendtoout-

sourceatleastpartoftheirITmanagementtospe-cialisedvendors.InmanycasestheauthoritativeDNS

serversfortheorganisation’sdomainwillbehosted

onanISP’sservers,andresolversmaybeinstalledin-

housebutmanagedbyanoutsideprovider.Thissitu-

ationhasimplicationsforthedeploymentofDNSSEC.

d.2 ds sssAsinanyoutsourcingarrangement,thedivisionof

responsibilitiesbetweentheorganisationandoutside

vendor(orvendors)willhavetobedenedcarefully.

Someareasthatanorganisationmaywanttoout-

source,inrelationtoDNSSEC,are:

• InstallingandconguringDNSSECenabledre-

solvers,authoritativeserversandsigners;

• ManagingDNSrelatedequipmenton-siteoroff-

site,orhostingDNSserversonthevendor’splat-

forms;

• Creating,storing,anddeployingKeySigningKeys

andZoneSigningKeys;

• Signingzonesanddeployingsignedzonesonthe

authoritativeservers.

Foreachoftheseactivities,thereshouldbesomeone

withintheorganisationwiththeoverallresponsibility,

whocanmonitorthevendor’sactivitiesandaddress

anyissuesthatarise.Theoutsourcingcontract

shouldmakeclearwhatthevendor’sresponsibilities

areincaseofaproblem,andwhowillassumeliability

foranyresultingdamages.

d.3 p s -Anyoutsourcingagreementwillhaveprovisionsin

casetheorganisationwantstomigratetoadifferent

vendor,orbringactivitiesbackin-house.However,

DNSSECintroducesafewpointsthatrequireextra

caretoavoidfuturedifcultiesinswitchingvendors:

• Clearagreementonthelegalownershipofcon-

gurationdataandcryptographickeys;

• Agreedprocedurestohandoverconguration

dataandcryptographickeystotheorganisation

ortoafuturevendorattheendofthecontract

(orearlier,ifnecessary);

• Agreedprocedurestoensurekeysremainavaila-

bletotheorganisationinthecaseofdisputes,

take-overorbankruptcyofthevendor.



35

appendix e alternativeS

e.1 iInthisappendixthepossiblealternativestoDNSSEC

areconsidered.

AlthoughDNSSECisapragmaticsolutionratherthananidealone,ithasclearadvantagesoverthealterna-

tivesavailable.Manyofthealternativesbelowfailon

accountofnotprotectingtheoriginofDNSdata.

AlthoughitispossibletoprotectDNSdatabypro-

tectingeverytransactionbetweeneveryclientand

server,thisisunreliableforanumberofreasons:

1. Achainofprotectedlinkscanbreakatitsweak-

estlink,meaningthatitisnotpossibletoenforce

minimumvalidationstandardsmerelybycong-

uringone’slocalresolver.Specically,itisnot

possibletoknowifalllinksareindividuallyse-

curedornot.BeingdependentonindependentlymanagedpartsoftheDNSinfrastructureerodes

thereliabilityofthesystemasawhole.

2. Betweeneverytwosecuredlinkssitsaname

server,eitheranauthoritativenameserverorare-

cursiveresolver.Evenifthelinksaresecure,then

thereisstilltheriskthatthenameserveritselfis

poisonedwithfalsedata,whichitwillhappilysign

uponforwarding.

3. AtsomepointinDNS,thereisaneedtoconnect

fromalocaldomaintoaremotedomain.This

happensmostoftenwhenarecursive/caching

nameserverstartsattherootnameserversand

proceedsdownwardintheDNStreeinorderto

resolveaquery.Therearequiteafewpractical

problemsrelatedtoprotectingeachlinksepa-

rately,especiallybecauseofthemultitudeof

serverstobecontacted.

e.2 th dnS ms Theeasiest“alternative”toDNSSECistodonothing.

Thatis,notrolloutanythingtosecureDNSandcon-

tinuepatchingsoftwareassoonasasecurityprob-

lemarises.

DNShasnotbeendesignedforsecurity,andname

serversoftwarecanonlycompensatetosomedegree.

Forexample,indefenceofDanKaminsky’sattack

therehavebeenpatchesthatusearandomportfor

sending/receivingtheDNSinformation.Thiseffective-

lyextendstheinformationtobeguessedbytheat-

tackerfrom16bitsto32bits.Thismaydeferthe

cachepoisoningproblemsfromallbutthemostde-

terminedattackersintheshortterm,butitissolely

dependentonthepossibilitytosqueezetheseextra

bitsoutoftheexistingsystems.Andtheresulting32

bitscanbynomeansbeclassiedasasecurelylarge

searchspacetodeferattacks.Itmerelymakesitsim-

plertodetectattackswithanintrusionprotectionsys-

tem,anditimprovesthechancesofshuttingdownan

attackerbywayofanintrusionpreventionsystem.

Rollingoutintrusiondetectionandprotectionsys-

temstoprotectalight-weightsystemlikeDNScan

beconsideredoverkill.Theintrusiondetectionsys-

temsmustbeverypowerfulsinceDNS,thankstoits

light-weightnature,canhandlequitealotofloadonasingleserver.Forinstance,itisnotuncommonfor

ISPstoserviceawholecountrywithonlyafewre-

cursiveDNSservers(DNScaches).Also,adeter-

minedattackermaysimplyreatrandominthefull

32-bitsearchspaceoveralongperiodoftime,call-

ingforintrusiondetectionsystemsthatrecognise

patternsoveralongperiod,whichisinfeasibleasthe

systemwouldhavetoconsidersomanyattackpat-

ternsatthesametime.

Thesortofattacksanddefencesthatarecurrently

appliedtoDNSareanarmsrace,battlingtomanipu-

lateorprotectthetechnicaldatacontainedintheIPandUDPheadersandtheDNSpayload.Theattacks,

iftheyarepublishedatall,usuallydemandinstant

patchesofone’ssystems,sotimeisoftheessence.

ThemajoradvantageofDNSSECisthatitintroduces

cryptographybywayofdigitalsignatures.Thebene-

tofcryptographyisthatitcreatesanincrediblegap

betweentheabilitiesofthedomainownerandanat-

tacker:Thesimplefactthataprivatekeyisinthe

possessionofadomainownerbutunknowntoanat-

tackerplacesthelatterinagreatlydisadvantaged

position.Potentialattackersknowthis,andwillgen-

erallyavoidattackingthecryptographicaspects.If

theremainingsoftwareiswell-written,noattackscan

realisticallybemounted.

Itcouldbearguedthatcryptographyisanarmsrace

ofitsown.This,however,isnotanarmsracethatin-

volveseverysingleDNSadministrator;itinvolvesac-

ademicandgovernmentinstitutionsthatworkon

generalcryptographicmechanismssuchasRSAand

SHA1.Thesemechanismsarewidelyusedandwidely

testedbyhighlyskilledpeople,andthegeneralten-

dencyistobeopenaboutanypossibleproblems

thatcouldcompromisesecurity.Afewdecennia

worthofexperiencewithcryptographicalgorithms

suggeststhatpracticalattackshardlyeverbreakan

algorithmcompletely,butmerelylettheirprotection

erodetosuchalevelthattheintroductionofalterna-

tivesisrequired.Thisallhappensatamuchslower

pacethanthearmsraceofDNSasitstandstoday.

e.3 tSig Sig(0)EarlyattemptstostandardiseDNSSEChaveinvolved

differentkindsofresourcerecords:TSIGandSIG(0).

Aswillbeexplained,thesearenotwithouttheir

usebuttheyareunsuitableforabroadroll-outof

DNSSEC.

TSIGisafacilityforasharedsecretbetweenapairof

hosts.ThesehostscanexchangenormalDNSinfor-

mation,andendwithasignaturebasedonthat



36

secret.Ifnopartybutthesetwohostsholdsthatin-

formation,itcanbeinferredthatnothirdpartycould

havecreatedthesignature.Themechanismislight-

weightandevenhasfacilitiesforkeyrollover15.Itis

usefulbetweenpairedhoststhathavealong-termre-

lationship(suchasprimaryandsecondarynameser-

versforadomain)butitcannotscaleuptoageneralsolutionforDNSSEC.Forexample,ifthe.comtop-level

domainweretobesignedwithTSIG,asharedsecret

wouldhavetobenegotiatedbetweenthe.comau-

thoritativenameserversandeveryresolvingname

serverontheInternet.Evenifthiswouldbetechnical-

lyfeasible,therewouldstillbetheproblemofco-ordi-

natingtheinitiationofthesharedsecrets.Clearly,a

public-keymechanismismoresuitedtothesituation

ofgeneralserversthatareopentoclientsanywhere.

Insituationswherethepairingcanbexedandsecrets

canbeexchangedhowever,TSIGremainsavaluable

mechanismduetoitssmallfootprint.

SIG(0)isapublic-keybasedmechanismthatsignsfor

selectedqueriesandresponses.AswithTSIG,thesig-

naturesaremadeforatransactionbetweenaclient

andaserver,butitdoesnotmaketheoriginofdata

veriable.BecauseSIG(0)signaturesmustbecon-

structedbytheresolver,itwouldoverloadthatdevice

ifusedtosupportvalidationofeveryquery;itshould

beusedsparingly.

AusefulapplicationofTSIG,TKEYandSIG(0)ina

DNSSEC-rolloutistoestablishasecurelinkbetweena

validatingresolverandarelativelydumblocalresolver,

suchasamodem/routerorasinglehostonthenet-

work.ThesewouldrequestaTKEYrecordsignedwith

SIG(0)usingatrustedkeyfortheconnectiontothe

validatingcache.TheTKEYrecordwouldrelaya

sharedsecrettotheclient,whichcanhenceforthbe

usedforlight-weightTSIGsecurity.Thesemechanisms

havetheiruses,butnotinaglobalroll-outofDNSSEC.

e.4 dnScDNSCurvesolvesanotherissuethanDNSSEC;DNSSEC

takestheviewpointthatinformationinDNSispublic,

anddoesnotneedencryption.Itcouldhoweverbear-

guedthattheactualDNStrafcdoescountasasecu-

ritythreat,eveniftheknowledgethatisexchangedis

public.Onabroadcastnetwork(cableInternet,WiFi)

onesharesamediumwithpotentiallyunreliableusers

whomaybequiteinterestedinlearningthatyouare

requestingdomaininformationforasensitivedomain

(suchasabank).

JustlikeTSIGandSIG(0),DNSCurveprotectsthe

query/responseexchangebetweenaclientanda

server.Itdoesnotprovideauthenticationoftheorigin

ofdata.NovelaboutDNSCurveisitsuseofelliptic

curvecryptography,beingamodernsetofpublickey

algorithmsthathashithertonotbeenstandardisedfor

useinDNSSEC.

e.5 ipsAssumingthatIPsecwouldbeomnipresent,itcould

sparktheideaofbeinganalternativetoDNSSEC.This

isnottruehowever--itmayhelptoauthenticatethe

remotepartybeingcontacted,butnottheoriginof

datathatisreceived.Iftheremotepartyisinanyway

compromised,itcanbeloadedwithinvaliddata.DNSSECisaboutvalidatingdatatohavecomefrom

thedesiredorigin,andnotjusttheproxythrough

whichtheinformationwasobtained.

Inadditiontothat,rollingoutIPsecrequiresevenmore

criticalmassthanDNSSEC,makingitunlikelytoever

hittheglobalInternet.Makingthisunlikelyisthefact

thatIPseciswidelyregardedtobea“boardstandard”,

fullofcompromisestokeeptoomanypartieshappy.

Theresultingstandardsaresofullofoptionsandalter-

nativesthatonecannotassumeinteroperabilityofsolu-

tionsbasedonthemerepremisethattheysupport

IPsec.

IPsecremainsusefulforgenerictrafcencryption

and/orauthenticationinalocallycontrolledenviron-

ment,actingasastandardisedVPN,butitisnotlikely

togainsufcienttractionforaglobe-spanningsecure

network.

e.6 SSl tlSFirstandforemost,noproposalshavebeenmadeto

secureDNSwithTLSoritspredecessorSSL.Theonly

relationbetweenDNSandtheseprotocolsisthatfacil-

itieshavebeenproposedtostoreX.509certicatesin

DNSresourcerecords.ThisapproachtreatsDNSasa

database,butithasnosecurityimplicationsforDNS

itself.

UsingTLS(orSSL)incombinationwithcerticates

couldhaveworked,ifthewholeinfrastructurebehind

itwouldn’thavebeensoriddledwithquestionsand

problems,rangingfromwhocontrolsthelistoftrust-

edrootcerticatestowhatitmeanstosignacerti-

cate.DNSSEContheotherhandgivesacleardeni-

tionofthesetechnicalissues.

ThestandardsforTLSandSSLareeasilymisinterpret-

edandthereisampleroomfordisagreementontheir

interpretation.Keepingthatinminditisasmallmira-

clethatbothstandardshavebeensowidelyadopted.

Themaincausefortheirpopularityisthattheyare

embeddedinbrowsers.Givenachoice,cryptogra-

phersgenerallypreferother,moretechnically-inclined

waysofapplication-packagingtheircryptographic

structures.

Finally,DNShasitsownrequirements,including

denselypackeddata(whichrulesoutX.509certi-

catescompletely)foroptimaluseofcacheandband-

width.Furthermore,itisdesirabletokeepthevalida-

tionprocessassimpleaspossible,inordertoretain

thelight-weightandalmost-instantnatureofDNSas

muchaspossible;interpretingcomplexstructures

suchascerticatechainsintroducescounter-produc-

tiveoverheadthatisunbearableinaDNSenvironment.

15 By means of the TKEY extension



37

colopHon

ahs

PaulBrand

RickvanRein

RolandvanRijswijk

DavidYoshikawa

e

RolandvanRijswijk

l h s

PaulEversdijk

iss

TychovanderKlip

ch © Surf b.v. 2008-2009

Thispaperisdistributedunderthetermsofthe

CreativeCommonsLicenseversion3.0

“Attribution-NonCommercial-ShareAlike”Netherlands

Acopyofthislicensecanbeobtainedonline:

http://creativecommons.org/licenses/by-nc-sa/3.0/nl/deed.en



SURFnet

Postbus19035

3501DAUtrecht

TheNetherlands

T+31302305305

F+31302305329

the impact and importance of dnssec

Documents