idnits 2.17.1 draft-ietf-dnsext-2929bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 645. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 651. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 IETF Trust 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 (August 2007) is 6096 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) == Missing Reference: 'A-Z' is mentioned on line 454, but not defined == Missing Reference: 'A-Z0-9-' is mentioned on line 454, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 4635 (Obsoleted by RFC 8945) -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' -- Obsolete informational reference (is this intentional?): RFC 2673 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2929 (Obsoleted by RFC 5395) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald E. Eastlake 3rd 2 Obsoletes RFC 2929 Motorola Laboratories 3 Updates RFCs 1183 and 3597 4 Expires: February 2008 August 2007 6 Domain Name System (DNS) IANA Considerations 7 ------ ---- ------ ----- ------------------- 8 10 Status of This Document 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Distribution of this draft is unlimited. It is intended to become 18 the new BCP 42 obsoleting RFC 2929. Comments should be sent to the 19 DNS Working Group mailing list . 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 Internet Assigned Number Authority (IANA) parameter assignment 40 considerations are specified for the allocation of Domain Name System 41 (DNS) resource record types, CLASSes, operation codes, error codes, 42 DNS protocol message header bits, and AFSDB resource record subtypes. 44 Table of Contents 46 Status of This Document....................................1 47 Abstract...................................................1 49 Table of Contents..........................................2 51 1. Introduction............................................3 52 2. DNS Query/Response Headers..............................3 53 2.1 One Spare Bit?.........................................4 54 2.2 Opcode Assignment......................................4 55 2.3 RCODE Assignment.......................................5 56 3. DNS Resource Records....................................6 57 3.1 RRTYPE IANA Considerations.............................7 58 3.1.1 DNS RRTYPE Allocation Policy.........................8 59 3.1.2 DNS RRTYPE Expert Guidelines.........................9 60 3.1.3 Special Note on the OPT RR...........................9 61 3.1.4 The AFSDB RR Subtype Field...........................9 62 3.2 RR CLASS IANA Considerations..........................10 63 3.3 Label Considerations..................................12 64 3.3.1 Label Types.........................................12 65 3.3.2 Label Contents and Use..............................12 66 4. Security Considerations................................12 67 5. IANA Considerations....................................13 69 Annex A: RRTYPE Allocation Template.......................14 71 Additional IPR Provisions.................................16 72 Copyright.................................................16 74 Normative References......................................17 75 Informative References....................................18 77 Author's Address..........................................19 78 Expiration and File Name..................................19 79 Disclaimer................................................19 81 1. Introduction 83 The Domain Name System (DNS) provides replicated distributed secure 84 hierarchical databases which store "resource records" (RRs) under 85 domain names. DNS data is structured into CLASSes and zones which 86 can be independently maintained. See [RFC1034], [RFC1035], 87 [RFC2136], [RFC2181], and [RFC4033] familiarity with which is 88 assumed. 90 This document provides, either directly or by reference, the general 91 IANA parameter assignment considerations applying across DNS query 92 and response headers and all RRs. There may be additional IANA 93 considerations that apply to only a particular RRTYPE or 94 query/response opcode. See the specific RFC defining that RRTYPE or 95 query/response opcode for such considerations if they have been 96 defined, except for AFSDB RR considerations [RFC1183] which are 97 included herein. This RFC obsoletes [RFC2929]. 99 IANA currently maintains a web page of DNS parameters. See 100 . 102 "IETF Standards Action", "IETF Consensus", "Specification Required", 103 and "Private Use" are as defined in [RFC2434]. 105 2. DNS Query/Response Headers 107 The header for DNS queries and responses contains field/bits in the 108 following diagram taken from [RFC2136] and [RFC2929]: 110 1 1 1 1 1 1 111 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 112 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 113 | ID | 114 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 115 |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | 116 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 117 | QDCOUNT/ZOCOUNT | 118 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 119 | ANCOUNT/PRCOUNT | 120 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 121 | NSCOUNT/UPCOUNT | 122 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 123 | ARCOUNT | 124 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 126 The ID field identifies the query and is echoed in the response so 127 they can be matched. 129 The QR bit indicates whether the header is for a query or a response. 131 The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful 132 only in queries or only in responses, depending on the bit. However, 133 some DNS implementations copy the query header as the initial value 134 of the response header without clearing bits. Thus any attempt to 135 use a "query" bit with a different meaning in a response or to define 136 a query meaning for a "response" bit is dangerous given existing 137 implementation. Such meanings may only be assigned by an IETF 138 Standards Action. 140 The unsigned integer fields query count (QDCOUNT), answer count 141 (ANCOUNT), authority count (NSCOUNT), and additional information 142 count (ARCOUNT) express the number of records in each section for all 143 opcodes except Update [RFC2136]. These fields have the same 144 structure and data type for Update but are instead the counts for the 145 zone (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and 146 additional information (ARCOUNT) sections. 148 2.1 One Spare Bit? 150 There have been ancient DNS implementations for which the Z bit being 151 on in a query meant that only a response from the primary server for 152 a zone is acceptable. It is believed that current DNS 153 implementations ignore this bit. 155 Assigning a meaning to the Z bit requires an IETF Standards Action. 157 2.2 Opcode Assignment 159 Currently DNS OpCodes are assigned as follows: 161 OpCode Name Reference 163 0 Query [RFC1035] 164 1 IQuery (Inverse Query, Obsolete) [RFC3425] 165 2 Status [RFC1035] 166 3 available for assignment 167 4 Notify [RFC1996] 168 5 Update [RFC2136] 169 6-15 available for assignment 171 New OpCode assignments require an IETF Standards Action as modified 172 by [RFC4020]. 174 2.3 RCODE Assignment 176 It would appear from the DNS header above that only four bits of 177 RCODE, or response/error code are available. However, RCODEs can 178 appear not only at the top level of a DNS response but also inside 179 OPT RRs [RFC2671], TSIG RRs [RFC2845], and TKEY RRs [RFC2930]. The 180 OPT RR provides an eight bit extension resulting in a 12 bit RCODE 181 field and the TSIG and TKEY RRs have a 16 bit RCODE field. 183 Error codes appearing in the DNS header and in these three RR types 184 all refer to the same error code space with the single exception of 185 error code 16 which has a different meaning in the OPT RR from its 186 meaning in other contexts. See table below. 188 RCODE Name Description Reference 189 Decimal 190 Hexadecimal 191 0 NoError No Error [RFC1035] 192 1 FormErr Format Error [RFC1035] 193 2 ServFail Server Failure [RFC1035] 194 3 NXDomain Non-Existent Domain [RFC1035] 195 4 NotImp Not Implemented [RFC1035] 196 5 Refused Query Refused [RFC1035] 197 6 YXDomain Name Exists when it should not [RFC2136] 198 7 YXRRSet RR Set Exists when it should not [RFC2136] 199 8 NXRRSet RR Set that should exist does not [RFC2136] 200 9 NotAuth Server Not Authoritative for zone [RFC2136] 201 10 NotZone Name not contained in zone [RFC2136] 202 11 - 15 Available for assignment 203 16 BADVERS Bad OPT Version [RFC2671] 204 16 BADSIG TSIG Signature Failure [RFC2845] 205 17 BADKEY Key not recognized [RFC2845] 206 18 BADTIME Signature out of time window [RFC2845] 207 19 BADMODE Bad TKEY Mode [RFC2930] 208 20 BADNAME Duplicate key name [RFC2930] 209 21 BADALG Algorithm not supported [RFC2930] 210 22 BADTRUC Bad Truncation [RFC4635] 211 23 - 3,840 212 0x0017 - 0x0F00 Available for assignment 214 3,841 - 4,095 215 0x0F01 - 0x0FFF Private Use 217 4,096 - 65,534 218 0x1000 - 0xFFFE Available for assignment 220 65,535 221 0xFFFF Reserved, can only be allocated by an IETF 222 Standards Action. 224 Since it is important that RCODEs be understood for interoperability, 225 assignment of new RCODE listed above as "available for assignment" 226 requires an IETF Consensus. 228 3. DNS Resource Records 230 All RRs have the same top level format shown in the figure below 231 taken from [RFC1035]. 233 1 1 1 1 1 1 234 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 235 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 236 | | 237 / / 238 / NAME / 239 / / 240 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 241 | TYPE | 242 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 243 | CLASS | 244 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 245 | TTL | 246 | | 247 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 248 | RDLENGTH | 249 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| 250 / RDATA / 251 / / 252 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 254 NAME is an owner name, i.e., the name of the node to which this 255 resource record pertains. NAMEs are specific to a CLASS as described 256 in section 3.2. NAMEs consist of an ordered sequence of one or more 257 labels each of which has a label type [RFC1035], [RFC2671]. 259 TYPE is a two octet unsigned integer containing one of the RRTYPE 260 codes. See section 3.1. 262 CLASS is a two octet unsigned integer containing one of the RR CLASS 263 codes. See section 3.2. 265 TTL is a four octet (32 bit) unsigned integer that specifies, for 266 data TYPEs, the number of seconds that the resource record may be 267 cached before the source of the information should again be 268 consulted. Zero is interpreted to mean that the RR can only be used 269 for the transaction in progress. 271 RDLENGTH is an unsigned 16 bit integer that specifies the length in 272 octets of the RDATA field. 274 RDATA is a variable length string of octets that constitutes the 275 resource. The format of this information varies according to the TYPE 276 and in some cases the CLASS of the resource record. 278 3.1 RRTYPE IANA Considerations 280 There are three subcategories of RRTYPE numbers: data TYPEs, QTYPEs, 281 and Meta-TYPEs. 283 Data TYPEs are the means of storing data. QTYPES can only be used in 284 queries. Meta-TYPEs designate transient data associated with a 285 particular DNS message and in some cases can also be used in queries. 286 Thus far, data TYPEs have been assigned from 1 upwards plus the block 287 from 100 through 103 and from 32,768 upward, while Q and Meta-TYPEs 288 have been assigned from 255 downwards except for the OPT Meta-RR 289 which is assigned TYPE 41. There have been DNS implementations which 290 made caching decisions based on the top bit of the bottom byte of the 291 RRTYPE. 293 There are currently three Meta-TYPEs assigned: OPT [RFC2671], TSIG 294 [RFC2845], and TKEY [RFC2930]. There are currently five QTYPEs 295 assigned: * (ALL), MAILA, MAILB, AXFR, and IXFR. 297 RRTYPEs have mnemonics which must be completely disjoint from the 298 mnemonics used for CLASSes and which must match the following regular 299 expression: 301 [A-Z][A-Z0-9-]* 303 Considerations for the allocation of new RRTYPEs are as follows: 305 Decimal 306 Hexadecimal 308 0 309 0x0000 - RRTYPE zero is used as a special indicator for the SIG RR 310 [RFC2931], [RFC4034] and in other circumstances and must never 311 be allocated for ordinary use. 313 1 - 127 314 0x0001 - 0x007F - remaining RRTYPEs in this range are assigned for 315 data TYPEs by the DNS RRTYPE Allocation Policy as specified in 316 section 3.1.1. 318 128 - 255 319 0x0080 - 0x00FF - remaining RRTYPEs in this rage are assigned for Q 320 and Meta TYPEs by the DNS RRTYPE Allocation Policy as 321 specified in section 3.1.1. 323 256 - 61,439 324 0x0100 - 0xEFFF - assigned for data RRTYPEs by the DNS RRTYPE 325 Allocation Policy as specified in section 3.1.1. 327 61,440 - 65,279 328 0xF000 - 0xFEFF - reserved for future use. IETF Consensus required to 329 define use. 331 65,280 - 65,534 332 0xFF00 - 0xFFFE - Private Use. 334 65,535 335 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. 337 3.1.1 DNS RRTYPE Allocation Policy 339 Parameter values specified in Section 3.1 above as assigned based on 340 DNS RRTYPE Allocation Policy are allocated by Expert Review if they 341 meet the two requirements listed below. There will be a pool of a 342 small number of Experts appointed by the IESG. Each application will 343 be ruled on by an Expert selected by IANA. In any case where the 344 selected Expert is unavailable or states they have a conflict of 345 interest, IANA may selected another Expert from the pool. 347 Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs 348 that do not meet the requirements below, may nonetheless be allocated 349 by IETF Standards Action as modified by [RFC4020]. 351 1. A complete template as specified in Annex A has been posted for 352 three weeks to the namedroppers@ops.ietf.org mailing list before 353 the Expert Review decision. 354 Note that partially completed or draft templates may be posted 355 directly by the applicant for comment and discussion but the 356 formal posting to start the three week period is made by IANA. 358 2. The RR for which a RRTYPE code is being requested is either (a) a 359 data TYPE which can be handled as an Unknown RR as described in 360 [RFC3597] or (b) a Meta-Type who processing is optional, i.e., 361 which it is safe to simply discard. 362 Note that such RRs may include additional section processing 363 provided such processing is optional. 365 IANA shall maintain a public archive of approved templates. 367 3.1.2 DNS RRTYPE Expert Guidelines 369 The selected DNS RRTYPE Expert is required to monitor discussion of 370 the proposed RRTYPE which may occur on the namedroppers mailing list 371 and may consult with other technical experts as necessary. The Expert 372 should normally reject any RRTYPE allocation request which meets one 373 or more of the following criterion: 375 1. Was documented in a manner that was not sufficiently clear to 376 evaluate or implement. 378 2. Proposed RRTYPE or RRTYPEs affect DNS processing and do not meet 379 the criteria in point 2 in Section 3.1.1 above. 381 3. The documentation of the proposed RRTYPE or RRTYPEs is incomplete. 382 (Additional documentation can be provided during the public 383 comment period or by the Expert.) 385 4. Application use as documented makes incorrect assumptions about 386 DNS protocol behavior, such as wild cards, CNAME, DNAME etc. 388 5. An excessive number of RRTYPE values is being requested when the 389 purpose could be met with a smaller number or with Private Use 390 values. 392 3.1.3 Special Note on the OPT RR 394 The OPT (OPTion) RR, RRTYPE 41, and its IANA Considerations are 395 specified in [RFC2671]. Its primary purpose is to extend the 396 effective field size of various DNS fields including RCODE, label 397 type, OpCode, flag bits, and RDATA size. In particular, for 398 resolvers and servers that recognize it, it extends the RCODE field 399 from 4 to 12 bits. 401 3.1.4 The AFSDB RR Subtype Field 403 The AFSDB RR [RFC1183] is a CLASS insensitive RR that has the same 404 RDATA field structure as the MX RR but the 16 bit unsigned integer 405 field at the beginning of the RDATA is interpreted as a subtype as 406 follows: 408 Decimal 409 Hexadecimal 411 0 412 0x0000 - Reserved, allocation requires IETF Standards Action. 414 1 415 0x0001 - Andrews File Service v3.0 Location Service [RFC1183]. 417 2 418 0x0002 - DCE/NCA root cell directory node [RFC1183]. 420 3 - 65,279 421 0x0003 - 0xFEFF - Allocation by IETF Consensus. 423 65,280 - 65,534 424 0xFF00 - 0xFFFE - Private Use. 426 65,535 427 0xFFFF - Reserved, allocation requires IETF Standards Action. 429 3.2 RR CLASS IANA Considerations 431 There are currently two subcategories of DNS CLASSes: normal, data 432 containing classes and QCLASSes that are only meaningful in queries 433 or updates. 435 DNS CLASSes have been little used but constitute another dimension of 436 the DNS distributed database. In particular, there is no necessary 437 relationship between the name space or root servers for one data 438 CLASS and those for another data CLASS. The same DNS NAME can have 439 completely different meanings in different CLASSes. The label types 440 are the same and the null label is usable only as root in every 441 CLASS. As global networking and DNS have evolved, the IN, or 442 Internet, CLASS has dominated DNS use. 444 As yet there has not be a requirement for "meta-CLASSes". That would 445 be a CLASS to designate transient data associated with a particular 446 DNS message and which might be usable in queries. However, it is 447 possible that their might be a future requirement for one or more 448 "meta-CLASSes". 450 CLASSes have mnemonics which must be completely disjoint from the 451 mnemonics used for RRTYPEs and which must match the following regular 452 expression: 454 [A-Z][A-Z0-9-]* 456 The current CLASS assignments and considerations for future 457 assignments are as follows: 459 Decimal 460 Hexadecimal 462 0 463 0x0000 - Reserved, assignment requires an IETF Standards Action. 465 1 466 0x0001 - Internet (IN). 468 2 469 0x0002 - Available for assignment by IETF Consensus as a data CLASS. 471 3 472 0x0003 - Chaos (CH) [Moon1981]. 474 4 475 0x0004 - Hesiod (HS) [Dyer1987]. 477 5 - 127 478 0x0005 - 0x007F - available for assignment by IETF Consensus for data 479 CLASSes only. 481 128 - 253 482 0x0080 - 0x00FD - available for assignment by IETF Consensus for 483 QCLASSes and meta-CLASSes only. 485 254 486 0x00FE - QCLASS NONE [RFC2136]. 488 255 489 0x00FF - QCLASS * (ANY) [RFC1035]. 491 256 - 32,767 492 0x0100 - 0x7FFF - Assigned by IETF Consensus. 494 32,768 - 57,343 495 0x8000 - 0xDFFF - Assigned for data CLASSes only based on 496 Specification Required as defined in [RFC2434]. 498 57,344 - 65,279 499 0xE000 - 0xFEFF - Assigned for QCLASSes and meta-CLASSes only based 500 on Specification Required as defined in [RFC2434]. 502 65,280 - 65,534 503 0xFF00 - 0xFFFE - Private Use. 505 65,535 506 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. 508 3.3 Label Considerations 510 DNS NAMEs are sequences of labels [RFC1035]. 512 3.3.1 Label Types 514 At the present time, there are two categories of label types, data 515 labels and compression labels. Compression labels are pointers to 516 data labels elsewhere within an RR or DNS message and are intended to 517 shorten the wire encoding of NAMEs. 519 The two existing data label types are sometimes referred to as Text 520 and Binary. Text labels can, in fact, include any octet value 521 including zero value octets but many current uses involve only [US- 522 ASCII]. For retrieval, Text labels are defined to treat ASCII upper 523 and lower case letter codes as matching [RFC4343]. Binary labels are 524 bit sequences [RFC2673]. The Binary label type is Experimental 525 [RFC3363]. 527 IANA considerations for label types are given in [RFC2671]. 529 3.3.2 Label Contents and Use 531 The last label in each NAME is "ROOT" which is the zero length label. 532 By definition, the null or ROOT label can not be used for any other 533 NAME purpose. 535 NAMEs are local to a CLASS. The Hesiod [Dyer1987] and Chaos 536 [Moon1981] CLASSes are for essentially local use. The IN or Internet 537 CLASS is thus the only DNS CLASS in global use on the Internet at 538 this time. 540 A somewhat out-of-date description of name allocation in the IN Class 541 is given in [RFC1591]. Some information on reserved top level domain 542 names is in BCP 32 [RFC2606]. 544 4. Security Considerations 546 This document addresses IANA considerations in the allocation of 547 general DNS parameters, not security. See [RFC4033], [RFC4034], and 548 [RFC4035] for secure DNS considerations. 550 5. IANA Considerations 552 This document consists entirely of DNS IANA Considerations and 553 includes the following changes from its predecessor [RFC2929]. It 554 affects the registry currently at 555 http://www.iana.org/assignments/dns-parameters and its subregistries. 557 1. In the Domain Name System "Resource record (RR) TYPES and QTYPEs" 558 registry, it changes most "IETF Consensus" and all "Specification 559 Required" allocation policies for RRTYPEs to be "DNS TYPE 560 Allocation Policy" and changes the policy for RRTYPE 0xFFFF to be 561 "IETF Standards Action". It also specifies the "DNS TYPE 562 Allocation Policy" which is based on Expert Review with additional 563 provisions and restrictions, including the sending of a completed 564 copy of the template in Annex A to , in most cases, 565 and requires "IETF Standards Action as modified by [RFC4020]" in 566 other cases. IANA shall establish a process for accepting such 567 templates, posting them to the namedroppers@ops.ietf.org mailing 568 list, selecting one of such Experts as have been appointed to 569 review such template form applications, and archive and make 570 available all approved RRTYPE allocation templates. See Section 571 3.1 and Annex A for more details. 573 2. For Opcodes (see Section 2.2), it changes "IETF Standards Action" 574 allocation requirements to add "as modified by [RFC4020]". 576 3. It changes the allocation status of RCODE 0xFFFF to be IETF 577 Standards Action required. See Section 2.3. 579 4. It adds an IANA allocation policy for the AFSDB RR Subtype field 580 which requires the creation of a new registry. See Section 3.1.4. 582 5. It splits Specification Required CLASSes into data CLASSes and 583 query or meta CLASSes. See Section 3.2. 585 Annex A: RRTYPE Allocation Template 587 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE 589 This template is to be submitted to IANA for processing by emailing 590 the template to @iana.org. 592 A. Submission Date: 594 B. Contact Information for submitter: 595 Name: 596 Email Address: 597 International telephone number: 598 Other contact handles: 600 C. Motivation for the new RRTYPE application? 601 Please keep this part at a high level to inform the Expert and 602 reviewers about uses of the RRTYPE. Remember most reviewers 603 will be DNS experts that may have limited knowledge of your 604 application space. 606 D. Description of the proposed RR type. This description can be 607 provided in-line in the template, as an attachment or with a 608 publicly available URL: 610 E. What existing RRTYPE or RRTYPEs come closest to filling that 611 need and why are they unsatisfactory? 613 F. What mnemonic is requested for the new RRTYPE (optional)? 614 Note: this can be left blank and the mnemonic decided after the 615 template is accepted. 617 G. Does the requested RRTYPE make use of any existing IANA 618 Registry or require the creation of a new IANA Registry and if 619 so what is that registry or registries? 620 If a new registry is needed, specify allocation policy for it 621 and initial contents. 623 H. Does the proposal require/expect any changes in DNS 624 servers/resolvers that prevent the new type from being 625 processed as an unknown RRTYPE (see [RFC3597])? 627 I. Comments: 629 Additional IPR Provisions 631 The IETF takes no position regarding the validity or scope of any 632 Intellectual Property Rights or other rights that might be claimed to 633 pertain to the implementation or use of the technology described in 634 this document or the extent to which any license under such rights 635 might or might not be available; nor does it represent that it has 636 made any independent effort to identify any such rights. Information 637 on the procedures with respect to rights in RFC documents can be 638 found in BCP 78 and BCP 79. 640 Copies of IPR disclosures made to the IETF Secretariat and any 641 assurances of licenses to be made available, or the result of an 642 attempt made to obtain a general license or permission for the use of 643 such proprietary rights by implementers or users of this 644 specification can be obtained from the IETF on-line IPR repository at 645 http://www.ietf.org/ipr. 647 The IETF invites any interested party to bring to its attention any 648 copyrights, patents or patent applications, or other proprietary 649 rights that may cover technology that may be required to implement 650 this standard. Please address the information to the IETF at ietf- 651 ipr@ietf.org. 653 Copyright 655 Copyright (C) The IETF Trust (2007). 657 This document is subject to the rights, licenses and restrictions 658 contained in BCP 78, and except as set forth therein, the authors 659 retain all their rights. 661 Normative References 663 [RFC1034] - Mockapetris, P., "Domain Names - Concepts and 664 Facilities", STD 13, RFC 1034, November 1987. 666 [RFC1035] - Mockapetris, P., "Domain Names - Implementation and 667 Specifications", STD 13, RFC 1035, November 1987. 669 [RFC1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone 670 Changes (DNS NOTIFY)", RFC 1996, August 1996. 672 [RFC2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, 673 "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 674 April 1997. 676 [RFC2181] - Elz, R. and R. Bush, "Clarifications to the DNS 677 Specification", RFC 2181, July 1997. 679 [RFC2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 680 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 682 [RFC2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 683 2671, August 1999. 685 [RFC2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. 686 Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", 687 RFC 2845, May 2000. 689 [RFC2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY 690 RR)", September 2000. 692 [RFC3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 693 2002. 695 [RFC3597] - Gustafsson, A., "Handling of Unknown DNS Resource Record 696 (RR) Types", RFC 3597, September 2003. 698 [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of 699 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 701 [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 702 Rose, "DNS Security Introduction and Requirements", RFC 4033, March 703 2005. 705 [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 706 Rose, "Resource Records for the DNS Security Extensions", RFC 4034, 707 March 2005. 709 [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 710 Rose, "Protocol Modifications for the DNS Security Extensions", RFC 711 4035, March 2005. 713 [RFC4635] - D. Eastlake 3rd, "HMAC SHA (Hashed Message Authentication 714 Code, Secure Hash Algorithm) TSIG Algorithm Identifiers". 716 [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", 717 X3.4, American National Standards Institute: New York, 1968. 719 Informative References 721 [Dyer1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical 722 Plan - Name Service, April 1987, 724 [Moon1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts 725 Institute of Technology Artificial Intelligence Laboratory, June 726 1981. 728 [RFC1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. 729 Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. 731 [RFC1591] - Postel, J., "Domain Name System Structure and 732 Delegation", RFC 1591, March 1994. 734 [RFC2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS 735 Names", RFC 2606, June 1999. 737 [RFC2673] - Crawford, M., "Binary Labels in the Domain Name System", 738 RFC 2673, August 1999. 740 [RFC2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, 741 "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, 742 September 2000. 744 [RFC2931] - Eastlake, E., "DNS Request and Transaction Signatures ( 745 SIG(0)s )", RFC 2931, September 2000. 747 [RFC3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 748 Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in 749 the Domain Name System (DNS)", RFC 3363, August 2002. 751 [RFC4343] - Eastlake, D., "Domain Name System (DNS) Case 752 Insensitivity Clarification", RFC 4343, December 2005. 754 Author's Address 756 Donald E. Eastlake 3rd 757 Motorola Laboratories 758 155 Beaver Street 759 Milford, MA 01757 USA 761 Telephone: +1-508-786-7554 (w) 762 email: Donald.Eastlake@motorola.com 764 Expiration and File Name 766 This draft expires February 2008. 768 Its file name is draft-ietf-dnsext-2929bis-06.txt. 770 Disclaimer 772 This document and the information contained herein are provided on an 773 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 774 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 775 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 776 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 777 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 778 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.