From 807c0c6103c051fd25961ea5bb00a7aec2ee910f Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Mon, 10 Jul 2000 04:37:49 +0000 Subject: [PATCH] pulled up removal of old drafts --- doc/draft/draft-ietf-dnsext-apl-rr-00.txt | 389 ----------- doc/draft/draft-ietf-dnsext-iana-dns-00.txt | 696 -------------------- 2 files changed, 1085 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsext-apl-rr-00.txt delete mode 100644 doc/draft/draft-ietf-dnsext-iana-dns-00.txt diff --git a/doc/draft/draft-ietf-dnsext-apl-rr-00.txt b/doc/draft/draft-ietf-dnsext-apl-rr-00.txt deleted file mode 100644 index 9d75e32e2f..0000000000 --- a/doc/draft/draft-ietf-dnsext-apl-rr-00.txt +++ /dev/null @@ -1,389 +0,0 @@ - -INTERNET-DRAFT Peter Koch -Expires: September 2000 Universitaet Bielefeld -Updates: RFC 1035 March 2000 - - A DNS RR Type for Lists of Address Prefixes (APL RR) - draft-ietf-dnsext-apl-rr-00.txt - - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - 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 as "work in progress." - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - Comments should be sent to the author or the DNSIND WG mailing list - . - -Abstract - - The Domain Name System is primarily used to translate domain names - into IPv4 addresses using A RRs. Several approaches exist to describe - networks or address ranges. This document specifies a new DNS RR type - "APL" for address prefix lists. - -1. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in [RFC2119]. - - Domain names herein are for explanatory purposes only and should not - be expected to lead to useful information in real life [RFC2606]. - - - - -Koch Expires September 2000 [Page 1] - -INTERNET-DRAFT DNS APL RR March 2000 - - -2. Background - - The Domain Name System [RFC1034], [RFC1035] provides a mechanism to - associate addresses and other internet infrastructure elements with - hierarchically built domain names. Various types of resource records - have been defined, especially those for IPv4 and IPv6 [RFC1886] - addresses. In [RFC1101] a method is described to publish information - about the address space allocated to an organisation. In older BIND - versions, a weak form of controlling access to zone data was - implemented using TXT RRs describing address ranges. - - This document specifies a new RR type for address prefix lists. - -3. APL RR Type - - An APL record has the DNS type of "APL" [draft: not yet applied for] - and a numeric value of [draft:to be assigned]. The APL RR is defined - in the IN class only. APL RRs cause no additional section processing. - -4. APL RDATA format - - The RDATA section consists of zero or more strings () of - the form - - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - | ADDRESSFAMILY | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - | PREFIX | N | AFDLENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - / AFDPART / - | | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - ADDRESSFAMILY 16 bit unsigned value as assigned by IANA - (see IANA Considerations) - PREFIX 8 bit unsigned binary coded prefix length. - Upper and lower bounds and interpretation of - this value are address family specific. - N negation flag, indicates the presence of the - "!" character in the textual format. It has - the value "1" if the "!" was given, "0" else. - AFDLENGTH length in octets of the following address - family dependent part (7 bit unsigned). - AFDPART address family dependent part. See below. - - - This document defines the AFDPARTs for address families 1 (IPv4) and - - - -Koch Expires September 2000 [Page 2] - -INTERNET-DRAFT DNS APL RR March 2000 - - - 2 (IPv6). Future revisions may deal with additional address - families. - -4.1. AFDPART for IPv4 - - The encoding of an IPv4 address (address family 1) follows the - encoding specified for the A RR by [RFC1035], section 3.4.1. Trailing - zero octets MUST be ignored, regardless of the prefix length. - - PREFIX specifies the number of bits of the IPv4 address starting at - the most significant bit. Legal values range from 0 to 32. - - An IPv4 AFDPART has a variable length of 0 to 4 octets. - -4.2. AFDPART for IPv6 - - The encoding of an IPv6 address (address family 2) follows the - specification for the AAAA RR in [RFC1886], section 2.2. The 128 bit - address is encoded in network byte order. Trailing zero octets MUST - be ignored, regardless of the prefix length. - - PREFIX specifies the number of bits of the IPv6 address starting at - the most significant bit. Legal values range from 0 to 128. - - An IPv6 AFDPART has a variable length of 0 to 16 octets. - -5. Zone File Syntax - - The textual representation of an APL RR in a DNS zone file is as - follows: - - IN APL {[!]afi:address/prefix}* - - The data consists of zero or more strings of the address family - indicator , immediately followed by a colon ":", an address, - immediately followed by the "/" character, immediately followed by a - decimal numeric value for the prefix length. Any such string may be - preceeded by a "!" character. The strings are separated by - whitespace. The is the decimal numeric value of that - particular address family. - -5.1. Textual Representation of IPv4 Addresses - - An IPv4 address in the
part of an is in dotted - quad notation, just as in an A RR. The has values from the - interval 0..32 (decimal). - -5.2. Textual Representation of IPv6 Addresses - - - -Koch Expires September 2000 [Page 3] - -INTERNET-DRAFT DNS APL RR March 2000 - - - The representation of an IPv6 address in the
part of an - follows [RFC2373], section 2.2. Legal values for - are from the interval 0..128 (decimal). - -6. APL RR usage - - An APL RR with empty RDATA is valid and implements an empty list. - Multiple occurences of the same in a single APL RR are - allowed and MUST NOT be merged by a DNS server or resolver. - MUST be kept in order and MUST NOT be rearranged or - aggregated. - - A single APL RR may contain belonging to different - address families. The maximum number of is upperbounded - by the available RDATA space. - - RRSets consisting of more than one APL RR are legal but the - interpretation is left to the particular application. - -7. Applicability Statement - - The APL RR defines a framework without specifying any particular - meaning for the list of prefixes. It is expected that APL RRs will - be used in different application scenarios which have to be - documented separately. Those scenarios may be distinguished by - characteristic prefixes placed in front of the DNS owner name. - - An APL application specification MUST include information on - - o the characteristic prefix, if any - - o how to interpret APL RRSets consisting of more than one RR - - o how to interpret an empty APL RR - - o which address families are expected to appear in the APL RRs for - that application - - o how to deal with APL RR list elements which belong to other - address families, including those not yet defined - - o the exact semantics of list elements negated by the "!" character - - - Possible applications include the publication of address ranges - similar to [RFC1101], description of zones built following [RFC2317] - and in-band access control to limit general access or zone transfer - (AXFR) availability for zone data held in DNS servers. - - - -Koch Expires September 2000 [Page 4] - -INTERNET-DRAFT DNS APL RR March 2000 - - - The specification of particular application scenarios is out of the - scope of this document. - -8. Examples - - The following examples only illustrate some of the possible usages - outlined in the previous section. None of those applications are - hereby specified nor is it implied that any particular APL RR based - application does exist now or will exist in the future. - - ; RFC 1101-like announcement of address ranges for foo.example - foo.example APL 1:192.168.32.0/21 !1:192.168.38.0/28 - - ; CIDR blocks covered by classless delegation - 42.168.192.IN-ADDR.ARPA APL ( 1:192.168.42.0/26 1:192.168.42.64/26 - 1:192.168.42.128/25 ) - - ; Zone transfer restriction - _axfr.sbo.example APL 1:127.0.0.1/32 1:172.16.64.0/22 - - ; List of address ranges for multicast - multicast.example APL 1:224.0.0.0/4 2:FF00:0:0:0:0:0:0:0/8 - - Note that since trailing zeroes are ignored in the first APL RR the - AFDLENGTH of both is three. - -9. Security Considerations - - Any information obtained from the DNS should be regarded as unsafe - unless techniques specified in [RFC2535] or [TSIGRR] were used. The - definition of a new RR type does not introduce security problems into - the DNS, but usage of information made available by APL RRs may - compromise security. This includes disclosure of network topology - information and in particular the use of APL RRs to construct access - control lists. - -10. IANA Considerations - - This section is to be interpreted as following [RFC2434]. - - This document does not define any new namespaces. It uses the 16 bit - identifiers for address families maintained by IANA in - ftp://ftp.iana.org/in-notes/iana/assignments/address-family-numbers. - - IANA is asked to assign a numeric RR type value for APL. - -11. Acknowledgements - - - - -Koch Expires September 2000 [Page 5] - -INTERNET-DRAFT DNS APL RR March 2000 - - - The author would like to thank Mark Andrews for his review and - constructive comments. - -12. References - - - [RFC1034] Mockapetris,P., "Domain Names - Concepts and Facilities", - RFC 1034, STD 13, November 1987 - - [RFC1035] Mockapetris,P., "Domain Names - Implementation and - Specification", RFC 1035, STD 13, November 1987 - - [RFC1101] Mockapetris,P., "DNS Encoding of Network Names and Other - Types", RFC 1101, April 1989 - - [RFC1886] Thomson,S., Huitema.,C., "DNS Extensions to support IP - version 6", RFC 1886, December 1995 - - [RFC2119] Bradner,S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997 - - [RFC2181] Elz,R., Bush,R., "Clarifications to the DNS - Specification", RFC 2181, July 1997 - - [RFC2317] Eidnes,H., de Groot,G., Vixie,P., "Classless IN-ADDR.ARPA - delegation", RFC 2317, March 1998 - - [RFC2373] Hinden,R., Deering,S., "IP Version 6 Addressing - Architecture", RFC 2373, July 1998 - - [RFC2434] Narten,T., Alvestrand,H., "Guidelines for Writing an IANA - Considerations Section in RFCs", RFC 2434, BCP 26, October - 1998 - - [RFC2535] Eastlake,D., "Domain Name System Security Extensions", RFC - 2535, March 1999 - - [RFC2606] Eastlake,D., Panitz,A., "Reserved Top Level DNS Names", - RFC 2606, BCP 32, June 1999 - - [TSIGRR] Vixie,P., Gudmundsson,O., Eastlake,D., Wellington,B., - "Secret Key Transaction Signatures for DNS (TSIG)", - , work in progress - - -13. Author's Address - - Peter Koch - - - -Koch Expires September 2000 [Page 6] - -INTERNET-DRAFT DNS APL RR March 2000 - - - Universitaet Bielefeld - Technische Fakultaet - D-33594 Bielefeld - Germany - +49 521 106 2902 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Koch Expires September 2000 [Page 7] diff --git a/doc/draft/draft-ietf-dnsext-iana-dns-00.txt b/doc/draft/draft-ietf-dnsext-iana-dns-00.txt deleted file mode 100644 index 84116106bc..0000000000 --- a/doc/draft/draft-ietf-dnsext-iana-dns-00.txt +++ /dev/null @@ -1,696 +0,0 @@ - -INTERNET-DRAFT Donald E. Eastlake 3rd - Eric Brunner - Bill Manning -Expires: June 2000 February 2000 - - - - Domain Name System (DNS) IANA Considerations - ------ ---- ------ ----- ---- -------------- - - - - -Status of This Document - - Distribution of this draft , which - is intended to become a Best Current Practice, is unlimited. Comments - should be sent to the DNS Working Group mailing list - or to the authors. - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. 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. Internet-Drafts may be updated, replaced, or obsoleted by - other documents at any time. It is not appropriate to use Internet- - Drafts as reference material or to cite them other than as a - ``working draft'' or ``work in progress.'' - - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt - - 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, etc. - - - - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 1] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -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....................................5 - 3.1 RR TYPE IANA Considerations............................7 - 3.1.1 Special Note on the OPT RR...........................8 - 3.2 RR CLASS IANA Considerations...........................8 - 3.3 RR NAME Considerations.................................9 - 4. Designated Expert......................................10 - 5. Security Considerations................................10 - References................................................10 - - Authors Addresses.........................................12 - Expiration and File Name..................................12 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 2] - - -INTERNET-DRAFT DNS IANA Considerations February 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 at - . - - "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. - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 3] - - -INTERNET-DRAFT DNS IANA Considerations February 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 - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 4] - - -INTERNET-DRAFT DNS IANA Considerations February 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 - TSIG RRs [RFC XXX3] and OPT RRs [RFC 2671]. The OPT RR provides an - eight bit extension resulting in a 12 bit RCODE field and the TSIG RR - has a 16 bit RCODE field. - - 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 XXX3] - 17 BADKEY Key not recognized [RFC XXX3] - 18 BADTIME Signature out of time window [RFC XXX3] - 19-3840 available for assignment - 0x0013-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. - - - -3. DNS Resource Records - - All RRs have the same top level format shown in the figure below - taken from [RFC 1035]: - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 5] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - - 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. - - 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. - - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 6] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -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 XXX3], and TKEY [work in progress]. - - 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. - - 32768 - 65279 - 0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434]. - - 65280 - 65535 - 0xFF00 - 0xFFFF - Private Use. - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 7] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -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, 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.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 81]. - - 4 - 0x0004 - Hesiod (HS) [Dyer 87]. - - 5 - 127 - 0x0005 - 0x007F - available for assignment by IETF Consensus as data - CLASSes only. - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 8] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - - 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 frequently referred to as ASCII and Binary. ASCII labels - can, in fact, include any octet value including zero octets but most - current uses involve only [US-ASCII] For retrieval ASCII labels are - defined to treat upper and lower case letters the same. Binary - labels are bit sequences [RFC 2673]. - - IANA considerations for label types are given in [RFC 2671]. - - NAMEs are local to a CLASS. The Hesiod [Dyer 87] and Chaos [Moon 81] - 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]. - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 9] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -4. Designated Expert - - To provide additional support to IANA in the DNS area, the IESG MAY - appoint a designed expert. - - - -5. 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 87] - Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical - Plan - Name Service, April 1987, - - [Moon 81] - D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts - Institute of Technology Artificial Intelligence Laboratory, June - 1981. - - [RFC 1034] - P. Mockapetris, "Domain Names - Concepts and - Facilities", STD 13, November 1987. - - [RFC 1035] - P. Mockapetris, "Domain Names - Implementation and - Specifications", STD 13, November 1987. - - [RFC 1591] - J. Postel, "Domain Name System Structure and - Delegation", March 1994. - - [RFC 1996] - P. Vixie, "A Mechanism for Prompt Notification of Zone - Changes (DNS NOTIFY)", August 1996. - - [RFC 2136] - P. Vixie, S. Thomson, Y. Rekhter, J. Bound, "Dynamic - Updates in the Domain Name System (DNS UPDATE)", 04/21/1997. - - [RFC 2181] - Robert Elz, Randy Bush, "Clarifications to the DNS - Specification", July 1997. - - [RFC 2434] - "Guidelines for Writing an IANA Considerations Section - in RFCs", T. Narten, H. Alvestrand, October 1998. - - [RFC 2535] - D. Eastlake, "Domain Name System Security Extensions", - March 1999. - - [RFC 2606] - D. Eastlake, A. Panitz, "Reserved Top Level DNS Names", - June 1999. - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 10] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - - [RFC 2671] - P. Vixie, "Extension mechanisms for DNS (EDNS0)", August - 1999. - - [RFC 2672] - M. Crawford, " Non-Terminal DNS Name Redirection", - August 1999. - - [RFC 2673] - M. Crawford, "Binary Labels in the Domain Name System", - August 1999. - - [RFC XXX3] - P. Vixie, O. Gudmundsson, D. Eastlake, B. Wellington, - "Secret Key Transaction Signatures for DNS (TSIG)", xxx 2000 (draft- - ietf-dnsind-tsig-*.txt). - - [US-ASCII] - ANSI, "USA Standard Code for Information - Interchange", X3.4, American National Standards Institute: New York, - 1968. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 11] - - -INTERNET-DRAFT DNS IANA Considerations February 2000 - - -Authors Addresses - - Donald E. Eastlake 3rd - Motorola - 65 Shindegan Hill Road - Carmel, NY 10512 USA - - Telephone: +1-914-276-2668 (h) - +1-508-261-5434 (w) - email: dee3@torque.pothole.com - - - Eric Brunner - 1415 Forest Avenue - Portland, ME 04103 USA - - Telephone: +1 207-797-0525 - email: brunner@world.std.com - - - Bill Manning - USC/ISI - 4676 Admiralty Way, #1001 - Marina del Rey, CA 90292 USA - - Telephone: +1 310 822 1511 - email: bmanning@isi.edu - - - -Expiration and File Name - - This draft expires August 2000. - - Its file name is draft-ietf-dnsext-iana-dns-00.txt. - - - - - - - - - - - - - - - - - -D. Eastlake 3rd, E. Brunner, B. Manning [Page 12] -