idnits 2.17.1 draft-ietf-dnsext-dns-threats-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2002) is 7826 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Schuba93' is defined on line 576, but no explicit reference was found in the text == Unused Reference: 'Vixie95' is defined on line 580, but no explicit reference was found in the text == Unused Reference: 'DNS-CONCEPTS' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'DNS-IMPLEMENTATION' is defined on line 586, but no explicit reference was found in the text == Unused Reference: 'HOST-REQUIREMENTS' is defined on line 589, but no explicit reference was found in the text == Unused Reference: 'DNS-CLARIFY' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'NCACHE' is defined on line 595, but no explicit reference was found in the text == Unused Reference: 'DNSSEC' is defined on line 598, but no explicit reference was found in the text == Unused Reference: 'EDNS0' is defined on line 601, but no explicit reference was found in the text == Unused Reference: 'TSIG' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'TKEY' is defined on line 608, but no explicit reference was found in the text == Unused Reference: 'SECURE-UPDATE' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'SIGNING-AUTHORITY' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'DNSSEC-ZONE-STATUS' is defined on line 617, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Galvin93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schuba93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Vixie95' ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2671 (ref. 'EDNS0') (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2845 (ref. 'TSIG') (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 3008 (ref. 'SIGNING-AUTHORITY') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 3090 (ref. 'DNSSEC-ZONE-STATUS') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-03) exists of draft-iab-sec-cons-01 Summary: 10 errors (**), 0 flaws (~~), 16 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Atkins 3 draft-ietf-dnsext-dns-threats-02.txt IHTFP Consulting 4 R. Austein 5 Bourgeois Dilettant 6 November 2002 8 Threat Analysis Of The Domain Name System 10 Status of this document 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 28 The list of Internet-Draft Shadow Directories can be accessed at 29 31 Distribution of this document is unlimited. Please send comments to 32 the Namedroppers mailing list . 34 Abstract 36 Although the DNS Security Extensions (DNSSEC) have been under 37 development for most of the last decade, the IETF has never written 38 down the specific set of threats against which DNSSEC is designed to 39 protect. Among other drawbacks, this cart-before-the-horse situation 40 has made it difficult to determine whether DNSSEC meets its design 41 goals, since its design goals are not well specified. This note 42 attempts to document some of the known threats to the DNS, and, in 43 doing so, attempts to measure to what extent (if any) DNSSEC is a 44 useful tool in defending against these threats. 46 1. Introduction 48 The earliest organized work on DNSSEC within the IETF was an open 49 design team meeting organized by members of the DNS working group in 50 November 1993 at the 28th IETF meeting in Houston. The broad 51 outlines of DNSSEC as we know it today are already clear in Jim 52 Galvin's summary of the results of that meeting [Galvin93]: 54 - While some participants in the meeting were interested in 55 protecting against disclosure of DNS data to unauthorized parties, 56 the design team made an explicit decision that "DNS data is 57 `public'", and ruled all threats of data disclosure explicitly out 58 of scope for DNSSEC. 60 - While some participants in the meeting were interested in 61 authentication of DNS clients and servers as a basis for access 62 control, this work was also ruled out of scope for DNSSEC per se. 63 DNS Transaction Signatures (TSIG) were eventually developed as a 64 separate mechanism to address threats of unauthorized access to 65 DNS's zone transfer and dynamic update mechanisms. 67 - Backwards compatibility and co-existence with "insecure DNS" was 68 listed as an explicit requirement. 70 - The resulting list of desired security services was 71 1) data integrity, and 72 2) data origin authentication. 74 - The design team noted that a digital signature mechanism would 75 support the desired services. 77 While a number of detail decisions were yet to be made (and in some 78 cases remade after implementation experience) over the subsequent 79 eight years, the basic model and design goals have remained fixed. 81 Nowhere, however, does any of the DNSSEC work attempt to specify in 82 any detail the sorts of attacks against which DNSSEC is intended to 83 protect, or the reasons behind the list of desired security services 84 that came out of the Houston meeting. For that, we have to go back 85 to a paper originally written by Steve Bellovin in 1990 but not 86 published until 1995, for reasons that Bellovin explained in the 87 paper's epilogue [Bellovin95]. 89 While it may seem a bit strange to publish the threat analysis eight 90 years after starting work on the protocol designed to defend against 91 it, that is nevertheless what this note attempts to do. Better late 92 than never. 94 This note assumes that the reader is familiar with both the DNS and 95 with DNSSEC, and does not attempt to provide a tutorial on either. 97 For purposes of discussion, this note uses the term "DNSSEC" to refer 98 to the core hierarchical public key and signature mechanism specified 99 in the DNSSEC documents, and refer to TKEY and TSIG as separate 100 mechanisms, even though TKEY and TSIG are also part of the larger 101 problem of "securing DNS" and thus are often considered part of the 102 overall set of "DNS security extensions". This is an arbitrary 103 distinction that in part reflects the way in which the protocol has 104 evolved (introduction of a putatively simpler transaction model 105 certain operations), and perhaps should be changed in a future 106 revision of this note. 108 2. Known Threats 110 There are several distinct classes of threats to the DNS, most of 111 which are DNS-related instances of more general problems, but a few 112 of which are specific to peculiarities of the DNS protocol. 114 2.1. Packet Interception 116 Some of the simplest threats against DNS are various forms of packet 117 interception: monkey-in-the-middle attacks, eavesdropping on requests 118 combined with spoofed responses that beat the real response back to 119 the resolver, and so forth. In any of these scenarios, the attacker 120 can simply tell either party (usually the resolver) whatever it wants 121 that party to believe. While packet interception attacks are far 122 from unique to DNS, DNS's usual behavior of sending an entire query 123 or response in a single unsigned, unencrypted UDP packet makes these 124 attacks particularly easy for any bad guy with the ability to 125 intercept packets on a shared or transit network. 127 To further complicate things, the DNS query the attacker intercepts 128 may just be a means to an end for the attacker: the attacker might 129 even chose to return the correct result in the answer section of a 130 reply message while using other parts of the message to set the stage 131 for something more complicated, for example, a name-based attack 132 (q.v., below). 134 While it certainly would be possible to sign DNS messages using TSIG 135 or IPsec, or even to encrypt them using IPsec, this would not be a 136 very good solution. First, this approach would impose a fairly high 137 processing cost per DNS message, as well as a very high cost 138 associated with establishing and maintaining bilateral trust 139 relationships between all the parties that might be involved in 140 resolving any particular query. For heavily used name servers (such 141 as the servers for the root zone), this cost would almost certainly 142 be prohibitively high. Even more important, however, is that the 143 underlying trust model in such a design would be wrong, since at best 144 it would only provide a hop-by-hop integrity check on DNS messages 145 and would not provide any sort of end-to-end integrity check between 146 the producer of DNS data (the zone administrator) and the consumer of 147 DNS data (the application that triggered the query). 149 By contrast, DNSSEC (when used properly) does provide an end-to-end 150 data integrity check, and is thus a much better solution for this 151 class of problems during basic DNS lookup operations. 153 TSIG does have its place in corners of the DNS protocol where there's 154 a specific trust relationship between a particular client and a 155 particular server, such as zone transfer, dynamic update, or a 156 resolver (stub or otherwise) that is not going to check all the 157 DNSSEC signatures itself. 159 Note that DNSSEC does not provide any protection against modification 160 of the DNS message header, so any properly paranoid resolver must: 162 - Perform all all of the DNSSEC signature checking on its own, 164 - Use TSIG (or some equivalent mechanism) to insure the integrity of 165 its communication with whatever name servers it chooses to trust, 166 or 168 - Resign itself to the possibility of being attacked via packet 169 interception (and via other techniques discussed below). 171 2.2. ID Guessing and Query Prediction 173 Since the ID field in the DNS header is only a 16-bit field and the 174 server UDP port associated with DNS is a well-known value, there are 175 only 2**32 possible combinations of ID and client UDP port for a 176 given client and server. This is not a particularly large range, and 177 is not proof against a brute force search; furthermore, in practice 178 both the client UDP port and the ID can often be predicted from 179 previous traffic, and it is not uncommon for the client port to be a 180 known fixed value as well (due to firewalls or other restrictions), 181 thus frequently reducing the search space to a range smaller than 182 2**16. 184 By itself, ID guessing is not enough to allow an attacker to inject 185 bogus data, but combined with knowledge (or guesses) about QNAMEs and 186 QTYPEs for which a resolver might be querying, this leaves the 187 resolver only weakly defended against injection of bogus responses. 189 Since this attack relies on predicting a resolver's behavior, it's 190 most likely to be successful when the victim is in a known state, 191 whether because the victim rebooted recently, or because the victim's 192 behavior has been influenced by some other action by the attacker, or 193 because the victim is responding (in a predictable way) to some third 194 party action known to the attacker. 196 This attack is both more and less difficult for the attacker than the 197 simple interception attack described above: more difficult, because 198 the attack only works when the attacker guesses correctly; less 199 difficult, because the attacker doesn't need to be on a transit or 200 shared network. 202 In most other respects, this attack is similar to a packet 203 interception attack. A resolver that checks DNSSEC signatures will 204 be able to detect the forged response; resolvers that do not 205 themselves perform DNSSEC signature checking should use TSIG or some 206 equivalent mechanism to insure the integrity of their communication 207 with a recursing name server that does perform DNSSEC signature 208 checking. 210 2.3. Name Games 212 Perhaps the most interesting class of DNS-specific threats are the 213 name-based attacks. There are several variations within this class, 214 sometimes called "cache poisoning" or "fake authority" attacks. What 215 all of these attacks have in common is that they all involve DNS RRs 216 whose RDATA portion (right hand side) includes a DNS name. Any such 217 RR is, at least in principle, a hook that lets an attacker feed bad 218 data into a victim's cache, thus potentially subverting subsequent 219 decisions based on DNS names. 221 The worst examples in this class of RRs are CNAME, NS, and DNAME RRs, 222 because they can redirect a victim's query to a location of the 223 attacker's choosing. RRs like MX and SRV are somewhat less 224 dangerous, but in principle they can also be used to trigger further 225 lookups at a location of the attacker's choosing. 227 The general form of a name-based attack is something like this: 229 - Victim issues a query, perhaps at the instigation of the attacker 230 or some third party; in some the query itself may be unrelated to 231 the name under attack (ie, the attacker is just using this query as 232 a means to inject false information about some other name). 234 - Attacker injects response, whether via packet interception, query 235 guessing, or by being a legitimate name server that's involved at 236 some point in the process of answering the query that the victim 237 issued. 239 - Attacker's response includes one or more RRs with DNS names in 240 their RDATA; depending on which particular form this attack takes, 241 the object may be to inject false data associated with those names 242 into the victim's cache via the Additional section of this 243 response, or may be to redirect the next stage of the query to a 244 server of the attacker's choosing (in order to inject more complex 245 lies into the victim's cache than will fit easily into a single 246 response, or in order to place the lies in the Authority or Answer 247 section of a response where they will have a better chance of 248 sneaking past a resolver's defenses). 250 The common thread in all of these attacks is that response messages 251 allow the attacker to introduce arbitrary DNS names of the attacker's 252 choosing and provide further information that the attacker claims is 253 associated with those names; unless the victim has better knowledge 254 of the data associated with those names, the victim is going to have 255 a hard time defending against this class of attacks. 257 This class of attack is particularly insidious given that it's quite 258 easy for an attacker to provoke a victim into querying for a 259 particular name of the attacker's choosing, for example, by embedding 260 a link to a 1x1-pixel "web bug" in a piece of Text/HTML mail to the 261 victim. 263 DNSSEC should provide a good defense against most (all?) variations 264 on this class of attack. By checking signatures, a resolver can 265 determine whether the data associated with a name really was inserted 266 by the delegated authority for that portion of the DNS name space 267 (more precisely, a resolver can determine whether the entity that 268 injected the data had access to an allegedly secret key whose 269 corresponding public key appears at an expected location in the DNS 270 name space with an expected chain of parental signatures that start 271 with a public key of which the resolver has prior knowledge). 273 DNSSEC signatures do not cover glue records, so there's still a 274 possibility of a name-based attack involving glue, but it should be 275 possible to detect the attack by temporarily accepting the glue in 276 order to fetch the signed authoritative version of the same data, 277 then checking the signatures on the authoritative version. 279 2.4. Betrayal By Trusted Server 281 Another variation on the packet interception attack is the trusted 282 server that turns out not to be so trustworthy, whether by accident 283 or by intent. Many client machines are only configured with stub 284 resolvers, and use trusted servers to perform all of their DNS 285 queries on their behalf. In many cases the trusted server is 286 furnished by the user's ISP and advertised to the client via DHCP or 287 PPP options. Besides accidental betrayal of this trust relationship 288 (via server bugs, successful server break-ins, etc), the server 289 itself may be configured to give back answers that are not what the 290 user would expect (whether in an honest attempt to help the user or 291 to further some other goal such as furthering a business partnership 292 between the ISP and some third party). 294 This problem is particularly acute for frequent travelers who carry 295 their own equipment and expect it to work in much the same way no 296 matter which network it's plugged into at any given moment (and no 297 matter what brand of middle boxes a particular hotel chain might have 298 installed when adding network drops in every guest room...). 300 From the protocol standpoint, the only difference between this sort 301 of betrayal and a packet interception attack is that in this case the 302 client has voluntarily sent its request to the attacker. The defense 303 against this is the same as with a packet interception attack: the 304 resolver must either check DNSSEC signatures itself or use TSIG (or 305 equivalent) to authenticate the server that it has chosen to trust. 306 Note that use of TSIG does not by itself guarantee that a name server 307 is at all trustworthy: all TSIG can do is help a resolver protect its 308 communication with a name server that it has already decided to trust 309 for other reasons. Protecting a resolver's communication with a 310 server that's giving out bogus answers is not particularly useful. 312 Also note that if the stub resolver does not trust the name server 313 that is doing work on its behalf and wants to check the DNSSEC 314 signatures itself, the resolver really does need to have independent 315 knowledge of the DNSSEC public key(s) it needs to perform the check 316 (usually the public key for the root zone, but in some cases 317 knowledge of additional keys may also be appropriate). 319 It is difficult to escape the conclusion that a properly paranoid 320 resolver must always perform its own signature checking, and that 321 this rule even applies to stub resolvers. 323 2.5. Denial of Service 325 As with any network service (or, indeed, almost any service of any 326 kind in any domain of discourse), DNS is vulnerable to denial of 327 service attacks. DNSSEC does not help this, and may in fact make the 328 problem worse for resolvers that check signatures, since checking 329 signatures both increases the processing cost per DNS message and in 330 some cases can also increase the number of messages needed to answer 331 a query. TSIG (and similar mechanisms) have equivalent problems. 333 DNS servers are also at risk of being used as denial of service 334 amplifiers, since DNS response packets tend to be significantly 335 longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help 336 here either. 338 2.6. Authenticated Denial of Domain Names 340 Much discussion has taken place over the question of authenticated 341 denial of domain names. The particular question is whether there is 342 a requirement for authenticating the non-existence of a name. The 343 issue is whether the resolver should be able to detect when an 344 attacker removes RRs from a response. 346 General paranoia aside, the existence of RR types whose absence 347 causes an action other than immediate failure (such as missing MX and 348 SRV RRs, which fail over to A RRs) constitutes a real threat. 349 Arguably, in some cases, even the immediate failure of a missing RR 350 might be considered a problem. The question remains: how serious is 351 this threat? Clearly the threat does exist; general paranoia says 352 that some day it'll be on the front page of the New York Times, even 353 if we cannot conceive of a plausible scenario involving this attack 354 today. This implies that some mitigation of this risk is required. 356 Note that it's necessary to prove the non-existance of applicable 357 wildcard RRs as part of the authenticated denial mechanism, and that, 358 in a zone that is more than one label deep, such a proof may require 359 proving the non-existance of multiple discrete sets of wildcard RRs. 361 2.7. Wildcards 363 Much discussion has taken place over whether and how to provide data 364 integrity and data origin authentication for "wildcard" DNS names. 365 Conceptually, RRs with wildcard names are patterns for synthesizing 366 RRs on the fly according to the matching rules described in section 367 4.3.2 of RFC 1034. While the rules that control the behavior of 368 wildcard names have a few quirks that can make them a trap for the 369 unwary zone administrator, it's clear that a number of sites make 370 heavy use of wildcard RRs, particularly wildcard MX RRs. 372 In order to provide the desired services for wildcard RRs, we need to 373 prove two things: 375 - We need to prove the existance of the wildcard RR itself (that is, 376 we need to prove that the synthesis rule exists), and 378 - We need to prove the non-existance of any RRs which, if they 379 existed, would make the wildcard RR irrelevant according to the 380 synthesis rules the way in which wildcards are used (that is, we 381 need to prove that the synthesis rule is applicable). 383 Note that this makes the wildcard proof mechanism dependent upon the 384 authenticated denial mechanism described in the previous section. 386 DNSSEC does include mechanisms by which it is possible to furnish 387 wildcard proofs along the lines described above. 389 3. Weaknesses of DNSSEC 391 DNSSEC has some problems of its own: 393 - DNSSEC is complex to implement, and includes some nasty edge cases 394 at the zone cuts that require very careful coding. Testbed 395 experience to date suggests that trivial zone configuration errors 396 or expired keys can cause serious problems for a DNSSEC-aware 397 resolver, and that the current protocol's error reporting 398 capabilities may leave something to be desired. 400 - DNSSEC significantly increases the size of DNS response packets; 401 among other issues, this makes DNSSEC-aware DNS servers even more 402 effective as denial of service amplifiers. 404 - DNSSEC answer validation increases the resolver's work load, since 405 a DNSSEC-aware resolver will need to perform signature validation 406 and in some cases will also need to issue further queries. This 407 increased workload will also increase the time it takes to get an 408 answer back to the original DNS client, which will almost certainly 409 trigger both timeouts and re-queries. (Arguably, many current DNS 410 clients are already too impatient even before taking the further 411 delays that DNSSEC will impose into account, but that's a separate 412 topic for another document....) 414 - Like DNS itself, DNSSEC's trust model is almost totally 415 hierarchical. While DNSSEC does allow resolvers to have special 416 additional knowledge of public keys beyond those for the root, in 417 the general case the root key is the one that matters. Thus any 418 compromise in any of the zones between the root and a particular 419 target name can damage DNSSEC's ability to protect the integrity of 420 data owned by that target name. This is not really a change, since 421 insecure DNS has essentially the same problem, but it's not good 422 either. 424 - Key rollover at the root is really hard. Work to date has not even 425 come close to adequately specifying how the root key rolls over, or 426 even how it's configured in the first place. 428 - DNSSEC creates a requirement of loose time synchronization between 429 the resolver and the host creating the DNSSEC signatures. Prior to 430 DNSSEC, all time-related actions in DNS could be performed by a 431 machine that only knew about "elapsed" or "relative" time. Because 432 the validity period of a DNSSEC signature is based on "absolute" 433 time, a resolver must have the same concept of absolute time in 434 order to determine whether the signature is within its validity 435 period or has expired. An attacker that can change a resolver's 436 opinion of the current absolute time can fool the resolver using 437 expired signatures. An attacker that can change the zone signer's 438 opinion of the current absolute time can fool the zone signer into 439 generating signatures whose validity period does not match what the 440 signer intended. 442 - The mechanism for wildcard proofs in DNSSEC is fairly painful. At 443 various times there have been questions as to whether the proof 444 mechanism is completely airtight and whether it would be worthwhile 445 to optimize the wildcard proof mechanism for the common case in 446 which wildcards do not exist, but the main problem is just the 447 inherent complexity of the wildcard mechanism itself. This 448 complexity probably makes the code for generating and checking 449 wildcard proofs somewhat fragile, but since the alternative of 450 giving up wildcards entirely is not practical due to widespread 451 use, we are going to have to live with wildcards, and the question 452 just becomes one of whether or not the proposed optimizations would 453 make DNSSEC's wildcard proof mechanisms more or less fragile. 455 4. Other issues 457 [Odds and ends that don't yet fit anywhere else, to be revised...] 459 4.1. Interactions With Other Protocols 461 The above discussion has concentrated exclusively on attacks within 462 the boundaries of the DNS protocol itself, since those are the 463 problems against (some of) which DNSSEC was intended to protect. 464 There are, however, other potential problems at the boundaries where 465 DNS interacts with other protocols. This topic needs further study. 467 4.2. Securing DNS Dynamic Update 469 DNS dynamic update opens a number of potential problems when combined 470 with DNSSEC. Dynamic update of a non-secure zone can use TSIG to 471 authenticate the updating client to the server. While TSIG does not 472 scale very well (it requires manual configuration of shared keys 473 between the DNS name server and each TSIG client), it works well in a 474 limited or closed environment such as a DHCP server updating a local 475 DNS name server. 477 Major issues arise when trying to use dynamic update on a secure 478 zone. TSIG can similarly be used in a limited fashion to 479 authenticate the client to the server, but TSIG only protects DNS 480 transactions, not the actual data, and the TSIG is not inserted into 481 the DNS zone, so resolvers cannot use the TSIG as a way of verifying 482 the changes to the zone. This means that either: 484 a) The updating client must have access to a zone-signing key in 485 order to sign the update before sending it to the server, or 487 b) The DNS name server must have access to an online zone-signing key 488 in order to sign the update. 490 In either case, a zone-signing key must be available to create signed 491 RRsets to place in the updated zone. The fact that this key must be 492 online (or at least available) is a potential security risk. 494 Dynamic update also requires an update to the SERIAL field of the 495 zone's SOA RR. In theory, this could also be handled via either of 496 the above options, but in practice (a) would almost certainly be 497 extremely fragile, so (b) is the only workable mechanism. 499 There are other threats in terms of describing the policy of who can 500 make what changes to which RRsets in the zone. The current access 501 control scheme in Secure Dynamic Update is fairly limited. There is 502 no way to give find-grained access to updating DNS zone information 503 to multiple entities, each of whom may require different kinds of 504 access. For example, Alice may need to be able to add new nodes to 505 the zone or change existing nodes, but not remove them; Bob may need 506 to be able to remove zones but not add them; Carol may need to be 507 able to add, remove, or modify nodes, but only A records. 509 NOTE: Scaling properties of the key management problem here is a 510 particular concern that needs more study. 512 4.3. Securing DNS Zone Replication 514 As discussed in previous sections, DNSSEC per se attempts to provide 515 data integrity and data origin authentication services on top of the 516 normal DNS query protocol. Using the terminology discussed in [SEC- 517 CONS], DNSSEC provides "object security" for the normal DNS query 518 protocol. For purposes of replicating entire DNS zones, however, 519 DNSSEC does not provide object security, because zones include 520 unsigned NS RRs and glue at delegation points. Use of TSIG to 521 protect zone transfer (AXFR or IXFR) operations provides "channel 522 security", but still does not provide object security for complete 523 zones, so the trust relationships involved in zone transfer are still 524 very much a hop-by-hop matter of name server operators trusting other 525 name server operators, rather than an end-to-end matter of name 526 server operators trusting zone administrators. 528 Zone object security was not an explicit design goal of DNSSEC, so 529 failure to provide this service should not be a surprise. 530 Nevertheless, there are some zone replication scenarios for which 531 this would be a very useful additional service, so this seems like a 532 useful area for future work. In theory it should not be difficult to 533 zone object security as a backwards compatible enhancement to the 534 existing DNSSEC model, but the DNSEXT WG has not yet discussed either 535 the desirability of or the requirements for such an enhancement. 537 5. Conclusion 539 Based on the above analysis, the DNSSEC extensions do appear to solve 540 a set of problems that do need to be solved, and are worth deploying. 542 Security Considerations 544 This entire document is about security considerations of the DNS. 545 The authors believe that deploying DNSSEC will help to address some, 546 but not all, of the known threats to with DNS. 548 IANA Considerations 550 None known. 552 Acknowledgments 554 This note is based both previous published works by others and on a 555 number of discussions both public and private over a period of many 556 years, but particular thanks go to Steve Bellovin, Dan Bernstein, 557 Randy Bush, Olafur Gudmundsson, Allison Mankin, Paul Vixie, and any 558 other members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups 559 whose names and contributions the authors have forgotten, none of 560 whom are responsible for what the authors did with their ideas. 562 The authors would also like to thank Paul Mockapetris and Xunhua 563 Wang, both of whom sent useful information to the authors, about 564 which the authors have, as yet, done absolutely nothing. We were 565 listening, really, we just ran out of time before the draft deadline. 567 References 569 [Bellovin95] Bellovin, S., "Using the Domain Name System for System 570 Break-Ins", Proceedings of the Fifth Usenix Unix Security 571 Symposium, June 1995. 573 [Galvin93] Design team meeting summary message posted to dns- 574 security@tis.com mailing list by Jim Galvin on 19 November 1993. 576 [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name 577 System Protocol", Master's thesis, Purdue University Department 578 of Computer Sciences, August 1993. 580 [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of 581 the Fifth Usenix Unix Security Symposium, June 1995. 583 [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and 584 facilities", RFC 1034, November 1987. 586 [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation 587 and specification", RFC 1035, November 1987. 589 [HOST-REQUIREMENTS] Braden, R., Editor, "Requirements for Internet 590 Hosts - Application and Support", RFC 1123, October 1989. 592 [DNS-CLARIFY] Elz, R., and Bush, R., "Clarifications to the DNS 593 Specification" RFC 2181, July 1997. 595 [NCACHE] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)" 596 RFC 2308, March 1998. 598 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 599 2535, March 1999. 601 [EDNS0] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, 602 August 1999. 604 [TSIG] Vixie, P., Gudmundsson, O., Eastlake, D., and Wellington, B., 605 "Secret Key Transaction Authentication for DNS (TSIG)" RFC 2845, 606 May 2000. 608 [TKEY] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)" RFC 609 2930, September 2000. 611 [SECURE-UPDATE] Wellington, B., "Secure Domain Name System (DNS) 612 Dynamic Update" RFC 3007, November 2000. 614 [SIGNING-AUTHORITY] Wellington, B., "Domain Name System Security 615 (DNSSEC) Signing Authority" RFC 3008, November 2000. 617 [DNSSEC-ZONE-STATUS] Lewis, E., "DNS Security Extension Clarification 618 on Zone Status" RFC 3090, March 2001. 620 [SEC-CONS] Rescorla, E., Korver, B., and the Internet Architecture 621 Board, "Guidelines for Writing RFC Text on Security 622 Considerations", work in progress (draft-iab-sec-cons-01.txt), 623 October 2002. 625 Author's addresses: 627 Derek Atkins 628 IHTFP Consulting 629 6 Farragut Ave 630 Somerville, MA 02144 631 USA 633 Email: derek@ihtfp.com 635 Rob Austein 637 Email: sra@hactrn.net