diff options
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt | 928 |
1 files changed, 0 insertions, 928 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt deleted file mode 100644 index fa41e76..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsext-2929bis-01.txt +++ /dev/null @@ -1,928 +0,0 @@ - -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] - |
