396 lines
12 KiB
Plaintext
396 lines
12 KiB
Plaintext
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
|
|||
|
|
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]
|
|||
|
|
|