diff options
Diffstat (limited to 'doc/draft/draft-ietf-dnsext-2929bis-01.txt')
| -rw-r--r-- | doc/draft/draft-ietf-dnsext-2929bis-01.txt | 928 |
1 files changed, 928 insertions, 0 deletions
diff --git a/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/doc/draft/draft-ietf-dnsext-2929bis-01.txt new file mode 100644 index 0000000..fa41e76 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-2929bis-01.txt @@ -0,0 +1,928 @@ + +INTERNET-DRAFT Donald E. Eastlake 3rd +Obsoletes RFC 2929, Updates RFC 1183 Motorola Laboratories +Expires: February 2006 August 2005 + + + + Domain Name System (DNS) IANA Considerations + ------ ---- ------ ----- ---- -------------- + <draft-ietf-dnsext-2929bis-01.txt> + + + +Status of This Document + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Distribution of this draft is unlimited. It is intended to become + the new BCP 42 obsoleting RFC 2929. Comments should be sent to the + DNS Working Group mailing list <namedroppers@ops.ietf.org>. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + + +Abstract + + Internet Assigned Number Authority (IANA) parameter assignment + considerations are given for the allocation of Domain Name System + (DNS) classes, RR types, operation codes, error codes, RR header + bits, and AFSDB subtypes. + + + + + + + + +D. Eastlake 3rd [Page 1] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Table of Contents + + Status of This Document....................................1 + Abstract...................................................1 + + Table of Contents..........................................2 + + 1. Introduction............................................3 + 2. DNS Query/Response Headers..............................3 + 2.1 One Spare Bit?.........................................4 + 2.2 Opcode Assignment......................................4 + 2.3 RCODE Assignment.......................................5 + 3. DNS Resource Records....................................6 + 3.1 RR TYPE IANA Considerations............................7 + 3.1.1 DNS TYPE Allocation Policy...........................8 + 3.1.2 Special Note on the OPT RR...........................9 + 3.1.3 The AFSDB RR Subtype Field...........................9 + 3.2 RR CLASS IANA Considerations...........................9 + 3.3 RR NAME Considerations................................11 + 4. Security Considerations................................11 + + Appendix: Changes from RFC 2929...........................12 + + Copyright and Disclaimer..................................13 + Normative References......................................13 + Informative References....................................14 + + Authors Addresses.........................................16 + Expiration and File Name..................................16 + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 2] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +1. Introduction + + The Domain Name System (DNS) provides replicated distributed secure + hierarchical databases which hierarchically store "resource records" + (RRs) under domain names. DNS data is structured into CLASSes and + zones which can be independently maintained. See [RFC 1034, 1035, + 2136, 2181, 4033] familiarity with which is assumed. + + This document provides, either directly or by reference, general IANA + parameter assignment considerations applying across DNS query and + response headers and all RRs. There may be additional IANA + considerations that apply to only a particular RR type or + query/response opcode. See the specific RFC defining that RR type or + query/response opcode for such considerations if they have been + defined, except for AFSDB RR considerations [RFC 1183] which are + included herein. This RFC obsoletes [RFC 2929]. + + IANA currently maintains a web page of DNS parameters. See + <http://www.iana.org/numbers.htm>. + + "IETF Standards Action", "IETF Consensus", "Specification Required", + and "Private Use" are as defined in [RFC 2434]. + + + +2. DNS Query/Response Headers + + The header for DNS queries and responses contains field/bits in the + following diagram taken from [RFC 2136, 2929]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ID | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + |QR| Opcode |AA|TC|RD|RA| Z|AD|CD| RCODE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | QDCOUNT/ZOCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ANCOUNT/PRCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | NSCOUNT/UPCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | ARCOUNT | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + The ID field identifies the query and is echoed in the response so + they can be matched. + + The QR bit indicates whether the header is for a query or a response. + + +D. Eastlake 3rd [Page 3] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful + only in queries or only in responses, depending on the bit. However, + many DNS implementations copy the query header as the initial value + of the response header without clearing bits. Thus any attempt to + use a "query" bit with a different meaning in a response or to define + a query meaning for a "response" bit is dangerous given existing + implementation. Such meanings may only be assigned by an IETF + Standards Action. + + The unsigned fields query count (QDCOUNT), answer count (ANCOUNT), + authority count (NSCOUNT), and additional information count (ARCOUNT) + express the number of records in each section for all opcodes except + Update. These fields have the same structure and data type for + Update but are instead the counts for the zone (ZOCOUNT), + prerequisite (PRCOUNT), update (UPCOUNT), and additional information + (ARCOUNT) sections. + + + +2.1 One Spare Bit? + + There have been ancient DNS implementations for which the Z bit being + on in a query meant that only a response from the primary server for + a zone is acceptable. It is believed that current DNS + implementations ignore this bit. + + Assigning a meaning to the Z bit requires an IETF Standards Action. + + + +2.2 Opcode Assignment + + Currently DNS OpCodes are assigned as follows: + + OpCode Name Reference + + 0 Query [RFC 1035] + 1 IQuery (Inverse Query, Obsolete) [RFC 3425] + 2 Status [RFC 1035] + 3 available for assignment + 4 Notify [RFC 1996] + 5 Update [RFC 2136] + 6-15 available for assignment + + New OpCode assignments require an IETF Standards Action as modified + by [RFC 4020]. + + + + + + +D. Eastlake 3rd [Page 4] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +2.3 RCODE Assignment + + It would appear from the DNS header above that only four bits of + RCODE, or response/error code are available. However, RCODEs can + appear not only at the top level of a DNS response but also inside + OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930]. + The OPT RR provides an eight bit extension resulting in a 12 bit + RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field. + + Error codes appearing in the DNS header and in these three RR types + all refer to the same error code space with the single exception of + error code 16 which has a different meaning in the OPT RR from its + meaning in other contexts. See table below. + + RCODE Name Description Reference + Decimal + Hexadecimal + 0 NoError No Error [RFC 1035] + 1 FormErr Format Error [RFC 1035] + 2 ServFail Server Failure [RFC 1035] + 3 NXDomain Non-Existent Domain [RFC 1035] + 4 NotImp Not Implemented [RFC 1035] + 5 Refused Query Refused [RFC 1035] + 6 YXDomain Name Exists when it should not [RFC 2136] + 7 YXRRSet RR Set Exists when it should not [RFC 2136] + 8 NXRRSet RR Set that should exist does not [RFC 2136] + 9 NotAuth Server Not Authoritative for zone [RFC 2136] + 10 NotZone Name not contained in zone [RFC 2136] + 11 - 15 Available for assignment + 16 BADVERS Bad OPT Version [RFC 2671] + 16 BADSIG TSIG Signature Failure [RFC 2845] + 17 BADKEY Key not recognized [RFC 2845] + 18 BADTIME Signature out of time window [RFC 2845] + 19 BADMODE Bad TKEY Mode [RPC 2930] + 20 BADNAME Duplicate key name [RPF 2930] + 21 BADALG Algorithm not supported [RPF 2930] + + 22 - 3,840 + 0x0016 - 0x0F00 Available for assignment + + 3,841 - 4,095 + 0x0F01 - 0x0FFF Private Use + + 4,096 - 65,534 + 0x1000 - 0xFFFE Available for assignment + + 65,535 + 0xFFFF Reserved, can only be allocated by an IETF + Standards Action. + + + +D. Eastlake 3rd [Page 5] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + Since it is important that RCODEs be understood for interoperability, + assignment of new RCODE listed above as "available for assignment" + requires an IETF Consensus. + + + +3. DNS Resource Records + + All RRs have the same top level format shown in the figure below + taken from [RFC 1035]: + + 1 1 1 1 1 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | | + / / + / NAME / + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TYPE | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | CLASS | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | TTL | + | | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + | RDLENGTH | + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| + / RDATA / + / / + +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ + + NAME is an owner name, i.e., the name of the node to which this + resource record pertains. NAMEs are specific to a CLASS as described + in section 3.2. NAMEs consist of an ordered sequence of one or more + labels each of which has a label type [RFC 1035, 2671]. + + TYPE is a two octet unsigned integer containing one of the RR TYPE + codes. See section 3.1. + + CLASS is a two octet unsigned integer containing one of the RR CLASS + codes. See section 3.2. + + TTL is a four octet (32 bit) bit unsigned integer that specifies the + number of seconds that the resource record may be cached before the + source of the information should again be consulted. Zero is + interpreted to mean that the RR can only be used for the transaction + in progress. + + RDLENGTH is an unsigned 16 bit integer that specifies the length in + + +D. Eastlake 3rd [Page 6] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + octets of the RDATA field. + + RDATA is a variable length string of octets that constitutes the + resource. The format of this information varies according to the TYPE + and in some cases the CLASS of the resource record. + + + +3.1 RR TYPE IANA Considerations + + There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs, + and MetaTYPEs. + + Data TYPEs are the primary means of storing data. QTYPES can only be + used in queries. Meta-TYPEs designate transient data associated with + an particular DNS message and in some cases can also be used in + queries. Thus far, data TYPEs have been assigned from 1 upwards plus + the block from 100 through 103 while Q and Meta Types have been + assigned from 255 downwards except for the OPT Meta-RR which is + assigned TYPE 41. There have been DNS implementations which made + caching decisions based on the top bit of the bottom byte of the RR + TYPE. + + There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG + [RFC 2845], and TKEY [RFC 2930]. + + There are currently five QTYPEs assigned: * (all), MAILA, MAILB, + AXFR, and IXFR. + + Considerations for the allocation of new RR TYPEs are as follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC + 2535] and in other circumstances and must never be allocated + for ordinary use. + + 1 - 127 + 0x0001 - 0x007F - remaining TYPEs in this range are assigned for data + TYPEs by the DNS TYPE Allocation Policy as specified in + section 3.1.1. + + 128 - 255 + 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and + Meta TYPEs by the DNS TYPE Allocation Policy as specified in + section 3.1.1. + + + + +D. Eastlake 3rd [Page 7] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + 256 - 32,767 + 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by the DNS + TYPE Allocation Policy as specified in section 3.1.1. + + 32,768 - 65,279 + 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. + + 65,280 - 65534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. + + + +3.1.1 DNS TYPE Allocation Policy + + Parameter values specified above as assigned based on DNS TYPE + Allocation Policy. That is, Expert Review with the additional + requirement that the review be based on a complete template as + specified below which has been posted for three weeks to the + namedroppers@ops.ietf.org mailing list. + + Partial or draft templates may be posted with the intend of + soliciting feedback. + + + DNS RR TYPE PARAMETER ALLOCATION TEMPLATE + + Date: + + Name and email of originator: + + Pointer to internet-draft or other document giving a detailed + description of the protocol use of the new RR Type: + + What need is the new RR TYPE intended to fix? + + What existing RR TYPE(s) come closest to filling that need and why are + they unsatisfactory? + + Does the proposed RR TYPR require special handling within the DNS + different from an Unknown RR TYPE? + + Comments: + + + + + + + +D. Eastlake 3rd [Page 8] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +3.1.2 Special Note on the OPT RR + + The OPT (OPTion) RR, number 41, is specified in [RFC 2671]. Its + primary purpose is to extend the effective field size of various DNS + fields including RCODE, label type, OpCode, flag bits, and RDATA + size. In particular, for resolvers and servers that recognize it, it + extends the RCODE field from 4 to 12 bits. + + + +3.1.3 The AFSDB RR Subtype Field + + The AFSDB RR [RFC 1183] is a CLASS insensitive RR that has the same + RDATA field structure as the MX RR but the 16 bit unsigned integer + field at the beginning of the RDATA is interpreted as a subtype as + follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - Allocation requires IETF Standards Action. + + 1 + 0x0001 - Andrews File Service v3.0 Location Service [RFC 1183]. + + 2 + 0x0002 - DCE/NCA root cell directory node [RFC 1183]. + + 3 - 65,279 + 0x0003 - 0xFEFF - Allocation by IETF Consensus. + + 65,280 - 65,534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, allocation requires IETF Standards Action. + + + +3.2 RR CLASS IANA Considerations + + DNS CLASSes have been little used but constitute another dimension of + the DNS distributed database. In particular, there is no necessary + relationship between the name space or root servers for one CLASS and + those for another CLASS. The same name can have completely different + meanings in different CLASSes; however, the label types are the same + and the null label is usable only as root in every CLASS. However, + as global networking and DNS have evolved, the IN, or Internet, CLASS + has dominated DNS use. + + +D. Eastlake 3rd [Page 9] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + There are two subcategories of DNS CLASSes: normal data containing + classes and QCLASSes that are only meaningful in queries or updates. + + The current CLASS assignments and considerations for future + assignments are as follows: + + Decimal + Hexadecimal + + 0 + 0x0000 - Reserved, assignment requires an IETF Standards Action. + + 1 + 0x0001 - Internet (IN). + + 2 + 0x0002 - Available for assignment by IETF Consensus as a data CLASS. + + 3 + 0x0003 - Chaos (CH) [Moon 1981]. + + 4 + 0x0004 - Hesiod (HS) [Dyer 1987]. + + 5 - 127 + 0x0005 - 0x007F - available for assignment by IETF Consensus for data + CLASSes only. + + 128 - 253 + 0x0080 - 0x00FD - available for assignment by IETF Consensus for + QCLASSes only. + + 254 + 0x00FE - QCLASS None [RFC 2136]. + + 255 + 0x00FF - QCLASS Any [RFC 1035]. + + 256 - 32,767 + 0x0100 - 0x7FFF - Assigned by IETF Consensus. + + 32,768 - 65,279 + 0x8000 - 0xFEFF - Assigned based on Specification Required as defined + in [RFC 2434]. + + 65,280 - 65,534 + 0xFF00 - 0xFFFE - Private Use. + + 65,535 + 0xFFFF - Reserved, can only be assigned by an IETF Standards Action. + + +D. Eastlake 3rd [Page 10] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +3.3 RR NAME Considerations + + DNS NAMEs are sequences of labels [RFC 1035]. The last label in each + NAME is "ROOT" which is the zero length label. By definition, the + null or ROOT label can not be used for any other NAME purpose. + + At the present time, there are two categories of label types, data + labels and compression labels. Compression labels are pointers to + data labels elsewhere within an RR or DNS message and are intended to + shorten the wire encoding of NAMEs. The two existing data label + types are sometimes referred to as Text and Binary. Text labels can, + in fact, include any octet value including zero value octets but most + current uses involve only [US-ASCII]. For retrieval, Text labels are + defined to treat ASCII upper and lower case letter codes as matching + [insensitive]. Binary labels are bit sequences [RFC 2673]. The + Binary label type is Experimental [RFC 3363]. + + IANA considerations for label types are given in [RFC 2671]. + + NAMEs are local to a CLASS. The Hesiod [Dyer 1987] and Chaos [Moon + 1981] CLASSes are essentially for local use. The IN or Internet + CLASS is thus the only DNS CLASS in global use on the Internet at + this time. + + A somewhat out-of-date description of name allocation in the IN Class + is given in [RFC 1591]. Some information on reserved top level + domain names is in BCP 32 [RFC 2606]. + + + +4. Security Considerations + + This document addresses IANA considerations in the allocation of + general DNS parameters, not security. See [RFC 4033, 4034, 4035] for + secure DNS considerations. + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 11] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Appendix: Changes from RFC 2929 + + RFC Editor: This Appendix should be deleted for publication. + + Changes from RFC 2929 to this draft: + + 1. Changed many "IETF Consensus" for RR TYPEs to be "DNS TYPE + Allocation Policy" and add the specification of that policy. Change + some remaining "IETF Standards Action" allocation requirements to say + "as modified by [RFC 4020]". + + 2. Updated various RFC references. + + 3. Mentioned that the Binary label type is now Experimental and + IQuery is Obsolete. + + 4. Changed allocation status of RR Type 0xFFFF and RCODE 0xFFFF to be + IETF Standards Action required. + + 5. Add an IANA allocation policy for the AFSDB RR Subtype field. + + 6. Addition of reference to case insensitive draft. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 12] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Copyright and Disclaimer + + Copyright (C) The Internet Society (2005). This document is subject to + the rights, licenses and restrictions contained in BCP 78, and except + as set forth therein, the authors retain all their rights. + + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + +Normative References + + [RFC 1034] - Mockapetris, P., "Domain Names - Concepts and + Facilities", STD 13, RFC 1034, November 1987. + + [RFC 1035] - Mockapetris, P., "Domain Names - Implementation and + Specifications", STD 13, RFC 1035, November 1987. + + [RFC 1183] - Everhart, C., Mamakos, L., Ullmann, R., and P. + Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990. + + [RFC 1996] - Vixie, P., "A Mechanism for Prompt Notification of Zone + Changes (DNS NOTIFY)", RFC 1996, August 1996. + + [RFC 2136] - Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, + "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [RFC 2181] - Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + [RFC 2434] - Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. + + [RFC 2671] - Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC 2673] - Crawford, M., "Binary Labels in the Domain Name System", + RFC 2673, August 1999. + + [RFC 2845] - Vixie, P., Gudmundsson, O., Eastlake, D. and B. + Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", + RFC 2845, May 2000. + + +D. Eastlake 3rd [Page 13] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + [RFC 2930] - Eastlake, D., "Secret Key Establishment for DNS (TKEY + RR)", September 2000. + + [RFC 3363] - Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. + Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in + the Domain Name System (DNS)", RFC 3363, August 2002. + + [RFC 3425] - Lawrence, D., "Obsoleting IQUERY", RFC 3425, November + 2002. + + [RFC 4020] - Kompella, K. and A. Zinin, "Early IANA Allocation of + Standards Track Code Points", BCP 100, RFC 4020, February 2005. + + [RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC 4033, March + 2005. + + [RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for the DNS Security Extensions", RFC 4034, + March 2005. + + [RFC 4044] - Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security Extensions", RFC + 4035, March 2005. + + [US-ASCII] - ANSI, "USA Standard Code for Information Interchange", + X3.4, American National Standards Institute: New York, 1968. + + + +Informative References + + [Dyer 1987] - Dyer, S., and F. Hsu, "Hesiod", Project Athena + Technical Plan - Name Service, April 1987, + + [Moon 1981] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts + Institute of Technology Artificial Intelligence Laboratory, June + 1981. + + [RFC 1591] - Postel, J., "Domain Name System Structure and + Delegation", RFC 1591, March 1994. + + [RFC 2929] - Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, + "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, + September 2000. + + [RFC 2606] - Eastlake, D. and A. Panitz, "Reserved Top Level DNS + Names", RFC 2606, June 1999. + + [insensitive] - Eastlake, D., "Domain Name System (DNS) Case + + +D. Eastlake 3rd [Page 14] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + + Insensitivity Clarification", draft-ietf-dnsext-insensitive-*.txt, + work in progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 15] + + +INTERNET-DRAFT DNS IANA Considerations August 2005 + + +Authors Addresses + + Donald E. Eastlake 3rd + Motorola Laboratories + 155 Beaver Street + Milford, MA 01757 USA + + Telephone: +1-508-786-7554 (w) + email: Donald.Eastlake@motorola.com + + + +Expiration and File Name + + This draft expires February 2006. + + Its file name is draft-ietf-dnsext-2929bis-01.txt. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +D. Eastlake 3rd [Page 16] + |