Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 8553 Brandenburg InternetWorking
BCP: 222 March 2019
Updates: 2782, 3263, 3529, 3620, 3832,
3887, 3958, 4120, 4227, 4386,
4387, 4976, 5026, 5328, 5389,
5415, 5518, 5555, 5617, 5679,
5766, 5780, 5804, 5864, 5928,
6120, 6186, 6376, 6733, 6763,
7208, 7489, 8145
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 8553 Brandenburg InternetWorking
BCP: 222 March 2019
Updates: 2782, 3263, 3529, 3620, 3832,
3887, 3958, 4120, 4227, 4386,
4387, 4976, 5026, 5328, 5389,
5415, 5518, 5555, 5617, 5679,
5766, 5780, 5804, 5864, 5928,
6120, 6186, 6376, 6733, 6763,
7208, 7489, 8145
Category: Best Current Practice
ISSN: 2070-1721
DNS AttrLeaf Changes: Fixing Specifications That Use Underscored Node Names
DNS AttrLeaf更改：修复使用下划线节点名称的规范
Abstract
摘要
Using an underscore for a prefix creates a space for constrained interoperation of resource records. Original uses of an underscore character as a domain node name prefix were specified without the benefit of an IANA registry. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry for these names has now been defined by RFC 8552. However, the existing specifications that use underscored naming need to be modified in order to be in line with the new registry. This document specifies those changes. The changes preserve existing software and operational practice, while adapting the specifications for those practices to the newer underscore registry model.
使用下划线作为前缀会为资源记录的受限互操作创建空间。指定下划线字符作为域节点名称前缀的原始用途时，没有使用IANA注册表。这产生了一组完全不协调的名称创建活动，它们都来自同一名称空间。RFC 8552现已定义了这些名称的注册表。但是，需要修改使用下划线命名的现有规范，以便与新的注册表保持一致。本文档指定了这些更改。这些更改保留了现有的软件和操作实践，同时使这些实践的规范适应新的下划线注册表模型。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8553.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8553.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Underscored RRset Use in Specifications . . . . . . . . . . . 3
2.1. TXT RRset . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. SRV RRset . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. URI RRset . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Underscored Template Specifications . . . . . . . . . . . . . 7
3.1. SRV Specification Changes . . . . . . . . . . . . . . . . 7
3.2. URI Specification Changes . . . . . . . . . . . . . . . . 8
3.3. DNSSEC Signaling Specification Changes . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Underscored RRset Use in Specifications . . . . . . . . . . . 3
2.1. TXT RRset . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. SRV RRset . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. URI RRset . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Underscored Template Specifications . . . . . . . . . . . . . 7
3.1. SRV Specification Changes . . . . . . . . . . . . . . . . 7
3.2. URI Specification Changes . . . . . . . . . . . . . . . . 8
3.3. DNSSEC Signaling Specification Changes . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
Original uses of an underscore character as a domain node name [RFC1035] prefix, which creates a space for constrained interpretation of resource records, were specified without the benefit of an IANA registry [IANA-reg]. This produced an entirely uncoordinated set of name-creation activities, all drawing from the same namespace. A registry has now been defined (see Section 4 of [RFC8552]); the RFC that defined it discusses the background for the use of underscored domain names [RFC8552].
最初使用下划线字符作为域节点名[RFC1035]前缀，为资源记录的受限解释创建了空间，但没有使用IANA注册表[IANA reg]。这产生了一组完全不协调的名称创建活动，它们都来自同一名称空间。现已定义了注册中心（见[RFC8552]第4节）；定义它的RFC讨论了使用下划线域名的背景[RFC8552]。
The basic model for underscored name registration, as specified in [RFC8552], is to have each registry entry be unique in terms of the combination of a resource record type and a "global" (highest-level) underscored node name; that is, the node name beginning with an underscore that is the closest to the DNS root.
[RFC8552]中规定的带下划线名称注册的基本模型是，每个注册表项在资源记录类型和“全局”（最高级别）带下划线节点名称的组合方面是唯一的；也就是说，节点名称以最接近DNS根的下划线开头。
The specifications describing the existing uses of underscored naming do not reflect the existence of this integrated registry. For the new reader or the new editor of one of those documents, there is currently nothing signaling that the underscored name(s) defined in the document are now processed through an IANA registry. This document remedies that, by marking such a published document with an update that indicates the nature of the change.
描述下划线命名的现有用途的规范并不反映此集成注册表的存在。对于其中一个文档的新读者或新编辑，目前没有任何迹象表明文档中定义的带下划线的名称现在已通过IANA注册表进行处理。本文件通过在此类已发布文件上标记一个指示变更性质的更新来弥补上述缺陷。
Further, the documents that define the SRV [RFC2782] and URI [RFC7553] DNS resource records provide a meta-template for underscored name assignments, partially based on separate registries [RFC6335]. For the portion that selects the global (highest-level) underscored node name, this perpetuates uncoordinated assignment activities by separate technical specifications, out of the same namespace. This document remedies that by providing detail for revisions to the SRV and URI specifications to bring their use in line with the single, integrated "Underscored and Globally Scoped DNS Node Names" registry.
此外，定义SRV[RFC2782]和URI[RFC7553]DNS资源记录的文档为下划线名称分配提供了元模板，部分基于单独的注册表[RFC6335]。对于选择带下划线的全局（最高级别）节点名称的部分，这将通过不同的技术规范，在同一名称空间之外，使不协调的分配活动永久化。本文档通过提供SRV和URI规范修订的详细信息，使其使用符合单一、集成的“带下划线和全局范围的DNS节点名称”注册表，弥补了这一缺陷。
The result of these changes preserves existing software and operations practices while adapting the technical specifications to the newer underscore registry model.
这些更改的结果保留了现有的软件和操作实践，同时使技术规范适应较新的注册表模型。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
The use of underscored node names is specific to each RR TYPE that is being scoped. Each name defines a place but does not define the rules for what appears underneath that place, either as additional underscored naming or as a leaf node with resource records. Details for those rules are provided by specifications for individual RR TYPEs. The sections below describe the way that existing underscored names are used with the RR TYPEs that they name.
带下划线的节点名称的使用特定于要确定作用域的每个RR类型。每个名称都定义了一个位置，但没有定义该位置下面显示的内容的规则，可以是附加下划线命名，也可以是带有资源记录的叶节点。这些规则的详细信息由各个RR类型的规范提供。以下各节描述了现有下划线名称与它们命名的RR类型一起使用的方式。
NOTE - Documents falling into this category include: [RFC5518], [RFC5617], [RFC6120], [RFC6376], [RFC6763], [RFC7208], and [RFC7489].
注-此类文件包括：[RFC5518]、[RFC5617]、[RFC6120]、[RFC6376]、[RFC6763]、[RFC7208]和[RFC7489]。
This section provides a generic approach for changes to existing specifications that define straightforward use of underscored node names when scoping the use of a TXT RRset. The approach provides the information needed for adapting such specifications to the use of the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. Hence, the approach is meant both as an update to these existing specifications and as guidance for changes when those documents are revised.
本节提供了一种通用方法，用于更改现有规范，这些规范定义了在确定TXT RRset的使用范围时直接使用带下划线的节点名称。该方法提供了使此类规范适应IANA“带下划线和全局范围的DNS节点名称”注册表使用所需的信息[RFC8552]。因此，该方法既是对这些现有规范的更新，也是修订这些文件时的变更指南。
For any document that specifies the use of a TXT RRset under one or more underscored names, the global node name is expected to be registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. An effort has been made to locate existing documents that do this, to register the global underscored node names, and to list them in the initial set of names added to the registry.
对于指定在一个或多个下划线名称下使用TXT RRset的任何文档，全局节点名称应在IANA“下划线和全局作用域DNS节点名称”注册表中注册[RFC8552]。已作出努力，找到进行这项工作的现有文件，登记带下划线的全局节点名称，并将其列入添加到登记册的初始名称集中。
If a public specification defines use of a TXT RRset and calls for the use of an underscored node name, here is a template of suggested text for registering the global underscored node name -- the one closest to the root -- that can be used through the IANA Considerations section of the specification:
如果公共规范定义了TXT RRset的使用，并要求使用带下划线的节点名，那么下面是一个建议文本模板，用于注册全局带下划线的节点名（最接近根的节点名），可通过规范的IANA注意事项部分使用该模板：
"Per [RFC8552], please add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry:"
根据[RFC8552]，请将以下条目添加到“带下划线和全局作用域的DNS节点名称”注册表中：
+--------+----------------+-----------------------------------------+
| RR | _NODE NAME | Reference |
| Type | | |
+--------+----------------+-----------------------------------------+
| TXT | _{DNS node | {citation for the document making the |
| | name} | addition} |
+--------+----------------+-----------------------------------------+
+--------+----------------+-----------------------------------------+
| RR | _NODE NAME | Reference |
| Type | | |
+--------+----------------+-----------------------------------------+
| TXT | _{DNS node | {citation for the document making the |
| | name} | addition} |
+--------+----------------+-----------------------------------------+
Table 1: Entry for the "Underscored and Globally Scoped DNS Node Names" Registry for TXT RR Use
表1:TXT RR使用的“带下划线和全局作用域的DNS节点名称”注册表项
NOTE - Documents falling into this category include:
注-此类文件包括：
[RFC3263], [RFC3529], [RFC3620], [RFC3832], [RFC3887],
[RFC3958], [RFC4120], [RFC4227], [RFC4386], [RFC4387],
[RFC4976], [RFC5026], [RFC5328], [RFC5389], [RFC5415],
[RFC5555], [RFC5679], [RFC5766], [RFC5780], [RFC5804],
[RFC5864], [RFC5928], and [RFC6186].
[RFC3263], [RFC3529], [RFC3620], [RFC3832], [RFC3887],
[RFC3958], [RFC4120], [RFC4227], [RFC4386], [RFC4387],
[RFC4976], [RFC5026], [RFC5328], [RFC5389], [RFC5415],
[RFC5555], [RFC5679], [RFC5766], [RFC5780], [RFC5804],
[RFC5864], [RFC5928], and [RFC6186].
Specification of the SRV resource record [RFC2782] provides a template for use of underscored node names. The global node name is characterized as referencing the 'protocol' that is associated with SRV RRset usage.
SRV资源记录[RFC2782]的规范提供了一个使用下划线节点名称的模板。全局节点名称的特征是引用与SRV RRset使用相关联的“协议”。
This section provides a generic approach for changes to existing specifications that define the use of an SRV RRset. The approach provides the information needed for adapting such specifications to the use of the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. Hence, the approach is meant both as an update to these existing specifications and as guidance for changes when those documents are revised.
本节提供了对定义SRV RRset使用的现有规范进行更改的通用方法。该方法提供了使此类规范适应IANA“带下划线和全局范围的DNS节点名称”注册表使用所需的信息[RFC8552]。因此，该方法既是对这些现有规范的更新，也是修订这些文件时的变更指南。
For any document that specifies the use of an SRV RRset, the global ('protocol') underscored node name is expected to be registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. An effort has been made to locate existing documents that do this, to register the global underscored node names, and to list them in the initial set of names added to the registry.
对于任何指定使用SRV RRset的文档，需要在IANA“带下划线和全局作用域的DNS节点名称”注册表中注册带下划线的全局（“协议”）节点名称[RFC8552]。已作出努力，找到进行这项工作的现有文件，登记带下划线的全局节点名称，并将其列入添加到登记册的初始名称集中。
If a public specification defines use of an SRV RRset and calls for the use of an underscored node name, here is a template of suggested text for registering the global underscored node name -- the one closest to the root -- that can be used through the IANA Considerations section of the specification:
如果公共规范定义了SRV RRset的使用，并要求使用带下划线的节点名称，那么下面是一个建议文本模板，用于注册全局带下划线的节点名称（最接近根的名称），可通过规范的IANA注意事项部分使用该模板：
"Per [RFC8552], please add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry:
“根据[RFC8552]，请将以下条目添加到“带下划线和全局作用域的DNS节点名称”注册表中：
+--------+----------------------+-----------------------------------+
| RR | _NODE NAME | Reference |
| Type | | |
+--------+----------------------+-----------------------------------+
| SRV | _{DNS 'protocol' | {citation for the document making |
| | node name} | the addition} |
+--------+----------------------+-----------------------------------+
+--------+----------------------+-----------------------------------+
| RR | _NODE NAME | Reference |
| Type | | |
+--------+----------------------+-----------------------------------+
| SRV | _{DNS 'protocol' | {citation for the document making |
| | node name} | the addition} |
+--------+----------------------+-----------------------------------+
Table 2: Entry for the "Underscored and Globally Scoped DNS Node Names" Registry for SRV RR Use
表2:SRV RR使用的“带下划线和全局作用域的DNS节点名称”注册表项
Specification of the URI resource record [RFC7553] provides a template for use of underscored node names. The global node name is characterized as naming the 'protocol' that is associated with URI RR usage or by reversing an Enumservice sequence [RFC6117].
URI资源记录[RFC7553]的规范提供了一个使用下划线节点名称的模板。全局节点名称的特征是命名与URI RR使用相关联的“协议”，或通过反转Enumservice序列[RFC6117]。
This section provides a generic approach for changes to existing specifications that define use of a URI RRset. The approach provides the information needed for adapting such specifications to the use of the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. Hence, the approach is meant both as an update to these existing specifications and as guidance for changes when those documents are revised.
本节提供了一种通用方法，用于更改定义URI RRset使用的现有规范。该方法提供了使此类规范适应IANA“带下划线和全局范围的DNS节点名称”注册表使用所需的信息[RFC8552]。因此，该方法既是对这些现有规范的更新，也是修订这些文件时的变更指南。
For any document that specifies the use of a URI RRset, the global ('protocol' or highest-level Enumservice) underscored node name is expected to be registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552]. An effort has been made to locate existing documents that do this, to register the global underscored node names, and to list them in the initial set of names added to the registry.
对于任何指定使用URI RRset的文档，全局（‘协议’或最高级别Enumservice）下划线的节点名称应在IANA“下划线和全局作用域DNS节点名称”注册表中注册[RFC8552]。已作出努力，找到进行这项工作的现有文件，登记带下划线的全局节点名称，并将其列入添加到登记册的初始名称集中。
If a public specification defines use of a URI RRset and calls for the use of an underscored node name, here is a template of suggested text for registering the global underscored node name -- the one closest to the root -- that can be used through the IANA Considerations section of the specification:
如果公共规范定义了URI RRset的使用，并要求使用带下划线的节点名，那么下面是一个建议文本模板，用于注册全局带下划线的节点名（最接近根的节点名），可通过规范的IANA注意事项部分使用该模板：
"Per [RFC8552], please add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry:
“根据[RFC8552]，请将以下条目添加到“带下划线和全局作用域的DNS节点名称”注册表中：
+-------+----------------------------+------------------------------+
| RR | _NODE NAME | Reference |
| Type | | |
+-------+----------------------------+------------------------------+
| URI | _{DNS 'protocol' or | {citation for the document |
| | Enumservice node name} | making the addition} |
+-------+----------------------------+------------------------------+
+-------+----------------------------+------------------------------+
| RR | _NODE NAME | Reference |
| Type | | |
+-------+----------------------------+------------------------------+
| URI | _{DNS 'protocol' or | {citation for the document |
| | Enumservice node name} | making the addition} |
+-------+----------------------------+------------------------------+
Table 3: Entry for the "Underscored and Globally Scoped DNS Node Names" Registry for URI RR Use
表3:URI RR使用的“带下划线和全局作用域的DNS节点名称”注册表项
The specification for a domain name, under which an SRV resource record [RFC2782] appears, provides a template for use of underscored node names. The global underscored node name is characterized as indicating the 'protocol' that is associated with SRV RR usage.
出现SRV资源记录[RFC2782]的域名规范提供了使用带下划线节点名的模板。全局加下划线的节点名称表示与SRV RR使用相关联的“协议”。
The text of [RFC2782] is changed as described below. In addition, note that a normative reference to RFC 8552 is added to the References section of RFC 2782.
[RFC2782]的文本更改如下所述。此外，请注意，RFC 8552的规范性参考文件添加到RFC 2782的参考文件部分。
OLD:
旧的：
The format of the SRV RR
SRV-RR的格式
Here is the format of the SRV RR, whose DNS type code is 33: _Service._Proto.Name TTL Class SRV Priority Weight Port Target ... Proto The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Proto is case insensitive.
以下是SRV RR的格式，其DNS类型代码为33:_Service._Proto.Name TTL Class SRV优先级权重端口目标。。。Proto所需协议的符号名，前面加下划线（ux），以防止与自然界中发生的DNS标签发生冲突_TCP和_UDP目前是该字段最有用的值，尽管可以使用由指定号码或本地定义的任何名称（如服务）。Proto不区分大小写。
NEW:
新的：
The format of the SRV RR
SRV-RR的格式
Here is the format of the SRV RR, whose DNS type code is 33:
以下是SRV RR的格式，其DNS类型代码为33：
"_Service._Proto.Name TTL Class SRV Priority Weight Port Target"
“_服务._协议名TTL类SRV优先级权重端口目标”
_..._
_..._
Proto
原型
The symbolic name of the desired protocol with an underscore (e.g., "_name") prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field. The Proto is case insensitive.
所需协议的符号名，前面带有下划线（例如“_name”），以防止与自然界中发生的DNS标签发生冲突_TCP和_UDP目前是该字段最有用的值。Proto不区分大小写。
The SRV RRset 'protocol' (global) underscored node name SHOULD be registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552].
SRV RRset“协议”（全局）带下划线的节点名称应在IANA“带下划线和全局作用域的DNS节点名称”注册表中注册[RFC8552]。
Specification for the domain name (under which a URI resource record [RFC7553] occurs) is similar to that for the SRV resource record [RFC2782], although the text refers only to 'service' name, rather than distinguishing 'service' from 'protocol'. Further, the URI RR specification permits alternative underscored naming schemes:
域名规范（URI资源记录[RFC7553]出现在该域名下）与SRV资源记录[RFC2782]的规范类似，尽管文本仅提及“服务”名称，而不是区分“服务”和“协议”。此外，URI-RR规范允许替代的命名方案：
One matches what is used for SRV, with the global underscored node name called 'protocol'.
一个匹配用于SRV的内容，全局加下划线的节点名为“protocol”。
The other is based on a reversing of an Enumservice [RFC6117] sequence.
另一种是基于Enumservice[RFC6117]序列的反转。
Text of [RFC7553] is changed as described below. In addition, a normative reference to RFC 8552 is added to the References section of RFC 7553.
[RFC7553]的文本更改如下所述。此外，RFC 7553的参考文件部分增加了RFC 8552的规范性参考文件。
OLD:
旧的：
4.1. Owner Name, Class, and Type
4.1. 所有者名称、类和类型
The URI owner name is subject to special conventions.
URI所有者名称受特殊约定的约束。
Just like the SRV RR [RFC2782], the URI RR has service information
encoded in its owner name. In order to encode the service for a
specific owner name, one uses service parameters. Valid service
parameters are those registered by IANA in the "Service Name and
Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice
---
Registrations [RFC6117]. The Enumservice Registration parameters are
reversed (i.e., subtype(s) before type), prepended with an underscore
(_), and prepended to the owner name in separate labels. The
underscore is prepended to the service parameters to avoid collisions
with DNS labels that occur in nature, and the order is reversed to
make it possible to do delegations, if needed, to different zones
(and therefore providers of DNS).
Just like the SRV RR [RFC2782], the URI RR has service information
encoded in its owner name. In order to encode the service for a
specific owner name, one uses service parameters. Valid service
parameters are those registered by IANA in the "Service Name and
Transport Protocol Port Number Registry" [RFC6335] or as "Enumservice
---
Registrations [RFC6117]. The Enumservice Registration parameters are
reversed (i.e., subtype(s) before type), prepended with an underscore
(_), and prepended to the owner name in separate labels. The
underscore is prepended to the service parameters to avoid collisions
with DNS labels that occur in nature, and the order is reversed to
make it possible to do delegations, if needed, to different zones
(and therefore providers of DNS).
For example, suppose we are looking for the URI for a service with ENUM Service Parameter "A:B:C" for host example.com. Then we would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI").
例如，假设我们正在为host example.com查找带有枚举服务参数“a:B:C”的服务的URI。然后我们将查询（QNAME，QTYPE）=（“_C._B._A.example.com”，“URI”）。
As another example, suppose we are looking for the URI for a service with Service Name "A" and Transport Protocol "B" for host example.com. Then we would query for (QNAME,QTYPE)=("_A._B.example.com","URI").
作为另一个示例，假设我们正在寻找一个服务名为“a”的服务的URI，以及主机example.com的传输协议“B”。然后我们将查询（QNAME，QTYPE）=（“\u A.\u B.example.com”，“URI”）。
NEW:
新的：
4.1. Owner Name, Class, and Type
4.1. 所有者名称、类和类型
The URI owner name is subject to special conventions.
URI所有者名称受特殊约定的约束。
As for the SRV RRset [RFC2782], the URI RRset global (highest-level) underscored node name SHOULD be registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552].
对于SRV RRset[RFC2782]，URI RRset全局（最高级别）带下划线的节点名称应在IANA“带下划线和全局作用域的DNS节点名称”注册表[RFC8552]中注册。
Just like the SRV RRset, the URI RRset has service information encoded in its owner name. In order to encode the service for a specific owner name, one uses service parameters. Valid service parameters are:
与SRV RRset一样，URI RRset具有以其所有者名称编码的服务信息。为了为特定所有者名称编码服务，可以使用服务参数。有效的服务参数包括：
+ Those registered by IANA in the "Service Name and Transport Protocol Port Number Registry" [RFC6335]. The underscore is prepended to the service parameters to avoid collisions with
+ IANA在“服务名称和传输协议端口号注册表”[RFC6335]中注册的。下划线在服务参数前面，以避免与
DNS labels that occur in nature, and the order is reversed to make it possible to do delegations, if needed, to different zones (and therefore providers of DNS).
DNS标签出现在自然界中，并且顺序颠倒，以便在需要时可以委托给不同的区域（因此也可以委托给DNS的提供者）。
+ Those listed in "Enumservice Registrations" [RFC6117]. The Enumservice Registration parameters are reversed (i.e., subtype(s) before type), prepended with an underscore (e.g., "_name"), and prepended to the owner name in separate labels. The highest-level (global) underscored Enumservice name becomes the global name per RFC 8552 to register.
+ “Enumservice Registrations”[RFC6117]中列出的服务。Enumservice注册参数是反向的（即类型之前的子类型），以下划线（例如“_name”）作为前缀，并在单独的标签中作为所有者名称的前缀。根据RFC 8552，最高级别（全局）服务名称将成为要注册的全局名称。
For example, suppose we are looking for the URI for a service with ENUM Service Parameter "A:B:C" for host example.com. Then we would query for (QNAME,QTYPE)=("_C._B._A.example.com","URI").
例如，假设我们正在为host example.com查找带有枚举服务参数“a:B:C”的服务的URI。然后我们将查询（QNAME，QTYPE）=（“_C._B._A.example.com”，“URI”）。
As another example, suppose we are looking for the URI for a service with Service Name "A" and Transport Protocol "B" for host example.com. Then we would query for (QNAME,QTYPE)=("_A._B.example.com","URI").
作为另一个示例，假设我们正在寻找一个服务名为“a”的服务的URI，以及主机example.com的传输协议“B”。然后我们将查询（QNAME，QTYPE）=（“\u A.\u B.example.com”，“URI”）。
"Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)" [RFC8145] defines a use of DNS node names that effectively consumes all names beginning with the string "_ta-" when using the NULL RR in the query.
“DNS安全扩展（DNSSEC）中的信令信任锚知识”[RFC8145]定义了DNS节点名称的使用，该名称在查询中使用空RR时有效地使用以字符串“_ta-”开头的所有名称。
Text of Section 5.1, "Query Format", of RFC 8145 is changed as described below. In addition, a normative reference to RFC 8552 is added to the References section of RFC 8145.
RFC 8145第5.1节“查询格式”的文本更改如下所述。此外，RFC 8145的参考文件部分增加了RFC 8552的规范性参考文件。
OLD:
旧的：
For example, a validating DNS resolver ... QNAME=_ta-4444.
例如，正在验证的DNS解析程序。。。QNAME=_ta-4444。
NEW:
新的：
For example, a validating DNS resolver ... "QNAME=_ta-4444".
例如，正在验证的DNS解析程序。。。“QNAME=_ta-4444”。
Under the NULL RR, an entry is registered in the IANA "Underscored and Globally Scoped DNS Node Names" registry [RFC8552] for all node names beginning with "_ta-".
在空RR下，在IANA“带下划线和全局作用域的DNS节点名称”注册表[RFC8552]中注册以“_ta-”开头的所有节点名称的条目。
Although this document makes reference to IANA registries, it introduces no new IANA registries or procedures.
尽管本文件参考了IANA登记册，但并未介绍新的IANA登记册或程序。
This memo raises no security issues.
这份备忘录没有提出任何安全问题。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations", RFC 6117, DOI 10.17487/RFC6117, March 2011, <https://www.rfc-editor.org/info/rfc6117>.
[RFC6117]Hoenesen，B.，Mayrhofer，A.，和J.Livingood，“Enumservices的IANA注册：指南，模板和IANA注意事项”，RFC 6117，DOI 10.17487/RFC6117，2011年3月<https://www.rfc-editor.org/info/rfc6117>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<https://www.rfc-editor.org/info/rfc6335>.
[RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", RFC 7553, DOI 10.17487/RFC7553, June 2015, <https://www.rfc-editor.org/info/rfc7553>.
[RFC7553]Faltstrom，P.和O.Kolkman，“统一资源标识符（URI）DNS资源记录”，RFC 7553，DOI 10.17487/RFC7553，2015年6月<https://www.rfc-editor.org/info/rfc7553>.
[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)", RFC 8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc-editor.org/info/rfc8145>.
[RFC8145]Wessels，D.，Kumari，W.和P.Hoffman，“DNS安全扩展（DNSSEC）中的信令信任锚知识”，RFC8145DOI 10.17487/RFC81452017年4月<https://www.rfc-editor.org/info/rfc8145>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.
[RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.translate error, please retry
[IANA-reg] IANA, "Protocol Registries", <https://www.iana.org/protocols>.
[IANA reg]IANA，“协议注册”<https://www.iana.org/protocols>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<https://www.rfc-editor.org/info/rfc2782>.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, DOI 10.17487/RFC3263, June 2002, <https://www.rfc-editor.org/info/rfc3263>.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，DOI 10.17487/RFC3263，2002年6月<https://www.rfc-editor.org/info/rfc3263>.
[RFC3529] Harold, W., "Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3529, DOI 10.17487/RFC3529, April 2003, <https://www.rfc-editor.org/info/rfc3529>.
[RFC3529]Harold，W.“在块可扩展交换协议（BEEP）中使用可扩展标记语言远程过程调用（XML-RPC）”，RFC 3529，DOI 10.17487/RFC3529，2003年4月<https://www.rfc-editor.org/info/rfc3529>.
[RFC3620] New, D., "The TUNNEL Profile", RFC 3620, DOI 10.17487/RFC3620, October 2003, <https://www.rfc-editor.org/info/rfc3620>.
[RFC3620]New，D.，“隧道剖面”，RFC 3620，DOI 10.17487/RFC3620，2003年10月<https://www.rfc-editor.org/info/rfc3620>.
[RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV", RFC 3832, DOI 10.17487/RFC3832, July 2004, <https://www.rfc-editor.org/info/rfc3832>.
[RFC3832]Zhao，W.，Schulzrinne，H.，Guttman，E.，Bisdikian，C.，和W.Jerome，“通过DNS SRV在服务位置协议（SLP）中进行远程服务发现”，RFC 3832，DOI 10.17487/RFC3832，2004年7月<https://www.rfc-editor.org/info/rfc3832>.
[RFC3887] Hansen, T., "Message Tracking Query Protocol", RFC 3887, DOI 10.17487/RFC3887, September 2004, <https://www.rfc-editor.org/info/rfc3887>.
[RFC3887]Hansen，T.，“消息跟踪查询协议”，RFC 3887，DOI 10.17487/RFC3887，2004年9月<https://www.rfc-editor.org/info/rfc3887>.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, DOI 10.17487/RFC3958, January 2005, <https://www.rfc-editor.org/info/rfc3958>.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，DOI 10.17487/RFC3958，2005年1月<https://www.rfc-editor.org/info/rfc3958>.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <https://www.rfc-editor.org/info/rfc4120>.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC 4120，DOI 10.17487/RFC4120，2005年7月<https://www.rfc-editor.org/info/rfc4120>.
[RFC4227] O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 4227, DOI 10.17487/RFC4227, January 2006, <https://www.rfc-editor.org/info/rfc4227>.
[RFC4227]O'Tuathail，E.和M.Rose，“在块中使用简单对象访问协议（SOAP）可扩展交换协议（BEEP）”，RFC 4227，DOI 10.17487/RFC4227，2006年1月<https://www.rfc-editor.org/info/rfc4227>.
[RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key Infrastructure Repository Locator Service", RFC 4386, DOI 10.17487/RFC4386, February 2006, <https://www.rfc-editor.org/info/rfc4386>.
[RFC4386]Boeyen，S.和P.Hallam Baker，“互联网X.509公钥基础设施存储库定位服务”，RFC 4386，DOI 10.17487/RFC4386，2006年2月<https://www.rfc-editor.org/info/rfc4386>.
[RFC4387] Gutmann, P., Ed., "Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP", RFC 4387, DOI 10.17487/RFC4387, February 2006, <https://www.rfc-editor.org/info/rfc4387>.
[RFC4387]Gutmann，P.，Ed.“Internet X.509公钥基础设施操作协议：通过HTTP访问证书存储”，RFC 4387，DOI 10.17487/RFC4387，2006年2月<https://www.rfc-editor.org/info/rfc4387>.
[RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, DOI 10.17487/RFC4976, September 2007, <https://www.rfc-editor.org/info/rfc4976>.
[RFC4976]Jennings，C.，Mahy，R.，和A.Roach，“消息会话中继协议（MSRP）的中继扩展”，RFC 4976，DOI 10.17487/RFC4976，2007年9月<https://www.rfc-editor.org/info/rfc4976>.
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, DOI 10.17487/RFC5026, October 2007, <https://www.rfc-editor.org/info/rfc5026>.
[RFC5026]Giaretta，G.，Ed.，Kempf，J.，和V.Devarapalli，Ed.，“拆分场景中的移动IPv6引导”，RFC 5026，DOI 10.17487/RFC5026，2007年10月<https://www.rfc-editor.org/info/rfc5026>.
[RFC5328] Adolf, A. and P. MacAvock, "A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB)", RFC 5328, DOI 10.17487/RFC5328, September 2008, <https://www.rfc-editor.org/info/rfc5328>.
[RFC5328]Adolf，A.和P.MacAvock，“数字视频广播项目（DVB）的统一资源名称（URN）命名空间”，RFC 5328，DOI 10.17487/RFC5328，2008年9月<https://www.rfc-editor.org/info/rfc5328>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，DOI 10.17487/RFC5389，2008年10月<https://www.rfc-editor.org/info/rfc5389>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009, <https://www.rfc-editor.org/info/rfc5415>.
[RFC5415]Calhoun，P.，Ed.，Montemurro，M.，Ed.，和D.Stanley，Ed.，“无线接入点的控制和供应（CAPWAP）协议规范”，RFC 5415，DOI 10.17487/RFC5415，2009年3月<https://www.rfc-editor.org/info/rfc5415>.
[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, <https://www.rfc-editor.org/info/rfc5518>.
[RFC5518]Hoffman，P.，Levine，J.和A.Hathcock，“参考凭证”，RFC 5518，DOI 10.17487/RFC5518，2009年4月<https://www.rfc-editor.org/info/rfc5518>.
[RFC5555] Soliman, H., Ed., "Mobile IPv6 Support for Dual Stack Hosts and Routers", RFC 5555, DOI 10.17487/RFC5555, June 2009, <https://www.rfc-editor.org/info/rfc5555>.
[RFC5555]Soliman，H.，Ed.，“双栈主机和路由器的移动IPv6支持”，RFC 5555，DOI 10.17487/RFC5555，2009年6月<https://www.rfc-editor.org/info/rfc5555>.
[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617, August 2009, <https://www.rfc-editor.org/info/rfc5617>.
[RFC5617]Allman，E.，Fenton，J.，Delany，M.，和J.Levine，“域密钥识别邮件（DKIM）作者域签名实践（ADSP）”，RFC 5617，DOI 10.17487/RFC5617，2009年8月<https://www.rfc-editor.org/info/rfc5617>.
[RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using DNS", RFC 5679, DOI 10.17487/RFC5679, December 2009, <https://www.rfc-editor.org/info/rfc5679>.
[RFC5679]Bajko，G.“使用DNS定位IEEE 802.21移动服务”，RFC 5679，DOI 10.17487/RFC5679，2009年12月<https://www.rfc-editor.org/info/rfc5679>.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>.
[RFC5766]Mahy，R.，Matthews，P.，和J.Rosenberg，“使用NAT周围的中继进行遍历（TURN）：NAT（STUN）会话遍历实用程序的中继扩展”，RFC 5766，DOI 10.17487/RFC5766，2010年4月<https://www.rfc-editor.org/info/rfc5766>.
[RFC5780] MacDonald, D. and B. Lowekamp, "NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)", RFC 5780, DOI 10.17487/RFC5780, May 2010, <https://www.rfc-editor.org/info/rfc5780>.
[RFC5780]MacDonald，D.和B.Lowekamp，“使用NAT会话遍历实用程序进行NAT行为发现（STUN）”，RFC 5780，DOI 10.17487/RFC5780，2010年5月<https://www.rfc-editor.org/info/rfc5780>.
[RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, July 2010, <https://www.rfc-editor.org/info/rfc5804>.
[RFC5804]Melnikov，A.，Ed.和T.Martin，“远程管理筛选脚本的协议”，RFC 5804，DOI 10.17487/RFC5804，2010年7月<https://www.rfc-editor.org/info/rfc5804>.
[RFC5864] Allbery, R., "DNS SRV Resource Records for AFS", RFC 5864, DOI 10.17487/RFC5864, April 2010, <https://www.rfc-editor.org/info/rfc5864>.
[RFC5864]Allbery，R.，“AFS的DNS SRV资源记录”，RFC 5864，DOI 10.17487/RFC5864，2010年4月<https://www.rfc-editor.org/info/rfc5864>.
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT (TURN) Resolution Mechanism", RFC 5928, DOI 10.17487/RFC5928, August 2010, <https://www.rfc-editor.org/info/rfc5928>.
[RFC5928]Petit Huguenin，M.“使用NAT（转弯）解析机制周围的中继进行遍历”，RFC 5928，DOI 10.17487/RFC5928，2010年8月<https://www.rfc-editor.org/info/rfc5928>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<https://www.rfc-editor.org/info/rfc6120>.
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, <https://www.rfc-editor.org/info/rfc6186>.
[RFC6186]Daboo，C.“使用SRV记录查找电子邮件提交/访问服务”，RFC 6186，DOI 10.17487/RFC6186，2011年3月<https://www.rfc-editor.org/info/rfc6186>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<https://www.rfc-editor.org/info/rfc6376>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<https://www.rfc-editor.org/info/rfc6763>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC7208]Kitterman，S.，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 7208，DOI 10.17487/RFC7208，2014年4月<https://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7489]Kucherawy，M.，Ed.和E.Zwicky，Ed.，“基于域的消息验证、报告和一致性（DMARC）”，RFC 7489，DOI 10.17487/RFC7489，2015年3月<https://www.rfc-editor.org/info/rfc7489>.
Acknowledgements
致谢
Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Peter Koch, Olaf Kolkman, and Andrew Sullivan for diligent review of the (much) earlier draft versions. For the later enhancements, thanks to Tim Wicinski, John Levine, Bob Harold, Joel Jaeggli, Ondrej Sury, and Paul Wouters.
感谢Bill Fenner、Dick Franks、Tony Hansen、Peter Koch、Olaf Kolkman和Andrew Sullivan对（更）早期版本草案的认真审查。对于后来的增强，感谢Tim Wicinski、John Levine、Bob Harold、Joel Jaeggli、Ondrej Sury和Paul Wouters。
Special thanks to Ray Bellis for his persistent encouragement to continue this effort, as well as the suggestion for an essential simplification to the registration model.
特别感谢Ray Bellis坚持不懈地鼓励继续这一努力，以及对注册模式进行必要简化的建议。
Author's Address
作者地址
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 United States of America
Dave Crocker Brandenburg互联675 Spruce Dr.Sunnyvale，加利福尼亚州，美国94086
Phone: +1.408.246.8253
Email: dcrocker@bbiw.net
URI: http://bbiw.net/
Phone: +1.408.246.8253
Email: dcrocker@bbiw.net
URI: http://bbiw.net/