idnits 2.17.1 draft-ietf-dnsext-zone-status-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Unrecognized Status in 'Category:I-D', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 13, 2000) is 8778 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: 'RFC1034' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC2535' is defined on line 562, but no explicit reference was found in the text -- Duplicate reference: RFC1034, mentioned in 'RFC1035', was also mentioned in 'RFC1034'. ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSEXT WG Edward Lewis 2 INTERNET DRAFT NAI Labs 3 Category:I-D April 13, 2000 5 DNS Security Extension Clarification on Zone Status 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Comments should be sent to the authors or the DNSIND WG mailing list 29 namedroppers@internic.net. 31 This draft expires on October 13, 2000. 33 Copyright Notice 35 Copyright (C) The Internet Society (1999, 2000). All rights reserved. 37 Abstract 39 The definition of a secured zone is presented, updating RFC 2535. The 40 new definition has consequences that alter the interpretation of the 41 NXT record, obsolete NULL keys, and the designation of "experimentally 42 secure." 44 1 Introduction 46 Whether a DNS zone is "secured" or not is a question asked in at least 47 four contexts. A zone administrator asks the question when 48 configuring a zone to use DNSSEC. A dynamic update server asks the 49 question when an update request arrives, which may require DNSSEC 50 processing. A delegating zone asks the question of a child zone when 51 the parent enters data indicating the status the child. A resolver 52 asks the question upon receipt of data belonging to the zone. 54 A zone administrator needs to be able to determine what steps are 55 needed to make the zone as secure as it can be. Realizing that due to 56 the distributed nature of DNS and its administration, any single zone 58 Expires October 13, 2000 [Page 1] 59 is at the mercy of other zones when it comes to the appearance of 60 security. This document will define what makes a zone qualify as 61 secure (absent interaction with other zones). 63 A name server performing dynamic updates needs to know whether a zone 64 being updated is to have signatures added to the updated data, NXT 65 records applied, and other required processing. In this case, it is 66 conceivable that the name server is configured with the knowledge, but 67 being able to determine the status of a zone by examining the data is 68 a desirable alternative to configuration parameters. 70 A delegating zone is required to indicate whether a child zone is 71 secured. The reason for this requirement lies in the way in which a 72 resolver makes its own determination about a zone (next paragraph). To 73 shorten a long story, a parent needs to know whether a child should be 74 considered secured. This is a two part question, what does a parent 75 consider a secure child to be, and how does a parent know if the child 76 conforms? 78 A resolver needs to know if a zone is secured when the resolver is 79 processing data from the zone. Ultimately, a resolver needs to know 80 whether or not to expect a usable signature covering the data. How 81 this determination is done is out of the scope of this document, 82 except that, in some cases, the resolver will need to contact the 83 parent of the zone to see if the parent states that the child is 84 secured. 86 This document updates several sections of RFC 2535. The definition of 87 a secured zone is an update to section 3.4 of the RFC. The document 88 updates section 2.3.4, by specifying a replacement for the NULL zone 89 keys. Section 3.4 is updated to eliminate the definition of 90 experimental keys and illustrate a way to still achieve the 91 functionality they were designed to provide. Section 3.1.3 is updated 92 by the specifying the value of the protocol octet in a zone key. 94 2 Status of a Zone 96 In this section, rules governing a zone's DNSSEC status are presented. 97 There are three levels of security defined: full, private, and 98 unsecured. A zone is fully secure when it complies with the strictest 99 set of DNSSEC processing rules. A zone is privately secured when it 100 is configured in such a way that only resolvers that are appropriately 101 configured see the zone as secured. All other zones are unsecured. 103 Note: there currently is no document completely defining DNSSEC 104 verification rules. For the purposes of this document, the strictest 105 rules are assumed to state that the verification chain of zone keys 106 parallels the delegation tree up to the root zone. This is not 107 intended to disallow alternate verification paths, just to establish a 108 baseline definition. 110 To avoid repetition in the rules below, the following terms are 111 defined. 113 Expires October 13, 2000 [Page 2] 114 2.a. Zone signing KEY RR - A KEY RR whose flag field has the value 01 115 for name type (indicating a zone key) and either value 00 or value 01 116 for key type (indicating a key permitted to authenticate data). (See 117 RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value 118 of DNSSEC (3) or All (255). 120 The definition updates RFC 2535's definition of a zone key. The 121 requirement that the protocol field be either DNSSEC or All is a new 122 requirement. 124 2.b On-tree Validation - The authorization model in which only the 125 parent zone can is recognized to supply a DNSSEC-meaningful signature 126 that is used by a resolver to build a chain of trust from the child's 127 keys to a recognized root of security. The term "on-tree" refers to 128 following up the DNS domain hierarchy to reach a trusted key, 129 presumably the root key if no other key is available. The term 130 "validation" refers to the digital signature by the parent to prove 131 the integrity, authentication and authorization of the child' key to 132 sign the child's zone data. 134 2.c Off-tree Validation - Any authorization model that permits domain 135 names other than the parent's to provide a signature over a child's 136 zone keys that will enable a resolver to trust the keys. 138 2.1 Fully Secured 140 A fully secured zone, in a nutshell, is a zone that uses only 141 mandatory to implement algorithms (RFC 2535, section 3.2) and relies 142 on a key certification chain that parallels the delegation tree 143 (on-tree validation). Fully secured zones are defined by the 144 following rules. 146 2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at least 147 one zone signing KEY RR (2.a) of a mandatory to implement algorithm in 148 the set. 150 2.1.b. The zone's apex KEY RR set MUST be signed by a private key 151 belonging to the parent zone. The private key's public companion MUST 152 be a zone signing KEY RR (2.a) of a mandatory to implement algorithm 153 and owned by the parent's apex. 155 If a zone cannot get a conforming signature from the parent zone, the 156 child zone cannot be considered fully secured. The only exception to 157 this is the root zone, for which there is no parent zone. 159 2.1.c. NXT records MUST be deployed throughout the zone. (Updates RFC 160 2535, section 2.3.2.) Note: there is some operational discomfort with 161 the current NXT record. This requirement is open to modification when 162 two things happen. First, an alternate mechanism to the NXT is 163 defined and second, a means by which a zone can indicate that it is 164 using an alternate method. 166 2.1.d. Each RR set that qualifies for zone membership MUST be signed 167 by a key that is in the apex's KEY RR set and is a zone signing KEY RR 169 Expires October 13, 2000 [Page 3] 170 (2.a) of a mandatory to implement algorithm. (Updates 2535, section 171 2.3.1.) 173 Mentioned earlier, the root zone is a special case. Defining what 174 constitutes a secure root zone is difficult, as the discussion on 175 securing the root zone has not come to a consensus in an open forum. 176 However, the security of the root zone will be determined by the 177 preconfiguration of a trusted key in resolvers. Who generates and 178 distributes the trusted key is an open issue. 180 2.2 Privately Secured 182 Note that the term "privately" is open to debate... 184 A privately secured zone is a zone that complies with rules like those 185 for a fully secured zone with the following exceptions. The signing 186 keys may be of an algorithm that is not mandatory to implement and/or 187 the verification of the zone keys in use may rely on a verification 188 chain that is not parallel to the delegation tree (off-tree 189 validation). 191 2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at least 192 one zone signing KEY RR (2.a) in the set. 194 2.2.b. The zone's apex KEY RR set MUST be signed by a private key and 195 one of the following two subclauses MUST hold true. 197 2.2.b.1 The private key's public companion MUST be preconfigured in 198 all the resolvers of interest. 200 2.2.b.2 The private key's public component MUST be a zone signing KEY 201 RR (2.a) authorized to provide validation of the zone's apex KEY RR 202 set, as recognized by resolvers of interest. 204 The previous sentence is trying to convey the notion of using a 205 trusted third party to provide validation of keys. If the domain name 206 owning the validating key is not the parent zone, the domain name must 207 represent someone the resolver trusts to provide validation. 209 2.2.c. NXT records MUST be deployed throughout the zone. (Updates RFC 210 2535, section 2.3.2.) Note: see the discussion following 2.1.c. 212 2.2.d. Each RR set that qualifies for zone membership MUST be signed 213 by a key that is in the apex's KEY RR set and is a zone signing KEY RR 214 (2.a).. (Updates 2535, section 2.3.1.) 216 2.3 Unsecured 218 All other zones qualify as unsecured. This includes zones that are 219 designed to be experimentally secure, as defined in a later section on 220 that topic. 222 Expires October 13, 2000 [Page 4] 223 2.4 Wrap up 225 The designation of fully secured, privately secured, and unsecured are 226 merely labels to apply to zones, based on their contents. Resolvers, 227 when determining whether a signature is expected or not, will only see 228 a zone as secured or unsecured. 230 Resolvers that follow the most restrictive DNSSEC verification rules 231 will only see fully secured zones as secured, and all others as 232 unsecured, including zones which are privately secured. Resolvers 233 that are not as restrictive, such as those that implement algorithms 234 in addition to the mandatory to implement algorithms, will see some 235 privately secured zones as secured. 237 The intent of the labels "fully" and "privately" is to identify the 238 specific attributes of a zone. The words are chosen to assist in the 239 writing of a document recommending the actions a zone administrator 240 take in making use of the DNS security extensions. The words are 241 explicitly not intended to convey a state of compliance with DNS 242 security standards. 244 3 Parental Notification 246 For a resolver to come to a definitive answer concerning a zone's 247 security status there is a requirement that the parent of a zone 248 signify whether the child zone is signed or not. The justification of 249 this requirement requires a discussion of the resolver's activity, 250 which is described in RFC 2535. 252 In RFC 2535, a parent is required to hold a NULL key for an unsigned 253 child (a bone of contention here is how this works in light of 254 multiple algorithms). The parent has the option to hold the keys of 255 the child if the child is signed. The parent may also hold nothing 256 cryptographic if the child is signed. This, of course, assumes the 257 parent is a signed zone. 259 RFC 2535 does permit the following case, a child zone that uses DNSSEC 260 capable software yet chooses to remain unsecured could hold a signed 261 NULL key delivered from the parent. This is considered to be a rare 262 condition, a zone administrator that goes to the trouble to get the 263 keys from the parent and have it signed will likely just sign the 264 whole zone, or leave the NULL key to the parent. 266 There is a strong case for discouraging a parent from holding keys of 267 a signed child, or an unsigned child for that matter. These include 268 concrete concerns about performance and more abstract concerns about 269 the liability of the parent. 271 DNS [RFC 1034 and 1035] requires a parent to hold NS records for a 272 child zone, this signifies the delegation. RFC 2535 requires a 273 secured parent to also have signed NXT records for the child, and 274 possibly a signed KEY RR set (required for some NULL key situations). 276 By redefining the security status of a zone to be per zone and not per 278 Expires October 13, 2000 [Page 5] 279 algorithm, there is an opportunity to completely remove the need for a 280 KEY RR set in the parent. Because the question of whether the zone is 281 secure or not is a yes-or-no question, the notification needs just one 282 bit to be expressed. 284 Keep in mind that the following sections speak to the contents of a 285 zone, not a name server. In the case of a name server speaking 286 authoritatively for both the parent and child, or if a server caches 287 the information for the other half of the delegation, then a server 288 will have more types of data at a delegation point than a parent is 289 supposed to hold. (E.g., if a parent zone's name server caches the 290 SOA for the child, the SOA is not in the parent zone, but is in the 291 server's cache.) 293 3.1 Child Has Keys Bit 295 This section is written assuming the current definition of NXT holds. 296 There is some controversy surrounding the NXT record, which may result 297 in a complete replacement of it for proof of non-existence. The 298 current NXT definition provides an extension bit in the types present 299 bit map, whose use is remains incompletely defined. The following 300 text largely ignores these uncertainties, and should be rewritten to 301 accommodate these uncertainties in revisions. 303 In the parent's half of the delegation point, there will be an NXT 304 record, called an "upper" NXT. According to the rules for a 305 delegation point, only the NS, NXT, and SIG bits will be turned on in 306 the types present field, assuming we drop the KEY set altogether. 308 The KEY bit in the parent's NXT types present bit map is hereby 309 redefined to have the following meaning. (Note that this applies to 310 just delegation points.) 312 If the bit corresponding to the KEY RR set in an upper NXT is set, the 313 parent has generated and issued a currently valid SIG (KEY) RR 314 validating the child's apex KEY RR set. Note that this does not 315 require the child to include either a zone signing KEY RR (2.a) or a 316 NULL zone KEY RR. This does assume that only on-tree validation (2.b) 317 is in use. 319 The temporal validity of the bit's setting may be enforced in the SIG 320 (NXT) RR validity period, timely editing of the master file, dynamic 321 updates, or whatever another mechanism. 323 If a child submits a key set to the parent for validation that does 324 not include a zone signing KEY RR (2.a), then the child will remain 325 unsecured although the upper NXT KEY RR bit will be set to 1 by the 326 parent. A resolver seeing this will know to look for a child key set, 327 and see that there is no zone signing KEY RR (2.a) and know to treat 328 the child as unsecured. 330 If a NULL zone KEY RR is seen, the resolver ignores it. If a NULL key 331 is the only zone key, then the resolver will deduce the child is 332 unsecured as in the previous paragraph. If there is both a NULL and 334 Expires October 13, 2000 [Page 6] 335 one or more zone signing KEY RR (2.a), then the zone is considered 336 signed in the algorithm(s) identified in the signing capable key(s). 338 If the bit is 0 then the child has not submitted a KEY RR set for 339 validation, hence is to be considered unsigned. 341 Note that for a fully secured zone (section 2.1), the bit is on (1). 342 For all unsecured zones (section 2.3) the bit is either off (0) or on 343 (1) with a NULL KEY and no zone signing KEY RR at the apex. For 344 privately secured zones (section 2.2), the setting of the bit is 345 determined by whether the parent signs the child's keys or not. 346 Hence, for privately secured zones, the parent may have no 347 responsibility. A child wishing to have the parent set the bit must 348 contact the parent. 350 3.2 Rules Governing the Bit 352 In this section, the words of the previous are turned into definitive 353 MUST and SHOULDs. Note that this section does not refer to the bit in 354 the NXT. This is in anticipation of a change in the way NXT indicates 355 types present (e.g., if bit 0 of the field is defined) or a successor 356 to the NXT is defined. 358 3.2.a. At a delegation point, a secured parent zone MUST have a 359 mechanism in place to indicate which RR sets are present. The 360 mechanism MUST indicate that the NS, SIG, and the type(s) 361 corresponding to the mechanism itself are present (of course, with 362 these types actually being present). With the exception of the KEY RR 363 type, all other types MUST be indicated as not present, and, in 364 accordance with delegation rules, actually be absent from the zone. 365 If, in the future, other data is permitted to be present at a 366 delegation point, this requirement MUST be amended. 368 Assuming the NXT record, the above requirement reads as follows. At a 369 delegation point, a parent zone must have a secured NXT record. This 370 NXT record must indicate that the NS, SIG, and NXT types are present. 371 With the exception of KEY, all other types must be indicated as not 372 present. The lower casing of the word "must" is intentional, 373 conveying that this is an explanation of the rule above. 375 3.2.b. The KEY set MUST be indicated as present during the time when 376 the parent has issued a signature for the child's KEY set. Conversely, 377 during periods of time in which the parent knows it has not generated 378 a signature for the KEY RR set, the KEY set MUST be indicated to be 379 absent. 381 If the parent has issued signatures with discontinuous validity spans, 382 then the presence of the KEY set will flip from present to not present 383 and back as time progresses. 385 3.2.c. When signing a child's KEY RR set, a parent SHOULD carefully 386 consider the algorithm of the key used to generate the signature. The 387 parent SHOULD make clear to child zones what steps are to be taken to 389 Expires October 13, 2000 [Page 7] 390 get the parent to indicate that the child is signed. This document 391 will go no further in specifying operational considerations. 393 (Let's say the parent signs the child's key set with an algorithm the 394 child can't process. The child could elect not to advertise this 395 signature, as it cannot verify that the signature covers the real key 396 set. If this happens, is the parent justified in claiming that the 397 child is secured?) 399 3.2.d. The parent MUST have the capability to allow the child, through 400 some trusted, probably non-DNS mechanism, to request that the 401 indication of the KEY set to be turned off. This allows a child to 402 revert to an unsigned state. 404 3.2.e. The parent SHOULD NOT allow the child to request that the KEY 405 set be indicated as present in the absence of a key signing request. 407 3.3 Operational Considerations 409 Retrieving the NXT for a delegated name from the parent zone (the 410 upper NXT) is not a trivial operation. The complication arises due to 411 having an NXT in the delegatee (the lower NXT) that matches the owner 412 name of the upper NXT. (The case in which both the parent and child 413 zones are secured is the only case mentioned here. If both are not 414 secured, then there will be at most one NXT, which is easily 415 retrieved.) 417 There are two complications to describe. One involves the multiple 418 NXT sets matching the same owner. The other is the pragmatic issue of 419 knowing where to get the answer. 421 With multiple NXT sets at the same owner, caches may become a problem. 422 If a (for example) recursive server has cached the lower NXT, any 423 query for the upper NXT may be confused for a lower NXT query. This 424 is akin to the issue of the ANY query, where a server with some cached 425 data will answer with just that and not seek the rest of the data. 427 Note that distinguishing between an upper and lower NXT is a trivial 428 operation, especially so if the SIG RR is available. 430 A resolver may know the child's server's addresses and the parent zone 431 may not be sharing servers with the child. In this case the resolver 432 will need to be able to locate the parent zones (possibly having to go 433 to the root servers and descend) in order to obtain the upper NXT 434 record. 436 A potential solution to this is to define an NXT meta-query that will 437 force a recursive server to find all available NXT RR sets for a given 438 name. Details of this have not been examined. 440 3.4 Interaction with Dynamic Update 442 Dynamic update [RFC 2136, draft-ietf-dnsext-simple-secure-update- 443 xy.txt] defines a means by which a zone can change without undergoing 445 Expires October 13, 2000 [Page 8] 446 a full reload. This combination of dynamic update and the proposed 447 use of the NXT record to signify a child's status raises some 448 concerns. 450 First a few elements need to be labeled. There is an off-line signer, 451 which is the process that signs zone data files away from the name 452 server. There is an on-line signer, part of a name server, that the 453 dynamic update mechanism uses to sign the updated data. Finally, 454 there is an on-line key validator, perhaps a misnomer, which accepts 455 requests for parent signatures over each child zone's keys. 457 The proposal depicted in this draft relies upon the on-line key 458 validator informing the on-line and off-line signers of the status of 459 a child, recall that the status of a child has a temporal element. 460 E.g., a signature may be generated for just the month of July, so the 461 child is secured for the month of July, but not the month of August. 463 The first issues pertain to the way in which an off-line signer comes 464 to encode a validation in an NXT record. There is a need for the 465 status information to flow from the on-line validator to the off-line 466 signer and then be used as input to the signing process. The way that 467 this information makes the transition is an issue. The second issue 468 is through what mechanism is this information ingested into the NXT 469 generating process. Recall that all other information can be derived 470 by the zone data, the status of the child isn't stored anywhere else 471 in the parent zone. 473 The next issue is the means in which a validation action is reported 474 to the active zone. On the surface, dynamically updating the NXT 475 would seem to make sense, but updating the NXT in this manner can lead 476 to a race condition in the server, this is unstable. The issue here 477 is deriving a mechanism by which a name server knows to signify that 478 the child status has changed. Note that this applies to newly 479 validated keys as well as the granting of a child's request to cancel 480 a validation. 482 The final issue is the operation of the off-line signer. When an NXT 483 is being regenerated, the old NXT is needed to see what the previous 484 setting of the child's status had been. The old NXT signature is also 485 needed to know that, had the child been known to be secured, for what 486 interval was is it thought to be secured so that the new NXT signature 487 is appropriately set. Of course, if the reason for updating the NXT 488 is a change as described in the previous paragraph, the old NXT is of 489 lesser value. 491 The issue raised in the last paragraph leads to a questioning of the 492 sanity of using signature validity periods to signify the temporal 493 status of data in a server. What does a server return if the NXT 494 needed is not currently covered by a valid signature? 496 4 NULL keys 498 Through the use of the types present to indicate the existence of a 499 signature validating the KEY set of a child, the need for NULL keys 501 Expires October 13, 2000 [Page 9] 502 effectively disappears. NULL keys are left as a defined entity, but 503 are rendered meaningless in DNSSEC. 505 5 Experimental Status 507 Without NULL keys, an experimentally secured zone cannot be defined as 508 it is in RFC 2535. The purpose of an experimentally secured zone was 509 to facilitate the migration from an unsecured zone to a secured zone. 511 The objective of facilitating the migration can be achieved without a 512 special designation of an experimentally secure status. Experimentally 513 secured is a special case of privately secured. A zone administrator 514 can achieve this by publishing a zone with signatures and configuring 515 a set of test resolvers with the corresponding public keys. Even if 516 the public key is published in a KEY RR, as long as there is no parent 517 signature, the resolvers will need some preconfiguration to know to 518 process the signatures. This allows a zone to be secured with in the 519 sphere of the experiment, yet still be registered as unsecured in the 520 general Internet. 522 6 IANA/ICANN Considerations 524 This document does not request any action from an assigned number 525 authority nor recommends any actions. 527 7 Security Considerations 529 Without a means to enforce compliance with specified protocols or 530 recommended actions, declaring a DNS zone to be "completely" secured 531 is impossible. Even if, assuming an omnipotent view of DNS, one can 532 declare a zone to be properly configured for security, and all of the 533 zones up to the root too, a misbehaving resolver could be duped into 534 believing bad data. If a zone and resolver comply, a non-compliant or 535 subverted parent could interrupt operations. The best that can be 536 hoped for is that all parties are prepared to be judged secure and 537 that security incidents can be traced to the cause in short order. 539 8 Acknowledgements 541 The need to refine the definition of a secured zone has become 542 apparent through the efforts of the participants at two DNSSEC 543 workshops, sponsored by the NIC-SE (.se registrar) and CAIRN (a 544 DARPA-funded research network). Further discussions leading to the 545 document include Olafur Gudmundsson, Russ Mundy, Robert Watson, and 546 Brian Wellington. 548 9 References 550 [RFC1034] P. Mockapetris, "Domain Names - Concepts and Facilities," 551 RFC 1034, November 1987. 553 [RFC1035] P. Mockapetris, "Domain Names - Implementation and 554 Specification," RFC 1034, November 1987. 556 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 557 Requirement Levels," RFC 2119, March 1997 559 [RFC2136] P. Vixie (Ed.), S. Thomson, Y. Rekhter, J. Bound "Dynamic 560 Updates in the Domain Name System," RFC 2136, April 1997. 562 [RFC2535] D. Eastlake, "Domain Name System Security Extensions," RFC 563 2535, March 1999. 565 [draft-ietf-dnsext-simple-secure-update-xy.txt] B. Wellington, "Simple 566 Secure Domain Name System (DNS) Dynamic Update," version 00, February 567 2000. 569 10 Author Information 571 Edward Lewis NAI Labs 3060 Washington Road Glenwood, MD 21738 +1 443 572 259 2352 574 11 Full Copyright Statement 576 Copyright (C) The Internet Society (1999, 2000). All Rights Reserved. 578 This document and translations of it may be copied and furnished to 579 others, and derivative works that comment on or otherwise explain it 580 or assist in its implementation may be prepared, copied, published and 581 distributed, in whole or in part, without restriction of any kind, 582 provided that the above copyright notice and this paragraph are 583 included on all such copies and derivative works. However, this 584 document itself may not be modified in any way, such as by removing 585 the copyright notice or references to the Internet Society or other 586 Internet organizations, except as needed for the purpose of developing 587 Internet standards in which case the procedures for copyrights defined 588 in the Internet Standards process must be followed, or as required to 589 translate it into languages other than English. 591 The limited permissions granted above are perpetual and will not be 592 revoked by the Internet Society or its successors or assigns. 594 This document and the information contained herein is provided on an 595 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 596 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 597 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 598 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 599 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."