diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc2673.txt')
| -rw-r--r-- | contrib/bind9/doc/rfc/rfc2673.txt | 395 |
1 files changed, 0 insertions, 395 deletions
diff --git a/contrib/bind9/doc/rfc/rfc2673.txt b/contrib/bind9/doc/rfc/rfc2673.txt deleted file mode 100644 index 19d272e..0000000 --- a/contrib/bind9/doc/rfc/rfc2673.txt +++ /dev/null @@ -1,395 +0,0 @@ - - - - - - -Network Working Group M. Crawford -Request for Comments: 2673 Fermilab -Category: Standards Track August 1999 - - - Binary Labels in the Domain Name System - -Status of this Memo - - This document specifies an Internet standards track protocol for the - Internet community, and requests discussion and suggestions for - improvements. Please refer to the current edition of the "Internet - Official Protocol Standards" (STD 1) for the standardization state - and status of this protocol. Distribution of this memo is unlimited. - -Copyright Notice - - Copyright (C) The Internet Society (1999). All Rights Reserved. - -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. - -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. - - - - - - -Crawford Standards Track [Page 1] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - - 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 - 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 <bit-spec> surrounded by the delimiters "\[" and "]". - The <bit-spec> is either a dotted quad or a base indicator and a - sequence of digits appropriate to that base, optionally followed by a - - - -Crawford Standards Track [Page 2] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - - 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 <length> is present, the number of digits in the <bit-data> MUST - be just sufficient to contain the number of bits specified by the - <length>. If there are insignificant bits in a final hexadecimal or - octal digit, they MUST be zero. A <dotted-quad> always has all four - parts even if the associated <slength> is less than 24, but, like the - other forms, insignificant bits MUST be zero. - - Each number represented by a <decbyte> must be between 0 and 255, - inclusive. - - The number represented by <length> must be between 1 and 256 - inclusive. - - The number represented by <slength> must be between 1 and 32 - inclusive. - - - - - -Crawford Standards Track [Page 3] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - - 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. - - 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]. - - - - - - - - - - - -Crawford Standards Track [Page 4] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - - 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]. - - - - - - - - - - - - - - - - - -Crawford Standards Track [Page 5] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - -8. References - - [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax - Specifications: ABNF", RFC 2234, November 1997. - - [DNSIS] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [DNSSEC] Eastlake, D., 3rd, C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, January 1997 - - [EDNS0] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671, - August 1999. - - [KWORD] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels," BCP 14, RFC 2119, March 1997. - -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 - - - - - - - - - - - - - - - - - - - - - - - - -Crawford Standards Track [Page 6] - -RFC 2673 Binary Labels in the Domain Name System August 1999 - - -10. Full Copyright Statement - - Copyright (C) The Internet Society (1999). 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. - - - - - - - - - - - - - - - - - - - -Crawford Standards Track [Page 7] - |
