Network Working Group D. Eastlake 3rd
Request for Comments: 4343 Motorola Laboratories
Updates: 1034, 1035, 2181 January 2006
Category: Standards Track
Network Working Group D. Eastlake 3rd
Request for Comments: 4343 Motorola Laboratories
Updates: 1034, 1035, 2181 January 2006
Category: Standards Track
Domain Name System (DNS) Case Insensitivity Clarification
域名系统（DNS）案例不敏感澄清
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
Domain Name System (DNS) names are "case insensitive". This document explains exactly what that means and provides a clear specification of the rules. This clarification updates RFCs 1034, 1035, and 2181.
域名系统（DNS）名称“不区分大小写”。本文件准确解释了这意味着什么，并提供了规则的明确说明。本澄清更新了RFCs 1034、1035和2181。
Table of Contents
目录
1. Introduction ....................................................2
2. Case Insensitivity of DNS Labels ................................2
2.1. Escaping Unusual DNS Label Octets ..........................2
2.2. Example Labels with Escapes ................................3
3. Name Lookup, Label Types, and CLASS .............................3
3.1. Original DNS Label Types ...................................4
3.2. Extended Label Type Case Insensitivity Considerations ......4
3.3. CLASS Case Insensitivity Considerations ....................4
4. Case on Input and Output ........................................5
4.1. DNS Output Case Preservation ...............................5
4.2. DNS Input Case Preservation ................................5
5. Internationalized Domain Names ..................................6
6. Security Considerations .........................................6
7. Acknowledgements ................................................7
Normative References................................................7
Informative References..............................................8
1. Introduction ....................................................2
2. Case Insensitivity of DNS Labels ................................2
2.1. Escaping Unusual DNS Label Octets ..........................2
2.2. Example Labels with Escapes ................................3
3. Name Lookup, Label Types, and CLASS .............................3
3.1. Original DNS Label Types ...................................4
3.2. Extended Label Type Case Insensitivity Considerations ......4
3.3. CLASS Case Insensitivity Considerations ....................4
4. Case on Input and Output ........................................5
4.1. DNS Output Case Preservation ...............................5
4.2. DNS Input Case Preservation ................................5
5. Internationalized Domain Names ..................................6
6. Security Considerations .........................................6
7. Acknowledgements ................................................7
Normative References................................................7
Informative References..............................................8
The Domain Name System (DNS) is the global hierarchical replicated distributed database system for Internet addressing, mail proxy, and other information. Each node in the DNS tree has a name consisting of zero or more labels [STD13, RFC1591, RFC2606] that are treated in a case insensitive fashion. This document clarifies the meaning of "case insensitive" for the DNS. This clarification updates RFCs 1034, 1035 [STD13], and [RFC2181].
域名系统（DNS）是用于Internet寻址、邮件代理和其他信息的全局分层复制分布式数据库系统。DNS树中的每个节点都有一个由零个或多个标签[STD13、RFC1591、RFC2606]组成的名称，这些标签以不区分大小写的方式处理。本文档澄清了DNS“不区分大小写”的含义。本澄清更新了RFCs 1034、1035[STD13]和[RFC2181]。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
DNS was specified in the era of [ASCII]. DNS names were expected to look like most host names or Internet email address right halves (the part after the at-sign, "@") or to be numeric, as in the in-addr.arpa part of the DNS name space. For example,
DNS是在[ASCII]时代指定的。DNS名称应与大多数主机名或Internet电子邮件地址的右半部分（at符号“@”后的部分）相似，或为数字，如DNS名称空间的in-addr.arpa部分。例如
foo.example.net. aol.com. www.gnu.ai.mit.edu. or 69.2.0.192.in-addr.arpa.
foo.example.net。美国在线。www.gnu.ai.mit.edu。或69.2.0.192.in-addr.arpa。
Case-varied alternatives to the above [RFC3092] would be DNS names like
上述[RFC3092]的不同大小写备选方案是DNS名称，如
Foo.ExamplE.net. AOL.COM. WWW.gnu.AI.mit.EDU. or 69.2.0.192.in-ADDR.ARPA.
Foo.ExamplE.net。美国在线。WWW.gnu.AI.mit.EDU。或69.2.0.192.in-ADDR.ARPA。
However, the individual octets of which DNS names consist are not limited to valid ASCII character codes. They are 8-bit bytes, and all values are allowed. Many applications, however, interpret them as ASCII characters.
但是，DNS名称包含的单个八位字节不限于有效的ASCII字符码。它们是8位字节，所有值都是允许的。然而，许多应用程序将它们解释为ASCII字符。
In Master Files [STD13] and other human-readable and -writable ASCII contexts, an escape is needed for the byte value for period (0x2E, ".") and all octet values outside of the inclusive range from 0x21 ("!") to 0x7E ("~"). That is to say, 0x2E and all octet values in the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
在主文件[STD13]和其他人类可读写的ASCII上下文中，周期（0x2E，“.”）的字节值和0x21（“！”）到0x7E（“~”）范围之外的所有八位字节值都需要转义。也就是说，0x2E和0x00到0x20以及0x7F到0xFF这两个包含范围内的所有八位组值。
One typographic convention for octets that do not correspond to an ASCII printing graphic is to use a back-slash followed by the value of the octet as an unsigned integer represented by exactly three decimal digits.
对于与ASCII打印图形不对应的八位字节，一种排版惯例是使用反斜杠，后跟八位字节的值，作为正好由三个十进制数字表示的无符号整数。
The same convention can be used for printing ASCII characters so that they will be treated as a normal label character. This includes the back-slash character used in this convention itself, which can be expressed as \092 or \\, and the special label separator period ("."), which can be expressed as and \046 or \. It is advisable to avoid using a backslash to quote an immediately following non-printing ASCII character code to avoid implementation difficulties.
同样的约定可用于打印ASCII字符，以便将其视为普通标签字符。这包括此约定本身中使用的反斜杠字符（可表示为\092或\），以及特殊标签分隔符句点（“.”），可表示为和\046或\。建议避免使用反斜杠引用紧跟其后的非打印ASCII字符代码，以避免实现困难。
A back-slash followed by only one or two decimal digits is undefined. A back-slash followed by four decimal digits produces two octets, the first octet having the value of the first three digits considered as a decimal number, and the second octet being the character code for the fourth decimal digit.
反斜杠后面只有一个或两个十进制数字是未定义的。后接四位十进制数字的反斜杠产生两个八位字节，第一个八位字节的前三位数值被视为十进制数，第二个八位字节是第四位十进制数字的字符代码。
The first example below shows embedded spaces and a period (".") within a label. The second one shows a 5-octet label where the second octet has all bits zero, the third is a backslash, and the fourth octet has all bits one.
下面的第一个示例显示了标签中嵌入的空格和句点（“.”）。第二个显示一个5个八位的标签，其中第二个八位的所有位为零，第三个是反斜杠，第四个八位的所有位为一。
Donald\032E\.\032Eastlake\0323rd.example. and a\000\\\255z.example.
唐纳德\032E\。\032Eastlake\0323.example。和一个\000\\\255z.example。
According to the original DNS design decision, comparisons on name lookup for DNS queries should be case insensitive [STD13]. That is to say, a lookup string octet with a value in the inclusive range from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the identical value and also match the corresponding value in the inclusive range from 0x61 to 0x7A, the lowercase ASCII letters. A lookup string octet with a lowercase ASCII letter value MUST similarly match the identical value and also match the corresponding value in the uppercase ASCII letter range.
根据最初的DNS设计决策，DNS查询的名称查找比较应不区分大小写[STD13]。也就是说，值在0x41到0x5A（大写ASCII字母）范围内的查找字符串八位字节必须与相同的值匹配，并且还必须与0x61到0x7A（小写ASCII字母）范围内的对应值匹配。具有小写ASCII字母值的查找字符串八位字节必须类似地匹配相同的值，并且还必须匹配大写ASCII字母范围中的相应值。
(Historical note: The terms "uppercase" and "lowercase" were invented after movable type. The terms originally referred to the two font trays for storing, in partitioned areas, the different physical type elements. Before movable type, the nearest equivalent terms were "majuscule" and "minuscule".)
（历史注释：术语“大写”和“小写”是在movable type之后发明的。这些术语最初指的是两个字体托盘，用于在分区区域存储不同的物理类型元素。在movable type之前，最接近的等效术语是“majuscule”和“minusile”。）
One way to implement this rule would be to subtract 0x20 from all octets in the inclusive range from 0x61 to 0x7A before comparing octets. Such an operation is commonly known as "case folding", but implementation via case folding is not required. Note that the DNS case insensitivity does NOT correspond to the case folding specified in [ISO-8859-1] or [ISO-8859-2]. For example, the octets 0xDD (\221) and 0xFD (\253) do NOT match, although in other contexts, where they are interpreted as the upper- and lower-case version of "Y" with an acute accent, they might.
实现此规则的一种方法是在比较八位字节之前，从0x61到0x7A的包含范围内的所有八位字节中减去0x20。这种操作通常称为“案例折叠”，但不需要通过案例折叠实现。请注意，DNS大小写不敏感与[ISO-8859-1]或[ISO-8859-2]中规定的大小写折叠不对应。例如，八位字节0xDD（\221）和0xFD（\253）不匹配，但在其他上下文中，如果它们被解释为带有尖锐重音的“Y”的大小写版本，则它们可能不匹配。
DNS labels in wire-encoded names have a type associated with them. The original DNS standard [STD13] had only two types: ASCII labels, with a length from zero to 63 octets, and indirect (or compression) labels, which consist of an offset pointer to a name location elsewhere in the wire encoding on a DNS message. (The ASCII label of length zero is reserved for use as the name of the root node of the name tree.) ASCII labels follow the ASCII case conventions described herein and, as stated above, can actually contain arbitrary byte values. Indirect labels are, in effect, replaced by the name to which they point, which is then treated with the case insensitivity rules in this document.
有线编码名称中的DNS标签具有与其关联的类型。最初的DNS标准[STD13]只有两种类型：ASCII标签（长度从0到63个八位字节）和间接（或压缩）标签（由指向DNS消息上有线编码中其他位置的名称位置的偏移指针组成）。（长度为零的ASCII标签保留用作名称树根节点的名称。）ASCII标签遵循本文所述的ASCII大小写约定，如上所述，实际上可以包含任意字节值。实际上，间接标签由它们所指向的名称替换，然后在本文档中使用大小写不敏感规则处理该名称。
DNS was extended by [RFC2671] so that additional label type numbers would be available. (The only such type defined so far is the BINARY type [RFC2673], which is now Experimental [RFC3363].)
DNS由[RFC2671]扩展，因此可以使用其他标签类型编号。（到目前为止，唯一定义的此类类型是二进制类型[RFC2673]，它现在是实验性的[RFC3363]。）
The ASCII case insensitivity conventions only apply to ASCII labels; that is to say, label type 0x0, whether appearing directly or invoked by indirect labels.
ASCII大小写不敏感约定仅适用于ASCII标签；也就是说，标签类型0x0，无论是直接显示还是由间接标签调用。
As described in [STD13] and [RFC2929], DNS has an additional axis for data location called CLASS. The only CLASS in global use at this time is the "IN" (Internet) CLASS.
如[STD13]和[RFC2929]所述，DNS有一个额外的数据位置轴，称为类。目前全球使用的唯一类是“in”（互联网）类。
The handling of DNS label case is not CLASS dependent. With the original design of DNS, it was intended that a recursive DNS resolver be able to handle new CLASSes that were unknown at the time of its implementation. This requires uniform handling of label case insensitivity. Should it become desirable, for example, to allocate a CLASS with "case sensitive ASCII labels", it would be necessary to allocate a new label type for these labels.
DNS标签大小写的处理不依赖于类。在DNS的原始设计中，递归DNS解析器可以处理在实现时未知的新类。这需要对标签大小写不敏感进行统一处理。例如，如果需要分配具有“区分大小写的ASCII标签”的类，则有必要为这些标签分配新的标签类型。
While ASCII label comparisons are case insensitive, [STD13] says case MUST be preserved on output and preserved when convenient on input. However, this means less than it would appear, since the preservation of case on output is NOT required when output is optimized by the use of indirect labels, as explained below.
虽然ASCII标签比较不区分大小写，但[STD13]表示输出时必须保留大小写，输入时必须方便地保留大小写。然而，这意味着比看起来要少，因为当通过使用间接标签优化输出时，不需要保留输出的大小写，如下所述。
[STD13] views the DNS namespace as a node tree. ASCII output is as if a name were marshaled by taking the label on the node whose name is to be output, converting it to a typographically encoded ASCII string, walking up the tree outputting each label encountered, and preceding all labels but the first with a period ("."). Wire output follows the same sequence, but each label is wire encoded, and no periods are inserted. No "case conversion" or "case folding" is done during such output operations, thus "preserving" case. However, to optimize output, indirect labels may be used to point to names elsewhere in the DNS answer. In determining whether the name to be pointed to (for example, the QNAME) is the "same" as the remainder of the name being optimized, the case insensitive comparison specified above is done. Thus, such optimization may easily destroy the output preservation of case. This type of optimization is commonly called "name compression".
[STD13]将DNS命名空间视为节点树。ASCII输出就好像是通过在要输出名称的节点上获取标签，将其转换为印刷编码的ASCII字符串，在树上遍历输出遇到的每个标签，并在除第一个标签之外的所有标签前面加上句点（“.”）来封送名称。导线输出遵循相同的顺序，但每个标签都是导线编码的，并且不插入句点。在这样的输出操作期间，不进行“大小写转换”或“大小写折叠”，因此“保留”大小写。但是，为了优化输出，可以使用间接标签来指向DNS应答中其他位置的名称。在确定要指向的名称（例如，QNAME）是否与正在优化的名称的其余部分“相同”时，将执行上面指定的不区分大小写的比较。因此，这种优化很容易破坏case的输出保存。这种类型的优化通常称为“名称压缩”。
Originally, DNS data came from an ASCII Master File as defined in [STD13] or a zone transfer. DNS Dynamic update and incremental zone transfers [RFC1995] have been added as a source of DNS data [RFC2136, RFC3007]. When a node in the DNS name tree is created by any of such inputs, no case conversion is done. Thus, the case of ASCII labels is preserved if they are for nodes being created. However, when a name label is input for a node that already exists in DNS data being held, the situation is more complex. Implementations are free to retain the case first loaded for such a label, to allow new input to override the old case, or even to maintain separate copies preserving the input case.
最初，DNS数据来自[STD13]中定义的ASCII主文件或区域传输。DNS动态更新和增量区域传输[RFC1995]已添加为DNS数据源[RFC2136，RFC3007]。当DNS名称树中的节点由任何此类输入创建时，不会进行大小写转换。因此，如果ASCII标签用于正在创建的节点，则保留其情况。但是，当为已存在于所持有的DNS数据中的节点输入名称标签时，情况更为复杂。实现可以自由地保留为此类标签首先加载的案例，允许新输入覆盖旧案例，甚至可以维护单独的副本来保留输入案例。
For example, if data with owner name "foo.bar.example" [RFC3092] is loaded and then later data with owner name "xyz.BAR.example" is input, the name of the label on the "bar.example" node (i.e., "bar") might or might not be changed to "BAR" in the DNS stored data. Thus, later retrieval of data stored under "xyz.bar.example" in this case can use "xyz.BAR.example" in all returned data, use "xyz.bar.example" in all returned data, or even, when more than one RR is being returned, use a mixture of these two capitalizations. This last case
例如，如果加载了所有者名称为“foo.bar.example”[RFC3092]的数据，然后输入了所有者名称为“xyz.bar.example”的后续数据，则在DNS存储数据中，“bar.example”节点（即“bar”）上的标签名称可能会更改为“bar”，也可能不会更改为“bar”。因此，在本例中，以后检索存储在“xyz.bar.example”下的数据时，可以在所有返回的数据中使用“xyz.bar.example”，在所有返回的数据中使用“xyz.bar.example”，甚至在返回多个RR时，可以混合使用这两种大写形式。这是最后一个案例
is unlikely, as optimization of answer length through indirect labels tends to cause only one copy of the name tail ("bar.example" or "BAR.example") to be used for all returned RRs. Note that none of this has any effect on the number or completeness of the RR set returned, only on the case of the names in the RR set returned.
不太可能，因为通过间接标签优化答案长度往往会导致所有返回的RRs只使用名称尾部（“bar.example”或“bar.example”）的一个副本。请注意，所有这些都不会对返回的RR集的数量或完整性产生任何影响，只会对返回的RR集中的名称产生影响。
The same considerations apply when inputting multiple data records with owner names differing only in case. For example, if an "A" record is the first resource record stored under owner name "xyz.BAR.example" and then a second "A" record is stored under "XYZ.BAR.example", the second MAY be stored with the first (lower case initial label) name, the second MAY override the first so that only an uppercase initial label is retained, or both capitalizations MAY be kept in the DNS stored data. In any case, a retrieval with either capitalization will retrieve all RRs with either capitalization.
当输入多个数据记录时，相同的注意事项也适用，这些记录的所有者名称仅在大小写上有所不同。例如，如果“A”记录是存储在所有者名称“xyz.BAR.example”下的第一个资源记录，然后第二个“A”记录存储在“xyz.BAR.example”下，则第二个“A”记录可以与第一个（小写初始标签）名称一起存储，第二个“A”记录可以覆盖第一个，以便只保留大写初始标签，或者这两种资本化都可以保存在DNS存储的数据中。在任何情况下，任何一种资本化的检索都将检索任何一种资本化的所有RRs。
Note that the order of insertion into a server database of the DNS name tree nodes that appear in a Master File is not defined so that the results of inconsistent capitalization in a Master File are unpredictable output capitalization.
请注意，主文件中出现的DNS名称树节点插入服务器数据库的顺序没有定义，因此主文件中不一致的大小写会导致无法预测的输出大小写。
A scheme has been adopted for "internationalized domain names" and "internationalized labels" as described in [RFC3490, RFC3454, RFC3491, and RFC3492]. It makes most of [UNICODE] available through a separate application level transformation from internationalized domain name to DNS domain name and from DNS domain name to internationalized domain name. Any case insensitivity that internationalized domain names and labels have varies depending on the script and is handled entirely as part of the transformation described in [RFC3454] and [RFC3491], which should be seen for further details. This is not a part of the DNS as standardized in STD 13.
已采用[RFC3490、RFC3454、RFC3491和RFC3492]中所述的“国际化域名”和“国际化标签”方案。它通过从国际化域名到DNS域名以及从DNS域名到国际化域名的单独应用程序级转换，使大部分[UNICODE]可用。国际化域名和标签的任何大小写不敏感都因脚本而异，并且完全作为[RFC3454]和[RFC3491]中描述的转换的一部分进行处理，有关更多详细信息，请参见。这不是STD 13中标准化的DNS的一部分。
The equivalence of certain DNS label types with case differences, as clarified in this document, can lead to security problems. For example, a user could be confused by believing that two domain names differing only in case were actually different names.
如本文档所述，某些DNS标签类型与大小写差异的等效性可能会导致安全问题。例如，用户可能会感到困惑，因为他们认为两个域名只是大小写不同，实际上是不同的名称。
Furthermore, a domain name may be used in contexts other than the DNS. It could be used as a case sensitive index into some database or file system. Or it could be interpreted as binary data by some integrity or authentication code system. These problems can usually be handled by using a standardized or "canonical" form of the DNS
此外，域名可以在DNS以外的上下文中使用。它可以用作某些数据库或文件系统的区分大小写的索引。或者，它可以被某些完整性或身份验证代码系统解释为二进制数据。这些问题通常可以通过使用标准化或“规范化”形式的DNS来处理
ASCII type labels; that is, always mapping the ASCII letter value octets in ASCII labels to some specific pre-chosen case, either uppercase or lower case. An example of a canonical form for domain names (and also a canonical ordering for them) appears in Section 6 of [RFC4034]. See also [RFC3597].
ASCII类型标签；也就是说，始终将ASCII标签中的ASCII字母值八位字节映射到某些特定的预先选择的大小写（大写或小写）。[RFC4034]第6节给出了域名的规范形式示例（以及域名的规范顺序）。另见[RFC3597]。
Finally, a non-DNS name may be stored into DNS with the false expectation that case will always be preserved. For example, although this would be quite rare, on a system with case sensitive email address local parts, an attempt to store two Responsible Person (RP) [RFC1183] records that differed only in case would probably produce unexpected results that might have security implications. That is because the entire email address, including the possibly case sensitive local or left-hand part, is encoded into a DNS name in a readable fashion where the case of some letters might be changed on output as described above.
最后，一个非DNS名称可能被存储到DNS中，错误地期望案例将始终被保留。例如，尽管这种情况非常罕见，但在具有区分大小写的电子邮件地址本地部分的系统上，尝试存储仅在大小写上不同的两个负责人（RP）[RFC1183]记录可能会产生可能具有安全影响的意外结果。这是因为整个电子邮件地址，包括可能区分大小写的本地或左手部分，以可读的方式编码为DNS名称，其中一些字母的大小写可能会在输出时改变，如上所述。
The contributions to this document by Rob Austein, Olafur Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana, Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman are gratefully acknowledged.
感谢Rob Austein、Olafur Gudmundsson、Daniel J.Anderson、Alan Barrett、Marc Blanchet、Dana、Andreas Gustafsson、Andrew Main、Thomas Narten和Scott Seligman对本文件的贡献。
Normative References
规范性引用文件
[ASCII] ANSI, "USA Standard Code for Information Interchange", X3.4, American National Standards Institute: New York, 1968.
[ASCII]ANSI，“美国信息交换标准代码”，X3.4，美国国家标准协会：纽约，1968年。
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[RFC1995]Ohta，M.，“DNS中的增量区域转移”，RFC 1995，1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 21811997年7月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]惠灵顿，B.，“安全域名系统（DNS）动态更新”，RFC 3007，2000年11月。
[RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003.
[RFC3597]Gustafsson，A.，“未知DNS资源记录（RR）类型的处理”，RFC3597，2003年9月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[STD13] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[STD13]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月。
Informative References
资料性引用
[ISO-8859-1] International Standards Organization, Standard for Character Encodings, Latin-1.
[ISO-8859-1]国际标准组织，字符编码标准，拉丁语-1。
[ISO-8859-2] International Standards Organization, Standard for Character Encodings, Latin-2.
[ISO-8859-2]国际标准组织，字符编码标准，拉丁语-2。
[RFC1183] Everhart, C., Mamakos, L., Ullmann, R., and P. Mockapetris, "New DNS RR Definitions", RFC 1183, October 1990.
[RFC1183]Everhart，C.，Mamakos，L.，Ullmann，R.，和P.Mockapetris，“新的DNS RR定义”，RFC 1183，1990年10月。
[RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, March 1994.
[RFC1591]Postel，J.，“域名系统结构和授权”，RFC15911994年3月。
[RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake 3rd，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年6月。
[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000.
[RFC2929]Eastlake 3rd，D.，Brunner Williams，E.，和B.Manning，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 29292000年9月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671]Vixie，P.，“DNS的扩展机制（EDNS0）”，RFC 26711999年8月。
[RFC2673] Crawford, M., "Binary Labels in the Domain Name System", RFC 2673, August 1999.
[RFC2673]克劳福德，M.，“域名系统中的二进制标签”，RFC2673，1999年8月。
[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology of "Foo"", RFC 3092, 1 April 2001.
[RFC3092]伊斯特莱克三世，D.，曼罗斯，C.，和E.雷蒙德，“Foo”的词源学”，RFC3092，2001年4月1日。
[RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. Hain, "Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)", RFC 3363, August 2002.
[RFC3363]Bush，R.，Durand，A.，Fink，B.，Gudmundsson，O.，和T.Hain，“代表域名系统（DNS）中的互联网协议版本6（IPv6）地址”，RFC 33632002年8月。
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
[RFC3454]Hoffman，P.和M.Blanchet，“国际化弦的准备（“stringprep”）”，RFC 3454，2002年12月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.
[RFC3491]Hoffman，P.和M.Blanchet，“Nameprep：国际化域名（IDN）的Stringprep配置文件”，RFC 3491，2003年3月。
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
[RFC3492]Costello，A.，“Punycode：应用程序中国际化域名的Unicode引导字符串编码（IDNA）”，RFC 3492，2003年3月。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/unicode/standard/standard.html>.
[UNICODE]UNICODE联盟，“UNICODE标准”<http://www.unicode.org/unicode/standard/standard.html>.
Author's Address
作者地址
Donald E. Eastlake 3rd Motorola Laboratories 155 Beaver Street Milford, MA 01757 USA
Donald E.Eastlake 3rd Motorola Laboratories美国马萨诸塞州米尔福德市海狸街155号，邮编01757
Phone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Phone: +1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。