diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2929.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2929.txt | 675 |
1 files changed, 0 insertions, 675 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2929.txt b/contrib/bind9/doc/rfc/rfc2929.txt deleted file mode 100644 index f055968..0000000 --- a/contrib/bind9/doc/rfc/rfc2929.txt +++ /dev/null @@ -1,675 +0,0 @@ - - - - - - -Network Working Group D. Eastlake, 3rd -Request for Comments: 2929 Motorola -BCP: 42 E. Brunner-Williams -Category: Best Current Practice Engage - B. Manning - ISI - September 2000 - - Domain Name System (DNS) IANA Considerations - -Status of this Memo - - This document specifies an Internet Best Current Practices for the - Internet Community, and requests discussion and suggestions for - improvements. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (2000). All Rights Reserved. - -Abstract - - Internet Assigned Number Authority (IANA) parameter assignment - considerations are given for the allocation of Domain Name System - (DNS) classes, Resource Record (RR) types, operation codes, error - codes, etc. - -Table of Contents - - 1. Introduction................................................. 2 - 2. DNS Query/Response Headers................................... 2 - 2.1 One Spare Bit?.............................................. 3 - 2.2 Opcode Assignment........................................... 3 - 2.3 RCODE Assignment............................................ 4 - 3. DNS Resource Records......................................... 5 - 3.1 RR TYPE IANA Considerations................................. 6 - 3.1.1 Special Note on the OPT RR................................ 7 - 3.2 RR CLASS IANA Considerations................................ 7 - 3.3 RR NAME Considerations...................................... 8 - 4. Security Considerations...................................... 9 - References...................................................... 9 - Authors' Addresses.............................................. 11 - Full Copyright Statement........................................ 12 - - - - - - - - -Eastlake, et al. Best Current Practice [Page 1] - -RFC 2929 DNS IANA Considerations September 2000 - - -1. Introduction - - The Domain Name System (DNS) provides replicated distributed secure - hierarchical databases which hierarchically store "resource records" - (RRs) under domain names. - - This data is structured into CLASSes and zones which can be - independently maintained. See [RFC 1034, 1035, 2136, 2181, 2535] - familiarity with which is assumed. - - This document covers, 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. - - 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, 2535]: - - 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. - - - - -Eastlake, et al. Best Current Practice [Page 2] - -RFC 2929 DNS IANA Considerations September 2000 - - - The QR bit indicates whether the header is for a query or a response. - - 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 - - New OpCode assignments require an IETF Standards Action. - - Currently DNS OpCodes are assigned as follows: - - OpCode Name Reference - - 0 Query [RFC 1035] - 1 IQuery (Inverse Query) [RFC 1035] - 2 Status [RFC 1035] - 3 available for assignment - 4 Notify [RFC 1996] - 5 Update [RFC 2136] - 6-15 available for assignment - - - - - - - - -Eastlake, et al. Best Current Practice [Page 3] - -RFC 2929 DNS IANA Considerations September 2000 - - -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 [RFC 2930] - 20 BADNAME Duplicate key name [RFC 2930] - 21 BADALG Algorithm not supported [RFC 2930] - 22-3840 available for assignment - 0x0016-0x0F00 - 3841-4095 Private Use - 0x0F01-0x0FFF - 4096-65535 available for assignment - 0x1000-0xFFFF - - Since it is important that RCODEs be understood for interoperability, - assignment of new RCODE listed above as "available for assignment" - requires an IETF Consensus. - - - - - -Eastlake, et al. Best Current Practice [Page 4] - -RFC 2929 DNS IANA Considerations September 2000 - - -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 - octets of the RDATA field. - - - - - - -Eastlake, et al. Best Current Practice [Page 5] - -RFC 2929 DNS IANA Considerations September 2000 - - - 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 IETF Consensus. - - 128 - 255 - 0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and - Meta TYPEs by IETF Consensus. - - 256 - 32767 - 0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF - Consensus. - - - - - -Eastlake, et al. Best Current Practice [Page 6] - -RFC 2929 DNS IANA Considerations September 2000 - - - 32768 - 65279 - 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. - - 65280 - 65535 - 0xFF00 - 0xFFFF - Private Use. - -3.1.1 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, 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.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 although 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. - - 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 - 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]. - - - -Eastlake, et al. Best Current Practice [Page 7] - -RFC 2929 DNS IANA Considerations September 2000 - - - 5 - 127 - 0x0005 - 0x007F - available for assignment by IETF Consensus as data - CLASSes only. - - 128 - 253 - 0x0080 - 0x00FD - available for assignment by IETF Consensus as - QCLASSes only. - - 254 - 0x00FE - QCLASS None [RFC 2136]. - - 255 - 0x00FF - QCLASS Any [RFC 1035]. - - 256 - 32767 - 0x0100 - 0x7FFF - assigned by IETF Consensus. - - 32768 - 65280 - 0x8000 - 0xFEFF - assigned based on Specification Required as defined - in [RFC 2434]. - - 65280 - 65534 - 0xFF00 - 0xFFFE - Private Use. - - 65535 - 0xFFFF - can only be assigned by an IETF Standards Action. - -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 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. - Binary labels are bit sequences [RFC 2673]. - - IANA considerations for label types are given in [RFC 2671]. - - - - - - - -Eastlake, et al. Best Current Practice [Page 8] - -RFC 2929 DNS IANA Considerations September 2000 - - - 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 dated description of name allocation in the IN Class is - given in [RFC 1591]. Some information on reserved top level domain - names is in Best Current Practice 32 [RFC 2606]. - -4. Security Considerations - - This document addresses IANA considerations in the allocation of - general DNS parameters, not security. See [RFC 2535] for secure DNS - considerations. - -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 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 1591] Postel, J., "Domain Name System Structure and - Delegation", RFC 1591, March 1994. - - [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. - - - - - -Eastlake, et al. Best Current Practice [Page 9] - -RFC 2929 DNS IANA Considerations September 2000 - - - [RFC 2535] Eastlake, D., "Domain Name System Security Extensions", - RFC 2535, March 1999. - - [RFC 2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS - Names", RFC 2606, June 1999. - - [RFC 2671] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC - 2671, August 1999. - - [RFC 2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC - 2672, 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. - - [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (TKEY - RR)", RFC 2930, September 2000. - - [US-ASCII] ANSI, "USA Standard Code for Information Interchange", - X3.4, American National Standards Institute: New York, - 1968. - - - - - - - - - - - - - - - - - - - - - - - - - - -Eastlake, et al. Best Current Practice [Page 10] - -RFC 2929 DNS IANA Considerations September 2000 - - -Authors' Addresses - - Donald E. Eastlake 3rd - Motorola - 140 Forest Avenue - Hudson, MA 01749 USA - - Phone: +1-978-562-2827 (h) - +1-508-261-5434 (w) - Fax: +1-508-261-4447 (w) - EMail: Donald.Eastlake@motorola.com - - - Eric Brunner-Williams - Engage - 100 Brickstone Square, 2nd Floor - Andover, MA 01810 - - Phone: +1-207-797-0525 (h) - +1-978-684-7796 (w) - Fax: +1-978-684-3118 - EMail: brunner@engage.com - - - Bill Manning - USC/ISI - 4676 Admiralty Way, #1001 - Marina del Rey, CA 90292 USA - - Phone: +1-310-822-1511 - EMail: bmanning@isi.edu - - - - - - - - - - - - - - - - - - - - -Eastlake, et al. Best Current Practice [Page 11] - -RFC 2929 DNS IANA Considerations September 2000 - - -Full Copyright Statement - - Copyright (C) The Internet Society (2000). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph are - included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. - - This document and the information contained herein is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Eastlake, et al. Best Current Practice [Page 12] - |
