idnits 2.17.1 draft-ietf-dnsext-rfc6195bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC1183, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1183, updated by this document, for RFC5378 checks: 1990-10-01) -- 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 (May 2, 2012) is 4378 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (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 481, but not defined == Missing Reference: 'A-Z0-9' is mentioned on line 481, but not defined ** 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Possible downref: Normative reference to a draft: ref. 'RFC2671bis' -- Obsolete informational reference (is this intentional?): RFC 2673 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 6195 (Obsoleted by RFC 6895) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Obsoletes: 6195 Huawei 3 Updates: 1183, 3597 4 Intended status: Best Current Practice 5 Expires: November 1, 2012 May 2, 2012 7 Domain Name System (DNS) IANA Considerations 8 10 Abstract 12 This document specifies Internet Assigned Number Authority (IANA) 13 parameter assignment considerations for the allocation of Domain Name 14 System (DNS) resource record types, CLASSes, operation codes, error 15 codes, DNS protocol message header bits, and AFSDB resource record 16 subtypes. It obsoletes RFC 6195. 18 Status of This Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Distribution of this draft is unlimited. It is intended to become the 24 new BCP 42 obsoleting RFC 6195. Comments should be sent to the DNS 25 Extensions Working Group mailing list . 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Table of Contents 45 1. Introduction............................................3 46 1.1. Terminology...........................................3 47 1.2 Acknowledgement........................................3 49 2. DNS Query/Response Headers..............................4 50 2.1. One Spare Bit?........................................4 51 2.2. OpCode Assignment.....................................5 52 2.3. RCODE Assignment......................................5 54 3. DNS Resource Records....................................7 55 3.1. RRTYPE IANA Considerations............................8 56 3.1.1. DNS RRTYPE Allocation Policy........................9 57 3.1.2. DNS RRTYPE Expert Guidelines.......................10 58 3.1.3. Special Note on the OPT RR.........................10 59 3.1.4. The AFSDB RR Subtype Field.........................11 60 3.2. RR CLASS IANA Considerations.........................11 61 3.3. Label Considerations.................................13 62 3.3.1. Label Types........................................13 63 3.3.2. Label Contents and Use.............................13 65 4. Security Considerations................................14 66 5. IANA Considerations....................................14 68 Appendix A: RRTYPE Allocation Template....................15 69 Appendix B: Changes From RFC 6195.........................16 71 Normative References......................................17 72 Informative References....................................18 74 1. Introduction 76 The Domain Name System (DNS) provides replicated distributed secure 77 hierarchical databases that store "resource records" (RRs) under 78 domain names. DNS data is structured into CLASSes and zones that can 79 be independently maintained. Familiarity with [RFC1034], [RFC1035], 80 [RFC2136], [RFC2181], and [RFC4033] is assumed. 82 This document provides, either directly or by reference, the general 83 IANA parameter assignment considerations that apply across DNS query 84 and response headers and all RRs. There may be additional IANA 85 considerations that apply to only a particular RRTYPE or 86 query/response OpCode. See the specific RFC defining that RRTYPE or 87 query/response OpCode for such considerations if they have been 88 defined, except for AFSDB RR considerations [RFC1183], which are 89 included herein. This RFC obsoletes [RFC6195]; however, the only 90 significant changes are those to the RRTYPE IANA allocation process, 91 aimed at streamlining it and clarifying the expected behavior of the 92 parties involved, and the closing of the AFSDB sub-type registry. 94 IANA currently maintains a web page of DNS parameters available from 95 http://www.iana.org. 97 1.1. Terminology 99 "Standards Action", "IETF Review", "Specification Required", and 100 "Private Use" are as defined in [RFC5226]. 102 1.2 Acknowledgement 104 Alfred Hoenes contributions are gratefully acknowledged. 106 2. DNS Query/Response Headers 108 The header for DNS queries and responses contains field/bits in the 109 following diagram taken from [RFC2136] and [RFC6195]: 111 1 1 1 1 1 1 112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 113 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 114 | ID | 115 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 116 |QR| OpCode |AA|TC|RD|RA| Z|AD|CD| RCODE | 117 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 118 | QDCOUNT/ZOCOUNT | 119 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 120 | ANCOUNT/PRCOUNT | 121 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 122 | NSCOUNT/UPCOUNT | 123 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 124 | ARCOUNT | 125 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 127 The ID field identifies the query and is echoed in the response so 128 they can be matched. 130 The QR bit indicates whether the header is for a query or a response. 132 The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful 133 only in queries or only in responses, depending on the bit. However, 134 some DNS implementations copy the query header as the initial value 135 of the response header without clearing bits. Thus, any attempt to 136 use a "query" bit with a different meaning in a response or to define 137 a query meaning for a "response" bit is dangerous, given existing 138 implementation. Such meanings may only be assigned by a Standards 139 Action. 141 The unsigned integer fields query count (QDCOUNT), answer count 142 (ANCOUNT), authority count (NSCOUNT), and additional information 143 count (ARCOUNT) express the number of records in each section for all 144 OpCodes except Update [RFC2136]. These fields have the same structure 145 and data type for Update but are instead the counts for the zone 146 (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and additional 147 information (ARCOUNT) sections. 149 2.1. One Spare Bit? 151 There have been ancient DNS implementations for which the Z bit being 152 on in a query meant that only a response from the primary server for 153 a zone is acceptable. It is believed that current DNS implementations 154 ignore this bit. 156 Assigning a meaning to the Z bit requires a Standards Action. 158 2.2. OpCode Assignment 160 Currently, DNS OpCodes are assigned as follows: 162 OpCode Name Reference 164 0 Query [RFC1035] 165 1 IQuery (Inverse Query, Obsolete) [RFC3425] 166 2 Status [RFC1035] 167 3 available for assignment 168 4 Notify [RFC1996] 169 5 Update [RFC2136] 170 6-15 available for assignment 172 New OpCode assignments require a Standards Action as modified by 173 [RFC4020]. 175 2.3. RCODE Assignment 177 It would appear from the DNS header above that only four bits of 178 RCODE, or response/error code, are available. However, RCODEs can 179 appear not only at the top level of a DNS response but also inside 180 OPT RRs [RFC2671bis], TSIG RRs [RFC2845], and TKEY RRs [RFC2930]. The 181 OPT RR provides an 8-bit extension resulting in a 12-bit RCODE field, 182 and the TSIG and TKEY RRs have a 16-bit RCODE field. 184 Error codes appearing in the DNS header and in these three RR types 185 all refer to the same error code space with the single exception of 186 error code 16, which has a different meaning in the OPT RR than in 187 other contexts. This duplicate assignment was accidental. See table 188 below. 190 RCODE Name Description Reference 191 Decimal 192 Hexadecimal 194 0 NoError No Error [RFC1035] 195 1 FormErr Format Error [RFC1035] 196 2 ServFail Server Failure [RFC1035] 197 3 NXDomain Non-Existent Domain [RFC1035] 198 4 NotImp Not Implemented [RFC1035] 199 5 Refused Query Refused [RFC1035] 200 6 YXDomain Name Exists when it should not [RFC2136] 201 7 YXRRSet RR Set Exists when it should not [RFC2136] 202 8 NXRRSet RR Set that should exist does not [RFC2136] 203 9 NotAuth Server Not Authoritative for zone [RFC2136] 204 10 NotZone Name not contained in zone [RFC2136] 206 11 - 15 207 0xB - 0xF Available for assignment 209 16 BADVERS Bad OPT Version [RFC2671bis] 210 16 BADSIG TSIG Signature Failure [RFC2845] 211 17 BADKEY Key not recognized [RFC2845] 212 18 BADTIME Signature out of time window [RFC2845] 213 19 BADMODE Bad TKEY Mode [RFC2930] 214 20 BADNAME Duplicate key name [RFC2930] 215 21 BADALG Algorithm not supported [RFC2930] 216 22 BADTRUC Bad Truncation [RFC4635] 218 23 - 3,840 219 0x0017 - 0x0F00 Available for assignment 221 3,841 - 4,095 222 0x0F01 - 0x0FFF Private Use 224 4,096 - 65,534 225 0x1000 - 0xFFFE Available for assignment 227 65,535 228 0xFFFF Reserved, can only be allocated by a Standards 229 Action. 231 Since it is important that RCODEs be understood for interoperability, 232 assignment of a new RCODE in the ranges listed above as "Available 233 for assignment" requires an IETF Review. 235 3. DNS Resource Records 237 All RRs have the same top-level format, shown in the figure below 238 taken from [RFC1035]. 240 1 1 1 1 1 1 241 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 242 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 243 | | 244 / / 245 / NAME / 246 / / 247 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 248 | TYPE | 249 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 250 | CLASS | 251 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 252 | TTL | 253 | | 254 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 255 | RDLENGTH | 256 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| 257 / RDATA / 258 / / 259 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 261 NAME is an owner name, i.e., the name of the node to which this 262 resource record pertains. NAMEs are specific to a CLASS as described 263 in Section 3.2. NAMEs consist of an ordered sequence of one or more 264 labels, each of which has a label type [RFC1035] [RFC2671bis]. 266 TYPE is a 2-octet unsigned integer containing one of the RRTYPE 267 codes. See Section 3.1. 269 CLASS is a 2-octet unsigned integer containing one of the RR CLASS 270 codes. See Section 3.2. 272 TTL is a 4-octet (32-bit) unsigned integer that specifies, for data 273 TYPEs, the number of seconds that the resource record may be cached 274 before the source of the information should again be consulted. Zero 275 is interpreted to mean that the RR can only be used for the 276 transaction in progress. 278 RDLENGTH is an unsigned 16-bit integer that specifies the length in 279 octets of the RDATA field. 281 RDATA is a variable-length string of octets that constitutes the 282 resource. The format of this information varies according to the TYPE 283 and, in some cases, the CLASS of the resource record. 285 3.1. RRTYPE IANA Considerations 287 There are three subcategories of RRTYPE numbers: data TYPEs, QTYPEs, 288 and Meta-TYPEs. 290 Data TYPEs are the means of storing data. QTYPES can only be used in 291 queries. Meta-TYPEs designate transient data associated with a 292 particular DNS message and, in some cases, can also be used in 293 queries. Thus far, data TYPEs have been assigned from 1 upward, plus 294 the block from 100 through 103, and from 32,768 upward, while Q and 295 Meta-TYPEs have been assigned from 255 downward except for the OPT 296 Meta-RR, which is assigned TYPE 41. There have been DNS 297 implementations that made caching decisions based on the top bit of 298 the bottom byte of the RRTYPE. 300 There are currently three Meta-TYPEs assigned: OPT [RFC2671bis], TSIG 301 [RFC2845], and TKEY [RFC2930]. There are currently five QTYPEs 302 assigned: * (ALL), MAILA, MAILB, AXFR, and IXFR. 304 RRTYPEs have mnemonics that must be completely disjoint from the 305 mnemonics used for CLASSes and that must match the following regular 306 expression: 308 [A-Z][A-Z0-9\-]*[A-Z0-9] 310 Considerations for the allocation of new RRTYPEs are as follows: 312 Decimal 313 Hexadecimal Assignment Policy 315 0 316 0x0000 RRTYPE zero is used as a special indicator for the 317 SIG (0) RR [RFC2931] [RFC4034] and in other 318 circumstances, and it must never be allocated for 319 ordinary use. 321 1 - 127 322 0x0001 - 0x007F Remaining RRTYPEs in this range are assigned for 323 data TYPEs by the DNS RRTYPE Allocation Policy as 324 specified in Section 3.1.1. 326 128 - 255 327 0x0080 - 0x00FF Remaining RRTYPEs in this range are assigned for Q 328 and Meta-TYPEs by the DNS RRTYPE Allocation Policy 329 as specified in Section 3.1.1. 331 256 - 61,439 332 0x0100 - 0xEFFF Remaining RRTYPEs in this range are assigned for 333 data RRTYPEs by the DNS RRTYPE Allocation Policy as 334 specified in Section 3.1.1. (32,768 and 32,769 335 (0x8000 and 0x8001) have been assigned.) 337 61,440 - 65,279 338 0xF000 - 0xFEFF Reserved for future use. IETF Review required to 339 define use. 341 65,280 - 65,534 342 0xFF00 - 0xFFFE Private Use. 344 65,535 345 0xFFFF Reserved, can only be assigned by a Standards 346 Action. 348 3.1.1. DNS RRTYPE Allocation Policy 350 Parameter values specified in Section 3.1 above, as assigned based on 351 DNS RRTYPE Allocation Policy, are allocated by Expert Review if they 352 meet the two requirements listed below. There will be a pool of a 353 small number of Experts appointed by the IESG. Each application will 354 be judged by an Expert selected by IANA. In any case where the 355 selected Expert is unavailable or states they have a conflict of 356 interest, IANA may select another Expert from the pool. 358 Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs 359 that do not meet the requirements below may nonetheless be allocated 360 by a Standards Action as modified by [RFC4020]. 362 1. A complete template as specified in Appendix A has been posted to 363 the dns-rrtype-applications@iana.org mailing list and received by 364 the Expert. 365 Note that the posting of partially completed, draft, or 366 formally submitted templates to dnsext@ietf.org by the applicant 367 or Expert for comment and discussion is highly encouraged. Formal 368 submission of an RRTYPE template without consideration of some 369 community review can be expected to increase the probability of 370 initial rejection leading to a need to re-submit after 371 modification. 373 2. The RR for which an RRTYPE code is being requested is either (a) a 374 data TYPE that can be handled as an Unknown RR as described in 375 [RFC3597] or (b) a Meta-TYPE whose processing is optional, i.e., 376 it is safe to simply discard RRs with that Meta-TYPE in queries or 377 responses. 378 Note that such RRs may include additional section processing, 380 provided such processing is optional. 382 After the applicant submits their formal application to IANA by 383 sending the completed template specified in Appendix A to the dns- 384 rrtype-applications@ietf.org mailing list, IANA appoints an Expert 385 and sends the completed template to the Expert copying the applicant. 386 No more than two weeks after receiving the application the Expert 387 shall explicitly approve or reject the application, informing IANA, 388 the applicant, and the dnsext@ietf.org mailing list. The Expert 389 should consult with other technical experts and the dnsext@ietf.org 390 mailing list as necessary. If the Expert does not approve the 391 application within this period, it is considered rejected. IANA 392 should report non-responsive Experts to the IESG. 394 IANA shall maintain a public archive of approved templates. In 395 addition, if the required description of the RRTYPE applied for is 396 referenced by URL, a copy of the document so referenced should be 397 included in the archive. 399 3.1.2. DNS RRTYPE Expert Guidelines 401 The Expert should normally reject any RRTYPE allocation request that 402 meets one or more of the following criteria: 404 1. Was documented in a manner that was not sufficiently clear or 405 complete to evaluate or implement. (Additional documentation can 406 be provided during the Expert review period.) 408 2. The proposed RRTYPE or RRTYPEs affect DNS processing and do not 409 meet the criteria in point 2 of Section 3.1.1 above. 411 3. Application use as documented makes incorrect assumptions about 412 DNS protocol behavior, such as wild cards, CNAME, DNAME, etc. 414 4. An excessive number of RRTYPE values is being requested when the 415 purpose could be met with a smaller number or with Private Use 416 values. 418 3.1.3. Special Note on the OPT RR 420 The OPT (OPTion) RR (RRTYPE 41) and its IANA considerations are 421 specified in [RFC2671bis]. Its primary purpose is to extend the 422 effective field size of various DNS fields including RCODE, label 423 type, OpCode, flag bits, and RDATA size. In particular, for resolvers 424 and servers that recognize it, it extends the RCODE field from 4 to 425 12 bits. 427 3.1.4. The AFSDB RR Subtype Field 429 The AFSDB RR [RFC1183] is a CLASS-insensitive RR that has the same 430 RDATA field structure as the MX RR [RFC1035], but the 16-bit unsigned 431 integer field at the beginning of the RDATA is interpreted as a 432 subtype as show below. This subtype registry is closed and allocation 433 of new subtypes is no longer permitted. 435 Decimal 436 Hexadecimal Assignment Policy 438 0 439 0x0000 Reserved, registry closed 441 1 442 0x0001 AFS v3.0 Location Service [RFC1183] 444 2 445 0x0002 DCE/NCA root cell directory node [RFC1183] 447 3 - 65,279 448 0x0003 - 0xFEFF Not allocated, registry closed 450 65,280 - 65,534 451 0xFF00 - 0xFFFE Private Use 453 65,535 454 0xFFFF Reserved, registry closed 456 3.2. RR CLASS IANA Considerations 458 There are currently two subcategories of DNS CLASSes: normal, data- 459 containing classes and QCLASSes that are only meaningful in queries 460 or updates. 462 DNS CLASSes have been little used but constitute another dimension of 463 the DNS distributed database. In particular, there is no necessary 464 relationship between the name space or root servers for one data 465 CLASS and those for another data CLASS. The same DNS NAME can have 466 completely different meanings in different CLASSes. The label types 467 are the same, and the null label is usable only as root in every 468 CLASS. As global networking and DNS have evolved, the IN, or 469 Internet, CLASS has dominated DNS use. 471 As yet, there has not been a requirement for "meta-CLASSes". That 472 would be a CLASS to designate transient data associated with a 473 particular DNS message, which might be usable in queries. However, it 474 is possible that there might be a future requirement for one or more 475 "meta-CLASSes". 477 CLASSes have mnemonics that must be completely disjoint from the 478 mnemonics used for RRTYPEs and that must match the following regular 479 expression: 481 [A-Z][A-Z0-9\-]*[A-Z0-9] 483 The current CLASS assignments and considerations for future 484 assignments are as follows: 486 Decimal 487 Hexadecimal Assignment / Policy, Reference 489 0 490 0x0000 Reserved; assignment requires a Standards Action 492 1 493 0x0001 Internet (IN) [RFC1035] 495 2 496 0x0002 Available for assignment by IETF Review as a data 497 CLASS 499 3 500 0x0003 Chaos (CH) [Moon1981] 502 4 503 0x0004 Hesiod (HS) [Dyer1987] 505 5 - 127 506 0x0005 - 0x007F Available for assignment by IETF Review for data 507 CLASSes only 509 128 - 253 510 0x0080 - 0x00FD Available for assignment by IETF Review for 511 QCLASSes and meta-CLASSes only 513 254 514 0x00FE QCLASS NONE [RFC2136] 516 255 517 0x00FF QCLASS * (ANY) [RFC1035] 519 256 - 32,767 520 0x0100 - 0x7FFF Available for assignment by IETF Review 522 32,768 - 57,343 523 0x8000 - 0xDFFF Assigned for data CLASSes only; Specification 524 Required for new assignments 526 57,344 - 65,279 527 0xE000 - 0xFEFF Assigned for QCLASSes and meta-CLASSes only; 528 Specification Required for new assignments 530 65,280 - 65,534 531 0xFF00 - 0xFFFE Private Use 533 65,535 534 0xFFFF Reserved; can only be assigned by a Standards 535 Action 537 3.3. Label Considerations 539 DNS NAMEs are sequences of labels [RFC1035]. 541 3.3.1. Label Types 543 At the present time, there are two categories of label types: data 544 labels and compression labels. Compression labels are pointers to 545 data labels elsewhere within an RR or DNS message and are intended to 546 shorten the wire encoding of NAMEs. 548 The two existing data label types are sometimes referred to as Text 549 and Binary. Text labels can, in fact, include any octet value 550 including zero-value octets, but many current uses involve only 551 printing ASCII characters [RFC20]. For retrieval, Text labels are 552 defined to treat ASCII upper and lower case letter codes as matching 553 [RFC4343]. Binary labels are bit sequences [RFC2673]. The Binary 554 label type is Historic [RFC2671bis]. 556 3.3.2. Label Contents and Use 558 The last label in each NAME is "ROOT", which is the zero-length 559 label. By definition, the null or ROOT label cannot be used for any 560 other NAME purpose. 562 NAMEs are local to a CLASS. The Hesiod [Dyer1987] and Chaos 563 [Moon1981] CLASSes are for essentially local use. The IN, or 564 Internet, CLASS is thus the only DNS CLASS in global use on the 565 Internet at this time. 567 A somewhat out-of-date description of name allocation in the IN Class 568 is given in [RFC1591]. Some information on reserved top-level domain 569 names is in BCP 32 [RFC2606]. 571 4. Security Considerations 573 This document addresses IANA considerations in the allocation of 574 general DNS parameters, not security. See [RFC4033], [RFC4034], and 575 [RFC4035] for secure DNS considerations. 577 5. IANA Considerations 579 This document consists entirely of DNS IANA Considerations. 581 IANA has established a process for accepting Appendix A templates and 582 selecting an Expert from those appointed to review such template form 583 applications. IANA forwards the template to the Expert copying the 584 applicant. IANA archives and makes available all approved RRTYPE 585 allocation templates and referred documentation (unless it is readily 586 available at a stable URI). It is the duty of the applicant to post 587 the formal application template to the dns-rrtype- 588 applications@ietf.org mailing list, which IANA will monitor. The 589 dnsext@ietf.org mailing list is for community discussion and comment. 590 See Section 3.1 and Appendix A for more details. 592 Appendix A: RRTYPE Allocation Template 594 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE 596 When ready for formal consideration, this template is to be submitted 597 to IANA for processing by emailing the template to dns-rrtype- 598 applications@ietf.org. 600 A. Submission Date: 602 B.1 Submission Type: [ ] New RRTYPE [ ] Modification to RRTYPE 603 B.2 Kind of RR: [ ] Data RR [ ] Meta-RR 605 C. Contact Information for submitter (will be publicly posted): 606 Name: 607 Email Address: 608 International telephone number: 609 Other contact handles: 611 D. Motivation for the new RRTYPE application. 612 Please keep this part at a high level to inform the Expert and 613 reviewers about uses of the RRTYPE. Most reviewers will be DNS 614 experts that may have limited knowledge of your application space. 616 E. Description of the proposed RR type. 617 This description can be provided in-line in the template, as an 618 attachment, or with a publicly available URL. 620 F. What existing RRTYPE or RRTYPEs come closest to filling that need 621 and why are they unsatisfactory? 623 G. What mnemonic is requested for the new RRTYPE (optional)? 624 Note: this can be left blank and the mnemonic decided after the 625 template is accepted. 627 H. Does the requested RRTYPE make use of any existing IANA registry 628 or require the creation of a new IANA sub-registry in DNS 629 Parameters? If so, please indicate which registry is to be used 630 or created. If a new sub-registry is needed, specify the 631 allocation policy for it and its initial contents. Also include 632 what the modification procedures will be. 634 I. Does the proposal require/expect any changes in DNS 635 servers/resolvers that prevent the new type from being processed 636 as an unknown RRTYPE (see [RFC3597])? 638 J. Comments: 640 Appendix B: Changes From RFC 6195 642 Drop description of changes from RFC 5395 to RFC 6195 since those 643 changes have already happened and we don't need to do them again. Add 644 description of changes from RFC 6195. 646 Cut back RRTYPE Expert review period to two weeks and eliminate the 647 mandatory dnsext@ietf.org comment period. Change workflow description 648 for RRTYPE review and allocation to correspond more closely to actual 649 practice. 651 Close AFSDB sub-type registry. 653 Update references for revised versions and change ASCII reference to 654 [RFC20]. 656 Clarify IANA archiving of referenced documentation as well as 657 approved RRTYPE application template. 659 In the RRTYPE application template, change the label of question "B" 660 to "B.1" and add "B.2" to ask about the kind of RR. 662 A number of editorial changes and typo fixes. 664 Normative References 666 [RFC20] - Cerf, V., "ASCII format for network interchange", RFC 20, 667 October 1969. 669 [RFC1034] - Mockapetris, P., "Domain names - concepts and 670 facilities", STD 13, RFC 1034, November 1987. 672 [RFC1035] - Mockapetris, P., "Domain names - implementation and 673 specification", STD 13, RFC 1035, November 1987. 675 [RFC1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone 676 Changes (DNS NOTIFY)", RFC 1996, August 1996. 678 [RFC2136] - Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 679 "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 680 April 1997. 682 [RFC2181] - Elz, R. and R. Bush, "Clarifications to the DNS 683 Specification", RFC 2181, July 1997. 685 [RFC2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 686 Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", 687 RFC 2845, May 2000. 689 [RFC2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY 690 RR)", RFC 2930, 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] - Eastlake 3rd, D., "HMAC SHA (Hashed Message 714 Authentication Code, Secure Hash Algorithm) TSIG Algorithm 715 Identifiers", RFC 4635, August 2006. 717 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 718 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 720 [RFC2671bis] - Damas, J., Graff, M., and Vixie, P., "Extension 721 Mechanisms for DNS (EDNS0)", draft-ietf-dnsext-rfc2671bis-edns0, work 722 in progress. 724 Informative References 726 [Dyer1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical 727 Plan - Name Service, April 1987. 729 [Moon1981] - Moon, D., "Chaosnet", A.I. Memo 628, Massachusetts 730 Institute of Technology Artificial Intelligence Laboratory, June 731 1981. 733 [RFC1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. 734 Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. 736 [RFC1591] - Postel, J., "Domain Name System Structure and 737 Delegation", RFC 1591, March 1994. 739 [RFC2606] - Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 740 Names", BCP 32, RFC 2606, June 1999. 742 [RFC2673] - Crawford, M., "Binary Labels in the Domain Name System", 743 RFC 2673, August 1999. 745 [RFC2931] - Eastlake 3rd, D., "DNS Request and Transaction Signatures 746 ( SIG(0)s )", RFC 2931, September 2000. 748 [RFC4343] - Eastlake 3rd, D., "Domain Name System (DNS) Case 749 Insensitivity Clarification", RFC 4343, January 2006. 751 [RFC6195] - Eastlake 3rd, D., "Domain Name System (DNS) IANA 752 Considerations", RFC 6195, March 2011. 754 Author's Address 756 Donald E. Eastlake 3rd 757 Huawei R&D USA 758 155 Beaver Street 759 Milford, MA 01757 USA 761 Telephone: +1-508-333-2270 762 email: d3e3e3@gmail.com 764 Copyright and IPR Provisions 766 Copyright (c) 2012 IETF Trust and the persons identified as the 767 document authors. All rights reserved. 769 This document is subject to BCP 78 and the IETF Trust's Legal 770 Provisions Relating to IETF Documents 771 (http://trustee.ietf.org/license-info) in effect on the date of 772 publication of this document. Please review these documents 773 carefully, as they describe your rights and restrictions with respect 774 to this document. Code Components extracted from this document must 775 include Simplified BSD License text as described in Section 4.e of 776 the Trust Legal Provisions and are provided without warranty as 777 described in the Simplified BSD License.