Network Working Group A. Gustafsson
Request for Comments: 3597 Nominum Inc.
Category: Standards Track September 2003
Network Working Group A. Gustafsson
Request for Comments: 3597 Nominum Inc.
Category: Standards Track September 2003
Handling of Unknown DNS Resource Record (RR) Types
处理未知DNS资源记录（RR）类型
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
Extending the Domain Name System (DNS) with new Resource Record (RR) types currently requires changes to name server software. This document specifies the changes necessary to allow future DNS implementations to handle new RR types transparently.
使用新的资源记录（RR）类型扩展域名系统（DNS）当前需要更改名称服务器软件。本文档指定了必要的更改，以允许将来的DNS实现透明地处理新的RR类型。
The DNS is designed to be extensible to support new services through the introduction of new resource record (RR) types. In practice, deploying a new RR type currently requires changes to the name server software not only at the authoritative DNS server that is providing the new information and the client making use of it, but also at all slave servers for the zone containing it, and in some cases also at caching name servers and forwarders used by the client.
DNS被设计为可扩展的，通过引入新的资源记录（RR）类型来支持新的服务。实际上，部署新的RR类型目前不仅需要在提供新信息的权威DNS服务器和使用新信息的客户机上更改名称服务器软件，还需要在包含新信息的区域的所有从属服务器上更改，在某些情况下还需要在缓存客户机使用的名称服务器和转发器上更改。
Because the deployment of new server software is slow and expensive, the potential of the DNS in supporting new services has never been fully realized. This memo proposes changes to name servers and to procedures for defining new RR types aimed at simplifying the future deployment of new RR types.
由于新服务器软件的部署速度慢且成本高，DNS在支持新服务方面的潜力从未完全实现。本备忘录建议更改名称服务器和定义新RR类型的过程，以简化新RR类型的未来部署。
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 [RFC 2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC 2119]中所述进行解释。
An "RR of unknown type" is an RR whose RDATA format is not known to the DNS implementation at hand, and whose type is not an assigned QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor within the range reserved in that section for assignment only to QTYPEs and Meta-TYPEs. Such an RR cannot be converted to a type-specific text format, compressed, or otherwise handled in a type-specific way.
“未知类型的RR”是指其RDATA格式不为当前DNS实现所知的RR，并且其类型不是[RFC 2929]（第3.1节）中指定的已分配QTYPE或元类型，也不在该节中为仅分配给QTYPE和元类型而保留的范围内。这样的RR不能转换为特定类型的文本格式、压缩或以特定类型的方式处理。
In the case of a type whose RDATA format is class specific, an RR is considered to be of unknown type when the RDATA format for that combination of type and class is not known.
对于RDATA格式特定于类的类型，当类型和类组合的RDATA格式未知时，RR被视为未知类型。
To enable new RR types to be deployed without server changes, name servers and resolvers MUST handle RRs of unknown type transparently. That is, they must treat the RDATA section of such RRs as unstructured binary data, storing and transmitting it without change [RFC1123].
为了在不更改服务器的情况下部署新的RR类型，名称服务器和解析程序必须透明地处理未知类型的RR。也就是说，他们必须将此类RRs的RDATA部分视为非结构化二进制数据，存储和传输它而不作更改[RFC1123]。
To ensure the correct operation of equality comparison (section 6) and of the DNSSEC canonical form (section 7) when an RR type is known to some but not all of the servers involved, servers MUST also exactly preserve the RDATA of RRs of known type, except for changes due to compression or decompression where allowed by section 4 of this memo. In particular, the character case of domain names that are not subject to compression MUST be preserved.
为确保当部分但并非所有相关服务器都知道RR类型时，等式比较（第6节）和DNSSEC规范格式（第7节）的正确操作，服务器还必须准确保留已知类型的RRs的RDATA，但本备忘录第4节允许的压缩或解压缩引起的更改除外。特别是，必须保留未经压缩的域名的字符大小写。
RRs containing compression pointers in the RDATA part cannot be treated transparently, as the compression pointers are only meaningful within the context of a DNS message. Transparently copying the RDATA into a new DNS message would cause the compression pointers to point at the corresponding location in the new message, which now contains unrelated data. This would cause the compressed name to be corrupted.
在RDATA部分中包含压缩指针的RRs不能被透明地处理，因为压缩指针仅在DNS消息的上下文中才有意义。透明地将RDATA复制到新的DNS消息将导致压缩指针指向新消息中的相应位置，该位置现在包含不相关的数据。这将导致压缩名称损坏。
To avoid such corruption, servers MUST NOT compress domain names embedded in the RDATA of types that are class-specific or not well-known. This requirement was stated in [RFC1123] without defining the term "well-known"; it is hereby specified that only the RR types defined in [RFC1035] are to be considered "well-known".
为避免此类损坏，服务器不得压缩嵌入特定于类或未知类型的RDATA中的域名。[RFC1123]中说明了该要求，但未定义术语“众所周知”；特此规定，只有[RFC1035]中定义的RR类型被视为“已知”。
The specifications of a few existing RR types have explicitly allowed compression contrary to this specification: [RFC2163] specified that compression applies to the PX RR, and [RFC2535] allowed compression in SIG RRs and NXT RRs records. Since this specification disallows compression in these cases, it is an update to [RFC2163] (section 4) and [RFC2535] (sections 4.1.7 and 5.2).
与本规范相反，一些现有RR类型的规范明确允许压缩：[RFC2163]指定压缩适用于PX RR，[RFC2535]允许压缩SIG RRs和NXT RRs记录。由于本规范不允许在这些情况下进行压缩，因此它是对[RFC2163]（第4节）和[RFC2535]（第4.1.7和5.2节）的更新。
Receiving servers MUST decompress domain names in RRs of well-known type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX, NXT, NAPTR, and SRV (although the current specification of the SRV RR in [RFC2782] prohibits compression, [RFC2052] mandated it, and some servers following that earlier specification are still in use).
接收服务器必须解压缩已知类型的RRs中的域名，并且还应该解压缩RP、AFSDB、RT、SIG、PX、NXT、NAPTR和SRV类型的RRs（尽管[RFC2782]中SRV RR的当前规范禁止压缩，[RFC2052]强制进行压缩，并且遵循该早期规范的一些服务器仍在使用）。
Future specifications for new RR types that contain domain names within their RDATA MUST NOT allow the use of name compression for those names, and SHOULD explicitly state that the embedded domain names MUST NOT be compressed.
在RDATA中包含域名的新RR类型的未来规范不得允许对这些名称使用名称压缩，并应明确说明不得压缩嵌入的域名。
As noted in [RFC1123], the owner name of an RR is always eligible for compression.
如[RFC1123]中所述，RR的所有者名称始终符合压缩条件。
In the "type" field of a master file line, an unknown RR type is represented by the word "TYPE" immediately followed by the decimal RR type number, with no intervening whitespace. In the "class" field, an unknown class is similarly represented as the word "CLASS" immediately followed by the decimal class number.
在主文件行的“类型”字段中，未知的RR类型由单词“type”表示，紧跟其后的是十进制RR类型编号，中间没有空格。在“类”字段中，未知类类似地表示为紧跟十进制类编号的单词“类”。
This convention allows types and classes to be distinguished from each other and from TTL values, allowing the "[<TTL>] [<class>] <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of [RFC1035] to both be unambiguously parsed.
此约定允许将类型和类彼此区分开来并与TTL值区分开来，从而允许对[RFC1035]的“[<TTL>][<class>]<type><RDATA>”和“[<class>][<TTL>]<type><RDATA>”形式进行明确的解析。
The RDATA section of an RR of unknown type is represented as a sequence of white space separated words as follows:
未知类型RR的RDATA部分表示为一系列空格分隔的单词，如下所示：
The special token \# (a backslash immediately followed by a hash sign), which identifies the RDATA as having the generic encoding defined herein rather than a traditional type-specific encoding.
特殊标记\#（紧跟哈希符号的反斜杠），它将RDATA标识为具有此处定义的通用编码，而不是传统的特定于类型的编码。
An unsigned decimal integer specifying the RDATA length in octets.
以八位字节为单位指定RDATA长度的无符号十进制整数。
Zero or more words of hexadecimal data encoding the actual RDATA field, each containing an even number of hexadecimal digits.
编码实际RDATA字段的零个或多个十六进制数据字，每个字包含偶数个十六进制数字。
If the RDATA is of zero length, the text representation contains only the \# token and the single zero representing the length.
如果RDATA的长度为零，则文本表示形式仅包含\#标记和表示长度的单个零。
An implementation MAY also choose to represent some RRs of known type using the above generic representations for the type, class and/or RDATA, which carries the benefit of making the resulting master file portable to servers where these types are unknown. Using the generic representation for the RDATA of an RR of known type can also be useful in the case of an RR type where the text format varies depending on a version, protocol, or similar field (or several) embedded in the RDATA when such a field has a value for which no text format is known, e.g., a LOC RR [RFC1876] with a VERSION other than 0.
实现还可以选择使用上述类型、类和/或RDATA的通用表示来表示一些已知类型的rr，这具有使生成的主文件可移植到这些类型未知的服务器的优点。在RR类型的情况下，使用已知类型RR的RDATA的通用表示也很有用，其中文本格式根据嵌入RDATA中的版本、协议或类似字段（或多个）而变化，而此类字段的值未知，例如，版本不是0的LOC RR[RFC1876]。
Even though an RR of known type represented in the \# format is effectively treated as an unknown type for the purpose of parsing the RDATA text representation, all further processing by the server MUST treat it as a known type and take into account any applicable type-specific rules regarding compression, canonicalization, etc.
即使以\#格式表示的已知类型的RR在解析RDATA文本表示时被有效地视为未知类型，服务器的所有进一步处理都必须将其视为已知类型，并考虑与压缩、规范化等相关的任何适用的特定类型规则。
The following are examples of RRs represented in this manner, illustrating various combinations of generic and type-specific encodings for the different fields of the master file format:
以下是以这种方式表示的rr的示例，说明了主文件格式的不同字段的通用和类型特定编码的各种组合：
a.example. CLASS32 TYPE731 \# 6 abcd ( ef 01 23 45 ) b.example. HS TYPE62347 \# 0 e.example. IN A \# 4 0A000001 e.example. CLASS1 TYPE1 10.0.0.2
a、 例如。CLASS32类型731\#6 abcd（ef 01 23 45）b.示例。HS类型62347\#0 e.示例。在\#4 0A000001 e.示例中。类别1类型10.0.0.2
Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs to be compared for equality. Two RRs of the same unknown type are considered equal when their RDATA is bitwise equal. To ensure that the outcome of the comparison is identical whether the RR is known to the server or not, specifications for new RR types MUST NOT specify type-specific comparison rules.
某些DNS协议，尤其是动态更新[RFC2136]，要求比较RRs是否相等。当两个相同未知类型的RRs的RDATA按位相等时，它们被视为相等。为了确保无论服务器是否知道RR，比较结果都是相同的，新RR类型的规范不得指定特定于类型的比较规则。
This implies that embedded domain names, being included in the overall bitwise comparison, are compared in a case-sensitive manner.
这意味着包含在整体按位比较中的嵌入式域名将以区分大小写的方式进行比较。
As a result, when a new RR type contains one or more embedded domain names, it is possible to have multiple RRs owned by the same name that differ only in the character case of the embedded domain name(s). This is similar to the existing possibility of multiple TXT records differing only in character case, and not expected to cause any problems in practice.
因此，当新的RR类型包含一个或多个嵌入式域名时，可能会有多个RRs属于同一个名称，而这些RRs仅在嵌入式域名的字符大小写上有所不同。这类似于多个TXT记录仅在字符大小写上有所不同的现有可能性，并且在实践中预计不会导致任何问题。
DNSSEC defines a canonical form and ordering for RRs [RFC2535] (section 8.1). In that canonical form, domain names embedded in the RDATA are converted to lower case.
DNSSEC定义了RRs[RFC2535]的规范形式和顺序（第8.1节）。在这种规范形式中，嵌入RDATA中的域名被转换为小写。
The downcasing is necessary to ensure the correctness of DNSSEC signatures when case distinctions in domain names are lost due to compression, but since it requires knowledge of the presence and position of embedded domain names, it cannot be applied to unknown types.
当域名中的大小写区分因压缩而丢失时，下框是确保DNSSEC签名正确性所必需的，但由于它需要了解嵌入域名的存在和位置，因此不能应用于未知类型。
To ensure continued consistency of the canonical form of RR types where compression is allowed, and for continued interoperability with existing implementations that already implement the [RFC2535] canonical form and apply it to their known RR types, the canonical form remains unchanged for all RR types whose whose initial publication as an RFC was prior to the initial publication of this specification as an RFC (RFC 3597).
为了确保允许压缩的RR类型的规范形式的持续一致性，以及与已经实现[RFC2535]规范形式并将其应用于其已知RR类型的现有实现的持续互操作性，所有RR类型的规范形式保持不变，其初始发布为RFC的时间早于本规范初始发布为RFC（RFC 3597）的时间。
As a courtesy to implementors, it is hereby noted that the complete set of such previously published RR types that contain embedded domain names, and whose DNSSEC canonical form therefore involves downcasing according to the DNS rules for character comparisons, consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, and A6.
作为对实施者的一种礼遇，特此注意，包含嵌入式域名且其DNSSEC规范形式因此涉及根据用于字符比较的DNS规则进行降级的完整的先前发布的RR类型集合包括RR类型NS、MD、MF、CNAME、SOA、MB、MG、MR、PTR、HINFO、MINFO、MX、，HINFO、RP、AFSDB、RT、SIG、PX、NXT、NAPTR、KX、SRV、DNAME和A6。
This document specifies that for all other RR types (whether treated as unknown types or treated as known types according to an RR type definition RFC more recent than RFC 3597), the canonical form is such that no downcasing of embedded domain names takes place, and otherwise identical to the canonical form specified in [RFC2535] section 8.1.
本文件规定，对于所有其他RR类型（根据比RFC 3597更新的RR类型定义，无论是被视为未知类型还是被视为已知类型），规范形式应确保不会出现嵌入式域名的降级，并且与[RFC2535]第8.1节中规定的规范形式相同。
Note that the owner name is always set to lower case according to the DNS rules for character comparisons, regardless of the RR type.
请注意，根据用于字符比较的DNS规则，所有者名称始终设置为小写，而与RR类型无关。
The DNSSEC canonical RR ordering is as specified in [RFC2535] section 8.3, where the octet sequence is the canonical form as revised by this specification.
DNSSEC规范RR顺序如[RFC2535]第8.3节所述，其中八位组序列是本规范修订的规范形式。
Unknown RR types cause no additional section processing. Future RR type specifications MAY specify type-specific additional section processing rules, but any such processing MUST be optional as it can only be performed by servers for which the RR type in case is known.
未知的RR类型不会导致额外的节处理。未来的RR类型规范可能会指定特定于类型的附加节处理规则，但任何此类处理都必须是可选的，因为它只能由已知案例中RR类型的服务器执行。
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
This specification is not believed to cause any new security problems, nor to solve any existing ones.
本规范不会导致任何新的安全问题，也不会解决任何现有问题。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实施和规范”，STD 13，RFC 1035，1987年11月。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，Ed.“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[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月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535]Eastlake，D.，“域名系统安全扩展”，RFC25351999年3月。
[RFC2163] Allocchio, C., "Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM)", RFC 2163, January 1998.
[RFC2163]Allocchio，C.，“使用Internet DNS分发符合混频器的全局地址映射（MCGAM）”，RFC 2163，1998年1月。
[RFC2929] Eastlake, D., Brunner-Williams, E. and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000.
[RFC2929]Eastlake，D.，Brunner Williams，E.和B.Manning，“域名系统（DNS）IANA注意事项”，BCP 42，RFC 29292000年9月。
[RFC1876] Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A Means for Expressing Location Information in the Domain Name System", RFC 1876, January 1996.
[RFC1876]Davis，C.，Vixie，P.，Goodwin，T.和I.Dickinson，“域名系统中表达位置信息的方法”，RFC1876，1996年1月。
[RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2052]Gulbrandsen，A.和P.Vixie，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2052，1996年10月。
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Ed.，Thomson，S.，Rekhter，Y.和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Andreas Gustafsson Nominum, Inc. 2385 Bay Rd Redwood City, CA 94063 USA
Andreas Gustafsson Nominum，Inc.美国加利福尼亚州红木市海湾路2385号，邮编94063
Phone: +1 650 381 6004
EMail: gson@nominum.com
Phone: +1 650 381 6004
EMail: gson@nominum.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。