Network Working Group M. Crawford
Request for Comments: 2673 Fermilab
Category: Standards Track August 1999
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[KWORD]中所述进行解释。
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.
当底层名称空间的结构最自然地用二进制表示时，二进制标签旨在有效地解决在任意边界上存储数据和授权的问题。
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.
最多可以将256个一位标签分组为一个位字符串标签。在位字符串标签中，最重要或“最高级别”位首先出现。这与DNS标签本身的排序不同，DNS标签本身首先具有最低有效或“最低级别”的标签。尽管如此，这种排序似乎是表示二进制标签最自然、最有效的方法。
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.
在连续的位串标签中，第一个出现的标签中的位的重要性低于或“处于较低的级别”，就像ASCII标签的顺序一样。
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
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.)
（每个tic标记代表一位。）
ELT 000001 binary, the six-bit extended label type [EDNS0] assigned to the Bit-String Label.
ELT 000001二进制，分配给位字符串标签的六位扩展标签类型[EDNS0]。
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.)
计算标签字段中的有效位数。计数值为零表示256位有效。（因此，表示DNS根的空标签不能表示为位字符串标签。）
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.
标记表示一个一位标签序列的位字符串，首先是最高有效位。也就是说，上图中位置17处的一位标签表示由位置16处的一位标签表示的域的子域，依此类推。
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.
标签字段在右侧用0到7个填充位填充，以使整个字段占据整数个八位字节。这些pad位在传输时必须为零，在接收时必须忽略。
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.
一个位序列可以被分割成两个或多个位串标签，但分割点没有意义，不需要保留。过于聪明的服务器实现可能会拆分位字符串标签，以便最大限度地提高消息压缩[DNSIS]的效率。如果任何区域边界恰好位于一个位标签之间，则更简单的服务器可能会在区域边界处划分位字符串标签。
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
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
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.
斜线和长度。基准指示器为“b”、“o”和“x”，分别表示基准2、8和16。长度对有效位进行计数，并且在虚线四元组之后必须介于1和32之间（含1和32），或者在其他形式之一之后必须介于1和256之间（含1和256）。如果省略长度，则虚线四元的隐式长度为32，或其他形式的隐式长度分别为提供的二进制、八进制或十六进制数字的1、3或4倍。
In augmented Backus-Naur form [ABNF],
在增广巴科斯诺尔形式[ABNF]，
bit-string-label = "\[" bit-spec "]"
位字符串标签=“\[“位规范”]”
bit-spec = bit-data [ "/" length ]
/ dotted-quad [ "/" slength ]
bit-spec = bit-data [ "/" length ]
/ dotted-quad [ "/" slength ]
bit-data = "x" 1*64HEXDIG
/ "o" 1*86OCTDIG
/ "b" 1*256BIT
bit-data = "x" 1*64HEXDIG
/ "o" 1*86OCTDIG
/ "b" 1*256BIT
dotted-quad = decbyte "." decbyte "." decbyte "." decbyte
虚线四元=decbyte.“decbyte.“decbyte.”decbyte.“decbyte
decbyte = 1*3DIGIT
decbyte = 1*3DIGIT
length = NZDIGIT *2DIGIT
长度=NZDIGIT*2数字
slength = NZDIGIT [ DIGIT ]
长度=NZDIGIT[位数]
OCTDIG = %x30-37
OCTDIG = %x30-37
NZDIGIT = %x31-39
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.
如果存在<length>，则<bit data>中的位数必须刚好足以包含<length>指定的位数。如果在最后的十六进制或八进制数字中有不重要的位，则它们必须为零。即使关联的<slength>小于24，一个<dottered quad>始终具有所有四个部分，但是，与其他形式一样，不重要的位必须为零。
Each number represented by a <decbyte> must be between 0 and 255, inclusive.
<decbyte>表示的每个数字必须介于0和255之间（包括0和255）。
The number represented by <length> must be between 1 and 256 inclusive.
<length>表示的数字必须介于1和256之间（含1和256）。
The number represented by <slength> must be between 1 and 32 inclusive.
<slength>表示的数字必须介于1和32之间（含1和32）。
When the textual form of a Bit-String Label is generated by machine, the length SHOULD be explicit, not implicit.
当机器生成位字符串标签的文本形式时，长度应该是显式的，而不是隐式的。
The following four textual forms represent the same Bit-String Label.
以下四种文本形式表示相同的位字符串标签。
\[b11010000011101]
\[o64072/14]
\[xd074/14]
\[208.116.0.0/14]
\[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.
以下表示两个连续的位字符串标签，它们表示DNS树中与上述任何单个位字符串标签相同的相对点。
\[b11101].\[o640]
\[b11101]。\[o640]
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.
二进制标签的有线形式和文本形式在将其分组为多个连续的位字符串标签方面都具有一定的灵活性。为了生成和检查DNS签名记录[DNSSEC]，二进制标签必须采用可预测的形式。此规范形式被定义为具有尽可能少的位字符串标签的形式，并且在该形式中，除了可能的第一个（最低有效）标签之外，任何连续位字符串标签序列中的所有标签都具有最大长度。
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.
例如，最多256个一位标签的任何序列的标准形式具有单位字符串标签，而513到768个一位标签的序列的标准形式具有三个位字符串标签，其中第二个和第三个包含256个标签位。
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].
域名[DNSSEC]的规范排序顺序扩展为包含二进制标签，如下所示。排序仍然是一个标签接一个标签，从最高到最低有效，其中标签现在可以是一位标签或标准（代码00）标签。任何一位标签在任何标准标签之前排序，0位标签在1位之前排序。按照[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
foo.example\[b1].foo.example\[b100].foo.example\[b101].foo.example bravo.\[b10].foo.example alpha.foo.example
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.
一位标签永远不会与任何其他类型的标签匹配。特别是，由单个ASCII字符“0”和“1”表示的DNS标签与由位值0和1表示的一位标签不匹配。
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.
wire表单中的零计数表示256位序列，不是为了优化该特定情况，而是为了使零位标签完全不可能存在。
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].
本文档定义了一种扩展标签类型，称为位字符串标签，并请求在[EDNS0]定义的空间中注册代码点000001二进制文件。
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].
适用于传统ASCII DNS标签的所有安全注意事项同样适用于二进制标签。第3.3节的规范化和排序规则允许DNS安全[DNSSEC]解决这些问题。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
[DNSIS] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[DNSIS]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
[DNSSEC] Eastlake, D., 3rd, C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997
[DNSSEC]Eastlake，D.，3rd，C.Kaufman，“域名系统安全扩展”，RFC 20651997年1月
[EDNS0] Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[EDNS0]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC26711999年8月。
[KWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997.
[KWORD]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Matt Crawford Fermilab MS 368 PO Box 500 Batavia, IL 60510 USA
Matt Crawford Fermilab MS 368美国伊利诺伊州巴达维亚500号邮政信箱60510
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Phone: +1 630 840-3461
EMail: crawdad@fnal.gov
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。