From 10a05eabf2aa6182db1724d050ea59b506f9b75d Mon Sep 17 00:00:00 2001 From: Bob Halley Date: Fri, 27 Aug 1999 01:34:01 +0000 Subject: [PATCH] remove --- .../draft-ietf-dnsind-binary-labels-05.txt | 337 ------------ doc/draft/draft-ietf-dnsind-dname-03.txt | 502 ------------------ doc/draft/draft-ietf-dnsind-edns0-01.txt | 319 ----------- 3 files changed, 1158 deletions(-) delete mode 100644 doc/draft/draft-ietf-dnsind-binary-labels-05.txt delete mode 100644 doc/draft/draft-ietf-dnsind-dname-03.txt delete mode 100644 doc/draft/draft-ietf-dnsind-edns0-01.txt diff --git a/doc/draft/draft-ietf-dnsind-binary-labels-05.txt b/doc/draft/draft-ietf-dnsind-binary-labels-05.txt deleted file mode 100644 index b95dfb6244..0000000000 --- a/doc/draft/draft-ietf-dnsind-binary-labels-05.txt +++ /dev/null @@ -1,337 +0,0 @@ -DNSIND Working Group Matt Crawford -Internet Draft Fermilab - May 5, 1999 - - Binary Labels in the Domain Name System - - - - -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. - - - -1. Introduction and Terminology - - This document defines a ``Bit-String Label'' which may appear within - domain names. This new label type compactly represents a sequence - of ``One-Bit Labels'' and enables resource records to be stored at - any bit-boundary in a binary-named section of the domain name tree. - - 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 [KWORD]. - - -2. Motivation - - Binary labels are intended to efficiently solve the problem of - storing data and delegating authority on arbitrary boundaries when - the structure of underlying name space is most naturally represented - in binary. - - - - - - - -Expires November 10, 1999 Crawford [Page 1] - -Internet Draft Binary DNS Labels May 5, 1999 - - -3. Label Format - - Up to 256 One-Bit Labels can be grouped into a single Bit-String - Label. Within a Bit-String Label the most significant or "highest - level" bit appears first. This is unlike the ordering of DNS labels - themselves, which has the least significant or "lowest level" label - first. Nonetheless, this ordering seems to be the most natural and - efficient for representing binary labels. - - Among consecutive Bit-String Labels, the bits in the first-appearing - label are less significant or "at a lower level" than the bits in - subsequent Bit-String Labels, just as ASCII labels are ordered. - - -3.1. Encoding - - - 0 1 2 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 . . . - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+ - |0 1| ELT | Count | Label ... | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+ - - (Each tic mark represents one bit.) - - - ELT 000001 binary, the six-bit extended label type [EDNS0] - assigned to the Bit-String Label. - - Count The number of significant bits in the Label field. A - Count value of zero indicates that 256 bits are - significant. (Thus the null label representing the DNS - root cannot be represented as a Bit String Label.) - - Label The bit string representing a sequence of One-Bit Labels, - with the most significant bit first. That is, the One-Bit - Label in position 17 in the diagram above represents a - subdomain of the domain represented by the One-Bit Label - in position 16, and so on. - - The Label field is padded on the right with zero to seven - pad bits to make the entire field occupy an integral - number of octets. These pad bits MUST be zero on - transmission and ignored on reception. - - A sequence of bits may be split into two or more Bit-String Labels, - but the division points have no significance and need not be - preserved. An excessively clever server implementation might split - - - -Expires November 10, 1999 Crawford [Page 2] - -Internet Draft Binary DNS Labels May 5, 1999 - - - Bit-String Labels so as to maximize the effectiveness of message - compression [DNSIS]. A simpler server might divide Bit-String - Labels at zone boundaries, if any zone boundaries happen to fall - between One-Bit Labels. - - -3.2. Textual Representation - - A Bit-String Label is represented in text -- in a zone file, for - example -- as a surrounded by the delimiters "\[" and - "]". The is either a dotted quad or a base indicator and - a sequence of digits appropriate to that base, optionally followed - by a slash and a length. The base indicators are "b", "o" and "x", - denoting base 2, 8 and 16 respectively. The length counts the - significant bits and MUST be between 1 and 32, inclusive, after a - dotted quad, or between 1 and 256, inclusive, after one of the other - forms. If the length is omitted, the implicit length is 32 for a - dotted quad or 1, 3 or 4 times the number of binary, octal or - hexadecimal digits supplied, respectively, for the other forms. - - In augmented Backus-Naur form [ABNF], - - bit-string-label = "\[" bit-spec "]" - - bit-spec = bit-data [ "/" length ] - / dotted-quad [ "/" slength ] - - bit-data = "x" 1*64HEXDIG - / "o" 1*86OCTDIG - / "b" 1*256BIT - - dotted-quad = decbyte "." decbyte "." decbyte "." decbyte - - decbyte = 1*3DIGIT - - length = NZDIGIT *2DIGIT - - slength = NZDIGIT [ DIGIT ] - - OCTDIG = %x30-37 - - NZDIGIT = %x31-39 - - If a is present, the number of digits in the - MUST be just sufficient to contain the number of bits specified by - the . If there are insignificant bits in a final - hexadecimal or octal digit, they MUST be zero. A - always has all four parts even if the associated is less - - - -Expires November 10, 1999 Crawford [Page 3] - -Internet Draft Binary DNS Labels May 5, 1999 - - - than 24, but, like the other forms, insignificant bits MUST be zero. - - Each number represented by a must be between 0 and 255, - inclusive. - - The number represented by must be between 1 and 256 - inclusive. - - The number represented by must be between 1 and 32 - inclusive. - - When the textual form of a Bit-String Label is generated by machine, - the length SHOULD be explicit, not implicit. - - -3.2.1. Examples - - The following four textual forms represent the same Bit-String - Label. - - \[b11010000011101] - \[o64072/14] - \[xd074/14] - \[208.116.0.0/14] - - The following represents two consecutive Bit-String Labels which - denote the same relative point in the DNS tree as any of the above - single Bit-String Labels. - - \[b11101].\[o640] - - - -3.3. Canonical Representation and Sort Order - - Both the wire form and the text form of binary labels have a degree - of flexibility in their grouping into multiple consecutive Bit- - String Labels. For generating and checking DNS signature records - [DNSSEC] binary labels must be in a predictable form. This - canonical form is defined as the form which has the fewest possible - Bit-String Labels and in which all except possibly the first (least - significant) label in any sequence of consecutive Bit-String Labels - is of maximum length. - - For example, the canonical form of any sequence of up to 256 One-Bit - Labels has a single Bit-String Label, and the canonical form of a - sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of - which the second and third contain 256 label bits. - - - -Expires November 10, 1999 Crawford [Page 4] - -Internet Draft Binary DNS Labels May 5, 1999 - - - The canonical sort order of domain names [DNSSEC] is extended to - encompass binary labels as follows. Sorting is still label-by- - label, from most to least significant, where a label may now be a - One-Bit Label or a standard (code 00) label. Any One-Bit Label - sorts before any standard label, and a 0 bit sorts before a 1 bit. - The absence of a label sorts before any label, as specified in - [DNSSEC]. - - For example, the following domain names are correctly sorted. - - foo.example - \[b1].foo.example - \[b100].foo.example - \[b101].foo.example - bravo.\[b10].foo.example - alpha.foo.example - - -4. Processing Rules - - A One-Bit Label never matches any other kind of label. In - particular, the DNS labels represented by the single ASCII - characters "0" and "1" do not match One-Bit Labels represented by - the bit values 0 and 1. - - -5. Discussion - - A Count of zero in the wire-form represents a 256-bit sequence, not - to optimize that particular case, but to make it completely - impossible to have a zero-bit label. - - -6. IANA Considerations - - This document defines one Extended Label Type, termed the Bit-String - Label, and requests registration of the code point 000001 binary in - the space defined by [EDNS0]. - - -7. Security Considerations - - All security considerations which apply to traditional ASCII DNS - labels apply equally to binary labels. he canonicalization and - sorting rules of section 3.3 allow these to be addressed by DNS - Security [DNSSEC]. - - - - - -Expires November 10, 1999 Crawford [Page 5] - -Internet Draft Binary DNS Labels May 5, 1999 - - -8. References - - [ABNF] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234. - - [DNSIS] P.V. Mockapetris, "Domain names - implementation and - specification", RFC 1035. - - [DNSSEC]D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security - Extensions", RFC 2065. - - [EDNS0] P. Vixie, "Extension mechanisms for DNS (EDNS0)", Currently - draft-dnsind-edns0-01.txt. - - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119. - - -9. Author's Address - - Matt Crawford - Fermilab MS 368 - PO Box 500 - Batavia, IL 60510 - USA - - Phone: +1 630 840-3461 - - EMail: crawdad@fnal.gov - - - - - - - - - - - - - - - - - - - - - - -Expires November 10, 1999 Crawford [Page 6] - diff --git a/doc/draft/draft-ietf-dnsind-dname-03.txt b/doc/draft/draft-ietf-dnsind-dname-03.txt deleted file mode 100644 index f28cd1b3ea..0000000000 --- a/doc/draft/draft-ietf-dnsind-dname-03.txt +++ /dev/null @@ -1,502 +0,0 @@ - -DNSIND Working Group Matt Crawford -Internet Draft Fermilab - March 21, 1999 - - Non-Terminal DNS Name Redirection - - - - -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." - - To view the list Internet-Draft Shadow Directories, see - http://www.ietf.org/shadow.html. - - -1. Introduction - - This document defines a new DNS Resource Record called ``DNAME'', - which provides the capability to map an entire subtree of the DNS - name space to another domain. It differs from the CNAME record - which maps a single node of the name space. - - 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 [KWORD]. - - -2. Motivation - - This Resource Record and its processing rules were conceived as a - solution to the problem of maintaining address-to-name mappings in a - context of network renumbering. Without the DNAME mechanism, an - authoritative DNS server for the address-to-name mappings of some - network must be reconfigured when that network is renumbered. With - DNAME, the zone can be constructed so that it needs no modification - when renumbered. DNAME can also be useful in other situations, such - as when an organizational unit is renamed. - - - -Expires September 26, 1999 Crawford [Page 1] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - -3. The DNAME Resource Record - - The DNAME RR has mnemonic DNAME and type code 39 (decimal). - - DNAME has the following format: - - DNAME - - The format is not class-sensitive. All fields are required. The - RDATA field is a [DNSIS]. - - The DNAME RR causes type NS additional section processing. - - The effect of the DNAME record is the substitution of the record's - for its as a suffix of a domain name. A "no- - descendants" limitation governs the use of DNAMEs in a zone file: - - If a DNAME RR is present at a node N, there may be other data at - N (except a CNAME or another DNAME), but there MUST be no data - at any descendant of N. This restriction applies only to - records of the same class as the DNAME record. - - This rule assures predictable results when a DNAME record is cached - by a server which is not authoritative for the record's zone. It - MUST be enforced when authoritative zone data is loaded. Together - with the rules for DNS zone authority [DNSCLR] it implies that DNAME - and NS records can only coexist at the top of a zone which has only - one node. - - The compression scheme of [DNSIS] MUST NOT be applied to the RDATA - portion of a DNAME record unless the sending server has some way of - knowing that the receiver understands the DNAME record format. - Signalling such understanding is expected to be the subject of - future DNS Extensions. - - Naming loops can be created with DNAME records or a combination of - DNAME and CNAME records, just as they can with CNAME records alone. - Resolvers, including resolvers embedded in DNS servers, MUST limit - the resources they devote to any query. Implementors should note, - however, that fairly lengthy chains of DNAME records may be valid. - - -4. Query Processing - - To exploit the DNAME mechanism the name resolution algorithms - [DNSCF] must be modified slightly for both servers and resolvers. - - Both modified algorithms incorporate the operation of making a - - - -Expires September 26, 1999 Crawford [Page 2] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - - substitution on a name (either QNAME or SNAME) under control of a - DNAME record. This operation will be referred to as "the DNAME - substitution". - - -4.1. Processing by Servers - - For a server performing non-recursive service steps 3.c and 4 of - section 4.3.2 [DNSCF] are changed to check for a DNAME record before - checking for a wildcard ("*") label, and to return certain DNAME - records from zone data and the cache. - - DNS clients sending Extended DNS [EDNS0] queries with Version 0 or - non-extended queries are presumed not to understand the semantics of - the DNAME record, so a server which implements this specification, - when answering a non-extended query, SHOULD synthesize a CNAME - record for each DNAME record encountered during query processing to - help the client reach the correct DNS data. The behavior of clients - and servers under Extended DNS versions greater than 0 will be - specified when those versions are defined. - - The synthesized CNAME RR, if provided, MUST have - - The same CLASS as the QCLASS of the query, - - TTL equal to zero, - - An equal to the QNAME in effect at the moment the DNAME - RR was encountered, and - - An RDATA field containing the new QNAME formed by the action of - the DNAME substitution. - - If the server has the appropriate key on-line [DNSSEC, SECDYN], it - MAY generate and return a SIG RR for the synthesized CNAME RR. - - The revised server algorithm is: - - 1. Set or clear the value of recursion available in the response - depending on whether the name server is willing to provide - recursive service. If recursive service is available and - requested via the RD bit in the query, go to step 5, otherwise - step 2. - - 2. Search the available zones for the zone which is the nearest - ancestor to QNAME. If such a zone is found, go to step 3, - otherwise step 4. - - - - -Expires September 26, 1999 Crawford [Page 3] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - - 3. Start matching down, label by label, in the zone. The matching - process can terminate several ways: - - a. If the whole of QNAME is matched, we have found the node. - - If the data at the node is a CNAME, and QTYPE doesn't match - CNAME, copy the CNAME RR into the answer section of the - response, change QNAME to the canonical name in the CNAME - RR, and go back to step 1. - - Otherwise, copy all RRs which match QTYPE into the answer - section and go to step 6. - - b. If a match would take us out of the authoritative data, we - have a referral. This happens when we encounter a node with - NS RRs marking cuts along the bottom of a zone. - - Copy the NS RRs for the subzone into the authority section - of the reply. Put whatever addresses are available into the - additional section, using glue RRs if the addresses are not - available from authoritative data or the cache. Go to step - 4. - - c. If at some label, a match is impossible (i.e., the - corresponding label does not exist), look to see whether the - last label matched has a DNAME record. - - If a DNAME record exists at that point, copy that record - into the answer section. If substitution of its - for its in QNAME would overflow the legal size for a - , set RCODE to YXDOMAIN [DNSUPD] and exit; - otherwise perform the substitution and continue. If the - query was not extended [EDNS0] with a Version indicating - understanding of the DNAME record, the server SHOULD - synthesize a CNAME record as described above and include it - in the answer section. Go back to step 1. - - If there was no DNAME record, look to see if the "*" label - exists. - - If the "*" label does not exist, check whether the name we - are looking for is the original QNAME in the query or a name - we have followed due to a CNAME. If the name is original, - set an authoritative name error in the response and exit. - Otherwise just exit. - - If the "*" label does exist, match RRs at that node against - QTYPE. If any match, copy them into the answer section, but - - - -Expires September 26, 1999 Crawford [Page 4] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - - set the owner of the RR to be QNAME, and not the node with - the "*" label. Go to step 6. - - 4. Start matching down in the cache. If QNAME is found in the - cache, copy all RRs attached to it that match QTYPE into the - answer section. If QNAME is not found in the cache but a DNAME - record is present at an ancestor of QNAME, copy that DNAME - record into the answer section. If there was no delegation from - authoritative data, look for the best one from the cache, and - put it in the authority section. Go to step 6. - - 5. Use the local resolver or a copy of its algorithm (see resolver - section of this memo) to answer the query. Store the results, - including any intermediate CNAMEs and DNAMEs, in the answer - section of the response. - - 6. Using local data only, attempt to add other RRs which may be - useful to the additional section of the query. Exit. - - Note that there will be at most one ancestor with a DNAME as - described in step 4 unless some zone's data is in violation of the - no-descendants limitation in section 3. An implementation might - take advantage of this limitation by stopping the search of step 3c - or step 4 when a DNAME record is encountered. - - -4.2. Processing by Resolvers - - A resolver or a server providing recursive service must be modified - to treat a DNAME as somewhat analogous to a CNAME. The resolver - algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d - as 4.e and insert a new 4.d. The complete algorithm becomes: - - 1. See if the answer is in local information, and if so return it - to the client. - - 2. Find the best servers to ask. - - 3. Send them queries until one returns a response. - - 4. Analyze the response, either: - - a. if the response answers the question or contains a name - error, cache the data as well as returning it back to the - client. - - b. if the response contains a better delegation to other - servers, cache the delegation information, and go to step 2. - - - -Expires September 26, 1999 Crawford [Page 5] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - - c. if the response shows a CNAME and that is not the answer - itself, cache the CNAME, change the SNAME to the canonical - name in the CNAME RR and go to step 1. - - d. if the response shows a DNAME and that is not the answer - itself, cache the DNAME. If substitution of the DNAME's - for its in the SNAME would overflow the - legal size for a , return an implementation- - dependent error to the application; otherwise perform the - substitution and go to step 1. - - e. if the response shows a server failure or other bizarre - contents, delete the server from the SLIST and go back to - step 3. - - A resolver or recursive server which understands DNAME records but - sends non-extended queries MUST augment step 4.c by deleting from - the reply any CNAME records which have an which is a - subdomain of the of any DNAME record in the response. - - -5. Examples of Use - -5.1. Organizational Renaming - - If an organization with domain name FROBOZZ.EXAMPLE became part of - an organization with domain name ACME.EXAMPLE, it might ease - transition by placing information such as this in its old zone. - - frobozz.example. DNAME frobozz-division.acme.example. - MX 10 mailhub.acme.example. - - The response to an extended recursive query for www.frobozz.example - would contain, in the answer section, the DNAME record shown above - and the relevant RRs for www.frobozz-division.acme.example. - - -5.2. Classless Delegation of Shorter Prefixes - - The classless scheme for in-addr.arpa delegation [INADDR] can be - extended to prefixes shorter than 24 bits by use of the DNAME - record. For example, the prefix 192.0.8.0/22 can be delegated by - the following records. - - - - - - - - -Expires September 26, 1999 Crawford [Page 6] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - - - $ORIGIN 0.192.in-addr.arpa. - 8/22 NS ns.slash-22-holder.example. - 8 DNAME 8.8/22 - 9 DNAME 9.8/22 - 10 DNAME 10.8/22 - 11 DNAME 11.8/22 - - A typical entry in the resulting reverse zone for some host with - address 192.0.9.33 might be - - $ORIGIN 8/22.0.192.in-addr.arpa. - 33.9 PTR somehost.slash-22-holder.example. - - - The same advisory remarks concerning the choice of the "/" character - apply here as in [INADDR]. - - -5.3. Network Renumbering Support - - If IPv4 network renumbering were common, maintenance of address - space delegation could be simplified by using DNAME records instead - of NS records to delegate. - - $ORIGIN new-style.in-addr.arpa. - 189.190 DNAME in-addr.example.net. - - $ORIGIN in-addr.example.net. - 188 DNAME in-addr.customer.example. - - $ORIGIN in-addr.customer.example. - 1 PTR www.customer.example. - 2 PTR mailhub.customer.example. - ; etc ... - - This would allow the address space 190.189.0.0/16 assigned to the - ISP "example.net" to be changed without the necessity of altering - the zone files describing the use of that space by the ISP and its - customers. - - Renumbering IPv4 networks is currently so arduous a task that - updating the DNS is only a small part of the labor, so this scheme - may have a low value. But it is hoped that in IPv6 the renumbering - task will be quite different and the DNAME mechanism may play a - useful part. - - - - - -Expires September 26, 1999 Crawford [Page 7] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - -6. IANA Considerations - - This document defines a new DNS Resource Record type with the - mnemonic DNAME and type code 39 (decimal). The naming/numbering - space is defined in [DNSIS]. This name and number have already been - registered with the IANA. - - -7. Security Considerations - - The DNAME record is similar to the CNAME record with regard to the - consequences of insertion of a spoofed record into a DNS server or - resolver, differing in that the DNAME's effect covers a whole - subtree of the name space. The facilities of [DNSSEC] are available - to authenticate this record type. - - -8. References - - [DNSCF] P.V. Mockapetris, "Domain names - concepts and facilities", - RFC 1034. - - [DNSCLR] R. Elz, R. Bush, "Clarifications to the DNS Specification", - RFC 2181. - - [DNSIS] P.V. Mockapetris, "Domain names - implementation and - specification", RFC 1035. - - [DNSSEC] D. Eastlake, 3rd, C. Kaufman, "Domain Name System Security - Extensions", RFC 2065. - - [DNSUPD] P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, "Dynamic - Updates in the Domain Name System", RFC 2136. - - [EDNS0] P. Vixie, "Extensions mechanisms for DNS (EDNS0)", Currently - draft-dnsind-edns0-01.txt. - - [INADDR] H. Eidnes, G. de Groot, P. Vixie, "Classless IN-ADDR.ARPA - delegation", RFC 2317. - - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," RFC 2119. - - [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic - Update", RFC 2137. - - - - - - -Expires September 26, 1999 Crawford [Page 8] - -Internet Draft Non-Terminal Nicknames March 21, 1999 - - -9. Author's Address - - Matt Crawford - Fermilab MS 368 - PO Box 500 - Batavia, IL 60510 - USA - - Phone: +1 630 840-3461 - - EMail: crawdad@fnal.gov - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Expires September 26, 1999 Crawford [Page 9] - diff --git a/doc/draft/draft-ietf-dnsind-edns0-01.txt b/doc/draft/draft-ietf-dnsind-edns0-01.txt deleted file mode 100644 index 8aefeaf902..0000000000 --- a/doc/draft/draft-ietf-dnsind-edns0-01.txt +++ /dev/null @@ -1,319 +0,0 @@ - - - - - DNSIND Working Group Paul Vixie - INTERNET-DRAFT ISC - January, 1999 - - - Extension mechanisms for DNS (EDNS0) - - - Status of this Memo - - This document is an Internet-Draft. 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.'' - - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). - - - Abstract - - The Domain Name System's wire protocol includes a number of fixed - fields whose range has been or soon will be exhausted and does not - allow clients to advertise their capabilities to servers. This - document describes backward compatible mechanisms for allowing the - protocol to grow. - - 1 - Rationale and Scope - - 1.1. DNS (see [RFC1035]) specifies a Message Format and within such - messages there are standard formats for encoding options, errors, and - name compression. The maximum allowable size of a DNS Message is fixed. - Many of DNS's protocol limits are too small for uses which are or which - are desired to become common. There is no way for implementations to - advertise their capabilities. - - - - - - Expires July 1999 [Page 1] - - INTERNET-DRAFT EDNS0 January 1999 - - - 1.2. Existing clients will not know how to interpret the protocol - extensions detailed here. In practice, these clients will be upgraded - when they have need of a new feature, and only new features will make - use of the extensions. We must however take account of client behaviour - in the face of extra fields, and design a fallback scheme for - interoperability with these clients. - - 2 - Affected Protocol Elements - - 2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit - word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of - 1-bit flags. The original reserved Z bits have been allocated to - various purposes, and most of the RCODE values are now in use. More - flags and more possible RCODEs are needed. - - 2.2. The first two bits of a wire format domain label are used to denote - the type of the label. [RFC1035 4.1.4] allocates two of the four - possible types and reserves the other two. Proposals for use of the - remaining types far outnumber those available. More label types are - needed. - - 2.3. DNS Messages are limited to 512 octets in size when sent over UDP. - While the minimum maximum reassembly buffer size still allows a limit of - 512 octets of UDP payload, most of the hosts now connected to the - Internet are able to reassemble larger datagrams. Some mechanism must - be created to allow requestors to advertise larger buffer sizes to - responders. - - 3 - Extended Label Types - - 3.1. The ``0 1'' label type will now indicate an extended label type, - whose value is encoded in the lower six bits of the first octet of a - label. All subsequently developed label types should be encoded using - an extended label type. - - 3.2. The ``1 1 1 1 1 1'' extended label type will be reserved for future - expansion of the extended label type code space. - - 4 - OPT pseudo-RR - - 4.1. The OPT pseudo-RR can be added to the additional data section of - either a request or a response. An OPT is called a pseudo-RR because it - pertains to a particular transport level message and not to any actual - DNS data. OPT RRs shall never be cached, forwarded, or stored in or - loaded from master files. - - - - Expires July 1999 [Page 2] - - INTERNET-DRAFT EDNS0 January 1999 - - - 4.2. An OPT RR has a fixed part and a variable set of options expressed - as {attribute, value} pairs. The fixed part holds some DNS meta data - and also a small collection of new protocol elements which we expect to - be so popular that it would be a waste of wire space to encode them as - {attribute, value} pairs. - - 4.3. The fixed part of an OPT RR is structured as follows: - - Field Name Field Type Description - ------------------------------------------------------ - NAME domain name empty (root domain) - TYPE u_int16_t OPT - CLASS u_int16_t sender's UDP payload size - TTL u_int32_t extended RCODE and flags - RDLEN u_int16_t describes RDATA - RDATA octet stream {attribute,value} pairs - - - 4.4. The variable part of an OPT RR is encoded in its RDATA and is - structured as zero or more of the following: - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | OPTION-CODE | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | OPTION-LENGTH | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 4: | | - / OPTION-DATA / - / / - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - OPTION-CODE (Assigned by IANA.) - - OPTION-LENGTH Size (in octets) of OPTION-DATA. - - OPTION-DATA Varies per OPTION-CODE. - - 4.5. The sender's UDP buffer size (which OPT stores in the RR CLASS - field) is the number of octets of the largest UDP payload that can be - reassembled and delivered in the sender's network stack. Note that path - MTU, with or without fragmentation, may be smaller than this. - - - - - - Expires July 1999 [Page 3] - - INTERNET-DRAFT EDNS0 January 1999 - - - 4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP - reassembly buffer. Choosing 1280 on an Ethernet connected requestor - would be reasonable. The consequence of choosing too large a value may - be an ICMP message from an intermediate gateway, or even a silent drop - of the response message. Requestors are advised to retry in such cases. - - 4.5.2. Both requestors and responders are advised to take account of the - path's already discovered MTU (if known) when considering message sizes. - - 4.6. The extended RCODE and flags (which OPT stores in the RR TTL field) - are structured as follows: - - +0 (MSB) +1 (LSB) - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 0: | EXTENDED-RCODE | VERSION | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - 2: | Z | - +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ - - - EXTENDED-RCODE Forms upper 8 bits of extended 12-bit RCODE. Note that - EXTENDED-RCODE value "0" indicates that an unextended - RCODE is in use (values "0" through "15"). - - VERSION Indicates the implementation level of whoever sets it. - Full conformance with this specification is indicated by - version ``0.'' Note that both requestors and responders - should set this to the highest level they implement, - that responders should send back RCODE=BADVERS and that - requestors should be prepared to probe using lower - version numbers if they receive an RCODE=BADVERS. - - Z Set to zero by senders and ignored by receivers, unless - modified in a subsequent specification. - - 5 - Transport Considerations - - 5.1. The presence of an OPT pseudo-RR in a request should be taken as an - indication that the requestor fully implements the given version of - EDNS, and can correctly understand any response that conforms to that - feature's specification. - - 5.2. Lack of use of these features in a request must be taken as an - indication that the requestor does not implement any part of this - specification and that the responder may make no use of any protocol - - - - Expires July 1999 [Page 4] - - INTERNET-DRAFT EDNS0 January 1999 - - - extension described here in its response. - - 5.3. Responders who do not understand these protocol extensions are - expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL. - Therefore use of extensions should be ``probed'' such that a responder - who isn't known to support them be allowed a retry with no extensions if - it responds with such an RCODE. If a responder's capability level is - cached by a requestor, a new probe should be sent periodically to test - for changes to responder capability. - - 6 - Security Considerations - - Requestor-side specification of the maximum buffer size may open a new - DNS denial of service attack if responders can be made to send messages - which are too large for intermediate gateways to forward, thus leading - to potential ICMP storms between gateways and responders. - - 7 - IANA Considerations - - IANA is hereby requested to assign an RR type code for OPT. - - It is the recommendation of this document and its working group that - IANA create a registry for EDNS Extended Label Types, for EDNS Option - Codes, and for EDNS Version Numbers. - - This document assigns label type 0b01xxxxxx as "EDNS Extended Label - Type." We request that IANA record this assignment. - - This document assigns extended label type 0bxx111111 as "Reserved for - future extended label types." We request that IANA record this - assignment. - - This document assigns option code 65535 to "Reserved for future - expansion." - - This document expands the RCODE space from 4 bits to 12 bits. This will - allow IANA to assign more than the 16 distinct RCODE values allowed in - [RFC1035]. - - This document assigns EDNS Extended RCODE "16" to "BADVERS". - - IESG approval should be required to create new entries in the EDNS - Extended Label Type or EDNS Version Number registries, while any - published RFC (including Informational, Experimental, or BCP) should be - grounds for allocation of an EDNS Option Code. - - - - Expires July 1999 [Page 5] - - INTERNET-DRAFT EDNS0 January 1999 - - - 8 - Acknowledgements - - Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley, - Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas - Narten were each instrumental in creating and refining this - specification. - - 9 - References - - [RFC1035] P. Mockapetris, ``Domain Names - Implementation and - Specification,'' RFC 1035, USC/Information Sciences - Institute, November 1987. - - 10 - Author's Address - - Paul Vixie - Internet Software Consortium - 950 Charter Street - Redwood City, CA 94063 - +1 650 779 7001 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Expires July 1999 [Page 6] -