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]
|
||
|