📄 draft-ietf-dnsext-2929bis-01.txt
字号:
INTERNET-DRAFT DNS IANA Considerations August 20053.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 20053.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 2005Appendix: 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 2005Copyright 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) CaseD. 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 2005Authors Addresses Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA Telephone: +1-508-786-7554 (w) email: Donald.Eastlake@motorola.comExpiration and File Name This draft expires February 2006. Its file name is draft-ietf-dnsext-2929bis-01.txt.D. Eastlake 3rd [Page 16]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -