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. KWORD].
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. 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.
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.
When the textual form of a Bit-String Label is generated by machine, the length SHOULD be explicit, not implicit. 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].
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 EDNS0]. section 3.3 allow these to be addressed by DNS Security [DNSSEC].
[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.
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.