idnits 2.17.1 draft-ietf-dnsext-2929bis-07.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 669. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 682. 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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2929, but the abstract doesn't seem to mention this, which it should. -- 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 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 (July 13, 2008) is 5763 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 466, but not defined == Missing Reference: 'A-Z0-9-' is mentioned on line 466, but not defined ** 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- 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 (~~), 5 warnings (==), 12 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 Eastlake Enterprises 3 Updates: RFCs 1183 and 3597 4 Intended status: Best Current Practice 5 Expires: January 12, 2009 July 13, 2008 7 Domain Name System (DNS) IANA Considerations 9 11 Status of This Document 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Distribution of this draft is unlimited. It is intended to become the 19 new BCP 42 obsoleting RFC 2929. Comments should be sent to the DNS 20 Extensions Working Group mailing list . 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 Internet Assigned Number Authority (IANA) parameter assignment 41 considerations are specified for the allocation of Domain Name System 42 (DNS) resource record types, CLASSes, operation codes, error codes, 43 DNS protocol message header bits, and AFSDB resource record subtypes. 45 Table of Contents 47 Status of This Document....................................1 48 Abstract...................................................1 50 1. Introduction............................................3 51 1.1 Terminology............................................3 53 2. DNS Query/Response Headers..............................4 54 2.1 One Spare Bit?.........................................4 55 2.2 Opcode Assignment......................................5 56 2.3 RCODE Assignment.......................................5 58 3. DNS Resource Records....................................7 59 3.1 RRTYPE IANA Considerations.............................8 60 3.1.1 DNS RRTYPE Allocation Policy.........................9 61 3.1.2 DNS RRTYPE Expert Guidelines........................10 62 3.1.3 Special Note on the OPT RR..........................10 63 3.1.4 The AFSDB RR Subtype Field..........................10 64 3.2 RR CLASS IANA Considerations..........................11 65 3.3 Label Considerations..................................13 66 3.3.1 Label Types.........................................13 67 3.3.2 Label Contents and Use..............................13 69 4. Security Considerations................................14 70 5. IANA Considerations....................................14 72 Annex A: RRTYPE Allocation Template.......................16 74 Additional IPR Provisions.................................18 75 Copyright.................................................18 76 Normative References......................................19 77 Informative References....................................20 78 Author's Address..........................................21 80 1. Introduction 82 The Domain Name System (DNS) provides replicated distributed secure 83 hierarchical databases which store "resource records" (RRs) under 84 domain names. DNS data is structured into CLASSes and zones which can 85 be independently maintained. See [RFC1034], [RFC1035], [RFC2136], 86 [RFC2181], and [RFC4033] familiarity with which is assumed. 88 This document provides, either directly or by reference, the general 89 IANA parameter assignment considerations applying across DNS query 90 and response headers and all RRs. There may be additional IANA 91 considerations that apply to only a particular RRTYPE or 92 query/response opcode. See the specific RFC defining that RRTYPE or 93 query/response opcode for such considerations if they have been 94 defined, except for AFSDB RR considerations [RFC1183] which are 95 included herein. This RFC obsoletes [RFC2929]. 97 IANA currently maintains a web page of DNS parameters. See 98 . 100 1.1 Terminology 102 "IETF Standards Action", "IETF Review", "Specification Required", and 103 "Private Use" are as defined in [RFC5226]. 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 use 135 a "query" bit with a different meaning in a response or to define a 136 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 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 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 Review. 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 upward 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 - remaining RRTYPEs in this range are assigned for 325 data RRTYPEs by the DNS RRTYPE Allocation Policy as specified 326 in section 3.1.1. (32,768 and 32,769 (0x8000 and 0x8001) have 327 been assigned.) 329 61,440 - 65,279 330 0xF000 - 0xFEFF - reserved for future use. IETF Review required to 331 define use. 333 65,280 - 65,534 334 0xFF00 - 0xFFFE - Private Use. 336 65,535 337 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. 339 3.1.1 DNS RRTYPE Allocation Policy 341 Parameter values specified in Section 3.1 above as assigned based on 342 DNS RRTYPE Allocation Policy are allocated by Expert Review if they 343 meet the two requirements listed below. There will be a pool of a 344 small number of Experts appointed by the IESG. Each application will 345 be ruled on by an Expert selected by IANA. In any case where the 346 selected Expert is unavailable or states they have a conflict of 347 interest, IANA may select another Expert from the pool. 349 Some guidelines for the Experts are given in Section 3.1.2. RRTYPEs 350 that do not meet the requirements below, may nonetheless be allocated 351 by IETF Standards Action as modified by [RFC4020]. 353 1. A complete template as specified in Annex A has been posted for 354 three weeks to the TBD2@TBD mailing list before the Expert Review 355 decision. 356 Note that partially completed or draft templates may be posted 357 directly by the applicant for comment and discussion but the 358 formal posting to start the three week period is made by the 359 Expert. 361 2. The RR for which a RRTYPE code is being requested is either (a) a 362 data TYPE which can be handled as an Unknown RR as described in 363 [RFC3597] or (b) a Meta-Type whose processing is optional, i.e., 364 it is safe to simply discard RRs with that Meta-Type in queries or 365 responses. 366 Note that such RRs may include additional section processing 367 provided such processing is optional. 369 No less than three weeks and no more than six weeks after a completed 370 template has been formally posted to TBD2@TBD, the selected Expert 371 shall post a message, explicitly accepting or rejecting the 372 application, to IANA, TBD2@TBD, and the email address provided by 373 the applicant. If the Expert does not post such a message, the 374 application shall be considered rejected but may be re-submitted to 375 IANA. 377 IANA shall maintain a public archive of approved templates. 379 3.1.2 DNS RRTYPE Expert Guidelines 381 The selected DNS RRTYPE Expert is required to monitor discussion of 382 the proposed RRTYPE which may occur on the TBD2@TBD2 mailing list and 383 may consult with other technical experts as necessary. The Expert 384 should normally reject any RRTYPE allocation request which meets one 385 or more of the following criterion: 387 1. Was documented in a manner that was not sufficiently clear to 388 evaluate or implement. 390 2. Proposed RRTYPE or RRTYPEs affect DNS processing and do not meet 391 the criteria in point 2 in Section 3.1.1 above. 393 3. The documentation of the proposed RRTYPE or RRTYPEs is incomplete. 394 (Additional documentation can be provided during the public 395 comment period or by the Expert.) 397 4. Application use as documented makes incorrect assumptions about 398 DNS protocol behavior, such as wild cards, CNAME, DNAME etc. 400 5. An excessive number of RRTYPE values is being requested when the 401 purpose could be met with a smaller number or with Private Use 402 values. 404 3.1.3 Special Note on the OPT RR 406 The OPT (OPTion) RR, RRTYPE 41, and its IANA Considerations are 407 specified in [RFC2671]. Its primary purpose is to extend the 408 effective field size of various DNS fields including RCODE, label 409 type, OpCode, flag bits, and RDATA size. In particular, for resolvers 410 and servers that recognize it, it extends the RCODE field from 4 to 411 12 bits. 413 3.1.4 The AFSDB RR Subtype Field 415 The AFSDB RR [RFC1183] is a CLASS insensitive RR that has the same 416 RDATA field structure as the MX RR but the 16 bit unsigned integer 417 field at the beginning of the RDATA is interpreted as a subtype as 418 follows: 420 Decimal 421 Hexadecimal 423 0 424 0x0000 - Reserved, allocation requires IETF Standards Action. 426 1 427 0x0001 - Andrews File Service v3.0 Location Service [RFC1183]. 429 2 430 0x0002 - DCE/NCA root cell directory node [RFC1183]. 432 3 - 65,279 433 0x0003 - 0xFEFF - Allocation by IETF Review. 435 65,280 - 65,534 436 0xFF00 - 0xFFFE - Private Use. 438 65,535 439 0xFFFF - Reserved, allocation requires IETF Standards Action. 441 3.2 RR CLASS IANA Considerations 443 There are currently two subcategories of DNS CLASSes: normal, data 444 containing classes and QCLASSes that are only meaningful in queries 445 or updates. 447 DNS CLASSes have been little used but constitute another dimension of 448 the DNS distributed database. In particular, there is no necessary 449 relationship between the name space or root servers for one data 450 CLASS and those for another data CLASS. The same DNS NAME can have 451 completely different meanings in different CLASSes. The label types 452 are the same and the null label is usable only as root in every 453 CLASS. As global networking and DNS have evolved, the IN, or 454 Internet, CLASS has dominated DNS use. 456 As yet there has not be a requirement for "meta-CLASSes". That would 457 be a CLASS to designate transient data associated with a particular 458 DNS message and which might be usable in queries. However, it is 459 possible that there might be a future requirement for one or more 460 "meta-CLASSes". 462 CLASSes have mnemonics which must be completely disjoint from the 463 mnemonics used for RRTYPEs and which must match the following regular 464 expression: 466 [A-Z][A-Z0-9-]* 468 The current CLASS assignments and considerations for future 469 assignments are as follows: 471 Decimal 472 Hexadecimal 474 0 475 0x0000 - Reserved, assignment requires an IETF Standards Action. 477 1 478 0x0001 - Internet (IN). 480 2 481 0x0002 - Available for assignment by IETF Review as a data CLASS. 483 3 484 0x0003 - Chaos (CH) [Moon1981]. 486 4 487 0x0004 - Hesiod (HS) [Dyer1987]. 489 5 - 127 490 0x0005 - 0x007F - available for assignment by IETF Review for data 491 CLASSes only. 493 128 - 253 494 0x0080 - 0x00FD - available for assignment by IETF Review for 495 QCLASSes and meta-CLASSes only. 497 254 498 0x00FE - QCLASS NONE [RFC2136]. 500 255 501 0x00FF - QCLASS * (ANY) [RFC1035]. 503 256 - 32,767 504 0x0100 - 0x7FFF - Assigned by IETF Review. 506 32,768 - 57,343 507 0x8000 - 0xDFFF - Assigned for data CLASSes only based on 508 Specification Required as defined in [RFC5226]. 510 57,344 - 65,279 511 0xE000 - 0xFEFF - Assigned for QCLASSes and meta-CLASSes only based 512 on Specification Required as defined in [RFC5226]. 514 65,280 - 65,534 515 0xFF00 - 0xFFFE - Private Use. 517 65,535 518 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. 520 3.3 Label Considerations 522 DNS NAMEs are sequences of labels [RFC1035]. 524 3.3.1 Label Types 526 At the present time, there are two categories of label types, data 527 labels and compression labels. Compression labels are pointers to 528 data labels elsewhere within an RR or DNS message and are intended to 529 shorten the wire encoding of NAMEs. 531 The two existing data label types are sometimes referred to as Text 532 and Binary. Text labels can, in fact, include any octet value 533 including zero value octets but many current uses involve only [US- 534 ASCII]. For retrieval, Text labels are defined to treat ASCII upper 535 and lower case letter codes as matching [RFC4343]. Binary labels are 536 bit sequences [RFC2673]. The Binary label type is Experimental 537 [RFC3363]. 539 IANA considerations for label types are given in [RFC2671]. 541 3.3.2 Label Contents and Use 543 The last label in each NAME is "ROOT" which is the zero length label. 544 By definition, the null or ROOT label cannot be used for any other 545 NAME purpose. 547 NAMEs are local to a CLASS. The Hesiod [Dyer1987] and Chaos 548 [Moon1981] CLASSes are for essentially local use. The IN or Internet 549 CLASS is thus the only DNS CLASS in global use on the Internet at 550 this time. 552 A somewhat out-of-date description of name allocation in the IN Class 553 is given in [RFC1591]. Some information on reserved top level domain 554 names is in BCP 32 [RFC2606]. 556 4. Security Considerations 558 This document addresses IANA considerations in the allocation of 559 general DNS parameters, not security. See [RFC4033], [RFC4034], and 560 [RFC4035] for secure DNS considerations. 562 5. IANA Considerations 564 This document consists entirely of DNS IANA Considerations and 565 includes the following changes from its predecessor [RFC2929]. It 566 affects the registry currently at 567 http://www.iana.org/assignments/dns-parameters and its subregistries. 569 1. In the Domain Name System "Resource record (RR) TYPES and QTYPEs" 570 registry, it changes most "IETF Consensus" and all "Specification 571 Required" allocation policies for RRTYPEs to be "DNS TYPE 572 Allocation Policy" and changes the policy for RRTYPE 0xFFFF to be 573 "IETF Standards Action". Remaining instances of "IETF Consensus" 574 are changed to "IETF Review" per [RFC5226]. It also specifies the 575 "DNS TYPE Allocation Policy" which is based on Expert Review with 576 additional provisions and restrictions, including the submittal of 577 a completed copy of the template in Annex A to TBD1@TBD, in most 578 cases, and requires "IETF Standards Action as modified by 579 [RFC4020]" in other cases. 581 IANA shall establish a process for accepting such templates, 582 selecting an Expert from those appointed to review such template 583 form applications, and archive and make available all approved 584 RRTYPE allocation templates. It is the duty of the selected Expert 585 to post the formal application template to the TBD2@TBD mailing 586 list. See Section 3.1 and Annex A for more details. 588 < Note to IANA/IESG/RFC Editor: An email address for the formal 589 submission of RR Type allocation templates and a email address 590 for the discussion of RR Type allocations will be decided and 591 the mailing lists created. All occurrences of TBD1@TBD in this 592 document will be replaced by the formal submission email 593 address. All occurrences of TBD2@TBD in this document will be 594 replaced by the discussion email address. This note is to be 595 deleted before publication. > 597 2. For Opcodes (see Section 2.2), it changes "IETF Standards Action" 598 allocation requirements to add "as modified by [RFC4020]". 600 3. It changes the allocation status of RCODE 0xFFFF to be IETF 601 Standards Action required. See Section 2.3. 603 4. It adds an IANA allocation policy for the AFSDB RR Subtype field 604 which requires the creation of a new registry. See Section 3.1.4. 606 5. It splits Specification Required CLASSes into data CLASSes and 607 query or meta CLASSes. See Section 3.2. 609 Annex A: RRTYPE Allocation Template 611 DNS RRTYPE PARAMETER ALLOCATION TEMPLATE 613 When ready for formal consideration, this template is to be submitted 614 to IANA for processing by emailing the template to TBD1@TBD. 616 A. Submission Date: 618 B. Submission Type: 619 [ ] New RRTYPE 620 [ ] Modification to existing RRTYPE 622 C. Contact Information for submitter: 623 Name: 624 Email Address: 625 International telephone number: 626 Other contact handles: 627 (Note: This information will be publicly posted) 629 D. Motivation for the new RRTYPE application? 630 Please keep this part at a high level to inform the Expert and 631 reviewers about uses of the RRTYPE. Remember most reviewers 632 will be DNS experts that may have limited knowledge of your 633 application space. 635 E. Description of the proposed RR type. 636 This description can be provided in-line in the template, as an 637 attachment or with a publicly available URL: 639 F. What existing RRTYPE or RRTYPEs come closest to filling that 640 need and why are they unsatisfactory? 642 G. What mnemonic is requested for the new RRTYPE (optional)? 643 Note: this can be left blank and the mnemonic decided after the 644 template is accepted. 646 H. Does the requested RRTYPE make use of any existing IANA 647 Registry or require the creation of a new IANA Sub-registry and 648 in DNS Parameters? 649 If so, please indicate which registry is to be used or created. 650 If a new sub-registry is needed, specify the allocation policy 651 for it and initial contents. Also include what the modification 652 procedures will be. 654 I. Does the proposal require/expect any changes in DNS 655 servers/resolvers that prevent the new type from being 656 processed as an unknown RRTYPE (see [RFC3597])? 658 J. Comments: 660 Additional IPR Provisions 662 The IETF takes no position regarding the validity or scope of any 663 Intellectual Property Rights or other rights that might be claimed to 664 pertain to the implementation or use of the technology described in 665 this document or the extent to which any license under such rights 666 might or might not be available; nor does it represent that it has 667 made any independent effort to identify any such rights. Information 668 on the procedures with respect to rights in RFC documents can be 669 found in BCP 78 and BCP 79. 671 Copies of IPR disclosures made to the IETF Secretariat and any 672 assurances of licenses to be made available, or the result of an 673 attempt made to obtain a general license or permission for the use of 674 such proprietary rights by implementers or users of this 675 specification can be obtained from the IETF on-line IPR repository at 676 http://www.ietf.org/ipr. 678 The IETF invites any interested party to bring to its attention any 679 copyrights, patents or patent applications, or other proprietary 680 rights that may cover technology that may be required to implement 681 this standard. Please address the information to the IETF at ietf- 682 ipr@ietf.org. 684 Copyright 686 Copyright (C) The IETF Trust (2008). 688 This document is subject to the rights, licenses and restrictions 689 contained in BCP 78, and except as set forth therein, the authors 690 retain all their rights. 692 Normative References 694 [RFC1034] - Mockapetris, P., "Domain Names - Concepts and 695 Facilities", STD 13, RFC 1034, November 1987. 697 [RFC1035] - Mockapetris, P., "Domain Names - Implementation and 698 Specifications", STD 13, RFC 1035, November 1987. 700 [RFC1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone 701 Changes (DNS NOTIFY)", RFC 1996, August 1996. 703 [RFC2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, 704 "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 705 April 1997. 707 [RFC2181] - Elz, R. and R. Bush, "Clarifications to the DNS 708 Specification", RFC 2181, July 1997. 710 [RFC2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 711 2671, August 1999. 713 [RFC2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. 714 Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", 715 RFC 2845, May 2000. 717 [RFC2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY 718 RR)", September 2000. 720 [RFC3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 721 2002. 723 [RFC3597] - Gustafsson, A., "Handling of Unknown DNS Resource Record 724 (RR) Types", RFC 3597, September 2003. 726 [RFC4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of 727 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 729 [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 730 Rose, "DNS Security Introduction and Requirements", RFC 4033, March 731 2005. 733 [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 734 Rose, "Resource Records for the DNS Security Extensions", RFC 4034, 735 March 2005. 737 [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 738 Rose, "Protocol Modifications for the DNS Security Extensions", RFC 739 4035, March 2005. 741 [RFC4635] - D. Eastlake 3rd, "HMAC SHA (Hashed Message Authentication 742 Code, Secure Hash Algorithm) TSIG Algorithm Identifiers". 744 [RFC5226] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 745 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 747 [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", 748 X3.4, American National Standards Institute: New York, 1968. 750 Informative References 752 [Dyer1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical 753 Plan - Name Service, April 1987, 755 [Moon1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts 756 Institute of Technology Artificial Intelligence Laboratory, June 757 1981. 759 [RFC1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. 760 Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. 762 [RFC1591] - Postel, J., "Domain Name System Structure and 763 Delegation", RFC 1591, March 1994. 765 [RFC2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS 766 Names", RFC 2606, June 1999. 768 [RFC2673] - Crawford, M., "Binary Labels in the Domain Name System", 769 RFC 2673, August 1999. 771 [RFC2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, 772 "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, 773 September 2000. 775 [RFC2931] - Eastlake, E., "DNS Request and Transaction Signatures ( 776 SIG(0)s )", RFC 2931, September 2000. 778 [RFC3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 779 Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in 780 the Domain Name System (DNS)", RFC 3363, August 2002. 782 [RFC4343] - Eastlake, D., "Domain Name System (DNS) Case 783 Insensitivity Clarification", RFC 4343, December 2005. 785 Author's Address 787 Donald E. Eastlake 3rd 788 Eastlake Enterprises 789 155 Beaver Street 790 Milford, MA 01757 USA 792 Telephone: +1-508-634-2066 (h) 793 email: d3e3e3@gmail.com 795 Expiration and File Name 797 This draft expires January 2009. 799 Its file name is draft-ietf-dnsext-2929bis-07.txt. 801 Disclaimer 803 This document and the information contained herein are provided on an 804 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 805 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 806 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 807 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 808 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 809 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.