idnits 2.17.1 draft-ietf-dnsext-dns-threats-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 2004) is 7308 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) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 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-07.txt IHTFP Consulting 4 R. Austein 5 ISC 6 April 2004 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. 64 - Backwards compatibility and co-existence with "insecure DNS" was 65 listed as an explicit requirement. 67 - The resulting list of desired security services was 68 1) data integrity, and 69 2) data origin authentication. 71 - The design team noted that a digital signature mechanism would 72 support the desired services. 74 While a number of detail decisions were yet to be made (and in some 75 cases remade after implementation experience) over the subsequent 76 decade, the basic model and design goals have remained fixed. 78 Nowhere, however, does any of the DNSSEC work attempt to specify in 79 any detail the sorts of attacks against which DNSSEC is intended to 80 protect, or the reasons behind the list of desired security services 81 that came out of the Houston meeting. For that, we have to go back 82 to a paper originally written by Steve Bellovin in 1990 but not 83 published until 1995, for reasons that Bellovin explained in the 84 paper's epilogue [Bellovin95]. 86 While it may seem a bit strange to publish the threat analysis a 87 decade after starting work on the protocol designed to defend against 88 it, that is nevertheless what this note attempts to do. Better late 89 than never. 91 This note assumes that the reader is familiar with both the DNS and 92 with DNSSEC, and does not attempt to provide a tutorial on either. 93 The DNS documents most relevant to the subject of this note are: 95 [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308], 96 [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535]. 98 For purposes of discussion, this note uses the term "DNSSEC" to refer 99 to the core hierarchical public key and signature mechanism specified 100 in the DNSSEC documents, and refers to TKEY and TSIG as separate 101 mechanisms, even though channel security mechanisms such as TKEY and 102 TSIG are also part of the larger problem of "securing DNS" and thus 103 are often considered part of the overall set of "DNS security 104 extensions". This is an arbitrary distinction that in part reflects 105 the way in which the protocol has evolved (introduction of a 106 putatively simpler channel security model for certain operations such 107 as zone transfers and dynamic update requests), and perhaps should be 108 changed in a future revision of this note. 110 2. Known Threats 112 There are several distinct classes of threats to the DNS, most of 113 which are DNS-related instances of more general problems, but a few 114 of which are specific to peculiarities of the DNS protocol. 116 2.1. Packet Interception 118 Some of the simplest threats against DNS are various forms of packet 119 interception: monkey-in-the-middle attacks, eavesdropping on requests 120 combined with spoofed responses that beat the real response back to 121 the resolver, and so forth. In any of these scenarios, the attacker 122 can simply tell either party (usually the resolver) whatever it wants 123 that party to believe. While packet interception attacks are far 124 from unique to DNS, DNS's usual behavior of sending an entire query 125 or response in a single unsigned, unencrypted UDP packet makes these 126 attacks particularly easy for any bad guy with the ability to 127 intercept packets on a shared or transit network. 129 To further complicate things, the DNS query the attacker intercepts 130 may just be a means to an end for the attacker: the attacker might 131 even choose to return the correct result in the answer section of a 132 reply message while using other parts of the message to set the stage 133 for something more complicated, for example, a name-based attack (see 134 below). 136 While it certainly would be possible to sign DNS messages using a 137 channel security mechanism such as TSIG or IPsec, or even to encrypt 138 them using IPsec, this would not be a very good solution. First, 139 this approach would impose a fairly high processing cost per DNS 140 message, as well as a very high cost associated with establishing and 141 maintaining bilateral trust relationships between all the parties 142 that might be involved in resolving any particular query. For 143 heavily used name servers (such as the servers for the root zone), 144 this cost would almost certainly be prohibitively high. Even more 145 important, however, is that the underlying trust model in such a 146 design would be wrong, since at best it would only provide a hop-by- 147 hop integrity check on DNS messages and would not provide any sort of 148 end-to-end integrity check between the producer of DNS data (the zone 149 administrator) and the consumer of DNS data (the application that 150 triggered the query). 152 By contrast, DNSSEC (when used properly) does provide an end-to-end 153 data integrity check, and is thus a much better solution for this 154 class of problems during basic DNS lookup operations. 156 TSIG does have its place in corners of the DNS protocol where there's 157 a specific trust relationship between a particular client and a 158 particular server, such as zone transfer, dynamic update, or a 159 resolver (stub or otherwise) that is not going to check all the 160 DNSSEC signatures itself. 162 Note that DNSSEC does not provide any protection against modification 163 of the DNS message header, so any properly paranoid resolver must: 165 - Perform all of the DNSSEC signature checking on its own, 167 - Use TSIG (or some equivalent mechanism) to ensure the integrity of 168 its communication with whatever name servers it chooses to trust, 169 or 171 - Resign itself to the possibility of being attacked via packet 172 interception (and via other techniques discussed below). 174 2.2. ID Guessing and Query Prediction 176 Since DNS is for the most part used over UDP/IP, it is relatively 177 easy for an attacker to generate packets which will match the 178 transport protocol parameters. The ID field in the DNS header is 179 only a 16-bit field and the server UDP port associated with DNS is a 180 well-known value, so there are only 2**32 possible combinations of ID 181 and client UDP port for a given client and server. This is not a 182 particularly large range, and is not sufficient to protect against a 183 brute force search; furthermore, in practice both the client UDP port 184 and the ID can often be predicted from previous traffic, and it is 185 not uncommon for the client port to be a known fixed value as well 186 (due to firewalls or other restrictions), thus frequently reducing 187 the search space to a range smaller than 2**16. 189 By itself, ID guessing is not enough to allow an attacker to inject 190 bogus data, but combined with knowledge (or guesses) about QNAMEs and 191 QTYPEs for which a resolver might be querying, this leaves the 192 resolver only weakly defended against injection of bogus responses. 194 Since this attack relies on predicting a resolver's behavior, it's 195 most likely to be successful when the victim is in a known state, 196 whether because the victim rebooted recently, or because the victim's 197 behavior has been influenced by some other action by the attacker, or 198 because the victim is responding (in a predictable way) to some third 199 party action known to the attacker. 201 This attack is both more and less difficult for the attacker than the 202 simple interception attack described above: more difficult, because 203 the attack only works when the attacker guesses correctly; less 204 difficult, because the attacker doesn't need to be on a transit or 205 shared network. 207 In most other respects, this attack is similar to a packet 208 interception attack. A resolver that checks DNSSEC signatures will 209 be able to detect the forged response; resolvers that do not 210 themselves perform DNSSEC signature checking should use TSIG or some 211 equivalent mechanism to ensure the integrity of their communication 212 with a recursing name server that does perform DNSSEC signature 213 checking. 215 2.3. Name Chaining 217 Perhaps the most interesting class of DNS-specific threats are the 218 name chaining attacks. These are a subset of a larger class of name- 219 based attacks, sometimes called "cache poisoning" attacks. Most 220 name-based attacks can be at least partially mitigated by the long- 221 standing defense of checking RRs in response messages for relevance 222 to the original query, but such defenses do not catch name chaining 223 attacks. There are several variations on the basic attack, but what 224 they all have in common is that they all involve DNS RRs whose RDATA 225 portion (right hand side) includes a DNS name (or, in a few cases, 226 something that is not a DNS name but which directly maps to a DNS 227 name). Any such RR is, at least in principle, a hook that lets an 228 attacker feed bad data into a victim's cache, thus potentially 229 subverting subsequent decisions based on DNS names. 231 The worst examples in this class of RRs are CNAME, NS, and DNAME RRs, 232 because they can redirect a victim's query to a location of the 233 attacker's choosing. RRs like MX and SRV are somewhat less 234 dangerous, but in principle they can also be used to trigger further 235 lookups at a location of the attacker's choosing. Address RR types 236 such as A or AAAA don't have DNS names in their RDATA, but since the 237 IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of 238 IPv4 and IPv6 addresses, these record types can also be used in a 239 name chaining attack. 241 The general form of a name chaining attack is something like this: 243 - Victim issues a query, perhaps at the instigation of the attacker 244 or some third party; in some cases the query itself may be 245 unrelated to the name under attack (that is, the attacker is just 246 using this query as a means to inject false information about some 247 other name). 249 - Attacker injects response, whether via packet interception, query 250 guessing, or by being a legitimate name server that's involved at 251 some point in the process of answering the query that the victim 252 issued. 254 - Attacker's response includes one or more RRs with DNS names in 255 their RDATA; depending on which particular form this attack takes, 256 the object may be to inject false data associated with those names 257 into the victim's cache via the Additional section of this 258 response, or may be to redirect the next stage of the query to a 259 server of the attacker's choosing (in order to inject more complex 260 lies into the victim's cache than will fit easily into a single 261 response, or in order to place the lies in the Authority or Answer 262 section of a response where they will have a better chance of 263 sneaking past a resolver's defenses). 265 Any attacker who can insert resource records into a victim's cache 266 can almost certainly do some kind of damage, so there are cache 267 poisoning attacks which are not name chaining attacks in the sense 268 discussed here. However, in the case of name chaining attacks, the 269 cause and effect relationship between the initial attack and the 270 eventual result may be significantly more complex than in the other 271 forms of cache poisoning, so name chaining attacks merit special 272 attention. 274 The common thread in all of the name chaining attacks is that 275 response messages allow the attacker to introduce arbitrary DNS names 276 of the attacker's choosing and provide further information that the 277 attacker claims is associated with those names; unless the victim has 278 better knowledge of the data associated with those names, the victim 279 is going to have a hard time defending against this class of attacks. 281 This class of attack is particularly insidious given that it's quite 282 easy for an attacker to provoke a victim into querying for a 283 particular name of the attacker's choosing, for example, by embedding 284 a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail 285 to the victim. If the victim's mail reading program attempts to 286 follow such a link, the result will be a DNS query for a name chosen 287 by the attacker. 289 DNSSEC should provide a good defense against most (all?) variations 290 on this class of attack. By checking signatures, a resolver can 291 determine whether the data associated with a name really was inserted 292 by the delegated authority for that portion of the DNS name space 293 (more precisely, a resolver can determine whether the entity that 294 injected the data had access to an allegedly secret key whose 295 corresponding public key appears at an expected location in the DNS 296 name space with an expected chain of parental signatures that start 297 with a public key of which the resolver has prior knowledge). 299 DNSSEC signatures do not cover glue records, so there's still a 300 possibility of a name chaining attack involving glue, but with DNSSEC 301 it is possible to detect the attack by temporarily accepting the glue 302 in order to fetch the signed authoritative version of the same data, 303 then checking the signatures on the authoritative version. 305 2.4. Betrayal By Trusted Server 307 Another variation on the packet interception attack is the trusted 308 server that turns out not to be so trustworthy, whether by accident 309 or by intent. Many client machines are only configured with stub 310 resolvers, and use trusted servers to perform all of their DNS 311 queries on their behalf. In many cases the trusted server is 312 furnished by the user's ISP and advertised to the client via DHCP or 313 PPP options. Besides accidental betrayal of this trust relationship 314 (via server bugs, successful server break-ins, etc), the server 315 itself may be configured to give back answers that are not what the 316 user would expect (whether in an honest attempt to help the user or 317 to further some other goal such as furthering a business partnership 318 between the ISP and some third party). 320 This problem is particularly acute for frequent travelers who carry 321 their own equipment and expect it to work in much the same way no 322 matter which network it's plugged into at any given moment (and no 323 matter what brand of middle boxes a particular hotel chain might have 324 installed when adding network drops in every guest room...). 326 While the obvious solution to this problem would be for the client to 327 choose a more trustworthy server, in practice this may not be an 328 option for the client. In many network environments a client machine 329 has only a limited set of recursive name servers from which to 330 choose, and none of them may be particularly trustworthy. In extreme 331 cases, port filtering or other forms of packet interception may 332 prevent the client host from being able to run an iterative resolver 333 even if the owner of the client machine is willing and able to do so. 334 Thus, while the initial source of this problem is not a DNS protocol 335 attack per se, this sort of betrayal is a threat to DNS clients, and 336 simply switching to a different recursive name server is not an 337 adequate defense. 339 Viewed strictly from the DNS protocol standpoint, the only difference 340 between this sort of betrayal and a packet interception attack is 341 that in this case the client has voluntarily sent its request to the 342 attacker. The defense against this is the same as with a packet 343 interception attack: the resolver must either check DNSSEC signatures 344 itself or use TSIG (or equivalent) to authenticate the server that it 345 has chosen to trust. Note that use of TSIG does not by itself 346 guarantee that a name server is at all trustworthy: all TSIG can do 347 is help a resolver protect its communication with a name server that 348 it has already decided to trust for other reasons. Protecting a 349 resolver's communication with a server that's giving out bogus 350 answers is not particularly useful. 352 Also note that if the stub resolver does not trust the name server 353 that is doing work on its behalf and wants to check the DNSSEC 354 signatures itself, the resolver really does need to have independent 355 knowledge of the DNSSEC public key(s) it needs in order to perform 356 the check (usually the public key for the root zone, but in some 357 cases knowledge of additional keys may also be appropriate). 359 It is difficult to escape the conclusion that a properly paranoid 360 resolver must always perform its own signature checking, and that 361 this rule even applies to stub resolvers. 363 2.5. Denial of Service 365 As with any network service (or, indeed, almost any service of any 366 kind in any domain of discourse), DNS is vulnerable to denial of 367 service attacks. DNSSEC does not help this, and may in fact make the 368 problem worse for resolvers that check signatures, since checking 369 signatures both increases the processing cost per DNS message and in 370 some cases can also increase the number of messages needed to answer 371 a query. TSIG (and similar mechanisms) have equivalent problems. 373 DNS servers are also at risk of being used as denial of service 374 amplifiers, since DNS response packets tend to be significantly 375 longer than DNS query packets. Unsurprisingly, DNSSEC doesn't help 376 here either. 378 2.6. Authenticated Denial of Domain Names 380 Much discussion has taken place over the question of authenticated 381 denial of domain names. The particular question is whether there is 382 a requirement for authenticating the non-existence of a name. The 383 issue is whether the resolver should be able to detect when an 384 attacker removes RRs from a response. 386 General paranoia aside, the existence of RR types whose absence 387 causes an action other than immediate failure (such as missing MX and 388 SRV RRs, which fail over to A RRs) constitutes a real threat. 389 Arguably, in some cases, even the immediate failure of a missing RR 390 might be considered a problem. The question remains: how serious is 391 this threat? Clearly the threat does exist; general paranoia says 392 that some day it'll be on the front page of some major newspaper, 393 even if we cannot conceive of a plausible scenario involving this 394 attack today. This implies that some mitigation of this risk is 395 required. 397 Note that it's necessary to prove the non-existence of applicable 398 wildcard RRs as part of the authenticated denial mechanism, and that, 399 in a zone that is more than one label deep, such a proof may require 400 proving the non-existence of multiple discrete sets of wildcard RRs. 402 DNSSEC does include mechanisms which make it possible to determine 403 which authoritative names exist in a zone, and which authoritative 404 resource record types exist at those names. The DNSSEC protections 405 do not cover non-authoritative data such as glue records. 407 2.7. Wildcards 409 Much discussion has taken place over whether and how to provide data 410 integrity and data origin authentication for "wildcard" DNS names. 411 Conceptually, RRs with wildcard names are patterns for synthesizing 412 RRs on the fly according to the matching rules described in section 413 4.3.2 of RFC 1034. While the rules that control the behavior of 414 wildcard names have a few quirks that can make them a trap for the 415 unwary zone administrator, it's clear that a number of sites make 416 heavy use of wildcard RRs, particularly wildcard MX RRs. 418 In order to provide the desired services for wildcard RRs, we need to 419 do two things: 421 - We need a way to attest to the existence of the wildcard RR itself 422 (that is, we need to show that the synthesis rule exists), and 424 - We need a way to attest to the non-existence of any RRs which, if 425 they existed, would make the wildcard RR irrelevant according to 426 the synthesis rules that govern the way in which wildcard RRs are 427 used (that is, we need to show that the synthesis rule is 428 applicable). 430 Note that this makes the wildcard mechanisms dependent upon the 431 authenticated denial mechanism described in the previous section. 433 DNSSEC includes mechanisms along the lines described above, which 434 make it possible for a resolver to verify that a name server applied 435 the wildcard expansion rules correctly when generating an answer. 437 3. Weaknesses of DNSSEC 439 DNSSEC has some problems of its own: 441 - DNSSEC is complex to implement, and includes some nasty edge cases 442 at the zone cuts that require very careful coding. Testbed 443 experience to date suggests that trivial zone configuration errors 444 or expired keys can cause serious problems for a DNSSEC-aware 445 resolver, and that the current protocol's error reporting 446 capabilities may leave something to be desired. 448 - DNSSEC significantly increases the size of DNS response packets; 449 among other issues, this makes DNSSEC-aware DNS servers even more 450 effective as denial of service amplifiers. 452 - DNSSEC answer validation increases the resolver's work load, since 453 a DNSSEC-aware resolver will need to perform signature validation 454 and in some cases will also need to issue further queries. This 455 increased workload will also increase the time it takes to get an 456 answer back to the original DNS client, which is likely to trigger 457 both timeouts and re-queries in some cases. (Arguably, many 458 current DNS clients are already too impatient even before taking 459 the further delays that DNSSEC will impose into account, but that's 460 a separate topic for another document....) 462 - Like DNS itself, DNSSEC's trust model is almost totally 463 hierarchical. While DNSSEC does allow resolvers to have special 464 additional knowledge of public keys beyond those for the root, in 465 the general case the root key is the one that matters. Thus any 466 compromise in any of the zones between the root and a particular 467 target name can damage DNSSEC's ability to protect the integrity of 468 data owned by that target name. This is not a change, since 469 insecure DNS has the same model. 471 - Key rollover at the root is really hard. Work to date has not even 472 come close to adequately specifying how the root key rolls over, or 473 even how it's configured in the first place. 475 - DNSSEC creates a requirement of loose time synchronization between 476 the validating resolver and the entity creating the DNSSEC 477 signatures. Prior to DNSSEC, all time-related actions in DNS could 478 be performed by a machine that only knew about "elapsed" or 479 "relative" time. Because the validity period of a DNSSEC signature 480 is based on "absolute" time, a validating resolver must have the 481 same concept of absolute time as the zone signer in order to 482 determine whether the signature is within its validity period or 483 has expired. An attacker that can change a resolver's opinion of 484 the current absolute time can fool the resolver using expired 485 signatures. An attacker that can change the zone signer's opinion 486 of the current absolute time can fool the zone signer into 487 generating signatures whose validity period does not match what the 488 signer intended. 490 - The possible existence of wildcard RRs in a zone complicates the 491 authenticated denial mechanism considerably. For most of the 492 decade that DNSSEC has been under development these issues were 493 poorly understood. At various times there have been questions as 494 to whether the authenticated denial mechanism is completely 495 airtight and whether it would be worthwhile to optimize the 496 authenticated denial mechanism for the common case in which 497 wildcards are not present in a zone, but the main problem is just 498 the inherent complexity of the wildcard mechanism itself. This 499 complexity probably makes the code for generating and checking 500 authenticated denial attestations somewhat fragile, but since the 501 alternative of giving up wildcards entirely is not practical due to 502 widespread use, we are going to have to live with wildcards, and 503 the question just becomes one of whether or not the proposed 504 optimizations would make DNSSEC's mechanisms more or less fragile. 506 - Even with DNSSEC, the class of attacks discussed in section 2.4 is 507 not easy to defeat. In order for DNSSEC to be effective in this 508 case, it must be possible to configure the resolver to expect 509 certain categories of DNS records to be signed, which may require 510 manual configuration of the resolver, especially during the initial 511 DNSSEC rollout period when the resolver cannot reasonably expect 512 the root and TLD zones to be signed. 514 4. Topics for Future Work 516 This section lists a few subjects not covered above which probably 517 need additional study, additional mechanisms, or both. 519 4.1. Interactions With Other Protocols 521 The above discussion has concentrated exclusively on attacks within 522 the boundaries of the DNS protocol itself, since those are the 523 problems against (some of) which DNSSEC was intended to protect. 524 There are, however, other potential problems at the boundaries where 525 DNS interacts with other protocols. 527 4.2. Securing DNS Dynamic Update 529 DNS dynamic update opens a number of potential problems when combined 530 with DNSSEC. Dynamic update of a non-secure zone can use TSIG to 531 authenticate the updating client to the server. While TSIG does not 532 scale very well (it requires manual configuration of shared keys 533 between the DNS name server and each TSIG client), it works well in a 534 limited or closed environment such as a DHCP server updating a local 535 DNS name server. 537 Major issues arise when trying to use dynamic update on a secure 538 zone. TSIG can similarly be used in a limited fashion to 539 authenticate the client to the server, but TSIG only protects DNS 540 transactions, not the actual data, and the TSIG is not inserted into 541 the DNS zone, so resolvers cannot use the TSIG as a way of verifying 542 the changes to the zone. This means that either: 544 a) The updating client must have access to a zone-signing key in 545 order to sign the update before sending it to the server, or 547 b) The DNS name server must have access to an online zone-signing key 548 in order to sign the update. 550 In either case, a zone-signing key must be available to create signed 551 RRsets to place in the updated zone. The fact that this key must be 552 online (or at least available) is a potential security risk. 554 Dynamic update also requires an update to the SERIAL field of the 555 zone's SOA RR. In theory, this could also be handled via either of 556 the above options, but in practice (a) would almost certainly be 557 extremely fragile, so (b) is the only workable mechanism. 559 There are other threats in terms of describing the policy of who can 560 make what changes to which RRsets in the zone. The current access 561 control scheme in Secure Dynamic Update is fairly limited. There is 562 no way to give fine-grained access to updating DNS zone information 563 to multiple entities, each of whom may require different kinds of 564 access. For example, Alice may need to be able to add new nodes to 565 the zone or change existing nodes, but not remove them; Bob may need 566 to be able to remove zones but not add them; Carol may need to be 567 able to add, remove, or modify nodes, but only A records. 569 Scaling properties of the key management problem here are a 570 particular concern that needs more study. 572 4.3. Securing DNS Zone Replication 574 As discussed in previous sections, DNSSEC per se attempts to provide 575 data integrity and data origin authentication services on top of the 576 normal DNS query protocol. Using the terminology discussed in 577 [RFC3552], DNSSEC provides "object security" for the normal DNS query 578 protocol. For purposes of replicating entire DNS zones, however, 579 DNSSEC does not provide object security, because zones include 580 unsigned NS RRs and glue at delegation points. Use of TSIG to 581 protect zone transfer (AXFR or IXFR) operations provides "channel 582 security", but still does not provide object security for complete 583 zones, so the trust relationships involved in zone transfer are still 584 very much a hop-by-hop matter of name server operators trusting other 585 name server operators, rather than an end-to-end matter of name 586 server operators trusting zone administrators. 588 Zone object security was not an explicit design goal of DNSSEC, so 589 failure to provide this service should not be a surprise. 590 Nevertheless, there are some zone replication scenarios for which 591 this would be a very useful additional service, so this seems like a 592 useful area for future work. In theory it should not be difficult to 593 zone object security as a backwards compatible enhancement to the 594 existing DNSSEC model, but the DNSEXT WG has not yet discussed either 595 the desirability of or the requirements for such an enhancement. 597 5. Conclusion 599 Based on the above analysis, the DNSSEC extensions do appear to solve 600 a set of problems that do need to be solved, and are worth deploying. 602 Security Considerations 604 This entire document is about security considerations of the DNS. 605 The authors believe that deploying DNSSEC will help to address some, 606 but not all, of the known threats to the DNS. 608 IANA Considerations 610 None. 612 Acknowledgments 614 This note is based both previous published works by others and on a 615 number of discussions both public and private over a period of many 616 years, but particular thanks go to Jaap Akkerhuis, Steve Bellovin, 617 Dan Bernstein, Randy Bush, Steve Crocker, Olafur Gudmundsson, Russ 618 Housley, Rip Loomis, Allison Mankin, Paul Mockapetris, Thomas Narten 619 Mans Nilsson, Pekka Savola, Paul Vixie, Xunhua Wang, and any other 620 members of the DNS, DNSSEC, DNSIND, and DNSEXT working groups whose 621 names and contributions the authors have forgotten, none of whom are 622 responsible for what the authors did with their ideas. 624 As with any work of this nature, the authors of this note acknowledge 625 that we are standing on the toes of those who have gone before us. 626 Readers interested in this subject may also wish to read 627 [Bellovin95], [Schuba93], and [Vixie95]. 629 Normative References 631 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 632 RFC 1034, November 1987. 634 [RFC1035] Mockapetris, P., "Domain names - implementation and 635 specification", RFC 1035, November 1987. 637 [RFC1123] Braden, R., Editor, "Requirements for Internet Hosts - 638 Application and Support", RFC 1123, October 1989. 640 [RFC2181] Elz, R., and R. Bush, "Clarifications to the DNS 641 Specification" RFC 2181, July 1997. 643 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)" 644 RFC 2308, March 1998. 646 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 647 2671, August 1999. 649 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D., and B. 650 Wellington, "Secret Key Transaction Authentication for DNS 651 (TSIG)" RFC 2845, May 2000. 653 [RFC2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)" 654 RFC 2930, September 2000. 656 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 657 Update" RFC 3007, November 2000. 659 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 660 2535, March 1999. 662 Informative References 664 [RFC3552] Rescorla, E., Korver, B., and the Internet Architecture 665 Board, "Guidelines for Writing RFC Text on Security 666 Considerations", RFC 3552, July 2003. 668 [Bellovin95] Bellovin, S., "Using the Domain Name System for System 669 Break-Ins", Proceedings of the Fifth Usenix Unix Security 670 Symposium, June 1995. 672 [Galvin93] Design team meeting summary message posted to dns- 673 security@tis.com mailing list by Jim Galvin on 19 November 1993. 675 [Schuba93] Schuba, C., "Addressing Weaknesses in the Domain Name 676 System Protocol", Master's thesis, Purdue University Department 677 of Computer Sciences, August 1993. 679 [Vixie95] Vixie, P, "DNS and BIND Security Issues", Proceedings of 680 the Fifth Usenix Unix Security Symposium, June 1995. 682 Authors' addresses: 684 Derek Atkins 685 IHTFP Consulting, Inc. 686 6 Farragut Ave 687 Somerville, MA 02144 688 USA 690 Email: derek@ihtfp.com 692 Rob Austein 693 Internet Systems Consortium 694 950 Charter Street 695 Redwood City, CA 94063 696 USA 698 Email: sra@isc.org 699 Intellectual Property Statement 701 The IETF takes no position regarding the validity or scope of any 702 intellectual property or other rights that might be claimed to 703 pertain to the implementation or use of the technology described in 704 this document or the extent to which any license under such rights 705 might or might not be available; neither does it represent that it 706 has made any effort to identify any such rights. Information on the 707 IETF's procedures with respect to rights in standards-track and 708 standards-related documentation can be found in BCP-11. Copies of 709 claims of rights made available for publication and any assurances of 710 licenses to be made available, or the result of an attempt made to 711 obtain a general license or permission for the use of such 712 proprietary rights by implementors or users of this specification can 713 be obtained from the IETF Secretariat. 715 The IETF invites any interested party to bring to its attention any 716 copyrights, patents or patent applications, or other proprietary 717 rights which may cover technology that may be required to practice 718 this standard. Please address the information to the IETF Executive 719 Director. 721 Full Copyright Statement 723 Copyright (C) The Internet Society (2003). All Rights Reserved. 725 This document and translations of it may be copied and furnished to 726 others, and derivative works that comment on or otherwise explain it 727 or assist in its implementation may be prepared, copied, published 728 and distributed, in whole or in part, without restriction of any 729 kind, provided that the above copyright notice and this paragraph are 730 included on all such copies and derivative works. However, this 731 document itself may not be modified in any way, such as by removing 732 the copyright notice or references to the Internet Society or other 733 Internet organizations, except as needed for the purpose of 734 developing Internet standards in which case the procedures for 735 copyrights defined in the Internet Standards process must be 736 followed, or as required to translate it into languages other than 737 English. 739 The limited permissions granted above are perpetual and will not be 740 revoked by the Internet Society or its successors or assigns. 742 This document and the information contained herein is provided on an 743 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 744 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 745 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 746 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 747 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 749 Acknowledgement 751 Funding for the RFC Editor function is currently provided by the 752 Internet Society.