idnits 2.17.1 draft-ietf-dnsind-sec-rr-00.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 expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 558 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 291: '...wner. The owner MUST also have an NS ...' RFC 2119 keyword, line 292: '.... A signed zone MUST have a SEC RR se...' RFC 2119 keyword, line 330: '...EC RR for a name SHOULD be supplied op...' RFC 2119 keyword, line 338: '...ading the parent zone), the server MAY...' RFC 2119 keyword, line 339: '... The resolver seeking a SEC RR SHOULD...' (11 more instances...) -- The abstract seems to indicate that this document updates RFC2181, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC2535, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (June 25, 1999) is 9070 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC-to-be' on line 153 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSIND WG Edward Lewis 2 INTERNET DRAFT NAI Labs 3 Category: I-D Jerry Scharf 4 ISC 5 Olafur Gudmundsson 6 NAI Labs 7 June 25, 1999 8 The SEC Resource Record 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet- 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 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Comments should be sent to the authors or the DNSIND WG mailing list 32 namedroppers@internic.net. 34 This draft expires on December 25, 1999. 36 Copyright Notice 38 Copyright (C) The Internet Society (1999). All rights reserved. 40 Abstract 42 A new DNS reseource record, the SECurity RR, is defined to address 43 concerns about the parent zone's holding of the child zone's KEY RR 44 set. These concerns are addressed in a manner that retains the 45 information needed by a secure resolver when asking a parent zone 46 about the child zone. This proposal updates RFC 2535 and RFC 2181. 48 1. Introduction 50 DNS security extensions require a signed zone to hold KEY RR sets for 51 each of its delegations. This requirement has four negative 52 implications for the top level domains, which, for the most part, 53 consist of delegation points. (These issues also impact other 54 delegating zones, these problems are not unique to the TLDs.) 55 Addressing these concerns by removing the requirement for the KEY RR 56 in the parent has an adverse effect on secure resolution of DNS 58 Expires December 25, 1999 [Page 1] 59 signatures. A new DNS reseource record, the SECurity RR, is defined 60 to address these concerns. 62 The Zone Key Referral, described in another draft by the same authors, 63 is one proposed response to the concerns about parent's holding child 64 keys. However, that proposal has two drawbacks. One, it results in 65 two KEY RR sets at a delegation, one in the parent and one in the 66 child, which differ. It also does not address the expression of 67 security parameters, such as whether or not the child zone uses the 68 NXT record (which is currently mandatory). 70 This document will begin by repeating the arguments against the 71 holding of keys at the parent as presented in the Zone Key Referral. 72 The document will then present the need for information about the 73 child to be held in parent. Following this, the SEC RR will be 74 defined, its master file representation discussed, and implications on 75 name servers. 77 (Editorial note. Sections 1.1 through 1.5 are copied nearly verbatim 78 from the Zone Key Referral so that retirement of that draft will not 79 cause a problem.) 81 1.1 Reasons for removing the KEY data from the parent 83 There are a number of different reasons for the removal of the KEY RR 84 from the parent. Reasons include: 86 o the performance impact that holding keys has on name servers 87 o the problem of updating a widely delegated parent zone on demand 88 o statements in RFC 2181 on authoritative data at delegations 89 o perceived liability of the operator of a name server or registry 91 1.2 Performance Issues 93 A sample zone will be used to illustrate the problem. The example 94 will part from reality mostly in the length of zone names, which 95 changes the size of the owner and resource record data fields. 97 Expires December 25, 1999 [Page 2] 98 # $ORIGIN test. 99 # @ IN SOA 100 # IN SIG SOA 101 # IN KEY <1024 bit zone key> 102 # IN SIG KEY 103 # IN SIG KEY 104 # IN NS ns.test. 105 # IN SIG NS 106 # IN NXT my-org.test. NS SOA SIG KEY NXT 107 # IN SIG NXT 108 # 109 # my-org IN KEY <1024 bit zone key> 110 # IN KEY <1024 bit zone key> 111 # IN SIG KEY 112 # IN NS ns1.my-org.test. 113 # IN NS ns2.my-org.test. 114 # IN NXT that-org.test. NS SIG KEY NXT 115 # IN SIG NXT 116 # 117 # that-org IN KEY 0xC100 3 255 118 # IN SIG KEY 119 # IN NS ns1.that-org.test. 120 # IN NS ns2.that-org.test. 121 # IN NXT test. NS SIG KEY NXT 122 # IN SIG NXT 124 In this zone file, "my-org" is a delegation point of interest with two 125 registered public keys. Presumably, one key is for signatures 126 generated currently and the other is for still living and valid but 127 older signatures. "that-org" is another delegation point, with a NULL 128 key. This signifies that this zone is unsecured. 130 To analyze the performance impact of the storing of keys, the number 131 of bytes used to represent the RRs in the procotol format is used. 132 The actual number of bytes stored will likely be higher, accounting 133 for data structure overhead and alignment. The actual number of bytes 134 transferred will be lower due to DNS name compression. 136 The number of bytes for my-org's two 1024-bit keys, two NS records, 137 NXT and the associated signatures is 526. (1024 bit RSA/MD5 keys were 138 used for the calculation.) The bytes needed for that-org (with the 139 NULL key) is 346. Currently, there are close to 2 million entries in 140 com., so if we take my-org as a typical domain, over 1GB on memory 141 will be needed for com. The zone keys used in the example are set to 142 1024 bits. This number may range from as low as 512 bits upwards to 143 over 3000 bits. 145 The increased size of the data held for the zone cuts will have two 146 impacts at the transport and below layers. Bandwidth beyond that 147 currently needed will be used to carry the KEY records. The inclusion 148 of all of the child's keys will also push DNS over the UDP size limit 149 and start using TCP - which could cause critical problems for current 151 Expires December 25, 1999 [Page 3] 152 heavily used name servers, like the root and TLD name servers. EDNS0 153 [RFC-to-be] addresses expansion of UDP message size, which alleviates 154 this problem. 156 Another impact, not illustrated by the example, is the frequency of 157 updates. If each time a public key for my-org is added or deleted, 158 the SOA serial number will have to increase, and the SOA signed again. 159 If an average zone changes the contents of its key RR set once per 160 month, there will be on average 45 updates per minute in a zone of 2 161 million delegations. (This estimate does not address the fact that 162 signatures also expire, requiring a new signing of the zone 163 periodically.) 165 1.3 Security Incident Recovery (w/ respect to keys only) 167 Once a zone administrator is alerted that any key's private 168 counterpart has been discovered (exposed), the first action to be 169 taken is to stop advertising the public key in DNS. This doesn't end 170 the availability of the key - it will be residing in caches and given 171 in answers from those caches - but is the closest action resembling 172 revokation available in DNS. 174 Stopping the advertisement in the zone's name servers is as quick as 175 altering the master file and restarting the name server. Having to do 176 this in two places will will only delay the time until the recovery is 177 complete. 179 For example, a registrar of a top level domain has decided to update 180 its zone only on Mondays and Fridays due to the size of the zone. A 181 customer/delegatee is the victim of a break in, in which one of the 182 items taken is the file of private keys used to sign DNS data. If this 183 occurs on a Tuesday, the thief has until Friday to use the keys before 184 they disappear from the DNS, even if the child stops publishing them 185 immediately. 187 If the public key set is in the parent zone, and the parent zone is 188 not able to make the change quickly, the public key cannot be revoked 189 quickly. If the parent only refers to there being a key at the child 190 zone, then the child has the agility to change the keys - even issue a 191 NULL key, which will force all signatures in the zone to become 192 suspect. 194 1.4 DNS Clarifications 196 RFC 2181, section 6, clarifies the status of data appearing at a zone 197 cut. Data at a zone cut is served authoritatively from the servers 198 listed in the NS set present at the zone cut. The data is not 199 (necessarily) served authoritatively from the parent. (The exception 200 is in servers handling both the parent and child zone.) 202 Section 6 also mentions that there are two exceptions created by 203 DNSSEC, the NXT single record set and the KEY set. This proposal 204 addresses the exception relating to the KEY set, by removing the set 206 Expires December 25, 1999 [Page 4] 207 from the parent. The SEC RR is introduced and belongs in the parent 208 zone, there is no counterpart in the child (at the apex). 210 1.5 Liability 212 Liability is a legal concept, so it is not wise to attempt an 213 engineering solution to it. However, the perceived liability incurred 214 in using DNSSEC by registrars may prevent the adoption of DNSSEC. 215 Hence DNSSEC should be engineered in such a way to address the 216 concern. 218 One source of liability is the notion that by advertising a public key 219 for a child zone, a parent zone is providing a service of security. 220 With that comes responsibility. By having the parent merely indicate 221 that a child has a key (or has no key), the parent is providing less 222 in the way of security. If the parent is wrong, the potential loss is 223 less. Instead of falsely authenticated data, configuration errors 224 will be apparent to the resolving client. 226 Whether or not the KEY RR remains advertised in the parent zone or the 227 SEC RR is in place, the parent zone administrators still have to 228 adhere to proper key handling practices, which are being documented in 229 DNSOP draft. In particular, the parent has to be sure that the keys 230 it is signing for a child have been submitted by the true 231 administrator of the the child zone, and not submitted by an imposter. 233 1.6 The needs of the resolver 235 Now that the reasons for removing the child's keys from the parent 236 zone have been presented, reasons why something must take their place 237 are presented. A "secure" resolver is a DNS resolver that receives an 238 answer and, if a signature arrives, verifies the signature. Most 239 often, this operation will happen in resolvers that are part of name 240 servers, as opposed to general purpose hosts. 242 The first step in authenticating a DNS response is to see if the data 243 is accompanied by a signature. There are five possible outcomes. 244 Three results are not desirable, a signature may arrive but shouldn't, 245 no signature arrives but should, or a signature arrives but uses the 246 wrong cryptographic algorthm Two outcomes can be considered 247 successful, a signature arriving with the correct algorithm or no 248 signature arrives and shouldn't. (There is one other case - a 249 signature generated with an inappropriate key - which is a matter 250 beyond the scope of this draft.) 252 Since the resolver can not instantly know whether a signature is 253 expected, the resolver must start a discovery process. This process 254 can be done by the resolver querying zones between the root and the 255 desired domain for information about the next successive zones. 256 (Optimizing this search is not presented here.) For this search to be 257 successful, the parent must hold something that indicates the status 258 of the child's security, so the resolver may search with certainty. 259 While refraining from using the word "policy" to describe the data, 260 the phrase "security parameters" is used. 262 Expires December 25, 1999 [Page 5] 263 The security parameters of a zone are not entirely defined yet, and 264 will remain open until a critical mass of operations experience is 265 gained. Initially, the following information is known to be needed. 267 The set of algorithms in use by the zone. 268 KEY RRs and SIG RRs have protocol fields indicating how the key is 269 made. For now, two are in distribution, a value of 1 for RSA/MD5 and 270 3 for DSA. Unfortunately, the value are numeric in 8 bits, so a 271 bitmap representation cannot be used. 273 The mechanism for negative answers. 274 Currently, the NXT is mandatory, liked by some administrators and 275 disliked by other administrators. NXTs cannot be made optional, doing 276 so makes them obsolete. (An attacker can make the responses look like 277 a zone doesn't use NXTs, even if the zone does.) If the choice of NXT 278 or no NXT can be securely indicated, then this is solved. There have 279 been discussions on alternatives to the NXT record. By allowing a 280 zone to indicate the style of negative answer in use, alternatives can 281 be installed in experimental zones. 283 Signature policy. 284 This is an untested issue. Expressing a policy, such as whether 285 multiple algorithms are used, whether verification of one signature 286 needed or all signatures, etc., has not been fully studied. 288 2. The SEC RR 290 The SEC RR is a record that describes the DNS security parameters of 291 the owner. The owner MUST also have an NS RR set, i.e., the owner 292 MUST be a cut point. A signed zone MUST have a SEC RR set for each 293 delegation point. 295 0 1 2 3 296 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Negative Answer Bitmap | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 300 | | 301 ~ Security Parameters ~ 302 | | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 The RDATA of the SEC RR 306 The SEC RR RDATA contains two data fields. One is a 16-bit field 307 acting as a bitmap to indicate the means used to signify a negative 308 answer. The other field is an unbounded field of option-value pairs 309 indicating other salient settings for the zone. The latter field is 310 not padded to any particular byte boundary. 312 The SEC RR is answered authoritatively from the parent zone, and is 313 signed by the parent. A properly configured delegation point in the 314 parent would have just an SEC RR, records used for negative answering, 315 and a glue NS set. The corresponding point in the child (the zone's 316 apex) would have the SOA, KEY set, NS records, negative answer 318 Expires December 25, 1999 [Page 6] 319 records, and other desired and legal RR sets. SIG RR's appear in both 320 the parent and child side of the delegation. 322 There is no other special processing of the SEC RR set. It is used in 323 a reply as an answer when it is the subject of a direct query (QTYPE 324 IS SEC) or when a QTYPE=ANY reaches the delegating zone. If a name 325 server is authoritative for both the parent and child, the SEC is 326 included in the ANY reply for the delegation point. 328 (Editorial note: this region is in particular need of careful review.) 330 The SEC RR for a name SHOULD be supplied optionally in the additional 331 data section if the CD bit is not set whenever a zone's NS or KEY set 332 is requested. If a request for a KEY set is sent to a parent-only 333 server and the server is not recursive, the server should add the SEC 334 record to the additional section of the referral message. 336 If a name server authoritative for a child zone is asked for its SEC 337 RR and the server has never learned the SEC RR (whether through 338 caching the record or by also loading the parent zone), the server MAY 339 answer with a negative answer. The resolver seeking a SEC RR SHOULD 340 know to ask for this from a parent-serving name server. 342 2.1 Negative Answer Bitmap 344 The Negative Answer Bitmap indicates the mechanism for use in denying 345 the existance of data. The bitmap is 16 bits, the most significant 346 bit called 0, least significant is 15. 348 Bit 0 = The parent doesn't know what the child uses (1=Yes) 349 Bit 1 = The child signs its negative answers (1=Yes) 350 Bit 2 = The child follows traditional DNS rules (1=yes) 351 Bit 3 = The child uses the NXT record (1=yes) 352 Bit 14 = The child uses a locally defined mechanism (1=yes) 353 Bit 15 = The length of the bit field has been extended (1=yes) 355 Bits 4 through 14 are currently unassigned, and are under the purview 356 of IANA. Bit 15 MUST BE zero. (This specification must be 357 superceeded to define an extension mechanism.) 359 A zone may use multiple mechanisms to indicate a negative answer. A 360 zone SHOULD expect that a resolver finding any one of the mechanisms 361 used in a reply indicates a negative answer, i.e. the mechanisms are 362 OR'd together. 364 The only illegal values for this bit field are: 365 Bit 0 = 1 and any other bit turned on 366 Bit 0 = 0, Bit 1 = 1, and no other bit turned on 367 Bit 15 = 1 369 2.1.1 Bit 0 (Better titles will be attached later) 371 The situation in which this bit is on should not arise, but it is 372 defined to be safe. The philosophy behind this is that security 374 Expires December 25, 1999 [Page 7] 375 parameters should always be made explicit, including when a sitation 376 is unclear. 378 2.1.2 Bit 1 380 This bit indicates that the child attachs SIG records to the resource 381 records used in the negative answer. For example, this may indicate 382 that the reslover should expect to see a SIG (NXT) when an NXT is 383 returned. 385 2.1.3 Bit 2 387 The child will answer with an SOA or any of the other means used in 388 the past to indicate a negative answer. (I think a reference to the 389 negative answer/cache document should go here.) 391 2.1.4. Bit 3 393 The child uses the NXT as defined in RFC 2535. This document declares 394 that the use of the NXT is optional, a deviation from RFC 2535. 396 2.1.5 Bit 14 398 The child is using a mechanism that is not globally defined. A zone 399 should be in such a state for only experimental reasons and realize 400 that in this state, the negative answers it gives may not be useful to 401 the general population of resolvers. 403 2.1.6 Bit 15 405 As of this specification, this bit must be 0 (zero). 407 2.1.7 Unallocated bits 409 The remainder of the bits must also be zero. A procedure will be 410 defined for allocating them. 412 2.2 Security Parameters 414 The Security parameters is a sequence of options and values. An 415 option is a numeric indicatior of the parameter. The value is usually 416 either a yes or no, or a enumerated value. In rare instances, an 417 option may require variable length data, in this case a triplet of 418 option-length-value is used. The presence of the length field is 419 indicated by the most significant bit in the option field being 1. 420 Due to the nature of the SEC RR, the length field is not commonly 421 used. 423 The option field is 8 bits. The most significant bit of the options 424 field is turned on if there is a length field. The value field is 425 also 8 bits. If the option-length-value is needed, the length is 8 426 bits and contains the number of octets comprising the value. No 427 padding is used. 429 Expires December 25, 1999 [Page 8] 430 An option may appear multiple times in the Security Parameters. The 431 sequencing of the options is not significant. If two options 433 contradict each other, this is an error, and is noted by the resolver. 434 A self-contradictory SEC RR is a security error and data from the zone 435 covered by it SHOULD be considered at risk. 437 Option Values are 438 0 Reserved 439 1 Zone is unsigned 440 2 Key Algorithm in use 441 3 Signing policy 442 0x70-0x7F Locally defined (no length field) 443 0xF0-0xFF Locally defined (uses length field) 445 All unassigned option values are under the control of IANA. Values 0 446 to 127 do not use the length field, values 128 to 255 do use the 447 length field. The option value is to be treated as unsigned. 449 2.2.1 Option 0 451 This option is reserved for future definition. 453 2.2.2 Option 1 455 The parent has not signed a KEY RR for the child, therefore the child 456 zone has no DNSSEC approved signing keys. If this option is not 457 present, then the resolver SHOULD assume that there are zone keys in 458 the child zone. 460 If the value of this is non-zero, this assertion is true. If the 461 value is zero, this assertion is false. If the parent has signed keys 462 for the child, the value is zero, however, in this case, the parent 463 SHOULD NOT include this option in the security parameters. 465 It is tempting to exclude an unsigned zone option from this list, 466 relying on the absence of any in use key algorithms (option 2) to 467 imply that the zone is unsigned. The unsigned option is included to 468 make this information explicit, so that when analyzing a running zone, 469 it is obvious to an administrator that a zone is unsigned. 471 2.2.3 Option 2 473 The parent has signed a key for the child which claims a particular 474 algorithm. This value field is equal to that of the algorithm field 475 of the triggering KEY RR. 477 Option 2 can be repeated for different algorithms. It is not 478 necessary to have multiple Option 2 entries with the same key 479 algorithm value. 481 If Option 1 and Option 2 appear in the same SEC RR, this is a 482 self-contradictory record. If neither Option 1 nor Option 2 appear, 483 this also constitues a self-contradictory record. 485 Expires December 25, 1999 [Page 9] 486 2.2.4 Option 3 488 The child has the option to require that all material signatures 489 (those generated by DNSSEC-approved signing keys) must be validated 490 (within any temporal constraints) for the data to be considered valid. 491 The child may instead require that just one of the signatures be 492 validated. This may be a reflection of the manner in which a zone's 493 administration is shared amongst organizations. 495 If Option 3 is not present (and Option 2 is), the resolver SHOULD 496 assume that ALL (temporally valid) signatures are required. If the 497 parent includes at least one Option 2, it SHOULD specify an Option 3, 498 with a value indicated by the child. 500 Values for Option 3 are 501 0 Reserved 502 1 All signatures are required 503 2 One signature is required 504 256 Locally defined 506 All remaining values are under the control of IANA. 508 (Editorial note: whether the assumption that all signatures are 509 necessary or just one is sufficient in the absence of this option is 510 open to WG debate.) 512 2.2.5 Options 0x70-0x7F 514 This option is reserved for an organization to use locally, in an 515 experimental fashion. This option does not use the length field. 516 Global interpretation of this option is undefined. 518 2.2.6 Options 0xF0-0xFF 520 This option is reserved for an organization to use locally, in an 521 experimental fashion. This option uses the length field. Global 522 interpretation of this option is undefined. 524 3. Master File Representation 526 The SEC RR fields are to be represented as hexidecimal fields, with a 527 preceeding '0x', or in decimal format. Hexidecimal SHOULD be used. 529 For example, the SEC RR representing a zone that use signed NXT 530 records, and has one or more DSA keys, one or more RSA keys, and 531 requires that just one signature be verified would be: 533 myzone.test. 3500 IN SEC 0x5000 0x0201 0203 0302 535 (0x020102030302 is one field, hence one 0x prefix.) 537 Hex values for the security parameters MAY BE separated by 538 whitespace, as shown. DNS data display routines SHOULD substitute 539 mnemonics for these values, but MUST write the numeric form in master 540 files. 542 4. Signature Policy 544 The SEC RR must be signed by one or more zone keys of the parent 545 (delgating) zone, and the signatures must adhere to the parent's 546 policy. 548 The SEC RR for the root zone is the lone exception, it appears at the 549 apex of the root zone, and must be signed sufficiently by the root's 550 zone key or keys. 552 5. Cache Considerations 554 When a SEC RR set for a name is held in a cache, it will have a 555 credibility rating indicating that the data came from the parent 556 (unless the parent and child share servers). When data about the same 557 name arrives from the child, with a higher credibility, the newly 558 arrived data MUST NOT cause the cache to remove the SEC RR. 560 6. IANA Considerations 562 IANA is requested to assign this RR an type parameter for DNS, and to 563 assign the indicated option numbers and values when requests are 564 approved. The procedure for requesting new options and values will be 565 defined in future versions of this specfication. 567 7. Security Considerations 569 This record is designed to address the concerns of securing delegation 570 points and resolving the security of DNS answers. This record is 571 important to the security because it supplies needed information and 572 eases the burden of security on the DNS. 574 The SEC RR does require one piece of additional information not 575 addressed to date to be communicated from the parent to the child. 576 This is the signature policy. This will be needed in the operations 577 documents. 579 Editorial Note: This document would benefit by a companion document 580 describing the process of evaluating the signatures in DNS. Such a 581 document would provide clearer input to the security parameters field. 583 8. Editorial Considerations 585 Although somewhat detailed in this current description, this record is 586 still in the formative state. The -00 document has been quickly 587 written to test the waters for interest. 589 9. References 591 RFC 2535 is the prime DNSSEC definition. RFC 2181 is the Clarify 592 document. EDNS0 reference needed... 594 10. Acknowledgements 596 This record is a successor to the Zone Key Referral, originally 597 promoted by John Gilmore and Jerry Scharf. A DNSSEC workshop 598 sponsored by the NIC-SE in May 1999 provided the enlightenment that 599 expanded the Zone Key Referral into the SEC RR proposal. 601 11. Author's Addresses 603 Edward Lewis Jerry Scharf Olafur Gudmundsson 604 NAI Labs Internet Software Consortium NAI Labs 605 3060 Washington Road 950 Charter St 3060 Washington Rd 606 Glenwood, MD 21738 Redwood City, CA 94063 Glenwood, MD 21738 607 +1 443 259 2352 +1 650 779 7060 +1 443 259 2389 608 610 12. Full Copyright Statement 612 Copyright (C) The Internet Society (1999). All Rights Reserved. 614 This document and translations of it may be copied and furnished to 615 others, and derivative works that comment on or otherwise explain it 616 or assist in its implmentation may be prepared, copied, published and 617 distributed, in whole or in part, without restriction of any kind, 618 provided that the above copyright notice and this paragraph are 619 included on all such copies and derivative works. However, this 620 document itself may not be modified in any way, such as by removing 621 the copyright notice or references to the Internet Society or other 622 Internet organizations, except as needed for the purpose of 623 developing Internet standards in which case the procedures for 624 copyrights defined in the Internet Standards process must be 625 followed, or as required to translate it into languages other than 626 English. 628 The limited permissions granted above are perpetual and will not be 629 revoked by the Internet Society or its successors or assigns. 631 This document and the information contained herein is provided on an 632 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 633 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 634 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 635 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 636 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."