Internet Engineering Task Force (IETF) T. Finch
Request for Comments: 7673 University of Cambridge
Category: Standards Track M. Miller
ISSN: 2070-1721 Cisco Systems, Inc.
P. Saint-Andre
&yet
October 2015
Internet Engineering Task Force (IETF) T. Finch
Request for Comments: 7673 University of Cambridge
Category: Standards Track M. Miller
ISSN: 2070-1721 Cisco Systems, Inc.
P. Saint-Andre
&yet
October 2015
Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records
使用基于DNS的命名实体（DANE）TLSA记录与SRV记录的身份验证
Abstract
摘要
The DNS-Based Authentication of Named Entities (DANE) specification (RFC 6698) describes how to use TLSA resource records secured by DNSSEC (RFC 4033) to associate a server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). However, application protocols that use SRV records (RFC 2782) to indirectly name the target server connection endpoints for a service domain name cannot apply the rules from RFC 6698. Therefore, this document provides guidelines that enable such protocols to locate and use TLSA records.
基于DNS的命名实体身份验证（DANE）规范（RFC 6698）描述了如何使用DNSSEC（RFC 4033）保护的TLSA资源记录将服务器的连接端点与其传输层安全（TLS）证书相关联（从而使域名管理员能够指定该域TLS服务器中使用的密钥）。但是，使用SRV记录（RFC 2782）间接命名服务域名的目标服务器连接端点的应用程序协议无法应用RFC 6698中的规则。因此，本文件提供了使此类协议能够定位和使用TLSA记录的指南。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7673.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7673.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. DNS Checks ......................................................4
3.1. SRV Query ..................................................4
3.2. Address Queries ............................................5
3.3. TLSA Queries ...............................................6
3.4. Impact on TLS Usage ........................................6
4. TLS Checks ......................................................7
4.1. SRV Records Only ...........................................7
4.2. TLSA Records ...............................................8
5. Guidance for Protocol Authors ...................................8
6. Guidance for Server Operators ...................................8
7. Guidance for Application Developers .............................9
8. Internationalization Considerations .............................9
9. Security Considerations ........................................10
9.1. Mixed Security Status .....................................10
9.2. Certificate Subject Name Matching .........................10
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
Appendix A. Examples ..............................................13
A.1. IMAP .......................................................13
A.2. XMPP .......................................................13
Appendix B. Rationale .............................................14
Acknowledgements ..................................................15
Authors' Addresses ................................................16
1. Introduction ....................................................3
2. Terminology .....................................................4
3. DNS Checks ......................................................4
3.1. SRV Query ..................................................4
3.2. Address Queries ............................................5
3.3. TLSA Queries ...............................................6
3.4. Impact on TLS Usage ........................................6
4. TLS Checks ......................................................7
4.1. SRV Records Only ...........................................7
4.2. TLSA Records ...............................................8
5. Guidance for Protocol Authors ...................................8
6. Guidance for Server Operators ...................................8
7. Guidance for Application Developers .............................9
8. Internationalization Considerations .............................9
9. Security Considerations ........................................10
9.1. Mixed Security Status .....................................10
9.2. Certificate Subject Name Matching .........................10
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
Appendix A. Examples ..............................................13
A.1. IMAP .......................................................13
A.2. XMPP .......................................................13
Appendix B. Rationale .............................................14
Acknowledgements ..................................................15
Authors' Addresses ................................................16
The base DNS-Based Authentication of Named Entities (DANE) specification [RFC6698] describes how to use TLSA resource records secured by DNSSEC [RFC4033] to associate a target server's connection endpoint with its Transport Layer Security (TLS) certificate (thus enabling administrators of domain names to specify the keys used in that domain's TLS servers). Some application protocols locate connection endpoints indirectly via SRV records [RFC2782]. As a result of this indirection, the rules specified in [RFC6698] cannot be directly applied to such application protocols. (Rules for SMTP [RFC5321], which uses MX resource records instead of SRV records, are described in [RFC7672].)
基于DNS的命名实体身份验证（DANE）基本规范[RFC6698]描述了如何使用DNSSEC[RFC4033]保护的TLSA资源记录将目标服务器的连接端点与其传输层安全（TLS）证书相关联（从而使域名管理员能够指定该域TLS服务器中使用的密钥）。某些应用程序协议通过SRV记录[RFC2782]间接定位连接终结点。因此，[RFC6698]中指定的规则无法直接应用于此类应用程序协议。（SMTP规则[RFC5321][RFC7672]中介绍了使用MX资源记录而不是SRV记录的。）
This document describes how to use DANE TLSA records with SRV records. To summarize:
本文档描述了如何将DANE TLSA记录与SRV记录一起使用。总结如下：
o We rely on DNSSEC to secure SRV records that map the desired service, transport protocol, and service domain name to the corresponding target server connection endpoints (i.e., the target server hostnames and port numbers returned in the SRV records for that service type).
o 我们依靠DNSSEC保护SRV记录，这些记录将所需服务、传输协议和服务域名映射到相应的目标服务器连接端点（即，该服务类型的SRV记录中返回的目标服务器主机名和端口号）。
o Although in accordance with [RFC2782] a service domain name can advertise a number of SRV records (some of which might map to connection endpoints that do not support TLS), the intent of this specification is for a client to securely discover connection endpoints that support TLS.
o 尽管根据[RFC2782]，服务域名可以公布大量SRV记录（其中一些可能映射到不支持TLS的连接端点），但本规范的目的是让客户端安全地发现支持TLS的连接端点。
o The TLSA records for each connection endpoint are located using the transport protocol, port number, and hostname for the target server (not the service domain name).
o 使用目标服务器的传输协议、端口号和主机名（而不是服务域名）定位每个连接端点的TLSA记录。
o When DNSSEC-validated TLSA records are published for a given connection endpoint, clients always use TLS when connecting (even if the connection endpoint supports cleartext communication).
o 当为给定连接端点发布DNSSEC验证的TLSA记录时，客户端在连接时始终使用TLS（即使连接端点支持明文通信）。
o If there is at least one usable TLSA record for a given connection endpoint, the connection endpoint's TLS certificate or public key needs to match at least one of those usable TLSA records.
o 如果给定连接端点至少有一个可用的TLSA记录，则该连接端点的TLS证书或公钥需要与这些可用的TLSA记录中的至少一个匹配。
o If there are no usable TLSA records for a given connection endpoint, the target server hostname is used as one of the acceptable reference identifiers, as described in [RFC6125]. Other reference identifiers might arise through CNAME expansion of either the service domain name or target server hostname, as detailed in [RFC7671].
o 如果给定连接端点没有可用的TLSA记录，则目标服务器主机名将用作可接受的引用标识符之一，如[RFC6125]中所述。其他引用标识符可能通过服务域名或目标服务器主机名的CNAME扩展产生，详见[RFC7671]。
o If there are no usable TLSA records for any connection endpoint (and thus the client cannot securely discover a connection endpoint that supports TLS), the client's behavior is a matter for the application protocol or client implementation; this might involve a fallback to non-DANE behavior using the public key infrastructure [RFC5280].
o 如果任何连接端点都没有可用的TLSA记录（因此客户端无法安全地发现支持TLS的连接端点），则客户端的行为取决于应用程序协议或客户端实现；这可能涉及使用公钥基础设施的非丹麦行为回退[RFC5280]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this memo are to be interpreted as described in [RFC2119].
本备忘录中的关键词“必须”、“不得”、“要求”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This document uses the definitions for "secure", "insecure", "bogus", and "indeterminate" from Section 4.3 of [RFC4035]. This document uses the acronyms from [RFC7218] for the values of TLSA fields where appropriate.
本文件使用[RFC4035]第4.3节中“安全”、“不安全”、“伪造”和“不确定”的定义。本文件使用[RFC7218]中的首字母缩略词表示TLSA字段的值（如适用）。
Additionally, this document uses the following terms:
此外，本文件使用以下术语：
connection endpoint: A tuple of a fully qualified DNS hostname, transport protocol, and port number that a client uses to establish a connection to the target server.
连接端点：客户端用于建立到目标服务器的连接的完全限定DNS主机名、传输协议和端口号的元组。
service domain name: The fully qualified DNS domain name that identifies an application service; corresponds to the term "source domain" from [RFC6125].
服务域名：标识应用程序服务的完全限定DNS域名；对应于[RFC6125]中的术语“源域”。
This document uses the term "target server hostname" in place of the term "derived domain" from the so-called CertID specification [RFC6125].
本文档使用术语“目标服务器主机名”代替所谓的CertID规范[RFC6125]中的术语“派生域”。
When the client makes an SRV query, a successful result will typically be a list of one or more SRV records (or possibly a chain of CNAME/DNAME aliases leading to such a list).
当客户端进行SRV查询时，成功的结果通常是一个或多个SRV记录的列表（或者可能是导致该列表的CNAME/DNAME别名链）。
NOTE: Implementers need to be aware that unsuccessful results can occur because of various DNS-related errors; guidance on avoiding downgrade attacks can be found in Section 2.1 of [RFC7672].
注意：实现者需要知道，由于各种DNS相关错误，可能会出现不成功的结果；有关避免降级攻击的指南，请参见[RFC7672]的第2.1节。
For this specification to apply, the entire chain of DNS RRset(s) returned MUST be "secure" according to DNSSEC validation (Section 5 of [RFC4035]). In the case where the answer is obtained via a chain of CNAME and/or DNAME aliases, the whole chain of CNAME and DNAME RRsets MUST also be secure.
为了适用本规范，根据DNSSEC验证（RFC4035第5节），返回的整个DNS RRset链必须是“安全的”。在通过CNAME和/或DNAME别名链获得答案的情况下，整个CNAME和DNAME RRSET链也必须是安全的。
If the SRV lookup fails because the RRset is "bogus" (or the lookup fails for reasons other than no records), the client MUST abort its attempt to connect to the desired service. If the lookup result is "insecure" (or no SRV records exist), this protocol does not apply and the client SHOULD fall back to its non-DNSSEC, non-DANE (and possibly non-SRV) behavior.
如果SRV查找失败是因为RRset是“伪造的”（或者查找失败是因为没有记录以外的原因），则客户端必须中止其连接到所需服务的尝试。如果查找结果是“不安全的”（或不存在SRV记录），则此协议不适用，客户端应退回到其非DNSSEC、非DANE（可能是非SRV）行为。
When the lookup returns a "secure" RRset (possibly via a chain of "secure" CNAME/DNAME records), the client now has an authentic list of target server connection endpoints with weight and priority values. It performs server ordering and selection using the weight and priority values without regard to the presence or absence of DNSSEC or TLSA records. It also takes note of the DNSSEC validation status of the SRV response for use when checking certificate names (see Section 4). The client can then proceed to making address queries on the target server hostnames as described in the following section.
当查找返回“安全”RRset（可能通过“安全”CNAME/DNAME记录链）时，客户机现在拥有一个具有权重和优先级值的目标服务器连接端点的真实列表。它使用权重和优先级值执行服务器排序和选择，而不考虑是否存在DNSSEC或TLSA记录。它还注意到SRV响应的DNSSEC验证状态，以便在检查证书名称时使用（请参阅第4节）。然后，客户机可以继续对目标服务器主机名进行地址查询，如以下部分所述。
For each SRV target server connection endpoint, the client makes A and/or AAAA queries, performs DNSSEC validation on the address (A or AAAA) response, and continues as follows, based on the results:
对于每个SRV目标服务器连接终结点，客户机进行A和/或AAAA查询，对地址（A或AAAA）响应执行DNSSEC验证，并根据结果继续执行以下操作：
o If a returned RRSet is "secure", the client MUST perform a TLSA query for that target server connection endpoint, as described in the next section.
o 如果返回的RRSet是“安全的”，则客户端必须对该目标服务器连接端点执行TLSA查询，如下一节所述。
o If no returned RRsets are "secure", the client MUST NOT perform a TLSA query for that target server connection endpoint; the TLSA query will most likely fail or produce spurious results.
o 如果没有返回的RRSET是“安全的”，则客户端不得对该目标服务器连接端点执行TLSA查询；TLSA查询很可能会失败或产生虚假结果。
o If the address record lookup fails (a validation status of either "bogus" or "indeterminate"), the client MUST NOT connect to this connection endpoint; instead, it uses the next most appropriate SRV target. This helps prevent downgrade attacks.
o 如果地址记录查找失败（验证状态为“假”或“不确定”），则客户端不得连接到此连接端点；相反，它使用下一个最合适的SRV目标。这有助于防止降级攻击。
The client SHALL construct the TLSA query name as described in Section 3 of [RFC6698], based on the fields from the SRV record: the port number from the SRV RDATA, the transport protocol from the SRV query name, and the TLSA base domain from the SRV target server hostname.
客户机应根据SRV记录中的字段（SRV RDATA中的端口号、SRV查询名称中的传输协议以及SRV目标服务器主机名中的TLSA基本域），按照[RFC6698]第3节中的说明构造TLSA查询名称。
For example, the following SRV record for IMAP (see [RFC6186])
例如，IMAP的以下SRV记录（请参见[RFC6186]）
_imap._tcp.example.com. 86400 IN SRV 10 0 9143 imap.example.net.
_imap._tcp.example.com。SRV 10 0 9143 imap.example.net中的86400。
leads to the TLSA query shown below:
导致TLSA查询，如下所示：
_9143._tcp.imap.example.net. IN TLSA ?
_9143._tcp.imap.example.net。在TLSA？
The client SHALL determine if the TLSA records returned in the previous step are usable according to Section 4.1 of [RFC6698]. This affects the use of TLS as follows:
客户应根据[RFC6698]第4.1节确定上一步返回的TLSA记录是否可用。这会对TLS的使用产生以下影响：
o If the TLSA response is "secure" and usable, then the client MUST use TLS when connecting to the target server. The TLSA records are used when validating the server's certificate as described in Section 4.
o 如果TLSA响应“安全”且可用，则客户端在连接到目标服务器时必须使用TLS。TLSA记录在验证服务器证书时使用，如第4节所述。
o If the TLSA response is "bogus" or "indeterminate" (or the lookup fails for reasons other than no records), then the client MUST NOT connect to the target server (the client can still use other SRV targets).
o 如果TLSA响应为“虚假”或“不确定”（或者查找失败的原因不是没有记录），则客户端不得连接到目标服务器（客户端仍可使用其他SRV目标）。
o If the TLSA response is "insecure" (or no TLSA records exist), then the client SHALL proceed as if the target server had no TLSA records. It MAY connect to the target server with or without TLS, subject to the policies of the application protocol or client implementation.
o 如果TLSA响应是“不安全的”（或不存在TLSA记录），则客户端应继续操作，就像目标服务器没有TLSA记录一样。根据应用程序协议或客户端实现的策略，它可以连接到有或没有TLS的目标服务器。
When connecting to a server, the client MUST use TLS if the responses to the SRV and TLSA queries were "secure" as described above. The rules described in the next two sections -- Section 4.2 for cases where there is at least one usable TLSA record, and Section 4.1 otherwise -- apply to such secure responses.
连接到服务器时，如果对SRV和TLSA查询的响应如上所述是“安全的”，则客户端必须使用TLS。接下来两节中描述的规则——第4.2节针对至少有一条可用TLSA记录的情况，第4.1节其他部分描述的规则——适用于此类安全响应。
If the client received zero usable TLSA certificate associations, it SHALL validate the server's TLS certificate using the normal PKIX rules [RFC5280] or protocol-specific rules (e.g., following [RFC6125]) without further input from the TLSA records. In this case, the client uses the information in the server certificate and the DNSSEC validation status of the SRV query in its authentication checks. It SHOULD use the Server Name Indication extension (TLS SNI) [RFC6066] or its functional equivalent in the relevant application protocol (e.g., in the Extensible Messaging and Presence Protocol (XMPP) [RFC6120], this is the 'to' address of the initial stream header). The preferred name SHALL be chosen as follows, and the client SHALL verify the identity asserted by the server's certificate according to Section 6 of [RFC6125], using a list of reference identifiers constructed as follows (note again that in RFC 6125 the terms "source domain" and "derived domain" refer to the same things as "service domain name" and "target server hostname" in this document). The examples below assume a service domain name of "im.example.com" and a target server hostname of "xmpp23.hosting.example.net".
如果客户端收到零个可用TLSA证书关联，则应使用正常PKIX规则[RFC5280]或协议特定规则（例如，遵循[RFC6125]）验证服务器的TLS证书，而无需从TLSA记录中进一步输入。在这种情况下，客户端在其身份验证检查中使用服务器证书中的信息和SRV查询的DNSSEC验证状态。它应该使用服务器名称指示扩展（TLS SNI）[RFC6066]或相关应用程序协议中的等效功能（例如，在可扩展消息和状态协议（XMPP）[RFC6120]中，这是初始流头的“到”地址）。首选名称的选择应如下所示，客户应根据[RFC6125]第6节，使用如下构造的参考标识符列表验证服务器证书声明的身份（再次注意，在RFC 6125中，术语“源域”和“派生域”指的是与“服务域名”相同的内容以及本文档中的“目标服务器主机名”）。下面的示例假定服务域名为“im.example.com”，目标服务器主机名为“xmpp23.hosting.example.net”。
SRV is insecure: The reference identifiers SHALL include the service domain name and MUST NOT include the SRV target server hostname (e.g., include "im.example.com" but not "xmpp23.hosting.example.net"). The service domain name is the preferred name for TLS SNI or its equivalent.
SRV不安全：参考标识符应包括服务域名，且不得包括SRV目标服务器主机名（例如，包括“im.example.com”，但不包括“xmpp23.hosting.example.net”）。服务域名是TLS SNI或其等效物的首选名称。
SRV is secure: The reference identifiers SHALL include both the service domain name and the SRV target server hostname (e.g., include both "im.example.com" and "xmpp23.hosting.example.net"). The service domain name is still the preferred name for TLS SNI or its equivalent (this reduces code complexity and the possibility of interoperability problems).
SRV是安全的：参考标识符应包括服务域名和SRV目标服务器主机名（例如，包括“im.example.com”和“xmpp23.hosting.example.net”）。服务域名仍然是TLS SNI或其等价物的首选名称（这降低了代码复杂性和互操作性问题的可能性）。
In the latter case, the client will accept either identity to ensure compatibility with servers that support this specification as well as servers that do not support this specification.
在后一种情况下，客户端将接受任一标识，以确保与支持此规范的服务器以及不支持此规范的服务器兼容。
If the client received one or more usable TLSA certificate associations, it SHALL process them as described in Section 2.1 of [RFC6698].
如果客户收到一个或多个可用的TLSA证书关联，则应按照[RFC6698]第2.1节中的说明进行处理。
If the TLS server's certificate -- or the public key of the server's certificate -- matches a usable TLSA record with certificate usage DANE-EE, the client MUST ignore validation checks from [RFC5280] and reference identifier checks from [RFC6125]. The information in such a TLSA record supersedes the non-key information in the certificate.
如果TLS服务器的证书（或服务器证书的公钥）与可用TLSA记录和证书使用DANE-EE相匹配，则客户端必须忽略[RFC5280]中的验证检查和[RFC6125]中的引用标识符检查。TLSA记录中的信息将取代证书中的非密钥信息。
This document describes how to use DANE with application protocols in which target servers are discovered via SRV records. Although this document attempts to provide generic guidance applying to all such protocols, additional documents for particular application protocols could cover related topics, such as:
本文档描述了如何将DANE与通过SRV记录发现目标服务器的应用程序协议一起使用。尽管本文件试图提供适用于所有此类协议的通用指南，但特定应用协议的其他文件可能涵盖相关主题，例如：
o Fallback logic in the event that a client is unable to connect securely to a target server by following the procedures defined in this document.
o 当客户端无法按照本文档中定义的过程安全地连接到目标服务器时的回退逻辑。
o How clients ought to behave if (1) they do not support SRV lookups or (2) they do support SRV lookups and encounter service domain names that do not offer SRV records.
o 如果（1）客户机不支持SRV查找，或者（2）客户机确实支持SRV查找，并且遇到不提供SRV记录的服务域名，那么客户机应该如何操作。
o Whether or not the application protocol has a functional equivalent for TLS SNI that is preferred within that protocol.
o 应用协议是否具有该协议中首选的TLS SNI功能等效物。
o The use of SRV records with additional discovery technologies, such as the use of both SRV records and NAPTR records [RFC3403] for transport selection in the Session Initiation Protocol (SIP).
o 使用SRV记录和其他发现技术，例如在会话启动协议（SIP）中使用SRV记录和NAPTR记录[RFC3403]进行传输选择。
For example, [XMPP-DNA] covers such topics for XMPP.
例如，[XMPP-DNA]涵盖了XMPP的此类主题。
To conform to this specification, the published SRV records and subsequent address (A and AAAA) records MUST be secured with DNSSEC. There SHOULD also be at least one TLSA record published that authenticates the server's certificate.
为符合本规范，发布的SRV记录和后续地址（A和AAAA）记录必须由DNSSEC保护。还应至少发布一条TLSA记录来验证服务器的证书。
When using TLSA records with certificate usage DANE-EE, it is not necessary for the deployed certificate to contain an identifier for either the source domain or target server hostname. However, operators need to be aware that servers relying solely on validation
在将TLSA记录与证书使用DANE-EE一起使用时，部署的证书不必包含源域或目标服务器主机名的标识符。但是，运营商需要知道，服务器完全依赖于验证
using certificate usage DANE-EE TLSA records might prevent clients that do not support this specification from successfully connecting with TLS.
使用证书使用DANE-EE TLSA记录可能会阻止不支持此规范的客户端成功连接TLS。
For TLSA records with certificate usage types other than DANE-EE, the certificate(s) MUST contain an identifier that matches:
对于证书使用类型不是DANE-EE的TLSA记录，证书必须包含与以下内容匹配的标识符：
o the service domain name (the "source domain" in [RFC6125] terms, which is the SRV query domain), and/or
o 服务域名（[RFC6125]术语中的“源域”，即SRV查询域），和/或
o the target server hostname (the "derived domain" in [RFC6125] terms, which is the SRV target hostname).
o 目标服务器主机名（[RFC6125]术语中的“派生域”，即SRV目标主机名）。
Servers that support multiple service domain names (i.e., so-called "multi-tenanted environments") can implement TLS SNI [RFC6066] or its functional equivalent to determine which certificate to offer. Clients that do not support this specification will indicate a preference for the service domain name, while clients that support this specification will indicate the target server hostname. However, the server determines what certificate to present in the TLS handshake; e.g., the presented certificate might only authenticate the target server hostname.
支持多个服务域名（即所谓的“多租户环境”）的服务器可以实现TLS SNI[RFC6066]或其功能等效物，以确定提供哪个证书。不支持此规范的客户端将指示服务域名的首选项，而支持此规范的客户端将指示目标服务器主机名。但是，服务器决定在TLS握手中显示什么证书；e、 例如，提供的证书可能仅对目标服务器主机名进行身份验证。
Developers of application clients that depend on DANE-SRV often would like to prepare as quickly as possible for making a connection to the intended service, thus reducing the wait time for end users. To make this optimization possible, a DNS library might perform the address queries and TLSA queries in parallel. (Because a TLSA record can be ignored if it turns out that the address record on which it depends is not secure, performing the TLSA queries in parallel with the address queries is not harmful from a security perspective and can yield some operational benefits.)
依赖DANE-SRV的应用程序客户端的开发人员通常希望尽快准备连接到预期的服务，从而减少最终用户的等待时间。为了使这种优化成为可能，DNS库可以并行执行地址查询和TLSA查询。（由于如果TLSA记录所依赖的地址记录不安全，则可以忽略该记录，因此从安全角度来看，与地址查询并行执行TLSA查询并不有害，并且可以产生一些操作好处。）
If any of the DNS queries are for an internationalized domain name, then they need to use the A-label form [RFC5890].
如果任何DNS查询是针对国际化域名的，则需要使用A标签形式[RFC5890]。
We do not specify that all of the target server connection endpoints for a service domain name need to be consistent in whether they have or do not have TLSA records. This is so that partial or incremental deployment does not break the service. Different levels of deployment are likely if a service domain name has a third-party fallback server, for example.
我们不指定服务域名的所有目标服务器连接端点在是否具有TLSA记录方面都需要一致。这样，部分或增量部署不会中断服务。例如，如果服务域名具有第三方后备服务器，则可能会有不同的部署级别。
The SRV sorting rules are unchanged; in particular, they have not been altered in order to prioritize secure connection endpoints over insecure connection endpoints. If a site wants to be secure, it needs to deploy this protocol completely; a partial deployment is not secure, and we make no special effort to support it.
SRV排序规则不变；特别是，它们并没有被改变，以便将安全连接端点优先于不安全连接端点。如果一个站点想要安全，它需要完全部署这个协议；部分部署是不安全的，我们没有特别努力来支持它。
Section 4 of the TLSA specification [RFC6698] leaves the details of checking names in certificates to higher-level application protocols, though it suggests the use of [RFC6125].
TLSA规范[RFC6698]第4节将检查证书中名称的细节留给了更高级别的应用程序协议，尽管它建议使用[RFC6125]。
Name checks are not necessary if the matching TLSA record is of certificate usage DANE-EE. Because such a record identifies the specific certificate (or public key of the certificate), additional checks are superfluous and potentially conflicting.
如果匹配的TLSA记录是DANE-EE使用的证书，则不需要进行名称检查。因为这样的记录标识特定的证书（或证书的公钥），所以额外的检查是多余的，并且可能会发生冲突。
Otherwise, while DNSSEC provides a secure binding between the server name and the TLSA record, and the TLSA record provides a binding to a certificate, this latter step can be indirect via a chain of certificates. For example, a certificate usage PKIX-TA TLSA record only authenticates the Certification Authority (CA) that issued the certificate, and third parties can obtain certificates from the same CA. Therefore, clients need to check to see whether or not the server's certificate matches one of the expected reference identifiers to ensure that the certificate was issued by the CA to the server the client expects (naturally, this is in addition to standard certificate-related checks as specified in [RFC5280], including but not limited to certificate syntax, certificate extensions such as name constraints and extended key usage, and handling of certification paths).
否则，虽然DNSSEC在服务器名称和TLSA记录之间提供安全绑定，并且TLSA记录提供对证书的绑定，但后一步可以通过证书链间接执行。例如，证书使用PKIX-TA TLSA记录仅对颁发证书的证书颁发机构（CA）进行身份验证，第三方可以从同一CA获得证书。因此，客户端需要检查服务器的证书是否与预期的参考标识符之一匹配，以确保证书是由CA颁发给客户端预期的服务器的（当然，这是在[RFC5280]中规定的标准证书相关检查之外的），包括但不限于证书语法、证书扩展（如名称约束和扩展密钥使用），以及证书路径的处理）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[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, <http://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月<http://www.rfc-editor.org/info/rfc2782>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, DOI 10.17487/RFC4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，DOI 10.17487/RFC4033，2005年3月<http://www.rfc-editor.org/info/rfc4033>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <http://www.rfc-editor.org/info/rfc4035>.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，DOI 10.17487/RFC4035，2005年3月<http://www.rfc-editor.org/info/rfc4035>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.，“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 5890，DOI 10.17487/RFC5890，2010年8月<http://www.rfc-editor.org/info/rfc5890>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.
[RFC6066]Eastlake 3rd，D.，“传输层安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011年1月<http://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6125]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”，RFC 6125，DOI 10.17487/RFC6125，2011年3月<http://www.rfc-editor.org/info/rfc6125>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<http://www.rfc-editor.org/info/rfc6698>.
[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <http://www.rfc-editor.org/info/rfc7218>.
[RFC7218]Gudmundsson，O.，“添加首字母缩略词以简化有关基于DNS的命名实体身份验证（DANE）的对话”，RFC 7218，DOI 10.17487/RFC7218，2014年4月<http://www.rfc-editor.org/info/rfc7218>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <http://www.rfc-editor.org/info/rfc7671>.
[RFC7671]Dukhovni，V.和W.Hardaker，“基于DNS的命名实体认证（DANE）协议：更新和操作指南”，RFC 7671，DOI 10.17487/RFC7671，2015年10月<http://www.rfc-editor.org/info/rfc7671>.
[RFC7672] Dukhovni, V. and W. Hardaker, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)", RFC 7672, DOI 10.17487/RFC7672, October 2015, <http://www.rfc-editor.org/info/rfc7672>.
[RFC7672]Dukhovni，V.和W.Hardaker，“通过基于机会DNS的命名实体身份验证（DANE）传输层安全性（TLS）实现SMTP安全”，RFC 7672，DOI 10.17487/RFC7672，2015年10月<http://www.rfc-editor.org/info/rfc7672>.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, DOI 10.17487/RFC3403, October 2002, <http://www.rfc-editor.org/info/rfc3403>.
[RFC3403]Mealling，M，“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC 3403，DOI 10.17487/RFC3403，2002年10月<http://www.rfc-editor.org/info/rfc3403>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <http://www.rfc-editor.org/info/rfc5321>.
[RFC5321]Klensin，J.，“简单邮件传输协议”，RFC 5321DOI 10.17487/RFC5321，2008年10月<http://www.rfc-editor.org/info/rfc5321>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC 6120，DOI 10.17487/RFC6120，2011年3月<http://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, <http://www.rfc-editor.org/info/rfc6186>.
[RFC6186]Daboo，C.“使用SRV记录查找电子邮件提交/访问服务”，RFC 6186，DOI 10.17487/RFC6186，2011年3月<http://www.rfc-editor.org/info/rfc6186>.
[XMPP-DNA] Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, draft-ietf-xmpp-dna-11, September 2015.
[XMPP-DNA]Saint Andre，P.，Miller，M.，和P.Hancke，“可扩展消息传递和存在协议（XMPP）中的域名关联（DNA）”，正在进行的工作，草案-ietf-XMPP-DNA-112015年9月。
In the following, most of the DNS resource data is elided for simplicity.
在下文中，为了简单起见，省略了大多数DNS资源数据。
; mail domain _imap._tcp.example.com. SRV 10 0 9143 imap.example.net. example.com. RRSIG SRV ...
; 邮件域\u imap.\u tcp.example.com。SRV 10 0 9143 imap.example.net。example.com。RRSIG SRV。。。
; target server hostname imap.example.net. A 192.0.2.1 imap.example.net. RRSIG A ...
; 目标服务器主机名imap.example.net。192.0.2.1 imap.example.net。RRSIG A。。。
imap.example.net. AAAA 2001:db8:212:8::e:1 imap.example.net. RRSIG ...
imap.example.net。AAAA 2001:db8:212:8:：e:1 imap.example.net。RRSIG。。。
; TLSA resource record _9143._tcp.imap.example.net. TLSA ... _9143._tcp.imap.example.net. RRSIG TLSA ...
; TLSA资源记录_9143._tcp.imap.example.net。TLSA_9143._tcp.imap.example.net。RRSIG TLSA。。。
Mail messages received for addresses at example.com are retrieved via IMAP at imap.example.net. Connections to imap.example.net port 9143 that use STARTTLS will get a server certificate that authenticates the name imap.example.net.
通过IMAP.example.net上的IMAP检索接收到的example.com地址的邮件消息。使用STARTTLS连接到imap.example.net端口9143将获得一个服务器证书，用于验证名称imap.example.net。
; XMPP domain _xmpp-client._tcp.example.com. SRV 1 0 5222 im.example.net. _xmpp-client._tcp.example.com. RRSIG SRV ...
; XMPP域_XMPP-client._tcp.example.com。SRV 1 0 5222 im.example.net_xmpp客户端。_tcp.example.com。RRSIG SRV。。。
; target server hostname im.example.net. A 192.0.2.3 im.example.net. RRSIG A ...
; 目标服务器主机名im.example.net。192.0.2.3 im.example.net。RRSIG A。。。
im.example.net. AAAA 2001:db8:212:8::e:4 im.example.net. RRSIG AAAA ...
im.example.net。AAAA 2001:db8:212:8:：e:4im.example.net。RRSIG AAAA。。。
; TLSA resource record _5222._tcp.im.example.net. TLSA ... _5222._tcp.im.example.net. RRSIG TLSA ...
; TLSA资源记录_5222._tcp.im.example.net。TLSA_5222._tcp.im.example.net。RRSIG TLSA。。。
XMPP sessions for addresses at example.com are established at im.example.net. Connections to im.example.net port 5222 that use STARTTLS will get a server certificate that authenticates the name im.example.net.
example.com地址的XMPP会话在im.example.net上建立。使用STARTTLS连接到im.example.net端口5222将获得一个服务器证书，该证书将验证名称im.example.net。
The long-term goal of this specification is to settle on TLS certificates that verify the target server hostname rather than the service domain name, since this is more convenient for servers hosting multiple domains (so-called "multi-tenanted environments") and scales up more easily to larger numbers of service domain names.
本规范的长期目标是确定验证目标服务器主机名而不是服务域名的TLS证书，因为这对于承载多个域（所谓的“多租户环境”）的服务器更方便，并且更容易扩展到更多的服务域名。
There are a number of other reasons for doing it this way:
这样做还有很多其他原因：
o The certificate is part of the server configuration, so it makes sense to associate it with the target server hostname rather than the service domain name.
o 证书是服务器配置的一部分，因此将其与目标服务器主机名而不是服务域名相关联是有意义的。
o In the absence of TLS SNI, if the certificate identifies the target server hostname, then it does not need to list all the possible service domain names.
o 在没有TLS SNI的情况下，如果证书标识目标服务器主机名，则不需要列出所有可能的服务域名。
o When the server certificate is replaced, it is much easier if there is one part of the DNS that needs updating to match, instead of an unbounded number of hosted service domain names.
o 当服务器证书被替换时，如果DNS中有一部分需要更新以匹配，而不是无限数量的托管服务域名，那么就容易多了。
o The same TLSA records work with this specification, and with direct connections to the connection endpoint in the style of [RFC6698].
o 相同的TLSA记录适用于本规范，并以[RFC6698]的样式直接连接到连接端点。
o Some application protocols, such as SMTP, allow a client to perform transactions with multiple service domain names in the same connection. It is not, in general, feasible for the client to specify the service domain name using TLS SNI when the connection is established, and the server might not be able to present a certificate that authenticates all possible service domain names. See [RFC7672] for details.
o 某些应用程序协议（如SMTP）允许客户端在同一连接中使用多个服务域名执行事务。一般来说，在建立连接时，客户端使用TLS SNI指定服务域名是不可行的，并且服务器可能无法提供对所有可能的服务域名进行身份验证的证书。详见[RFC7672]。
o It is common for SMTP servers to act in multiple roles -- for example, as outgoing relays or as incoming MX servers, depending on the client identity. It is simpler if the server can present the same certificate regardless of the role in which it is to act. Sometimes the server does not know its role until the client has authenticated, which usually occurs after TLS has been established. See [RFC7672] for details.
o SMTP服务器通常扮演多个角色——例如，作为传出中继或作为传入MX服务器，具体取决于客户端标识。如果服务器可以提供相同的证书，而不考虑它要扮演的角色，则更简单。有时，在客户端进行身份验证之前，服务器不知道自己的角色，这通常发生在TLS建立之后。详见[RFC7672]。
This specification does not provide an option to put TLSA records under the service domain name, because that would add complexity without providing any benefit; security protocols are best kept simple. As described above, there are real-world cases where authenticating the service domain name cannot be made to work, so there would be complicated criteria regarding when service domain name TLSA records might be used and when they cannot. This is all avoided by putting the TLSA records under the target server hostname.
本规范未提供将TLSA记录置于服务域名下的选项，因为这将增加复杂性，但不会带来任何好处；安全协议最好保持简单。如上所述，在现实世界中存在无法对服务域名进行身份验证的情况，因此关于何时可以使用服务域名TLSA记录以及何时不能使用，将存在复杂的标准。通过将TLSA记录放在目标服务器主机名下，可以避免这一切。
The disadvantage is that clients that do not complete DNSSEC validation must, according to [RFC6125] rules, check the server certificate against the service domain name, since they have no other way to authenticate the server. This means that SNI support or its functional equivalent is necessary for backward compatibility.
缺点是，根据[RFC6125]规则，未完成DNSSEC验证的客户端必须根据服务域名检查服务器证书，因为它们没有其他方式来验证服务器。这意味着SNI支持或其功能等价物对于向后兼容性是必要的。
Acknowledgements
致谢
Thanks to Mark Andrews for arguing that authenticating the target server hostname is the right thing, and that we ought to rely on DNSSEC to secure the SRV lookup. Thanks to Stephane Bortzmeyer, James Cloos, Viktor Dukhovni, Ned Freed, Olafur Gudmundsson, Paul Hoffman, Phil Pennock, Hector Santos, Jonas Schneider, and Alessandro Vesely for helpful suggestions.
感谢Mark Andrews，他认为验证目标服务器主机名是正确的，我们应该依靠DNSSEC来保护SRV查找。感谢Stephane Bortzmeyer、James Cloos、Viktor Dukhovni、Ned Freed、Olafur Gudmundsson、Paul Hoffman、Phil Pennock、Hector Santos、Jonas Schneider和Alessandro Vesely提供的有用建议。
Carl Wallace completed an insightful review on behalf of the Security Directorate.
卡尔·华莱士代表安全局完成了一次富有洞察力的审查。
Ben Campbell, Brian Haberman, and Alvaro Retana provided helpful feedback during IESG review.
Ben Campbell、Brian Haberman和Alvaro Retana在IESG审查期间提供了有用的反馈。
The authors gratefully acknowledge the assistance of Olafur Gudmundsson and Warren Kumari as the working group chairs and Stephen Farrell as the sponsoring Area Director.
作者衷心感谢工作组主席Olafur Gudmundsson和Warren Kumari以及赞助区域主任Stephen Farrell的协助。
Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.
Peter Saint Andre希望感谢Cisco Systems，Inc.在编写本文件早期草稿期间聘用了他。
Authors' Addresses
作者地址
Tony Finch University of Cambridge Information Services Roger Needham Building 7 JJ Thomson Avenue Cambridge CB3 0RB United Kingdom
托尼芬奇剑桥大学信息服务罗杰尼达姆建设7 JJ汤姆逊大道剑桥CB3 0RB英国
Phone: +44 797 040 1426
Email: dot@dotat.at
URI: http://dotat.at/
Phone: +44 797 040 1426
Email: dot@dotat.at
URI: http://dotat.at/
Matthew Miller Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 United States
Matthew Miller Cisco Systems，Inc.美国科罗拉多州丹佛市温库普街1899号600室，邮编：80202
Email: mamille2@cisco.com
Email: mamille2@cisco.com
Peter Saint-Andre &yet
彼得·圣安德烈&还没有
Email: peter@andyet.com
URI: https://andyet.com/
Email: peter@andyet.com
URI: https://andyet.com/