idnits 2.17.1 draft-ietf-dnsext-rfc6195bis-02.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 abstract seems to indicate that this document updates RFC3597, but the header doesn't have an 'Updates:' line to match this. 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 (June 10, 2012) is 4338 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 486, but not defined == Missing Reference: 'A-Z0-9' is mentioned on line 486, 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' -- 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 6195 (Obsoleted by RFC 6895) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 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: December 9, 2012 June 10, 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 and updates RFCs 1183 and 3597. 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. The list of Internet-Draft 39 Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Table of Contents 44 1. Introduction............................................3 45 1.1 Terminology............................................3 46 1.2 Acknowledgement........................................3 48 2. DNS Query/Response Headers..............................4 49 2.1 One Spare Bit?.........................................4 50 2.2 OpCode Assignment......................................5 51 2.3 RCODE Assignment.......................................5 53 3. DNS Resource Records....................................7 54 3.1 RRTYPE IANA Considerations.............................8 55 3.1.1 DNS RRTYPE Allocation Policy.........................9 56 3.1.2 DNS RRTYPE Expert Guidelines........................10 57 3.1.3 Special Note on the OPT RR..........................10 58 3.1.4 The AFSDB RR Subtype Field..........................11 59 3.2 RR CLASS IANA Considerations..........................11 60 3.3. Label Considerations.................................13 61 3.3.1 Label Types.........................................13 62 3.3.2 Label Contents and Use..............................13 64 4. Security Considerations................................15 65 5. IANA Considerations....................................15 67 Appendix A: RRTYPE Allocation Template....................16 68 Appendix B: Changes From RFC 6195.........................17 70 Normative References......................................18 71 Informative References....................................19 73 1. Introduction 75 The Domain Name System (DNS) provides replicated distributed secure 76 hierarchical databases that store "resource records" (RRs) under 77 domain names. DNS data is structured into CLASSes and zones that can 78 be independently maintained. Familiarity with [RFC1034], [RFC1035], 79 [RFC2136], [RFC2181], and [RFC4033] is assumed. 81 This document provides, either directly or by reference, the general 82 IANA parameter assignment considerations that apply across DNS query 83 and response headers and all RRs. There may be additional IANA 84 considerations that apply to only a particular RRTYPE or 85 query/response OpCode. See the specific RFC defining that RRTYPE or 86 query/response OpCode for such considerations if they have been 87 defined, except for AFSDB RR considerations [RFC1183], which are 88 included herein. This RFC obsoletes [RFC6195]; however, the only 89 significant changes are those to the RRTYPE IANA allocation process, 90 aimed at streamlining it and clarifying the expected behavior of the 91 parties involved, and the closing of the AFSDB sub-type registry. 93 IANA currently maintains a web page of DNS parameters available from 94 http://www.iana.org. 96 1.1 Terminology 98 "Standards Action", "IETF Review", "Specification Required", and 99 "Private Use" are as defined in [RFC5226]. 101 1.2 Acknowledgement 103 Alfred Hoenes contributions are gratefully acknowledged. 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 [RFC6195]: 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 a Standards 138 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 structure 144 and data type for Update but are instead the counts for the zone 145 (ZOCOUNT), prerequisite (PRCOUNT), update (UPCOUNT), and additional 146 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 implementations 153 ignore this bit. 155 Assigning a meaning to the Z bit requires a 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 a Standards Action as modified by 172 [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 [RFC2671bis], TSIG RRs [RFC2845], and TKEY RRs [RFC2930]. The 180 OPT RR provides an 8-bit extension resulting in a 12-bit RCODE field, 181 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 than in 186 other contexts. This duplicate assignment was accidental. See table 187 below. 189 RCODE Name Description Reference 190 Decimal 191 Hexadecimal 193 0 NoError No Error [RFC1035] 194 1 FormErr Format Error [RFC1035] 195 2 ServFail Server Failure [RFC1035] 196 3 NXDomain Non-Existent Domain [RFC1035] 197 4 NotImp Not Implemented [RFC1035] 198 5 Refused Query Refused [RFC1035] 199 6 YXDomain Name Exists when it should not [RFC2136] 200 7 YXRRSet RR Set Exists when it should not [RFC2136] 201 8 NXRRSet RR Set that should exist does not [RFC2136] 202 9 NotAuth Server Not Authoritative for zone [RFC2136] 203 10 NotZone Name not contained in zone [RFC2136] 205 11 - 15 206 0xB - 0xF Available for assignment 208 16 BADVERS Bad OPT Version [RFC2671bis] 209 16 BADSIG TSIG Signature Failure [RFC2845] 210 17 BADKEY Key not recognized [RFC2845] 211 18 BADTIME Signature out of time window [RFC2845] 212 19 BADMODE Bad TKEY Mode [RFC2930] 213 20 BADNAME Duplicate key name [RFC2930] 214 21 BADALG Algorithm not supported [RFC2930] 215 22 BADTRUC Bad Truncation [RFC4635] 217 23 - 3,840 218 0x0017 - 0x0F00 Available for assignment 220 3,841 - 4,095 221 0x0F01 - 0x0FFF Private Use 223 4,096 - 65,534 224 0x1000 - 0xFFFE Available for assignment 226 65,535 227 0xFFFF Reserved, can only be allocated by a Standards 228 Action. 230 Since it is important that RCODEs be understood for interoperability, 231 assignment of a new RCODE in the ranges listed above as "Available 232 for assignment" requires an IETF Review. 234 3. DNS Resource Records 236 All RRs have the same top-level format, shown in the figure below 237 taken from [RFC1035]. 239 1 1 1 1 1 1 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 241 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 242 | | 243 / / 244 / NAME / 245 / / 246 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 247 | TYPE | 248 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 249 | CLASS | 250 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 251 | TTL | 252 | | 253 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 254 | RDLENGTH | 255 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| 256 / RDATA / 257 / / 258 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 260 NAME is an owner name, i.e., the name of the node to which this 261 resource record pertains. NAMEs are specific to a CLASS as described 262 in Section 3.2. NAMEs consist of an ordered sequence of one or more 263 labels, each of which has a label type [RFC1035] [RFC2671bis]. 265 TYPE is a 2-octet unsigned integer containing one of the RRTYPE 266 codes. See Section 3.1. 268 CLASS is a 2-octet unsigned integer containing one of the RR CLASS 269 codes. See Section 3.2. 271 TTL is a 4-octet (32-bit) unsigned integer that specifies, for data 272 TYPEs, the number of seconds that the resource record may be cached 273 before the source of the information should again be consulted. Zero 274 is interpreted to mean that the RR can only be used for the 275 transaction in progress. 277 RDLENGTH is an unsigned 16-bit integer that specifies the length in 278 octets of the RDATA field. 280 RDATA is a variable-length string of octets that constitutes the 281 resource. The format of this information varies according to the TYPE 282 and, in some cases, the CLASS of the resource record. 284 3.1 RRTYPE IANA Considerations 286 There are three subcategories of RRTYPE numbers: data TYPEs, QTYPEs, 287 and Meta-TYPEs. 289 Data TYPEs are the means of storing data. QTYPES can only be used in 290 queries. Meta-TYPEs designate transient data associated with a 291 particular DNS message and, in some cases, can also be used in 292 queries. Thus far, data TYPEs have been assigned from 1 upward, plus 293 the block from 100 through 103, and from 32,768 upward, while Q and 294 Meta-TYPEs have been assigned from 255 downward except for the OPT 295 Meta-RR, which is assigned TYPE 41. There have been DNS 296 implementations that made caching decisions based on the top bit of 297 the bottom byte of the RRTYPE. 299 There are currently three Meta-TYPEs assigned: OPT [RFC2671bis], TSIG 300 [RFC2845], and TKEY [RFC2930]. There are currently five QTYPEs 301 assigned: * (ALL), MAILA, MAILB, AXFR, and IXFR. 303 Allocated RRTYPEs have mnemonics that must be completely disjoint 304 from the mnemonics used for CLASSes and that must match the regular 305 expression below. In addition, the generic CLASS and RRTYPE names 306 specified in Section 5 of [RFC3597] cannot be assigned as new RRTYPE 307 mnemonics. 309 [A-Z][A-Z0-9\-]*[A-Z0-9] 310 but not 311 (TYPE|CLASS)(0|[1-9][0-9]*) 313 Considerations for the allocation of new RRTYPEs are as follows: 315 Decimal 316 Hexadecimal Assignment Policy 318 0 319 0x0000 RRTYPE zero is used as a special indicator for the 320 SIG (0) RR [RFC2931] [RFC4034] and in other 321 circumstances, and it must never be allocated for 322 ordinary use. 324 1 - 127 325 0x0001 - 0x007F Remaining RRTYPEs in this range are assigned for 326 data TYPEs by the DNS RRTYPE Allocation Policy as 327 specified in Section 3.1.1. 329 128 - 255 330 0x0080 - 0x00FF Remaining RRTYPEs in this range are assigned for Q 331 and Meta-TYPEs by the DNS RRTYPE Allocation Policy 332 as specified in Section 3.1.1. 334 256 - 61,439 335 0x0100 - 0xEFFF Remaining RRTYPEs in this range are assigned for 336 data RRTYPEs by the DNS RRTYPE Allocation Policy as 337 specified in Section 3.1.1. (32,768 and 32,769 338 (0x8000 and 0x8001) have been assigned.) 340 61,440 - 65,279 341 0xF000 - 0xFEFF Reserved for future use. IETF Review required to 342 define use. 344 65,280 - 65,534 345 0xFF00 - 0xFFFE Private Use. 347 65,535 348 0xFFFF Reserved, can only be assigned by a Standards 349 Action. 351 3.1.1 DNS RRTYPE Allocation Policy 353 Parameter values specified in Section 3.1 above as assigned based on 354 DNS RRTYPE Allocation Policy, are allocated by Expert Review if they 355 meet the two requirements listed below. There will be a pool of a 356 small number of Experts appointed by the IESG. Each application will 357 be judged by an Expert selected by IANA. In any case where the 358 selected Expert is unavailable or states they have a conflict of 359 interest, IANA may select another Expert from the pool. Some 360 guidelines for the Experts are given in Section 3.1.2. 362 RRTYPEs that do not meet the requirements below may nonetheless be 363 allocated by a Standards Action as modified by [RFC4020]. 365 1. A complete template as specified in Appendix A has been posted to 366 the dns-rrtype-applications@iana.org mailing list and received by 367 the Expert. 368 Note that the posting of partially completed, draft, or 369 formally submitted templates to dnsext@ietf.org by the applicant 370 or Expert for comment and discussion is highly encouraged. Formal 371 submission of an RRTYPE template without consideration of some 372 community review can be expected to increase the probability of 373 initial rejection leading to a need to re-submit after 374 modification. 376 2. The RR for which an RRTYPE code is being requested is either (a) a 377 data TYPE that can be handled as an Unknown RR as described in 378 [RFC3597] or (b) a Meta-TYPE whose processing is optional, i.e., 379 it is safe to simply discard RRs with that Meta-TYPE in queries or 380 responses. 381 Note that such RRs may include additional section processing, 383 provided such processing is optional. 385 After the applicant submits their formal application to IANA by 386 sending the completed template specified in Appendix A to the dns- 387 rrtype-applications@ietf.org mailing list, IANA appoints an Expert 388 and sends the completed template to the Expert copying the applicant. 389 No more than two weeks after receiving the application the Expert 390 shall explicitly approve or reject the application, informing IANA, 391 the applicant, and the dnsext@ietf.org mailing list. The Expert 392 should consult with other technical experts and the dnsext@ietf.org 393 mailing list as necessary. If the Expert does not approve the 394 application within this period, it is considered rejected. IANA 395 should report non-responsive Experts to the IESG. 397 IANA shall maintain a public archive of approved templates. In 398 addition, if the required description of the RRTYPE applied for is 399 referenced by URL, a copy of the document so referenced should be 400 included in the archive. 402 3.1.2 DNS RRTYPE Expert Guidelines 404 The Expert should normally reject any RRTYPE allocation request that 405 meets one or more of the following criteria: 407 1. Was documented in a manner that was not sufficiently clear or 408 complete to evaluate or implement. (Additional documentation can 409 be provided during the Expert review period.) 411 2. The proposed RRTYPE or RRTYPEs affect DNS processing and do not 412 meet the criteria in point 2 of Section 3.1.1 above. 414 3. Application use as documented makes incorrect assumptions about 415 DNS protocol behavior, such as wild cards, CNAME, DNAME, etc. 417 4. An excessive number of RRTYPE values is being requested when the 418 purpose could be met with a smaller number or with Private Use 419 values. 421 3.1.3 Special Note on the OPT RR 423 The OPT (OPTion) RR (RRTYPE 41) and its IANA considerations are 424 specified in [RFC2671bis]. Its primary purpose is to extend the 425 effective field size of various DNS fields including RCODE, label 426 type, OpCode, flag bits, and RDATA size. In particular, for resolvers 427 and servers that recognize it, it extends the RCODE field from 4 to 428 12 bits. 430 3.1.4 The AFSDB RR Subtype Field 432 The AFSDB RR [RFC1183] is a CLASS-insensitive RR that has the same 433 RDATA field structure as the MX RR [RFC1035], but the 16-bit unsigned 434 integer field at the beginning of the RDATA is interpreted as a 435 subtype as shown below. This subtype registry is closed and 436 allocation of new subtypes is no longer permitted. 438 Decimal 439 Hexadecimal Assignment Policy 441 0 442 0x0000 Reserved, registry closed 444 1 445 0x0001 AFS v3.0 Location Service [RFC1183] 447 2 448 0x0002 DCE/NCA root cell directory node [RFC1183] 450 3 - 65,279 451 0x0003 - 0xFEFF Not allocated, registry closed 453 65,280 - 65,534 454 0xFF00 - 0xFFFE Private Use 456 65,535 457 0xFFFF Reserved, registry closed 459 3.2 RR CLASS IANA Considerations 461 There are currently two subcategories of DNS CLASSes: normal, data- 462 containing classes and QCLASSes that are only meaningful in queries 463 or updates. 465 DNS CLASSes have been little used but constitute another dimension of 466 the DNS distributed database. In particular, there is no necessary 467 relationship between the name space or root servers for one data 468 CLASS and those for another data CLASS. The same DNS NAME can have 469 completely different meanings in different CLASSes. The label types 470 are the same, and the null label is usable only as root in every 471 CLASS. As global networking and DNS have evolved, the IN, or 472 Internet, CLASS has dominated DNS use. 474 As yet, there has not been a requirement for "meta-CLASSes". That 475 would be a CLASS to designate transient data associated with a 476 particular DNS message, which might be usable in queries. However, it 477 is possible that there might be a future requirement for one or more 478 "meta-CLASSes". 480 Assigned CLASSes have mnemonics that must be completely disjoint from 481 the mnemonics used for RRTYPEs and that must match the regular 482 expression below. In addition, the generic CLASS and RRTYPE names 483 specified in Section 5 of [RFC3597] cannot be assigned as new CLASS 484 mnemonics. 486 [A-Z][A-Z0-9\-]*[A-Z0-9] 487 but not 488 (CLASS|RRTYPE)(0|[1-9][0-9]*) 490 The current CLASS assignments and considerations for future 491 assignments are as follows: 493 Decimal 494 Hexadecimal Assignment / Policy, Reference 496 0 497 0x0000 Reserved; assignment requires a Standards Action 499 1 500 0x0001 Internet (IN) [RFC1035] 502 2 503 0x0002 Available for assignment by IETF Review as a data 504 CLASS 506 3 507 0x0003 Chaos (CH) [Moon1981] 509 4 510 0x0004 Hesiod (HS) [Dyer1987] 512 5 - 127 513 0x0005 - 0x007F Available for assignment by IETF Review for data 514 CLASSes only 516 128 - 253 517 0x0080 - 0x00FD Available for assignment by IETF Review for 518 QCLASSes and meta-CLASSes only 520 254 521 0x00FE QCLASS NONE [RFC2136] 523 255 524 0x00FF QCLASS * (ANY) [RFC1035] 526 256 - 32,767 527 0x0100 - 0x7FFF Available for assignment by IETF Review 528 32,768 - 57,343 529 0x8000 - 0xDFFF Available for assignment to data CLASSes only; 530 Specification Required 532 57,344 - 65,279 533 0xE000 - 0xFEFF Available for assignment to QCLASSes and meta- 534 CLASSes only; Specification Required 536 65,280 - 65,534 537 0xFF00 - 0xFFFE Private Use 539 65,535 540 0xFFFF Reserved; can only be assigned by a Standards 541 Action 543 3.3. Label Considerations 545 DNS NAMEs are sequences of labels [RFC1035]. 547 3.3.1 Label Types 549 At the present time, there are two categories of label types: data 550 labels and compression labels. Compression labels are pointers to 551 data labels elsewhere within an RR or DNS message and are intended to 552 shorten the wire encoding of NAMEs. 554 The two existing data label types are sometimes referred to as Text 555 and Binary. Text labels can, in fact, include any octet value 556 including zero-value octets, but many current uses involve only 557 printing ASCII characters [US-ASCII]. For retrieval, Text labels are 558 defined to treat ASCII upper and lower case letter codes as matching 559 [RFC4343]. Binary labels are bit sequences [RFC2673]. The Binary 560 label type is Historic [RFC2671bis]. 562 3.3.2 Label Contents and Use 564 The last label in each NAME is "ROOT", which is the zero-length 565 label. By definition, the null or ROOT label cannot be used for any 566 other NAME purpose. 568 NAMEs are local to a CLASS. The Hesiod [Dyer1987] and Chaos 569 [Moon1981] CLASSes are for essentially local use. The IN, or 570 Internet, CLASS is thus the only DNS CLASS in global use on the 571 Internet at this time. 573 A somewhat out-of-date description of name allocation in the IN Class 574 is given in [RFC1591]. Some information on reserved top-level domain 575 names is in BCP 32 [RFC2606]. 577 4. Security Considerations 579 This document addresses IANA considerations in the allocation of 580 general DNS parameters, not security. See [RFC4033], [RFC4034], and 581 [RFC4035] for secure DNS considerations. 583 5. IANA Considerations 585 This document consists entirely of DNS IANA Considerations. 587 IANA has established a process for accepting Appendix A templates and 588 selecting an Expert from those appointed to review such template form 589 applications. IANA forwards the template to the Expert copying the 590 applicant. IANA archives and makes available all approved RRTYPE 591 allocation templates and referred documentation (unless it is readily 592 available at a stable URI). It is the duty of the applicant to post 593 the formal application template to the dns-rrtype- 594 applications@ietf.org mailing list, which IANA will monitor. The 595 dnsext@ietf.org mailing list is for community discussion and comment. 596 See Section 3.1 and Appendix A for more details. 598 Appendix A: RRTYPE Allocation Template 600 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE 602 When ready for formal consideration, this template is to be submitted 603 to IANA for processing by emailing the template to dns-rrtype- 604 applications@ietf.org. 606 A. Submission Date: 608 B.1 Submission Type: [ ] New RRTYPE [ ] Modification to RRTYPE 609 B.2 Kind of RR: [ ] Data RR [ ] Meta-RR 611 C. Contact Information for submitter (will be publicly posted): 612 Name: 613 Email Address: 614 International telephone number: 615 Other contact handles: 617 D. Motivation for the new RRTYPE application. 618 Please keep this part at a high level to inform the Expert and 619 reviewers about uses of the RRTYPE. Most reviewers will be DNS 620 experts that may have limited knowledge of your application space. 622 E. Description of the proposed RR type. 623 This description can be provided in-line in the template, as an 624 attachment, or with a publicly available URL. 626 F. What existing RRTYPE or RRTYPEs come closest to filling that need 627 and why are they unsatisfactory? 629 G. What mnemonic is requested for the new RRTYPE (optional)? 630 Note: this can be left blank and the mnemonic decided after the 631 template is accepted. 633 H. Does the requested RRTYPE make use of any existing IANA registry 634 or require the creation of a new IANA sub-registry in DNS 635 Parameters? If so, please indicate which registry is to be used 636 or created. If a new sub-registry is needed, specify the 637 allocation policy for it and its initial contents. Also include 638 what the modification procedures will be. 640 I. Does the proposal require/expect any changes in DNS 641 servers/resolvers that prevent the new type from being processed 642 as an unknown RRTYPE (see [RFC3597])? 644 J. Comments: 646 Appendix B: Changes From RFC 6195 648 Drop description of changes from RFC 5395 to [RFC6195] since those 649 changes have already happened and we don't need to do them again. Add 650 description of changes from [RFC6195] to this document. 652 Cut back RRTYPE Expert review period to two weeks and eliminate the 653 mandatory dnsext@ietf.org comment period. Change workflow description 654 for RRTYPE review and allocation to correspond more closely to actual 655 practice. 657 Close the AFSDB sub-type registry. 659 Update references for revised versions. 661 Clarify IANA archiving of referenced documentation as well as 662 approved RRTYPE application template. 664 In the RRTYPE application template, change the label of question "B" 665 to "B.1" and add "B.2" to ask about the kind of RR. 667 Addition of text and an exclusory regular expression to Sections 3.1 668 and 3.2 to prohibit the use of the generic CLASS and RRTYPE names 669 specified in [RFC3597] as the mnemonics for new CLASSes and RRTYPEes. 671 A number of editorial changes and typo fixes. 673 Normative References 675 [RFC1034] - Mockapetris, P., "Domain names - concepts and 676 facilities", STD 13, RFC 1034, November 1987. 678 [RFC1035] - Mockapetris, P., "Domain names - implementation and 679 specification", STD 13, RFC 1035, November 1987. 681 [RFC1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone 682 Changes (DNS NOTIFY)", RFC 1996, August 1996. 684 [RFC2136] - Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 685 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 686 RFC 2136, April 1997. 688 [RFC2181] - Elz, R. and R. Bush, "Clarifications to the DNS 689 Specification", RFC 2181, July 1997. 691 [RFC2845] - Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 692 Wellington, "Secret Key Transaction Authentication for 693 DNS (TSIG)", RFC 2845, May 2000. 695 [RFC2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY 696 RR)", RFC 2930, September 2000. 698 [RFC3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 699 2002. 701 [RFC3597] - Gustafsson, A., "Handling of Unknown DNS Resource Record 702 (RR) Types", RFC 3597, September 2003. 704 [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of 705 Standards Track Code Points", BCP 100, RFC 4020, February 706 2005. 708 [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 709 Rose, "DNS Security Introduction and Requirements", RFC 710 4033, March 2005. 712 [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 713 Rose, "Resource Records for the DNS Security Extensions", 714 RFC 4034, March 2005. 716 [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 717 Rose, "Protocol Modifications for the DNS Security 718 Extensions", RFC 4035, March 2005. 720 [RFC4635] - Eastlake 3rd, D., "HMAC SHA (Hashed Message 721 Authentication Code, Secure Hash Algorithm) TSIG 722 Algorithm Identifiers", RFC 4635, August 2006. 724 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 725 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 726 May 2008. 728 [RFC2671bis] - Damas, J., Graff, M., and Vixie, P., "Extension 729 Mechanisms for DNS (EDNS0)", draft-ietf-dnsext- 730 rfc2671bis-edns0, work in progress. 732 [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", 733 X3.4, American National Standards Institute: New York, 734 1968 736 Informative References 738 [Dyer1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical 739 Plan - Name Service, April 1987. 741 [Moon1981] - Moon, D., "Chaosnet", A.I. Memo 628, Massachusetts 742 Institute of Technology Artificial Intelligence 743 Laboratory, June 1981. 745 [RFC1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. 746 Mockapetris, "New DNS RR Definitions", RFC 1183, October 747 1990. 749 [RFC1591] - Postel, J., "Domain Name System Structure and 750 Delegation", RFC 1591, March 1994. 752 [RFC2606] - Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 753 Names", BCP 32, RFC 2606, June 1999. 755 [RFC2673] - Crawford, M., "Binary Labels in the Domain Name System", 756 RFC 2673, August 1999. 758 [RFC2931] - Eastlake 3rd, D., "DNS Request and Transaction Signatures 759 ( SIG(0)s )", RFC 2931, September 2000. 761 [RFC4343] - Eastlake 3rd, D., "Domain Name System (DNS) Case 762 Insensitivity Clarification", RFC 4343, January 2006. 764 [RFC6195] - Eastlake 3rd, D., "Domain Name System (DNS) IANA 765 Considerations", RFC 6195, March 2011. 767 Author's Address 769 Donald E. Eastlake 3rd 770 Huawei R&D USA 771 155 Beaver Street 772 Milford, MA 01757 USA 774 Telephone: +1-508-333-2270 775 email: d3e3e3@gmail.com 777 Copyright and IPR Provisions 779 Copyright (c) 2012 IETF Trust and the persons identified as the 780 document authors. All rights reserved. 782 This document is subject to BCP 78 and the IETF Trust's Legal 783 Provisions Relating to IETF Documents 784 (http://trustee.ietf.org/license-info) in effect on the date of 785 publication of this document. Please review these documents 786 carefully, as they describe your rights and restrictions with respect 787 to this document. Code Components extracted from this document must 788 include Simplified BSD License text as described in Section 4.e of 789 the Trust Legal Provisions and are provided without warranty as 790 described in the Simplified BSD License.