Table Of ContentA Security Evaluation of DNSSEC with NSEC3∗
JasonBau JohnC.Mitchell
StanfordUniversity StanfordUniversity
Stanford,CA,USA Stanford,CA,USA
[email protected] [email protected]
Abstract serversthatresultedintheredirectionofpopularwebsitesto
attacksitesforcustomersoftheseISPs[18]. Thoughinitial
softwarepatcheswereissuedwhichmadecache-poisoning
Domain Name System Security Extensions (DNSSEC) and
attacks much less likely to succeed, DNSSEC is proposed
Hashed Authenticated Denial of Existence (NSEC3) are
as a long-term solution to DNS data integrity [17] against
slated for adoption by important parts of the DNS hierar-
cache-poisoningaswellasin-path“man-in-the-middle”at-
chy, including the root zone, as a solution to vulnerabili-
tacks. As of August 2009, the operators of the .org, .com,
tiessuchas”cache-poisoning”attacks. Westudythesecu-
and .net Top Level Domains (TLDs) as well as the opera-
rity goals and operation of DNSSEC/NSEC3 using Mur𝜑,
torsoftheDNSrootzonehaveallannouncedplanstode-
a finite-state enumeration tool, to analyze security prop-
ploy DNSSEC/NSEC3 on their servers. Given the current
erties that may be relevant to various deployment scenar-
interest in DNSSEC/NSEC3, we feel it worthwhile to per-
ios. Oursystematicstudyrevealsseveralsubtletiesandpo-
formathoroughsecurityanalysisoftheprotocolinorderto
tentialpitfallsthatcanbeavoidedbyproperconfiguration
understanditsbenfitsandshortcomings.
choices, including resource records that may remain valid
aftertheexpirationofrelevantsignaturesandpotentialin- Duringthecourseofthisstudy,wefoundpotentiallyprob-
sertion of forged names into a DNSSEC-enabled domain lematicDNSSECconfigurationoptionsthatwereintention-
via the opt-out option. We demonstrate the exploitability ally included in the protocol design to support incremen-
ofDNSSECopt-outoptionsinanenterprisesettingbycon- tal adoption and to minimize the performance impact of
structing a browser cookie-stealing attack on a laboratory DNSSEC at the high-traffic top-level domains. We will
domain. Under recommended configuration settings, fur- highlight the DNSSEC/NSEC3 design trade-offs associ-
ther Mur𝜑 model checking finds no vulnerabilities within atedwiththeseoptions,theresultantpotentialdangers,and
our threat model, suggesting that DNSSEC with NSEC3 recommendDNSSECconfigurationchoicesforenterprise-
providessignificantsecuritybenefits. leveladministratorsconsideringDNSSECadoption.
As background, we review standard DNS and Kaminsky-
style cache-poisoning attacks. We then examine the se-
1 Introduction curity goals and limitations of DNSSEC/NSEC3, explain
its operations, and consider its effectiveness against cache
poisoning. We perform finite-state model checking of the
Domain Name System Security Extensions, or DNSSEC
DNSSEC/NSEC3protocolagainstsafetyinvariantsderived
[4, 5, 6], with Hashed Authenticated Denial-of-Existence
from its stated security goals. By identifying the parts
(NSEC3)[8]isasecuritystandardforDNSthathasbeenin
of DNSSEC packet content possessing cryptographic in-
developmentsinceatleast1999[1]. Briefly,DNSSECadds
tegrity, we define the capabilities of network attackers ex-
cryptographic signatures to standard DNS records to pro-
ecuting a man-in-the-middle attack on DNSSEC packets.
vide origin authentication and cryptographic integrity, but
The model checker identifies several security invariant vi-
notsecrecyorimprovedavailability,forthoserecords. Re-
olations, including resource records that remain valid af-
cently, DNS security has garnered quite a lot of interest,
ter the expiration of signatures attesting to their validity
due to the highly publicized DNS “cache-poisoning” vul-
and also protocol configurations that create an unsigned
nerability discovered by Dan Kaminsky [15, 22], and sev-
subspace in the DNSSEC namespace of a domain, allow-
eral actual exploits of this vulnerabilities on ISP-run DNS
ing forged names to be inserted into an otherwise secure
∗ThisupdatedMarch2,2010versioncorrectsandsupersedesapaper domain. We discuss how the first violation may pro-
withthesametitlethatappearsintheNDSS’10proceedings. long the vulnerability window if a private key is compro-
mised or signed records are successfully forged. Also, to 2 Background: DNSProtocol
demonstrate the exploitability of possible name-insertion,
we implemented an actual attack on a realistic laboratory
2.1 DNSBasics
DNSSECdomainmimickinganenterprisedeployment,ex-
ploiting the vulnerable configuration to steal user browser
cookies. Wethenincorporateprotocolconfigurationrepairs We first review the relevant background information on
intotheMur𝜑modelandverifythatnoexploitablevulner- DNS.Table2liststherelevantRFCsdefiningDNS.DNSis
abilities are detected. Based on our analysis, we provide a hierarchical distributed database that translates alphanu-
recommendations to domain operators, DNSSEC software meric domain names, such as www1.example.com, into
implementors,andwebsitedesignersthatmaximizethese- (most commonly) IPv4 and IPv6 addresses. DNS lookups
curityofDNSSECimplementationanddeployment. are ubiquitous as they must be performed before any net-
work resource, such as a website or a mail server, is ac-
During the process of writing up this work, a presentation cessed by its alphanumeric domain name. The domain
wasgivenbyDanielBernsteinatWOOT’09[12]pointing namesmaybethoughtofasdatabasekeysthatareusedto
outpossiblevulnerabilitiesinDNSSEC.Incomparison,our lookupavarietyofvalues,calledResourceRecords(RRs),
work further exposes the mechanisms behind the vulnera- associatedwiththekey. (The“key”domainnameiscalled
bilitiesandtherebyprovidesconfiguration/operationadvice theRR’s“ownername”inDNSparlance). Themostcom-
to eliminate exposure to attacks. For the replay vulner- mon RRs are IPv4 addresses (the A RR), IPv6 addresses
ability caused by signature-expiration mismanagement re- (theAAAARR),mailserversassociatedwithadomain(the
ported by Bernstein, we provide simple operational guide- MX RR), and name servers associated with a domain (the
linesthatpreventpossibleattacks. OneoverlapwithBern- NS RR). The values associated with the MX and NS RRs
stein’s presentation is the relatively minor observation of are in name and not IP address form. The set of all RRs
forgeableglueNSandArecordswithinDNSSECresponse of the same type belonging to the same owner name, e.g.
packets. While Bernstein correctly concludes this forgery multipleNSorARRs,istermedaRRSet.
raises security concerns, we explain why this forgery does
Wenowusethedomainnamewww.example.comasanex-
not actually add any capabilities for the network attacker
ampletoexplainDNSterminologyaswellasitshierarchi-
andthusdoesnotcreateadditionalexploitableattacks. Be-
caloperations. Thenamewww.example.comhasacanoni-
yond Bernstein’s presentation, we found and experimen-
calDNSformofwww.example.com.. Eachsuccessivela-
tallyconfirmedanattackusingNSEC3opt-outthatdoesnot
bel (“www”, “example”, “com”) in this form corresponds
requirecryptoanalysis. Infact,ourentireworkassumesun-
toalevelwithintheDNShierarchy(azone),andtheextra
forgeablecryptographicsignaturesinordertostudyattacks
trailingdot(“.”)attheendofthecanonicalDNSformisin-
possible even with adequate cryptography, complementing
sertedtosignifythepresenceoftherootzone,thetoplevel
Bernstein’s thoughts on breaking DNSSEC cryptography.
oftheDNShierarchy.
A summary of the contributions of this work, in terms of
securityviolationsdiscoveredandattackpreventionadvice, A DNS zone is named by zero or more labels, e.g. “ex-
islistedinTable1. ample.com.” and consists of a set of RRs over which the
zone is authoritative. The concept of authority is best
illustrated by example. For instance, a zone is authori-
Theremainderofthispaperisorganizedasfollows.Section
tative for all RRs whose owner name is the zone name
2reviewsstandardDNSandcache-poisoningattacks. Sec-
– the .com zone is authoritative over the NS and MX
tion 3 gives an overview of the security limitations, goals,
records for .com. A zone server is also authoritative over
andmechanismsofDNSSEC/NSEC3anddemonstratesits
RRs where 1) the owner name contain the zone name
effectiveness against cache-poisoning. Section 4 presents
as a suffix and 2) no “longer suffix” of the RR’s owner
ourfinite-statemodelofDNSSEC/NSEC3,thenetworkat-
name is also a authoritative zone. For example, the ex-
tacker model, and also the inconsistency in DNSSEC at-
ample.com zone is usually authoritative over the A record
testationchaintemporaldependenciesthatwefound. Sec-
forwww.example.com.,exceptwhenwww.example.comis
tion 5 presents the rest of the security violations reported
configured as its own zone, (possibly to support a domain
by finite-state model checking as well as the configuration
namesuchaswww1.www.example.com).
and implementation choices that eliminate them. Section
6 details our experiment confirming the exploitability of In addition to authoritative RRs, a zone may also store
the name-insertion property, using insecure delegation and gluerecordsthataidindelegation. GluerecordsareRRs,
NSEC3opt-outasillustrations. Finally,Section7presents typically A and NS, under the authority of child zones
our best-practice DNSSEC adoption and implementation but copied to parent zones for the purpose of “gluing” to-
adviceandconcludes. gether a delegation. For instance, the .com server may
SecurityPropertyViolations PreventAt PreventionAdvice Section
ResourceRecordremainsvalidinlocalresolver ResolverSoftware Resolver software sets RR TTL to depend 4.5.1
cacheafterexpirationofsignaturesorkey onallsignaturesinattestationchaintotrust
rollover(revocation)higherinattestationchain anchor
ISP Resolver software imposes an independent
(fromauthoritativezonevalues)caponTTL
andsignaturevalidityperiods
Gluerecordsmaybeforgedtodirectnext DomainOperator Useallsecuredelegations 5.1.1
recursivequerytoattackDNSserver ResolverSoftware Ifforgeryissuspected, querysupposedau-
thoritative zone to obtain signed version of
gluerecords.
(Even if no action is taken, this violation
does not result in acceptance of forged RR
asfinalqueryanswer.Seepapersection.)
NSEC3opt-outmaybeusedtoprependfalsified DomainOperator Do not set NSEC3 opt-out flag 5.1.3
ownernameindomain,asstatedinRFC5155,
resultinginvulnerabilitytocookie-theftand WebsiteDesigner Do not use overly coarse cookie “domain”
pharming setting
Replay of still valid A+RRSIG after IP-address DomainOperator Do not relinquish IP-address until all 5.1.4
move(Bernstein[12]) A+RRSIGshaveexpired
Inter-operation with standard-DNS child zones DomainOperator AdoptionofDNSSEC;Donotinteroperate 5.1.2
means insecure answer returned by DNSSEC re- DNSSECwithDNS
solver
Lackofend-usersoftwareindicatorofsecurevs. End-User Software Support DNSSEC by providing lookup se- 3.1.2
insecureDNSSECqueryresultexposesend-user (Browser/OS) curityindicatorsusingDNSSECADBit
toexploitableinsecureDNSSECqueryresult
Networkattackercanarbitrarilymanipulate ResolverSoftware Donottrustheaderbits. Resolvervalidates 5.3.1
DNSSECreplyheaderandstatusbits onlyusinginternalstateandsignedRRs.
ISPorOS Cannot trust remote DNSSEC validation
without secure channel. Provide secure
channelorvalidateallDNSSECRRslocally
NetworkattackercanaddrecordedRRs/subtract ResolverSoftware Build attested cache for answering user 5.3.1
RRs/manglebitsinRRsinDNSSECreplypacket queriesusingonlyauthoritativesignedRRs
containedinDNSSECreplies.
Table1.SummaryofRecommendations
Reply RRSetsinDNSReply RRSetsaddedbyDNSSEC
3 “com.NSa.gtld.net.” “com.DS”
2 Root Zone
3 (".") “a.gtld.net.A192.5.6.30” “RRSIG(DS)by.”
1 4 5 “example.com.NSa.iana.net.” “com.DNSKEY”
“a.iana.net.A192.0.34.43” “RRSIG(DNSKEY)bycom.”
8 5
“example.com.DS”
User PC Local TLD Zone
Stub Recursive 6 ("com.") “RRSIG(DS)bycom.”
Resolver Resolver 7 7 “www.example.com.A1.2.3.4” “example.com.DNSKEY”
“RRSIG(DNSKEY)by
example.com.”
Zone for
“RRSIG(A)byexample.com.”
"example.com."
8 “www.example.com.A1.2.3.4”
Figure 1. DNS(SEC) name resolution sequence for query “www.example.com A?" resolving to IP address
“1.2.3.4". Authoritative RRSets are in plain text and glue RRSets are in italic. The stub resolver is not ex-
pectedtohandleDNSSECRRs,sononearesenttoit.
DNS DNSSEC
RFC Relevance RFC Relevance
1034,1035 DNSDefinition 4033,4034,4035 DNSSECDefinition(NSEC)
2671 EDNS0 longer packets (used by 5155 NSEC3Definition
DNSSEC)
3833 ThreatanalysisofDNS 4641 DNSSECoperationalguidlines
2845 TSIGChannelSecurity 2535 DNSSECinitialproposal(AD,CDheader
bits)
2931 SIG(0)ChannelSecurity 3757 KeySigningKeys(KSKs)andZoneSign-
ingKeys(ZSKs)
Table2.RelevantDNSandDNSSECRFCs
storeboththetheNSrecordforexample.com,withavalue 2.2 DNSPacketFormat
of ns.example.com, and the A record for ns.example.com,
so that a single query response may contain all the infor-
mation needed to follow a delegation. However, the .com We will now briefly describe the DNS packet format
zonewouldnotbeauthoritativeovereithergluerecord;the and transmission characteristics and subsequently discuss
glue records fall under the authority of the example.com “cache-poisoning” attacks on DNS, conducted via both
server. “man-in-the-middle”and“out-of-path”means.
The format of a DNS packet is illustrated in Figure 2
Figure 1 illustrates a typical DNS lookup process, which
(DNSSEC packets are completely identical). DNS queries
involves two types of DNS resolvers, a stub resolver and
andresponsesareusuallycontainedinasinglesmallpacket,
a recursive resolver. Consider the name resolution pro-
less than 512 bytes, and are usually sent over UDP. This
cess that occurs after a user types www.example.com into
makes it fairly simple for network attackers to spoof DNS
the browser address bar. This triggers the DNS resolution
responses. TheonlyprotectionthattheDNSpacketformat
process of the stub resolver on the user’s PC, which then
provides against spoofing is in the 16-bit TXID (transac-
issues a query (“www.example.com A?”) to the local ISP-
tionID)field. ADNSresolverwillacceptasvalidthefirst
run DNS server. This server now becomes a local DNS
responsepacketcontainingaTXIDmatchingtheTXIDof
recursive resolver: it first queries the DNS root server for
an outstanding query. This creates a race condition for at-
the A RR of www.example.com. The root server is not
tackers: their spoofed responses to the DNS resolver must
authoritative for this information, so it issues a delegation
match an outstanding TXID before the actual response re-
response, pointing the local recursive resolver towards the
turns.
authoritativeserverforthe.comzone. Thisquery/response
pair occurs again between the recursive resolver and the
.com authoritative server, which leads to the resolver ob- 2.3 Cache-PoisoningAttack
taining the address of the authoritative DNS server of ex-
ample.com.Whentherecursiveresolverqueriestheauthor-
itative DNS server for example.com, it finally obtains an In a cache poisoning attack, the attacker spoofs a DNS re-
answerto“www.example.comA?”,whichitcanthenpass sponse packet so that a DNS resolver accepts and caches
back to DNS stub resolver on the user’s PC that initiated data “poisoned” by the attacker, such as an A RR of a
thisentireprocess. valid owner name pointing at the IP address of an attack-
ing server. The resolver then provides this poisoned data
To reduce DNS network traffic, each DNS server caches totheenduser,redirectingcommondomainnamerequests
RRstokeepfromissuingredundantrequests. DNSreplies (suchaswww.google.com)awayfromthelegitimateserver
include the specified caching period (TTL) of a returned toattackingservers[18].
RR, set by the authoritative zone. As an example, sup-
pose that the set of queries and responses in Figure 1 has
occurred recently, so that the TTL of caches records has 2.3.1 Man-in-the-Middle
not yet expired. When another user of same local recur-
siveresolverrequests“mail.example.comA?”,thelocalre- Man-in-the-middle attackers are attackers who have read
solver will be able to bypass steps 2-5 due to caching and andwriteaccesstonetworkpacketsbelongingtothevictim.
directlyquerythe“example.com.”authoritativeserverwith In this scenario an attacker can overhear the queries made
“mail.example.comA?”. bythelocalrecursiveresolvertotheremoteDNSzonesand
0 1516 2324 31 TXID = Transaction ID
QR = Query or Reply
UDP UDP Source Port UDP Dest Port Opcode = Typically 0 (QUERY)
Header UDP Length UDP Checksum AA = Authoritative Answer
UDP Source Port TC = Truncated
TXID QR Opcode AATCRDRA Z ADCD RCODE RD = Recursion Desired
DNS RA = Recursion Available
QDCOUNT ANCOUNT Z = Zero Bit
Header
AD = Authenticated Data
NSCOUNT ARCOUNT CD = Checking Disabled
RCODE: 0 = No Error
Question Section Answer Section RRs
2 = Server Failure or
Bogus DNSSEC data
Authority Section RRs Additional Section RRs DO
DO = DNSSEC OK (in EDNS0 header)
Figure2.DNSandDNSSECpacketformat. DObitisinEDNS0HeaderinAdditionalSectionRR
inject faux replies from the remote zones. As DNS is un- after only seconds of attacking the 16-bit TXID field. Af-
encrypted,itistrivialfortheman-in-the-middleattackerto terasuccessfulmatch,theresolverwillquerytheattacking
copy the correct TXID to generate an acceptable spoofed servertoresolveanyRRswithownernameendingin“ex-
DNS reply, which will then poison the cache of the recur- ample.com”, essentially giving the attacker full control of
siveresolver. the “example.com” zone for users of this resolver. After
thesuccessfulattack,allusersofapoisonedDNSresolver
thatattempttoaccess“example.com”willbedirectedtoa
2.3.2 Out-of-PathAttack serveroftheattacker’schoosing.
In order to address this vulnerability, Kaminsky worked
We will now discuss out-of-path DNS cache-poisoning at- with DNS software vendors to randomize the UDP source
tacks,ofwhichtherecentworkpublicizedbyDanKamin- port of DNS queries [9, 13]; these random ports become
sky [15] is the most infamous. In a Kaminsky attack, the thedestinationportsforDNSresponsepackets. Thiseffec-
attacker does not require the ability to overhear the outgo- tively adds 10-11 bits of entropy for the attacker, making
ingDNSrequestsgeneratedbythelocalrecursiveresolver. theexpectedsuccesstimeofanattackseveraltensofmin-
Instead, the ingenuity of the Kaminsky attack involves in- utesratherthanseconds. However,themitigationdoesnot
creasing the number of valid outstanding TXIDs, thus in- fundamentally prevent a spoofing packet success; it only
creasing the probability that a randomly generated spoof lowers the probability of such an event. This mitigation
TXIDwillmatchanoutstandingone. alsoprovidesnodefenseagainstman-in-the-middleattack-
ers.Therefore,manyresearchers,includingKaminskyhim-
The Kaminsky attack works with delegation responses
self [9, 17], have been actively supporting DNSSEC as a
rather than authoritative answers. The attacker issues
long-termsolutiontoDNSsecurityvulnerabilities, includ-
many DNS queries to a DNS recursive resolver for non-
ingcache-poisoning.
existent names sharing a common suffix zone, e.g. aN-
otExist.example.com, bNotExist.example.com, etc. (The
queries may also be coerced from a user, for instance by 3 DNSSECProtocol
an attacker-crafted web page containing these names in
<img>tags).ThiscreatesmanyvalidoutstandingTXIDsat
3.1 StatedSecurityGoalsandLimitations
therecursiveDNSresolver. Sinceallofthesequeriescon-
tainacommonsuffixzone(“example.com”), allresponses
coming from the “.com” zone will include NS and A glue DNSSEC, as the name implies, consists of a set of secu-
records for the name server of “example.com”. The at- rity extensions to the DNS protocol (see Table 2 for the
tackerthushasmanychancestopoisontheRRsforthe“ex- relevant RFCs). DNSSEC introduces additional security-
ample.com” name server at the resolver, by sending many related resource records with each reply, for the purpose
spoofeddelegationresponses(packet5fromFigure1)with ofprovidingcryptographicallysignedintegritytotheorig-
differentTXIDscontainingalteredNSandAgluerecords. inalDNSresourcerecords. ThismakesDNSSECeffective
Since the resolver will accept and cache the glue records against both types of cache-poisoning attacks described in
uponfindingamatch,thiscreatesaninstanceofthe“birth- Section 2.3. DNSSEC does not guarantee delivery of re-
dayproblem”[11]fromprobabilitythatcanleadtosuccess source records and doesnot provide integrity for unsigned
portionsofpackets. ItssecuritygoalsaredescribedinRFC 3.1.2 InteroperabilitywithDNSLimitations
4033asfollows:
Undercurrentspecifications,anyinter-operationwithstan-
“TheDomainNameSystem(DNS)securityextensionspro- dard DNS zones exposes the end-user of a DNSSEC re-
vide origin authentication and integrity assurance services cursive resolver to forgeable query results. When inter-
for DNS data, including mechanisms for authenticated de- operatingwithastandardDNSzone,aDNSSECrecursive
nialofexistenceofDNSdata.” resolvercannotverifytheintegrityofremotezonedatadue
to the lack of cryptographic signatures. For compatibility,
the recursive resolver still returns any responses from the
In RFC 4033, the authors explicitly distinguish DNSSEC
zone to the stub resolver, but without setting the AD se-
data (RR) security from channel security. DNSSEC pack-
curity indicator bit. Thus, whenever a DNSSEC recursive
ets, containing resource records carrying encoded-binary
resolvermustqueryastandardDNSzone,therecursivere-
cryptographic material, are typically carried in the clear
solverisforcedtoprovideananswerwithoutsecurityguar-
over UDP. Thus, the current paper is largely about the
antees to the stub resolver. As of this writing, end-user
implications of the DNSSEC design decision to provide
software accepts both secure and insecure results from the
data (RR) security rather than channel security. We will
stub resolver, without any user-interface elements to indi-
firstdiscussthelimitationsofDNSSEC,andthenconsider
cate the security of the lookup result. Thus, the current
in turn the three component DNSSEC data integrity goals
end-user cannot trust the security of DNS lookups even if
fromabove: originauthentication,dataintegrityassurance,
a DNSSEC recursive resolver with last-hop channel secu-
and authenticated denial-of-existence, and detail how the
rityisutilized. Whilethisisthefaultofend-usersoftware,
DNSSECprotocolattemptstoreachthesegoals,evenwith
not DNSSEC/NSEC3, this is still an issue that enterprise
in-the-clearcommunications.
networkadministrators(andapplicationdevelopers)should
recognize.
3.2 OriginAuthentication
3.1.1 “Last-Hop”Limitations
The need for origin authentication is possibly best under-
stoodinthecontextofpreventingcache-poisoningattacks.
RFC 4033 specifically states the “last-hop” between stub
As we described above, these attacks are possible because
resolver and recursive resolver (1 and 8 in Figure 1) may
the DNS recursive resolver will accept DNS data sent to
be out-of-scope for DNSSEC, to be protected via DNS
it by any computer connected to Internet (possibly with
channel security means such as SIG(0) [3] or TSIG [2].
a falsified source IP address) as long as the destination
ThisisbecauseinanticipatedDNSSECdeployment,cryp-
port/TXID fields match. There is no mechanism within
tographicsignaturesareexpectedtoflowfromauthoritative
DNS, aside from source IP address, that verifies the data
serversonlytolocalrecursiveresolvers,withstubresolvers
originatesfromanauthoritativeserverforaparticularzone.
onend-userPCsnotequippedtohandlesignatureverifica-
Tosolvethisissue,DNSSECprovidesaformofhierarchi-
tion.
cal public key infrastructure (PKI) which allows resolvers
to securely obtain the public key for a DNSSEC zone and
Asourfinite-stateanalysisisfocusedontheDNSSECpro-
to use this for authenticating signed data belonging to the
tocol, we consider last-hop security out-of-scope and des-
zone.
ignate the recursive resolver as the trusted end-point for
name resolution in the analysis. However, we emphasize DNSSEC introduces three new RRs to support this PKI:
that the channel security of this last hop is critically im- DNSKEY, RRSIG (RR Signature), and DS (Delegation
portanttoend-to-endDNSSECintegrity. Forexample,the Signer). The DNSKEY RR contains the binary-text-
recursive resolver marks the difference between two types encodedpublickeyalongwithrelevantkeyparameterssuch
ofresponsestothestubresolver: verifiablysecureanswers astheencryptionalgorithmused. Thezoneusesthecorre-
and insecure answers, with a single “Authenticated Data” spondingprivatekeytosignalloftheRRSetsoverwhichit
(AD) bit. Thus, attackers able to manipulate DNS replies is authoritative. Each signature over an RRSet is recorded
overthislasthopmayforgesecureanswerssimplybyset- inaRRSIGRR.TheDSverificationRRcontainsacrypto-
tingtheADbit. Inusagescenarioswherelast-hopsecurity graphic digest of a DNSKEY belonging to a child zone in
isabsent,suchasunencryptedwirelesshotspots,DNSSEC a delegation. The DS RR is considered under the author-
cannotguaranteedomain-namelookupintegritytotheend ityoftheparentzoneandcanthusbesignedbytheparent
user. zone (with a corresponding RRSIG). It is returned by the
parent sideof a delegationas an authenticatedpointer to a RRSIG containing the signature over the A record, as Re-
DNSKEY in the child zone. This [Parent DNSKEY 𝑠𝑖→𝑔𝑛𝑠 ply7inFigure1demonstrates.
𝑠𝑖𝑔𝑛𝑠
ParentDS → ChildDNSKEY]sequenceformsalinkin DNSSEC allows a zone only to sign RRs over which it is
an extensible attestation chain that can impart trust to any authoritative. Thismeansthatanygluerecordsincludedin
publickeyobtained viathechain, solongasthe chainbe- adelegationresponseareunsigned,asillustratedinReplies
ginsatatrustanchor. IntheDNSSECPKI,atrustanchor 3 and 5 from Figure 1. As Bernstein has noted and as we
is any DNSKEY or DS RR confirmed as trustworthy via willexplain,thesegluerecordsmaybeforged,causingthe
out-of-band means and configured in the resolver as trust- local resolver to query an attacking server in its recursive
worthy.Withtherecentannouncementofrootzonesigning, nextstep. WeshowinSection3.7,however,thatthisredi-
thisisexpectedtobetherootDNSKEY. rection does not allow the network attacker to influence to
endresultofnameresolution.
TheoperationoftheDNSSECPKIisillustratedinFigure1,
whichliststheDNSSECpacketcontentsforthenameres-
olution “www.example.com A?”, for which the DNSKEY 3.4 AuthenticatedDenialofExistence
of the “example.com.” zone are needed. Starting with the
DNSKEYoftherootzoneasthetrustanchor,Reply3pro-
Thus far, we have discussed how DNSSEC provides in-
vides the DS to attest to the DNSKEYs of “com.”. Re-
tegrity assurance for existent RRs. Authentication and in-
ply5addstheDNSKEYof“com.”andtheDStoattestto
tegrityisalsorequiredforresponsesdenyingtheexistence
theDNSKEY“example.com.”,whichisprovidedbyReply
ofanyRRsmatchingaquery.Ifauthenticationmechanisms
7.
didnotexist,forexample,anattackermaybeabletoforge
a response packet denying the existence of an existent do-
main name and have this response cached at the local re-
3.2.1 OriginAuthenticationwithRegularDNS
solverforlongperiods,creatingadirecteddenial-of-service
attack.
In order to inter-operate with non-SEC DNS implemen-
For performance reasons, development of an off-line
tations, DNSSEC must also provide for cases where a
methodwasastrongdesignconsiderationforauthenticated
DNSSEC zone has a non-DNSSEC parent or child zone.
denial of existence, preferable by top-level domain opera-
Inthe insecureparent zonecase, since thetrustchain can-
tors over on-line methods such as that proposed by RFC
notbeestablishedallthewaybacktotheDNSroot,either
4470[7]. TheinitialDNSSECschemeforthiscreatesRRs,
theDNSKEYofthesecurezoneoraDSgeneratedfromthe
namedNextSecure(NSEC),thatlistalloftheexistentRRs
DNSKEYmustbemanuallyconfiguredasatrustanchorat
belonging to an owner name within an authoritative zone,
therecursiveresolver.Whenthereisnosuchmanuallycon-
so that a resolver can verify the non-existence of an RR
figuredtrustanchor,noattestationchaincanimparttrustto
againsttheRRlistofitsownername. EachNSECRRalso
the DNSKEY of the secure zone. In this case, no records
containsthenextexistentownernameincanonicalform,so
fromthesecurezoneareverifiablebytherecursiveresolver
thatthenon-existenceofanownernamewithinazonemay
and all records ostensibly from the zone will passed on to
beshownbyreturningacoveringNSEC,whoseownerand
thestubresolverasaninsecureanswer.
nextexistentnamesbracketthequeriedname. Asanunde-
Inthecaseofaninsecurechildzoneofasecurezone,anin- sirable consequence, the entire contents of a zone may be
securedelegationwillbecreatedwithnoDSrecordwithin triviallyenumeratedbyfollowingNSECrecordsandmak-
thesecurezonepointingatthechildzone. Wewillseethat ingappropriatequeries.
thishassignificantsecurityconsequences.
An alternative scheme for hashed authenticated denial of
existence,namedNSEC3[8],isnearlyequivalenttoNSEC
3.3 IntegrityAssurance except that all owner names are cryptographically hashed
andnotavailableincleartext. Thecanonicalorderofexis-
tent names in NSEC3 is the hashed order. Under NSEC3,
Given the hierarchical PKI provided by DNSSEC, it is zoneenumerationofhashednamesremainstrivial, butthe
straightforwardforazonetoprovide“integrityassurance” attacker must expend computational resources in a dictio-
for its existent data. The zone signs all the RRSets over nary attack to learn the zone contents in cleartext. A salt
whichitisauthoritativeandtransmitstheRRSIGalongwith string is appended to each owner name, the same for each
theRRSetinitsreplies. Forexample, whenrespondingto nameinthedomain,inordertoeliminatepre-computation
the “www.example.com A?” query, the example.com au- ofdictionariesbyexplodingtheirsize. However, sincethe
thoritative server will transmit both the A record and the salt is available publically via a RR query, NSEC3 is still
vulnerabletotheleakageofRRownernamesafterfewdays (see Figure 1). DNSSEC does introduces a single enable
ofpost-querycomputation[12]. bit,DNSSECOK(DO),locatedintheEDNS0headercon-
tainedintheAdditionalSectionofDNSpackets. Italsode-
With NSEC, all owner names within the zone, including
finestwobitintheDNSheader: AuthenticatedData(AD),
namesonlyassociatedwithNSrecordsusedfordelegation,
which indicates that the sending server has validated the
form the NSEC “next owner” chain. In NSEC3, such an
RRsinthepacket,andCheckingDisabled(CD),whichtell
owner name may “opt-out” of the chain via a bit in the
upstreamserverstonotperformRRvalidation.
NSEC3 RR. When the “opt-out” bit is set in an NSEC3
record, one or more unsigned delegations may exist with The DNSSEC signature scheme only allows for individ-
ownernamesthathashestoavaluebetweenthetwohashed ual RRSets to be signed by an associated RRSIG record.
namesintheNSEC3RR.Opt-outallowstop-levelzonesto Thus, the integrity provided by DNSSEC is at individual
supportincrementaladoptionofDNSSECattheenterprise RRSet+RRSIG granularity. Essentially, the only guaran-
levelbyexcludingdelegationstoenterprisezonesnotsup- teeofDNSSECisthatitisimpossible,shortofprivatekey
porting DNSSEC from the NSEC3 chain. This saves the compromise, for a network attacker to create a RRSet and
TLDsthecomputationalcostofNSEC3-hashingthenames RRSIGpaircontainingmanipulateddatavalidlysignedby
ofnon-DNSSECchilddomains. the originating zone. We thus incorporate capabilities for
manipulatingallotheraspectsofDNSSECpacketsintoour
Whenaresolverreceivesasignedopt-outNSEC3RRcov-
attacker model, including stripping RRSIGs from RRSets,
ering its queried name, it must still consult unsigned in-
changingheaderbits, insertinganddeletingrecordedRRs,
formation, such as glue records indicating a delegation, to
etc. SeeSection4.4foradetaileddescription.
decide whether the query answer exists lower in the DNS
hierarchy. TheNSEC3opt-outoptionallowsinsecuredele-
gationsandthusanyRRstobeinsertedbyanattackerinto 3.7 RobustnessAgainstCachePoisoning
the “span” of the NSEC3 record [8]. This NSEC3 charac-
teristic,posingdangerstoenterprise-levelzonesbecauseof
DNSSEC is effective against the cache-poisoning attacks
trust implied by domain membership, forms one instance
described in Section 2.3. In the presence of the attacker
for the demonstrated attack that we will detail later in this
capabilities listed in Section 4.4, which model a man-in-
paper.
the-middle network attacker, our finite-state model check-
ingresultsinSection5.2demonstratethatsignedDNSSEC
3.5 TemporalSpecifications recordsobtainedusingonlysecuredelegationsarenotvul-
nerabletoforgery. Anend-usertrustingonlysecurequery
responsesisthussafefromsuchanetworkattacker.
UnderDNS,aRRinaDNSreplypacket includedaspec-
ificationofTTLasthetime, startingfromreplyreception, We will also now detail how DNSSEC successfully pro-
that the resolver may validly cache the RR. This specifi- tectsagainstout-of-path(Kaminsky)cache-poisoning. Re-
cation of TTL relative to packet reception makes DNS re- call that the Kaminsky attack works by redirecting the IP
ply packets susceptible to replay attacks. To avoid replay addresses associated with glue NS and A records, causing
vulnerability, DNSSEC introduces absolute-time temporal therecursiveresolvertoqueryaDNSservercontrolledby
specificationsforitssignatures. EachRRSIGRRhasasig- anattacker. AsnotedbyBernstein,redirectionofthechild
naturevalidityperiod,statedasabsolutestartandendtimes. zonequerytoanattackingDNSSECserverisstillpossible
ThisintroducesadependencyofTTLtimesuponsignature underDNSSEC,sincegluerecordsareunsignedandforge-
validitytimesattheresolver,asTTLsforRRsmustnotre- able. However, with the DNSSEC protocol, a DS record
main valid for longer than the valid periods of signatures with RRSIG will also be sent in a secure delegation re-
attesting to these RRs. The absolute timing eliminates the sponse. The authenticity of this signed DS record is veri-
possiblyofreplayaftertheexpirationofthecorresponding fiable by the recursive resolver via the attestation chain (it
RRSIG. shouldnotfollowdelegationresponseswithoutasignedand
attestedDS),thusgivingtherecursiveresolverawaytover-
ifythepublickeyofthechildzone.
3.6 PacketFormat&AttackerCapabilities
Withatrustedpublickeyforthechildzone,theresolvercan
validate whether a RR contained in a response sent by the
Because DNSSEC operates solely by adding RRs to reg- attackingserverisproperlysignedbythechildzone. Short
ular DNS, its packet format is essentially unchanged from of key compromise, the attacking server therefore cannot
DNS(seeFigure2).Thesecurity-relatedDNSSECRRsare falsifyanysignedRRSetsinthischildzone, includingDS
carriedalongsidetheoriginalDNSRRsinthesamepacket records for further secure delegation. Since the ultimate
RRs requested by name resolution, usually A or MX, are 4.1 OverviewofMur𝜑Model
available in signed form in their authoritative zone, a re-
solver never has to rely on an unsigned record as its final
Our model is based on a typical usage scenario of the
answer. Thus, aslongasaDNSSECresolveracceptsonly
DNSSEC service. Table 3 summarizes this finite-state
RRSets appropriately signed by their authoritative zone as
model. We model three layers of the DNSSEC hierar-
final query answers, the response packets may come from
chy,representingrootzoneservers(“.”),TLDzoneservers
anyserver, redirectedornot, withoutallowingtheattacker
(“com.”),andanauthoritativeserverforasinglezone(“ex-
toviolatetheultimateintegrityofaDNSSECnameresolu-
ample.com.”).TherootzoneDNSKEYisourmodeledtrust
tion.
anchor. In the state machine, these zone servers are sim-
In fact, server redirection does not increase the packet ply modeled as a set of transition rules on network state;
forgery capabilities of the network attacker. Once an at- they do not introduce any additional state themselves. We
tacker has caused a recursive resolver to query its attack- alsomodelalocalrecursiveresolver, representingISP-run
ing DNSSEC server, it can form any type of response to DNSSEC resolvers, as a set of transition rules on network
the resolver that it chooses except create a valid RRSet stateaswellaslocalstate,representingnameresolutionsta-
and RRSIG pair signed with the zone’s private key. These tusandknowledgeoftheDNSSEChierarchy,suchaszone
are exactly the same capabilities that we ascribed to the keys, DS RRs, and server addresses. The network is sim-
man-in-the-middle network attacker in Section 3.6, albeit ply a set of modifiable packet state structures. The final
made more convenient for the attacker by eliminating the aspect of our model is the attacker model, which consists
race with a legitimate DNSSEC server. Thus, glue record both of transition rules modifying network state and addi-
forgery does not present any additional security threat to tionalstaterepresentingpacketknowledgerecordedbythe
DNSSEC beyond the normal capabilities of a network at- attacker.
tacker, though it may allow the attacker to more easily in-
hibitDNSSECperformancewithroguepacketsthat,forex-
4.2 Root, TLD, and Authoritative Servers
ample,consumeresolverCPUtime.
Model
4 FiniteStateModelChecking
The behaviors of the root, TLD, and authoritative zone
serversrequirenoserverstateandareentirelydescribedby
network state transition rules. Our modeled root and TLD
In order to evaluate the security of the DNSSEC proto-
behaviors are quite simple. They respond to network state
col,weperformedafinite-state“rationalreconstruction”of
containingaquerypacketaddressedtothemandwillwrite
DNSSEC using Mur𝜑 [14], a Nondeterministic Finite Au-
aresponsetothenetworkcontainingeitherasecuredelega-
tomaton (NFA) enumerator to check its operations against
tion,withDSandRRSIGauthoritativeRRsandNSandA
safety invariants derived from its stated security goals. In
glueRRs.
the rational reconstruction process, decribed in [21], the
mostbasicpartsoftheprotocolmessagesaremodeledand Themodeledbehavioroftheauthoritative“example.com.”
executedinthemodelchecker,toseeifanysafetyinvariants server is more complex, as it covers the entire set of zone
are violated. When invariants are violated, more protocol responses to an RR query. The full set is enumerated in
components are added until the invariants pass or cannot Figure4.3.1. Response1representsthesimplecasewhere
be passed. The entire process thus aids in understanding thequerymatchesanRRexistentinthezone. Responses2-
the component design of the protocol and ensures that the 4 represent when the query matches an existent delegation
properties expressed in the invariants test the functionality pointinsteadofanRRinthezone. Response2isthesecure
ofeachprotocolcomponent. delegation case. Responses 3 and 4 represent the options
foraninsecuredelegation: aNSgluerecordusedforinse-
Furthermore,sinceMur𝜑triesallpossiblecombinationsof
curedelegationinDNSSECmayeitherberecordedbythe
modeled attacker capabilities, when the reconstructed pro-
NSEC3 chain (response 3), or unrecorded, with the cover-
tocol runs to completion without violating any invariants,
ingNSEC3settingopt-outinstead(response4).
wemaydrawtheconclusionthattheprotocolpreservesthe
expressedsafetyinvariantsagainsttheattackerdescribedin Finally, responses 5 and 6 represent cases when the query
themodel. Inthissection,wewilldetailourreconstruction matchesneitherexistentRRnordelegation. Thezonemust
of the protocol, the network attacker mode, and the secu- thenindicatenon-existenceofthequeriedRRbyreturning
rity invariants. We will also report on an inconsistency in thecoveringNSEC3,whichmayhappentohaveopt-outset
thetemporaldependenciesoftheDNSSECattestationchain (response 5), or not (response 6). Our modeled authorita-
foundbyourmodeling. tivezonehasRRcontentthatwilleliciteachofthesesixre-
States TransitionRules
LocalResolverState LocalResolver
KnowledgeofTLDandAuthoritativeZone QueryGeneration
Address(andvalidity) 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑠𝑜𝑙𝑣𝑒𝑟𝑆𝑡𝑎𝑡𝑒→𝑁𝑒𝑡𝑤𝑜𝑟𝑘
DS(andvalidity) ReplyHandling
DNSKEY(andvalidity) 𝑁𝑒𝑡𝑤𝑜𝑟𝑘→𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑠𝑜𝑙𝑣𝑒𝑟𝑆𝑡𝑎𝑡𝑒
NamestoResolve(name1-name6) TTLandSignatureExpiration
Answer(andvalidity) 𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑠𝑜𝑙𝑣𝑒𝑟𝑆𝑡𝑎𝑡𝑒→𝐿𝑜𝑐𝑎𝑙𝑅𝑒𝑠𝑜𝑙𝑣𝑒𝑟𝑆𝑡𝑎𝑡𝑒
Network Root,TLD,andAuthoritativeZoneServers
SetofPackets QueryResponse
AttackerKnowledge 𝑁𝑒𝑡𝑤𝑜𝑟𝑘→𝑁𝑒𝑡𝑤𝑜𝑟𝑘
SetofPackets Attackers
LearningLegitimateReplies
𝑁𝑒𝑡𝑤𝑜𝑟𝑘→𝐴𝑡𝑡𝑎𝑐𝑘𝑒𝑟𝐾𝑛𝑜𝑤𝑙𝑒𝑑𝑔𝑒
ForgeryGeneration
𝐴𝑡𝑡𝑎𝑐𝑘𝑒𝑟𝐾𝑛𝑜𝑤𝑙𝑒𝑑𝑔𝑒,𝑁𝑒𝑡𝑤𝑜𝑟𝑘→𝑁𝑒𝑡𝑤𝑜𝑟𝑘
Table3.OverviewofDNSSECMur𝜑Model. ArrowsdenoteStatesRead→StatesWritten.
sponseswhenqueriesforname1throughname6aresentby mustexpirewhenthecorrespondingRRSIGsexpire;thisis
theresolver,allowingMur𝜑toenumerateallpossiblestates strictly enforced in our model by combining RR TTL and
ofanauthoritativezonerespondingtoaquery. RRSIG validity into a single entity. Also, all modeled va-
liditystatesinitializeto’expired’,andtransitionrulesexist
for each record that change a ’valid’ state to an ’expired’
4.3 LocalRecursiveResolverModel
state.
Themodeledlocalrecursiveresolvertriestoresolvetheset
4.3.2 ReplyValidationLogic
ofsixnamesthatelicitthefullrangeofDNSSECresponse
behavior as described in the previous section. These six
The local resolver model also contains logic that validates
namesalsoformthebasisofourinvariants,aswecheckthat
the contents of a reply packet and decides what actions to
the information associated with the names in the authori-
take with regards to the query based on received informa-
tative zone matches the understanding the resolver learns
tion. Thislogicisofutmostimportancetothesecurityofa
fromreplies.Theresolverstaterecordstheanswersupplied
DNSSECimplementation. Forexample,incorrectresolver
by the authoritative zone to each of the six query targets,
validationbehaviorthatacceptsunsignedRRsfromanex-
along with the temporal validity of the answer. When any
pected DNSSEC zone opens up a downgrade path for at-
answer is in the expired state, the resolver will try to re-
tackers to exploit. We distilled the guidance of RFC 4035
solvethecorrespondingnamebywritingaquerypacketto
intoourmodel.
theauthoritativezoneserver,provideditsknowledgeofau-
thoritativeserveraddressisvalid. Forthepurposeofquery- Inparticular,ourmodeledresolverplacesRRSetscontained
ing and authenticating replies, the local resolver state also in replies into two separate entities for use in this logic:
maintains TLD and authoritative zone address, DNSKEY, an Attested Cache, whose contents are secure RRSets that
and DS, and will appropriately query when these expire. haveafullattestationchainbacktothetrustanchor, anda
(TherootserveraddressandDNKSEYarenotmodeledas Non-Attested Cache, whose contents are RRSets the zone
resolverstatebecausetheyarehard-codedinaresolverim- expects to be insecure, such as glue records or data from
plementation). regular DNS zones. The attested cache consists of zone
DNSKEYsandDSesaswellassignedAandNSEC3RRs
from reply packets. For instance, to include an A record
4.3.1 TTLandSignatureExpiration signed by the authoritative zone in the attested cache, the
resolver’sTLDandauthoritativezoneDSesandDNSKEYs
We model validity expiration for all query answers and all must all be valid. The unattested cache consists of zone
serveraddresses,DNSKEYs,andDSs. InDNSSEC,allof addressesandgluerecordsfromreplypackets. RRSetsde-
thisinformationisstoredasaRR.RRshaveanassociated terminedtobebogus,suchasthosewithinvalidsignatures,
TTLand, ifsigned, alsoasignaturevalidityperiodforthe orindeterminate,suchasthosewithincompleteattestation
corresponding RRSIG. As per RFC 4033, TTLs for RRs chains, are discarded by validation logic. We believe that
