idnits 2.17.1 draft-eastlake-dnsext-2929bis-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 511. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 2005) is 6883 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1035' on line 80 -- Looks like a reference, but probably isn't: '2136' on line 80 -- Looks like a reference, but probably isn't: '2181' on line 80 -- Looks like a reference, but probably isn't: '4033' on line 80 -- Looks like a reference, but probably isn't: '2929' on line 123 == Missing Reference: 'RPC 2930' is mentioned on line 222, but not defined == Missing Reference: 'RPF 2930' is mentioned on line 224, but not defined -- Looks like a reference, but probably isn't: '2671' on line 269 -- Looks like a reference, but probably isn't: '4034' on line 469 -- Looks like a reference, but probably isn't: '4035' on line 469 == Unused Reference: 'RFC 2181' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC 4034' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'RFC 4044' is defined on line 568, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1183 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2673 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Downref: Normative reference to an Informational RFC: RFC 3363 ** Obsolete normative reference: RFC 4020 (Obsoleted by RFC 7120) -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' -- Obsolete informational reference (is this intentional?): RFC 2929 (Obsoleted by RFC 5395) Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 14 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, Updates RFC 1183 Motorola Laboratories 3 Expires: December 2005 June 2005 5 Domain Name System (DNS) IANA Considerations 6 ------ ---- ------ ----- ---- -------------- 7 9 Status of This Document 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Distribution of this draft, which is intended to become a Best 17 Current Practice, is unlimited. Comments should be sent to the DNS 18 Working Group mailing list or to the 19 author. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than a "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 Internet Assigned Number Authority (IANA) parameter assignment 40 considerations are given for the allocation of Domain Name System 41 (DNS) classes, RR types, operation codes, error codes, RR header 42 bits, and AFSDB subtypes. 44 Table of Contents 46 Status of This Document....................................1 47 Abstract...................................................1 49 Table of Contents..........................................2 51 1. Introduction............................................3 52 1.1 The DNS Special Allocation Policy......................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 57 3. DNS Resource Records....................................6 58 3.1 RR TYPE IANA Considerations............................8 59 3.1.1 Special Note on the OPT RR...........................9 60 3.1.2 The AFSDB RR Subtype Field...........................9 61 3.2 RR CLASS IANA Considerations...........................9 62 3.3 RR NAME Considerations................................11 63 4. Security Considerations................................11 64 Appendix: Changes from RFC 2929...........................11 66 Copyright and Disclaimer..................................13 67 Normative References......................................13 68 Informative References....................................14 70 Authors Addresses.........................................16 71 Expiration and File Name..................................16 73 1. Introduction 75 The Domain Name System (DNS) provides replicated distributed secure 76 hierarchical databases which hierarchically store "resource records" 77 (RRs) under domain names. 79 This data is structured into CLASSes and zones which can be 80 independently maintained. See [RFC 1034, 1035, 2136, 2181, 4033] 81 familiarity with which is assumed. 83 This document provides, either directly or by reference, general IANA 84 parameter assignment considerations applying across DNS query and 85 response headers and all RRs. There may be additional IANA 86 considerations that apply to only a particular RR type or 87 query/response opcode. See the specific RFC defining that RR type or 88 query/response opcode for such considerations if they have been 89 defined except for AFSDB considerations [RFC 1183] which are included 90 herein. This RFC replaces [RFC 2929]. 92 IANA currently maintains a web page of DNS parameters. See 93 . 95 "IETF Standards Action", "IETF Consensus", "Specification Required", 96 and "Private Use" are as defined in [RFC 2434]. 98 1.1 The DNS Special Allocation Policy 100 Many DNS parameters are allocated by IANA based on the DNS special 101 policy. This policy authorizes IANA allocation base on meeting any of 102 the following three criteria: 104 1. An IETF Standards Action. 106 2. Approval as an Experimental Protocol. 108 3. As provided in [RFC 4020] for Early Allocation except that all the 109 criteria in Section 2 of [RFC 4020] are replaced by the following: 111 3.a: The format, semantics, processing, and other rules related to 112 handling the protocol entities defined by the code points (the 113 "specifications") are adequately described in an Internet draft 114 that is intended to become Standards Track or Experimental. 116 3.b: There is sufficient interest in early (pre-RFC) implementation 117 and deployment in the community as determined by working group 118 consensus. 120 2. DNS Query/Response Headers 122 The header for DNS queries and responses contains field/bits in the 123 following diagram taken from [RFC 2136, 2929]: 125 1 1 1 1 1 1 126 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 127 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 128 | ID | 129 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 130 |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | 131 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 132 | QDCOUNT/ZOCOUNT | 133 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 134 | ANCOUNT/PRCOUNT | 135 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 136 | NSCOUNT/UPCOUNT | 137 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 138 | ARCOUNT | 139 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 141 The ID field identifies the query and is echoed in the response so 142 they can be matched. 144 The QR bit indicates whether the header is for a query or a response. 146 The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful 147 only in queries or only in responses, depending on the bit. However, 148 many DNS implementations copy the query header as the initial value 149 of the response header without clearing bits. Thus any attempt to 150 use a "query" bit with a different meaning in a response or to define 151 a query meaning for a "response" bit is dangerous given existing 152 implementation. Such meanings may only be assigned by an IETF 153 Standards Action. 155 The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), 156 authority count (NSCOUNT), and additional information count (ARCOUNT) 157 express the number of records in each section for all opcodes except 158 Update. These fields have the same structure and data type for 159 Update but are instead the counts for the zone (ZOCOUNT), 160 prerequisite (PRCOUNT), update (UPCOUNT), and additional information 161 (ARCOUNT) sections. 163 2.1 One Spare Bit? 165 There have been ancient DNS implementations for which the Z bit being 166 on in a query meant that only a response from the primary server for 167 a zone is acceptable. It is believed that current DNS 168 implementations ignore this bit. 170 Assigning a meaning to the Z bit requires an IETF Standards Action. 172 2.2 Opcode Assignment 174 Currently DNS OpCodes are assigned as follows: 176 OpCode Name Reference 178 0 Query [RFC 1035] 179 1 IQuery (Inverse Query, Obsolete) [RFC 3425] 180 2 Status [RFC 1035] 181 3 available for assignment 182 4 Notify [RFC 1996] 183 5 Update [RFC 2136] 184 6-15 available for assignment 186 New OpCode assignments require an IETF Standards Action modified by 187 [RFC 4020]. 189 2.3 RCODE Assignment 191 It would appear from the DNS header above that only four bits of 192 RCODE, or response/error code are available. However, RCODEs can 193 appear not only at the top level of a DNS response but also inside 194 OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. 195 The OPT RR provides an eight bit extension resulting in a 12 bit 196 RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field. 198 Error codes appearing in the DNS header and in these three RR types 199 all refer to the same error code space with the single exception of 200 error code 16 which has a different meaning in the OPT RR from its 201 meaning in other contexts. See table below. 203 RCODE Name Description Reference 204 Decimal 205 Hexadecimal 206 0 NoError No Error [RFC 1035] 207 1 FormErr Format Error [RFC 1035] 208 2 ServFail Server Failure [RFC 1035] 209 3 NXDomain Non-Existent Domain [RFC 1035] 210 4 NotImp Not Implemented [RFC 1035] 211 5 Refused Query Refused [RFC 1035] 212 6 YXDomain Name Exists when it should not [RFC 2136] 213 7 YXRRSet RR Set Exists when it should not [RFC 2136] 214 8 NXRRSet RR Set that should exist does not [RFC 2136] 215 9 NotAuth Server Not Authoritative for zone [RFC 2136] 216 10 NotZone Name not contained in zone [RFC 2136] 217 11 - 15 Available for assignment 218 16 BADVERS Bad OPT Version [RFC 2671] 219 16 BADSIG TSIG Signature Failure [RFC 2845] 220 17 BADKEY Key not recognized [RFC 2845] 221 18 BADTIME Signature out of time window [RFC 2845] 222 19 BADMODE Bad TKEY Mode [RPC 2930] 223 20 BADNAME Duplicate key name [RPF 2930] 224 21 BADALG Algorithm not supported [RPF 2930] 225 22 - 3,840 Available for assignment 226 0x0016 - 0x0F00 227 3,841 - 4,095 Private Use 228 0x0F01 - 0x0FFF 229 4,096 - 5,7343 Available for assignment 230 0x1000 - 0xDFFF 231 57,344 - 65,534 Specification Required 232 0xE000 - 0xFFFE 233 65,535 Reserved 234 0xFFFF 236 Assignment of new RCODE listed above as "Available for assignment" 237 requires an IETF Standards Action modified by [RFC 4020]. Assignment 238 of RCODE 65,535 requires an IETF Standards Action. 240 3. DNS Resource Records 242 All RRs have the same top level format shown in the figure below 243 taken from [RFC 1035]: 245 1 1 1 1 1 1 246 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 247 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 248 | | 249 / / 250 / NAME / 251 | | 252 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 253 | TYPE | 254 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 255 | CLASS | 256 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 257 | TTL | 258 | | 259 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 260 | RDLENGTH | 261 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| 262 / RDATA / 263 / / 264 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 266 NAME is an owner name, i.e., the name of the node to which this 267 resource record pertains. NAMEs are specific to a CLASS as described 268 in section 3.2. NAMEs consist of an ordered sequence of one or more 269 labels each of which has a label type [RFC 1035, 2671]. 271 TYPE is a two octet unsigned integer containing one of the RR TYPE 272 codes. See section 3.1. 274 CLASS is a two octet unsigned integer containing one of the RR CLASS 275 codes. See section 3.2. 277 TTL is a four octet (32 bit) bit unsigned integer that specifies the 278 number of seconds that the resource record may be cached before the 279 source of the information should again be consulted. Zero is 280 interpreted to mean that the RR can only be used for the transaction 281 in progress. 283 RDLENGTH is an unsigned 16 bit integer that specifies the length in 284 octets of the RDATA field. 286 RDATA is a variable length string of octets that constitutes the 287 resource. The format of this information varies according to the 288 TYPE and in some cases the CLASS of the resource record. 290 3.1 RR TYPE IANA Considerations 292 There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, 293 and MetaTYPEs. 295 Data TYPEs are the primary means of storing data. QTYPES can only be 296 used in queries. Meta-TYPEs designate transient data associated with 297 an particular DNS message and in some cases can also be used in 298 queries. Thus far, data TYPEs have been assigned from 1 upwards plus 299 the block from 100 through 103 while Q and Meta Types have been 300 assigned from 255 downwards (except for the OPT Meta-RR which is 301 assigned TYPE 41). There have been DNS implementations which made 302 caching decisions based on the top bit of the bottom byte of the RR 303 TYPE. 305 There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG 306 [RFC 2845], and TKEY [RFC 2930]. 308 There are currently five QTYPEs assigned: * (all), MAILA, MAILB, 309 AXFR, and IXFR. 311 Considerations for the allocation of new RR TYPEs are as follows: 313 Decimal 314 Hexadecimal 316 0 317 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC 318 2535] and in other circumstances and must never be allocated 319 for ordinary use. 321 1 - 127 322 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data 323 TYPEs by the DNS Special Allocation Policy. 325 128 - 255 326 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and 327 Meta TYPEs by the DNS Special Allocation Policy. 329 256 - 32,767 330 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS 331 Special Allocation Policy. 333 32,768 - 65,279 334 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. 336 65280 - 65534 337 0xFF00 - 0xFFFE - Private Use. 339 65,535 340 0xFFFF - can only be assigned by an IETF Standards Action. 342 3.1.1 Special Note on the OPT RR 344 The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its 345 primary purpose is to extend the effective field size of various DNS 346 fields including RCODE, label type, OpCode, flag bits, and RDATA 347 size. In particular, for resolvers and servers that recognize it, it 348 extends the RCODE field from 4 to 12 bits. 350 3.1.2 The AFSDB RR Subtype Field 352 The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same 353 RDATA field structure as the MX RR but the 16 bit unsigned integer 354 field at the beginning of the RDATA is interpreted as a subtype as 355 follows: 357 Decimal 358 Hexadecimal 360 0 361 0x0000 - Allocation requires IETF Standards Action. 363 1 364 0x0001 - Andrews File Service v3.0 Location Service [RFC 1183]. 366 2 367 0x0002 - DCE/NCA root cell directory node [RFC 1183]. 369 3 - 65,534 370 0x0003 - 0xFFFE - Allocation by the DNS Special Allocation Policy. 372 65,535 373 0xFFFF - Allocation requires IETF Standards Action. 375 3.2 RR CLASS IANA Considerations 377 DNS CLASSes have been little used but constitute another dimension of 378 the DNS distributed database. In particular, there is no necessary 379 relationship between the name space or root servers for one CLASS and 380 those for another CLASS. The same name can have completely different 381 meanings in different CLASSes although the label types are the same 382 and the null label is usable only as root in every CLASS. However, 383 as global networking and DNS have evolved, the IN, or Internet, CLASS 384 has dominated DNS use. 386 There are two subcategories of DNS CLASSes: normal data containing 387 classes and QCLASSes that are only meaningful in queries or updates. 389 The current CLASS assignments and considerations for future 390 assignments are as follows: 392 Decimal 393 Hexadecimal 395 0 396 0x0000 - assignment requires an IETF Standards Action. 398 1 399 0x0001 - Internet (IN). 401 2 402 0x0002 - available for assignment by the DNS Special Allocation 403 Policy as a data CLASS. 405 3 406 0x0003 - Chaos (CH) [Moon 1981]. 408 4 409 0x0004 - Hesiod (HS) [Dyer 1987]. 411 5 - 127 412 0x0005 - 0x007F - available for assignment by the DNS Special 413 Allocation Policy for data CLASSes only. 415 128 - 253 416 0x0080 - 0x00FD - available for assignment by the DNS Special 417 Allocation Policy for QCLASSes only. 419 254 420 0x00FE - QCLASS None [RFC 2136]. 422 255 423 0x00FF - QCLASS Any [RFC 1035]. 425 256 - 32767 426 0x0100 - 0x7FFF - assigned by the DNS Special Allocation Policy. 428 32768 - 65280 429 0x8000 - 0xFEFF - assigned based on Specification Required as defined 430 in [RFC 2434]. 432 65280 - 65534 433 0xFF00 - 0xFFFE - Private Use. 435 65535 436 0xFFFF - can only be assigned by an IETF Standards Action. 438 3.3 RR NAME Considerations 440 DNS NAMEs are sequences of labels [RFC 1035]. The last label in each 441 NAME is "ROOT" which is the zero length label. By definition, the 442 null or ROOT label can not be used for any other NAME purpose. 444 At the present time, there are two categories of label types, data 445 labels and compression labels. Compression labels are pointers to 446 data labels elsewhere within an RR or DNS message and are intended to 447 shorten the wire encoding of NAMEs. The two existing data label 448 types are sometimes referred to as Text and Binary. Text labels can, 449 in fact, include any octet value including zero value octets but most 450 current uses involve only [US-ASCII]. For retrieval, Text labels are 451 defined to treat ASCII upper and lower case letter codes as matching 452 [insensitive]. Binary labels are bit sequences [RFC 2673]. The 453 Binary label type is Experimental [RFC 3363]. 455 IANA considerations for label types are given in [RFC 2671]. 457 NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon 458 1981] CLASSes are essentially for local use. The IN or Internet 459 CLASS is thus the only DNS CLASS in global use on the Internet at 460 this time. 462 A somewhat out-of-date description of name allocation in the IN Class 463 is given in [RFC 1591]. Some information on reserved top level 464 domain names is in Best Current Practice 32 [RFC 2606]. 466 4. Security Considerations 468 This document addresses IANA considerations in the allocation of 469 general DNS parameters, not security. See [RFC 4033, 4034, 4035] for 470 secure DNS considerations. 472 Appendix: Changes from RFC 2929 474 RFC Editor: This section should be deleted for publication. 476 Changes from RFC 2929 to this draft: 478 1. Changed many "IETF Consensus" and some "IETF Standards Action" 479 allocation requirements changed to be "DNS Special Allocation Policy" 480 and add the specification of that policy. Change most remaining "IETF 481 Standards Action" allocation requirements to say "as modified by [RFC 482 4020]". 484 2. Updated various RFC references. 486 3. Mentioned that the Binary label type is now Experimental and 487 IQuery is Obsolete.. 489 4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be 490 IETF Standards Action required. 492 5. Change allocation status of the upper one eighth of the current 493 RCODE space (except 0xFFFF) to be Specification Required. 495 6. Add allocation policy for the AFSDB RR Subtype field. 497 7. Addition of reference to case insensitive draft. 499 Copyright and Disclaimer 501 Copyright (C) The Internet Society (2005). This document is subject to 502 the rights, licenses and restrictions contained in BCP 78, and except 503 as set forth therein, the authors retain all their rights. 505 This document and the information contained herein are provided on an 506 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 507 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 508 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 509 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 510 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 511 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 513 Normative References 515 [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and 516 Facilities", STD 13, RFC 1034, November 1987. 518 [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and 519 Specifications", STD 13, RFC 1035, November 1987. 521 [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. 522 Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. 524 [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone 525 Changes (DNS NOTIFY)", RFC 1996, August 1996. 527 [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, 528 "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, 529 April 1997. 531 [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS 532 Specification", RFC 2181, July 1997. 534 [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an 535 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 537 [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 538 2671, August 1999. 540 [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System", 541 RFC 2673, August 1999. 543 [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. 544 Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", 545 RFC 2845, May 2000. 547 [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY 548 RR)", September 2000. 550 [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 551 Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in 552 the Domain Name System (DNS)", RFC 3363, August 2002. 554 [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November 555 2002. 557 [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of 558 Standards Track Code Points", BCP 100, RFC 4020, February 2005. 560 [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 561 Rose, "DNS Security Introduction and Requirements", RFC 4033, March 562 2005. 564 [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 565 Rose, "Resource Records for the DNS Security Extensions", RFC 4034, 566 March 2005. 568 [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 569 Rose, "Protocol Modifications for the DNS Security Extensions", RFC 570 4035, March 2005. 572 [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", 573 X3.4, American National Standards Institute: New York, 1968. 575 Informative References 577 [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena 578 Technical Plan - Name Service, April 1987, 580 [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts 581 Institute of Technology Artificial Intelligence Laboratory, June 582 1981. 584 [RFC 1591] - Postel, J., "Domain Name System Structure and 585 Delegation", RFC 1591, March 1994. 587 [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, 588 "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, 589 September 2000. 591 [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS 592 Names", RFC 2606, June 1999. 594 [insensitive] - Eastlake, D., "Domain Name System (DNS) Case 595 Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt, 596 work in progress. 598 Authors Addresses 600 Donald E. Eastlake 3rd 601 Motorola Laboratories 602 155 Beaver Street 603 Milford, MA 01757 USA 605 Telephone: +1-508-786-7554 (w) 606 email: Donald.Eastlake@motorola.com 608 Expiration and File Name 610 This draft expires December 2005. 612 Its file name is draft-eastlake-dnsext-2929bis-01.txt.