Internet Engineering Task Force (IETF) V. Dukhovni
Request for Comments: 7671 Two Sigma
Updates: 6698 W. Hardaker
Category: Standards Track Parsons
ISSN: 2070-1721 October 2015
Internet Engineering Task Force (IETF) V. Dukhovni
Request for Comments: 7671 Two Sigma
Updates: 6698 W. Hardaker
Category: Standards Track Parsons
ISSN: 2070-1721 October 2015
The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
基于DNS的命名实体认证（DANE）协议：更新和操作指南
Abstract
摘要
This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records.
本文件根据后续实施经验澄清并更新了基于DNS的命名实体认证（DANE）TLSA规范（RFC 6698）。它还包含对希望使用DANE记录的实现者、操作员和协议开发人员的指导。
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/rfc7671.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7671.
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
1.1. Terminology ................................................4
2. DANE TLSA Record Overview .......................................5
2.1. Example TLSA Record ........................................6
3. DANE TLS Requirements ...........................................6
4. DANE Certificate Usage Selection Guidelines .....................7
4.1. Opportunistic Security and PKIX Usages .....................7
4.2. Interaction with Certificate Transparency ..................8
4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE ............9
5. Certificate-Usage-Specific DANE Updates and Guidelines ..........9
5.1. Certificate Usage DANE-EE(3) ...............................9
5.2. Certificate Usage DANE-TA(2) ..............................11
5.3. Certificate Usage PKIX-EE(1) ..............................15
5.4. Certificate Usage PKIX-TA(0) ..............................15
6. Service Provider and TLSA Publisher Synchronization ............16
7. TLSA Base Domain and CNAMEs ....................................18
8. TLSA Publisher Requirements ....................................19
8.1. Key Rollover with Fixed TLSA Parameters ...................20
8.2. Switching to DANE-TA(2) from DANE-EE(3) ...................21
8.3. Switching to New TLSA Parameters ..........................22
8.4. TLSA Publisher Requirements: Summary ......................23
9. Digest Algorithm Agility .......................................23
10. General DANE Guidelines .......................................25
10.1. DANE DNS Record Size Guidelines ..........................25
10.2. Certificate Name Check Conventions .......................26
10.3. Design Considerations for Protocols Using DANE ...........27
11. Note on DNSSEC Security .......................................28
12. Summary of Updates to RFC 6698 ................................29
13. Operational Considerations ....................................29
14. Security Considerations .......................................30
15. References ....................................................30
15.1. Normative References .....................................30
15.2. Informative References ...................................32
Acknowledgements ..................................................33
Authors' Addresses ................................................33
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. DANE TLSA Record Overview .......................................5
2.1. Example TLSA Record ........................................6
3. DANE TLS Requirements ...........................................6
4. DANE Certificate Usage Selection Guidelines .....................7
4.1. Opportunistic Security and PKIX Usages .....................7
4.2. Interaction with Certificate Transparency ..................8
4.3. Switching from/to PKIX-TA/EE to/from DANE-TA/EE ............9
5. Certificate-Usage-Specific DANE Updates and Guidelines ..........9
5.1. Certificate Usage DANE-EE(3) ...............................9
5.2. Certificate Usage DANE-TA(2) ..............................11
5.3. Certificate Usage PKIX-EE(1) ..............................15
5.4. Certificate Usage PKIX-TA(0) ..............................15
6. Service Provider and TLSA Publisher Synchronization ............16
7. TLSA Base Domain and CNAMEs ....................................18
8. TLSA Publisher Requirements ....................................19
8.1. Key Rollover with Fixed TLSA Parameters ...................20
8.2. Switching to DANE-TA(2) from DANE-EE(3) ...................21
8.3. Switching to New TLSA Parameters ..........................22
8.4. TLSA Publisher Requirements: Summary ......................23
9. Digest Algorithm Agility .......................................23
10. General DANE Guidelines .......................................25
10.1. DANE DNS Record Size Guidelines ..........................25
10.2. Certificate Name Check Conventions .......................26
10.3. Design Considerations for Protocols Using DANE ...........27
11. Note on DNSSEC Security .......................................28
12. Summary of Updates to RFC 6698 ................................29
13. Operational Considerations ....................................29
14. Security Considerations .......................................30
15. References ....................................................30
15.1. Normative References .....................................30
15.2. Informative References ...................................32
Acknowledgements ..................................................33
Authors' Addresses ................................................33
The DNS-Based Authentication of Named Entities (DANE) specification [RFC6698] introduces the DNS "TLSA" resource record (RR) type ("TLSA" is not an acronym). TLSA records associate a certificate or a public key of an end-entity or a trusted issuing authority with the corresponding Transport Layer Security (TLS) [RFC5246] or Datagram Transport Layer Security (DTLS) [RFC6347] transport endpoint. DANE relies on the DNS Security Extensions (DNSSEC) [RFC4033]. DANE TLSA records validated by DNSSEC can be used to augment or replace the use of trusted public Certification Authorities (CAs).
基于DNS的命名实体身份验证（DANE）规范[RFC6698]引入了DNS“TLSA”资源记录（RR）类型（“TLSA”不是首字母缩写）。TLSA记录将终端实体或可信颁发机构的证书或公钥与相应的传输层安全性（TLS）[RFC5246]或数据报传输层安全性（DTLS）[RFC6347]传输端点相关联。DANE依赖DNS安全扩展（DNSSEC）[RFC4033]。经DNSSEC验证的DANE TLSA记录可用于增加或取代可信公共认证机构（CA）的使用。
The TLS and DTLS protocols provide secured TCP and UDP communication, respectively, over IP. In the context of this document, channel security is assumed to be provided by TLS or DTLS. By convention, "TLS" will be used throughout this document; unless otherwise specified, the text applies equally well to DTLS over UDP. Used without authentication, TLS provides protection only against eavesdropping through its use of encryption. With authentication, TLS also protects the transport against man-in-the-middle (MITM) attacks.
TLS和DTLS协议分别通过IP提供安全的TCP和UDP通信。在本文档中，信道安全性假定由TLS或DTL提供。按照惯例，“TLS”将在本文件中使用；除非另有规定，否则该文本同样适用于UDP上的DTL。TLS在没有身份验证的情况下使用，仅通过使用加密来防止窃听。通过身份验证，TLS还可以保护传输免受中间人（MITM）攻击。
[RFC6698] defines three TLSA record fields: the first with four possible values, the second with two, and the third with three. These yield 24 distinct combinations of TLSA record types. This document recommends a smaller set of best-practice combinations of these fields to simplify protocol design, implementation, and deployment.
[RFC6698]定义了三个TLSA记录字段：第一个字段有四个可能的值，第二个字段有两个，第三个字段有三个。这产生了24种不同的TLSA记录类型组合。本文档推荐这些字段的一组较小的最佳实践组合，以简化协议设计、实现和部署。
This document explains and recommends DANE-specific strategies to simplify "virtual hosting", where a single Service Provider transport endpoint simultaneously supports multiple hosted Customer Domains.
本文档解释并推荐了简化“虚拟主机”的丹麦特定策略，其中单个服务提供商传输端点同时支持多个托管客户域。
Other related documents that build on [RFC6698] are [RFC7673] and [RFC7672].
基于[RFC6698]的其他相关文档有[RFC7673]和[RFC7672]。
Section 12 summarizes the normative updates this document makes to [RFC6698].
第12节总结了本文件对[RFC6698]的规范性更新。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The following terms are used throughout this document:
本文件中使用了以下术语：
Web PKI: The Public Key Infrastructure (PKI) model employed by browsers to authenticate web servers. This employs a set of trusted public CAs to vouch for the authenticity of public keys associated with a particular party (the subject).
Web PKI：浏览器用于验证Web服务器的公钥基础设施（PKI）模型。这使用一组受信任的公共CA来保证与特定方（主体）相关联的公钥的真实性。
Service Provider: A company or organization that offers to host a service on behalf of the owner of a Customer Domain. The original domain name associated with the service often remains under the control of the customer. Connecting applications may be directed to the Service Provider via a redirection RR. Example redirection records include MX, SRV, and CNAME. The Service Provider frequently provides services for many customers and needs to ensure that the TLS credentials presented to connecting applications authenticate it as a valid server for the requested domain.
服务提供者：代表客户域所有者提供服务的公司或组织。与服务相关联的原始域名通常由客户控制。连接应用程序可以通过重定向RR定向到服务提供商。示例重定向记录包括MX、SRV和CNAME。服务提供商经常为许多客户提供服务，并且需要确保提供给连接应用程序的TLS凭据将其验证为请求域的有效服务器。
Customer Domain: As described above, a TLS client may be interacting with a service that is hosted by a third party. This document refers to the domain name used to locate the service (prior to any redirection) as the "Customer Domain".
客户域：如上所述，TLS客户端可能与第三方托管的服务交互。本文档将用于定位服务（在任何重定向之前）的域名称为“客户域”。
TLSA Publisher: The entity responsible for publishing a TLSA record within a DNS zone. This zone will be assumed DNSSEC-signed and validatable to a trust anchor (TA), unless otherwise specified. If the Customer Domain is not outsourcing its DNS service, the TLSA Publisher will be the customer itself. Otherwise, the TLSA Publisher may be the operator of the outsourced DNS service.
TLSA发布者：负责在DNS区域内发布TLSA记录的实体。除非另有规定，否则该区域将假定DNSSEC已签名并可由信任锚（TA）验证。如果客户域未外包其DNS服务，则TLSA发布者将是客户本身。否则，TLSA发布者可能是外包DNS服务的运营商。
Public key: The term "public key" is shorthand for the subjectPublicKeyInfo component of a PKIX [RFC5280] certificate.
公钥：术语“公钥”是PKIX[RFC5280]证书的subjectPublicKeyInfo组件的缩写。
SNI: The Server Name Indication (SNI) TLS protocol extension allows a TLS client to request a connection to a particular service name of a TLS server ([RFC6066], Section 3). Without this TLS extension, a TLS server has no choice but to offer a certificate with a default list of server names, making it difficult to host multiple Customer Domains at the same IP-address-based TLS service endpoint (i.e., provide "secure virtual hosting").
SNI：服务器名称指示（SNI）TLS协议扩展允许TLS客户端请求连接到TLS服务器的特定服务名称（[RFC6066]，第3节）。没有此TLS扩展，TLS服务器别无选择，只能提供带有服务器名称默认列表的证书，这使得在同一个基于IP地址的TLS服务端点上托管多个客户域变得困难（即，提供“安全虚拟托管”）。
TLSA parameters: In [RFC6698], the TLSA record is defined to consist of four fields. The first three of these are numeric parameters that specify the meaning of the data in the fourth and final field. This document refers to the first three fields as "TLSA parameters", or sometimes just "parameters" when obvious from context.
TLSA参数：在[RFC6698]中，TLSA记录定义为由四个字段组成。其中前三个是数值参数，用于指定第四个也是最后一个字段中数据的含义。本文档将前三个字段称为“TLSA参数”，或者在上下文中显而易见时，有时仅称为“参数”。
TLSA base domain: Per Section 3 of [RFC6698], TLSA records are stored at a DNS domain name that is a combination of a port and protocol prefix and a "base domain". In [RFC6698], the "base domain" is the fully qualified domain name of the TLS server. This document modifies the TLSA record lookup strategy to prefer the fully CNAME-expanded name of the TLS server, provided that expansion is "secure" (DNSSEC validated) at each stage of the expansion, and TLSA records are published for this fully expanded name. Thus, the "TLSA base domain" is either the fully CNAME-expanded TLS server name or otherwise the initial fully qualified TLS server name, whichever is used in combination with a port and protocol prefix to obtain the TLSA RRset.
TLSA基本域：根据[RFC6698]第3节，TLSA记录存储在DNS域名上，该域名是端口和协议前缀与“基本域”的组合。在[RFC6698]中，“基本域”是TLS服务器的完全限定域名。本文档修改了TLSA记录查找策略，以首选TLS服务器的完全CNAME扩展名，前提是在扩展的每个阶段扩展都是“安全的”（DNSSEC验证），并且针对此完全扩展名发布TLSA记录。因此，“TLSA基本域”是完全CNAME扩展的TLS服务器名称或初始完全限定的TLS服务器名称，以与端口和协议前缀结合使用的名称为准，以获得TLSA RRset。
DANE TLSA [RFC6698] specifies a protocol for publishing TLS server certificate associations via DNSSEC [RFC4033] [RFC4034] [RFC4035]. DANE TLSA records consist of four fields. The record type is determined by the values of the first three fields, which this document refers to as the "TLSA parameters" to distinguish them from the fourth and last field. The numeric values of these parameters were given symbolic names in [RFC7218]. The four fields are as follows:
DANE TLSA[RFC6698]指定了通过DNSSEC[RFC4033][RFC4034][RFC4035]发布TLS服务器证书关联的协议。丹麦TLSA记录由四个字段组成。记录类型由前三个字段的值确定，本文档将其称为“TLSA参数”，以区别于第四个和最后一个字段。[RFC7218]中给出了这些参数的数值的符号名称。这四个字段如下所示：
The Certificate Usage field: Section 2.1.1 of [RFC6698] specifies four values: PKIX-TA(0), PKIX-EE(1), DANE-TA(2), and DANE-EE(3). There is an additional private-use value: PrivCert(255), which, given its private scope, shall not be considered further in this document. All other values are reserved for use by future specifications.
[RFC6698]第2.1.1节中的证书使用字段指定了四个值：PKIX-TA（0）、PKIX-EE（1）、DANE-TA（2）和DANE-EE（3）。还有一个额外的私人使用价值：PrivCert（255），鉴于其私人范围，本文件不应进一步考虑。所有其他值保留供将来的规范使用。
The Selector field: Section 2.1.2 of [RFC6698] specifies two values: Cert(0) and SPKI(1). There is an additional private-use value: PrivSel(255). All other values are reserved for use by future specifications.
[RFC6698]第2.1.2节中的选择器字段指定了两个值：Cert（0）和SPKI（1）。还有一个额外的私人使用值：PrivSel（255）。所有其他值保留供将来的规范使用。
The Matching Type field: Section 2.1.3 of [RFC6698] specifies three values: Full(0), SHA2-256(1), and SHA2-512(2). There is an additional private-use value: PrivMatch(255). All other values are reserved for use by future specifications.
[RFC6698]第2.1.3节中的匹配类型字段指定了三个值：Full（0）、SHA2-256（1）和SHA2-512（2）。还有一个额外的私有使用值：PrivMatch（255）。所有其他值保留供将来的规范使用。
The Certificate Association Data field: See Section 2.1.4 of [RFC6698]. This field stores the full value or digest of the certificate or subject public key as determined by the matching type and selector, respectively.
证书关联数据字段：见[RFC6698]第2.1.4节。此字段分别存储由匹配类型和选择器确定的证书或主题公钥的完整值或摘要。
In the Matching Type field, of the two digest algorithms -- SHA2-256(1) and SHA2-512(2) -- as of the time of this writing, only SHA2-256(1) is mandatory to implement. Clients SHOULD implement SHA2-512(2), but servers SHOULD NOT exclusively publish SHA2-512(2) digests. The digest algorithm agility protocol defined in Section 9 SHOULD be used by clients to decide how to process TLSA RRsets that employ multiple digest algorithms. Server operators MUST publish TLSA RRsets that are compatible (see Section 8) with digest algorithm agility (Section 9).
在匹配类型字段中，两个摘要算法——SHA2-256（1）和SHA2-512（2）——截至撰写本文时，只有SHA2-256（1）是必须实现的。客户端应该实现SHA2-512（2），但服务器不应该专门发布SHA2-512（2）摘要。客户应使用第9节中定义的摘要算法敏捷协议来决定如何处理采用多个摘要算法的TLSA RRSET。服务器运营商必须发布与摘要算法敏捷性（第9节）兼容的TLSA RRSET（见第8节）。
In the example TLSA record below, the TLSA certificate usage is DANE-TA(2), the selector is Cert(0), and the matching type is SHA2-256(1). The last field is the Certificate Association Data field, which in this case contains the SHA2-256 digest of the server certificate.
在下面的示例TLSA记录中，TLSA证书用法为DANE-TA（2），选择器为Cert（0），匹配类型为SHA2-256（1）。最后一个字段是证书关联数据字段，在本例中，该字段包含服务器证书的SHA2-256摘要。
_25._tcp.mail.example.com. IN TLSA 2 0 1 ( E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 )
_25._tcp.mail.example.com。在TLSA 2 0 1中（E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F530EBFBB77D022F834C0）
[RFC6698] does not discuss what versions of TLS are required when using DANE records. This document specifies that TLS clients that support DANE/TLSA MUST support at least TLS 1.0 and SHOULD support TLS 1.2 or later.
[RFC6698]未讨论使用DANE记录时需要哪些版本的TLS。本文档规定，支持DANE/TLSA的TLS客户端必须至少支持TLS 1.0，并且应支持TLS 1.2或更高版本。
TLS clients using DANE MUST support the SNI extension of TLS [RFC6066]. Servers MAY support SNI and respond with a matching certificate chain but MAY also ignore SNI and respond with a default certificate chain. When a server supports SNI but is not configured with a certificate chain that exactly matches the client's SNI extension, the server SHOULD respond with another certificate chain (a default or closest match). This is because clients might support more than one server name but can only put a single name in the SNI extension.
使用DANE的TLS客户端必须支持TLS的SNI扩展[RFC6066]。服务器可能支持SNI并使用匹配的证书链进行响应，但也可能忽略SNI并使用默认证书链进行响应。当服务器支持SNI但未配置与客户端SNI扩展完全匹配的证书链时，服务器应使用另一个证书链（默认或最接近的匹配）进行响应。这是因为客户端可能支持多个服务器名称，但只能在SNI扩展中输入一个名称。
As mentioned in Section 2, the TLSA Certificate Usage field takes one of four possible values. With PKIX-TA(0) and PKIX-EE(1), the validation of peer certificate chains requires additional preconfigured CA TAs that are mutually trusted by the operators of the TLS server and client. With DANE-TA(2) and DANE-EE(3), no preconfigured CA TAs are required and the published DANE TLSA records are sufficient to verify the peer's certificate chain.
如第2节所述，TLSA证书使用字段采用四个可能值之一。对于PKIX-TA（0）和PKIX-EE（1），对等证书链的验证需要额外的预配置CA TA，这些CA TA由TLS服务器和客户端的操作员相互信任。对于DANE-TA（2）和DANE-EE（3），不需要预配置CA TA，发布的DANE TLSA记录足以验证对等方的证书链。
Standards for application protocols that employ DANE TLSA can specify more specific guidance than [RFC6698] or this document. Such application-specific standards need to carefully consider which set of DANE certificate usages to support. Simultaneous support for all four usages is NOT RECOMMENDED for DANE clients. When all four usages are supported, an attacker capable of compromising the integrity of DNSSEC needs only to replace the server's TLSA RRset with one that lists suitable DANE-EE(3) or DANE-TA(2) records, effectively bypassing any added verification via public CAs. In other words, when all four usages are supported, PKIX-TA(0) and PKIX-EE(1) offer only illusory incremental security over DANE-TA(2) and DANE-EE(3).
采用DANE TLSA的应用协议标准可以比[RFC6698]或本文件规定更具体的指南。这样的应用程序特定标准需要仔细考虑哪一组丹麦证书使用支持。不建议丹麦客户同时支持所有四种用法。当支持所有四种用途时，能够破坏DNSSEC完整性的攻击者只需将服务器的TLSA RRset替换为列出适当DANE-EE（3）或DANE-TA（2）记录的TLSA RRset，即可有效绕过通过公共CA添加的任何验证。换句话说，当所有四种用法都得到支持时，PKIX-TA（0）和PKIX-EE（1）仅在DANE-TA（2）和DANE-EE（3）上提供了虚幻的增量安全性。
Designs in which clients support just the DANE-TA(2) and DANE-EE(3) certificate usages are RECOMMENDED. With DANE-TA(2) and DANE-EE(3), clients don't need to track a large changing list of X.509 TAs in order to successfully authenticate servers whose certificates are issued by a CA that is brand new or not widely trusted.
建议客户机仅支持DANE-TA（2）和DANE-EE（3）证书使用的设计。使用DANE-TA（2）和DANE-EE（3），客户机不需要跟踪X.509 TA的大量变化列表，就可以成功地对其证书由全新或不受广泛信任的CA颁发的服务器进行身份验证。
The DNSSEC TLSA records for servers MAY include both sets of usages if the server needs to support a mixture of clients, some supporting one pair of usages and some the other.
如果服务器需要支持混合客户端，则服务器的DNSSEC TLSA记录可能包括两组用法，一些客户端支持一对用法，另一些客户端支持另一对用法。
When the client's protocol design is based on "Opportunistic Security" (OS) [RFC7435] and the use of authentication is based on the presence of server TLSA records, it is especially important to avoid the PKIX-EE(1) and PKIX-TA(0) certificate usages.
当客户端的协议设计基于“机会主义安全”（OS）[RFC7435]并且身份验证的使用基于服务器TLSA记录的存在时，避免使用PKIX-EE（1）和PKIX-TA（0）证书尤为重要。
When authenticated TLS is used opportunistically based on the presence of DANE TLSA records and no secure TLSA records are present, unauthenticated TLS is used if possible, and if TLS is not possible, perhaps even cleartext. However, if usable secure TLSA records are published, then authentication MUST succeed. Also, outside the browser space, there is no preordained canon of trusted CAs, and in any case there is no security advantage in using PKIX-TA(0) or
当基于DANE TLSA记录的存在而机会主义地使用经过身份验证的TLS时，如果不存在安全的TLSA记录，则在可能的情况下使用未经身份验证的TLS，如果TLS不可能，甚至可能使用明文。但是，如果发布了可用的安全TLSA记录，则身份验证必须成功。此外，在浏览器空间之外，没有预先规定的可信CA标准，而且在任何情况下，使用PKIX-TA（0）或
PKIX-EE(1) when the DANE-TA(2) and DANE-EE(3) usages are also supported (as an attacker who can compromise DNS can replace the former with the latter).
也支持DANE-TA（2）和DANE-EE（3）使用时的PKIX-EE（1）（因为可以破坏DNS的攻击者可以将前者替换为后者）。
Authentication via the PKIX-TA(0) and PKIX-EE(1) certificate usages is more brittle; the client and server need to happen to agree on a mutually trusted CA, but with OS the client is just trying to protect the communication channel at the request of the server and would otherwise be willing to use cleartext or unauthenticated TLS. The use of fragile mechanisms (like public CA authentication for some unspecified set of trusted CAs) is not sufficiently reliable for an OS client to honor the server's request for authentication. OS needs to be non-intrusive and to require few, if any, workarounds for valid but mismatched peers.
通过PKIX-TA（0）和PKIX-EE（1）证书使用的身份验证更加脆弱；客户机和服务器需要恰好在相互信任的CA上达成一致，但对于操作系统，客户机只是在服务器请求时试图保护通信通道，否则愿意使用明文或未经验证的TLS。脆弱机制的使用（如对某些未指定的受信任CA集的公共CA身份验证）对于操作系统客户端来说不够可靠，无法满足服务器的身份验证请求。操作系统需要是非侵入性的，并且对于有效但不匹配的对等点，需要很少的（如果有的话）变通方法。
Because the PKIX-TA(0) and PKIX-EE(1) usages offer no more security and are more prone to failure, they are a poor fit for OS and SHOULD NOT be used in that context.
由于PKIX-TA（0）和PKIX-EE（1）的使用没有提供更多的安全性，并且更容易失败，因此它们不适合操作系统，不应在该上下文中使用。
Certificate Transparency (CT) [RFC6962] defines an experimental approach that could be used to mitigate the risk of rogue or compromised public CAs issuing unauthorized certificates. This section clarifies the interaction of the experimental CT and DANE. This section may need to be revised in light of any future Standards Track version of CT.
证书透明性（CT）[RFC6962]定义了一种实验性方法，可用于降低流氓或受损公共CA颁发未经授权证书的风险。本节阐明了实验CT和DANE的相互作用。本节可能需要根据CT的任何未来标准轨道版本进行修订。
When a server is authenticated via a DANE TLSA RR with TLSA certificate usage DANE-EE(3), the domain owner has directly specified the certificate associated with the given service without reference to any public CA. Therefore, when a TLS client authenticates the TLS server via a TLSA record with usage DANE-EE(3), CT checks SHOULD NOT be performed. Publication of the server certificate or public key (digest) in a TLSA record in a DNSSEC-signed zone by the domain owner assures the TLS client that the certificate is not an unauthorized certificate issued by a rogue CA without the domain owner's consent.
当通过DANE TLSA RR和TLSA证书使用DANE-EE（3）对服务器进行身份验证时，域所有者直接指定了与给定服务关联的证书，而不参考任何公共CA。因此，当TLS客户端通过使用DANE-EE（3）的TLSA记录对TLS服务器进行身份验证时，不应进行CT检查。域所有者在DNSSEC签名区域的TLSA记录中发布服务器证书或公钥（摘要），可确保TLS客户端在未经域所有者同意的情况下，该证书不是由恶意CA颁发的未经授权的证书。
When a server is authenticated via a DANE TLSA record with TLSA usage DANE-TA(2) and the server certificate does not chain to a known public root CA, CT cannot apply (CT logs only accept chains that start with a known public root). Since TLSA certificate usage DANE-TA(2) is generally intended to support non-public TAs, TLS clients SHOULD NOT perform CT checks with usage DANE-TA(2).
当服务器通过具有TLSA用法DANE-TA（2）的DANE TLSA记录进行身份验证，并且服务器证书未链接到已知的公共根CA时，CT无法应用（CT日志仅接受以已知公共根开始的链接）。由于TLSA证书使用DANE-TA（2）通常用于支持非公共TA，因此TLS客户端不应使用DANE-TA（2）执行CT检查。
With certificate usages PKIX-TA(0) and PKIX-EE(1), CT applies just as it would without DANE. TLSA records of this type only constrain which CAs are acceptable in PKIX validation. All checks used in the absence of DANE still apply when validating certificate chains with DANE PKIX-TA(0) and PKIX-EE(1) constraints.
对于使用PKIX-TA（0）和PKIX-EE（1）的证书，CT的应用与没有DANE的情况相同。此类型的TLSA记录仅约束PKIX验证中可接受的CA。在验证具有DANE PKIX-TA（0）和PKIX-EE（1）约束的证书链时，在没有DANE的情况下使用的所有检查仍然适用。
The choice of preferred certificate usages may need to change as an application protocol evolves. When transitioning between PKIX-TA/ PKIX-EE and DANE-TA/DANE-EE, clients begin to enable support for the new certificate usage values. If the new preferred certificate usages are PKIX-TA/EE, this requires installing and managing the appropriate set of CA TAs. During this time, servers will publish both types of TLSA records. At some later time, when the vast majority of servers have published the new preferred TLSA records, clients can stop supporting the legacy certificate usages. Similarly, servers can stop publishing legacy TLSA records once the vast majority of clients support the new certificate usages.
首选证书用法的选择可能需要随着应用程序协议的发展而改变。在PKIX-TA/PKIX-EE和DANE-TA/DANE-EE之间转换时，客户端开始支持新的证书使用值。如果新的首选证书使用是PKIX-TA/EE，则需要安装和管理适当的CA-TA集。在此期间，服务器将发布这两种类型的TLSA记录。稍后，当绝大多数服务器发布了新的首选TLSA记录时，客户端可以停止支持旧证书的使用。类似地，一旦绝大多数客户端支持新的证书使用，服务器就可以停止发布遗留TLSA记录。
The four certificate usage values from the TLSA record -- DANE-EE(3), DANE-TA(2), PKIX-EE(1), and PKIX-TA(0) -- are discussed below.
下面讨论TLSA记录中的四个证书使用值——DANE-EE（3）、DANE-TA（2）、PKIX-EE（1）和PKIX-TA（0）。
In this section, the meaning of DANE-EE(3) is updated from [RFC6698] to specify that peer identity matching and validity period enforcement are based solely on the TLSA RRset properties. This document also extends [RFC6698] to cover the use of DANE authentication of raw public keys [RFC7250] via TLSA records with certificate usage DANE-EE(3) and selector SPKI(1).
在本节中，DANE-EE（3）的含义从[RFC6698]更新，以规定对等身份匹配和有效期强制仅基于TLSA RRset属性。本文档还扩展了[RFC6698]以涵盖通过TLSA记录对原始公钥[RFC7250]进行DANE身份验证的使用，该记录具有证书使用DANE-EE（3）和选择器SPKI（1）。
Authentication via certificate usage DANE-EE(3) TLSA records involves simply checking that the server's leaf certificate matches the TLSA record. In particular, the binding of the server public key to its name is based entirely on the TLSA record association. The server MUST be considered authenticated even if none of the names in the certificate match the client's reference identity for the server. This simplifies the operation of servers that host multiple Customer Domains, as a single certificate can be associated with multiple domains without having to match each of the corresponding reference identifiers.
通过证书使用DANE-EE（3）TLSA记录进行身份验证只需检查服务器的叶证书是否与TLSA记录匹配。特别是，服务器公钥与其名称的绑定完全基于TLSA记录关联。即使证书中的名称与服务器的客户端引用标识不匹配，也必须将服务器视为已验证。这简化了托管多个客户域的服务器的操作，因为单个证书可以与多个域关联，而不必匹配每个相应的引用标识符。
; Multiple Customer Domains hosted by an example.net
; Service Provider:
;
www.example.com. IN CNAME ex-com.example.net.
www.example.org. IN CNAME ex-org.example.net.
;
; In the provider's DNS zone, a single certificate and TLSA
; record support multiple Customer Domains, greatly simplifying
; "virtual hosting".
;
ex-com.example.net. IN A 192.0.2.1
ex-org.example.net. IN A 192.0.2.1
_443._tcp.ex-com.example.net. IN CNAME tlsa._dane.example.net.
_443._tcp.ex-org.example.net. IN CNAME tlsa._dane.example.net.
tlsa._dane.example.net. IN TLSA 3 1 1 e3b0c44298fc1c14...
; Multiple Customer Domains hosted by an example.net
; Service Provider:
;
www.example.com. IN CNAME ex-com.example.net.
www.example.org. IN CNAME ex-org.example.net.
;
; In the provider's DNS zone, a single certificate and TLSA
; record support multiple Customer Domains, greatly simplifying
; "virtual hosting".
;
ex-com.example.net. IN A 192.0.2.1
ex-org.example.net. IN A 192.0.2.1
_443._tcp.ex-com.example.net. IN CNAME tlsa._dane.example.net.
_443._tcp.ex-org.example.net. IN CNAME tlsa._dane.example.net.
tlsa._dane.example.net. IN TLSA 3 1 1 e3b0c44298fc1c14...
Also, with DANE-EE(3), the expiration date of the server certificate MUST be ignored. The validity period of the TLSA record key binding is determined by the validity period of the TLSA record DNSSEC signatures. Validity is reaffirmed on an ongoing basis by continuing to publish the TLSA record and signing the zone in which the record is contained, rather than via dates "set in stone" in the certificate. The expiration becomes a reminder to the administrator that it is likely time to rotate the key, but missing the date no longer causes an outage. When keys are rotated (for whatever reason), it is important to follow the procedures outlined in Section 8.
此外，对于DANE-EE（3），必须忽略服务器证书的过期日期。TLSA记录密钥绑定的有效期由TLSA记录DNSSEC签名的有效期确定。通过继续发布TLSA记录并在记录所在区域签字，而不是通过证书中“固定”的日期，持续确认有效性。过期将提醒管理员，可能是轮换密钥的时候了，但错过日期将不再导致停机。旋转键时（无论出于何种原因），务必遵循第8节中概述的程序。
If a server uses just DANE-EE(3) TLSA records and all its clients are DANE clients, the server need not employ SNI (i.e., it may ignore the client's SNI message) even when the server is known via multiple domain names that would otherwise require separate certificates. It is instead sufficient for the TLSA RRsets for all the domain names in question to match the server's default certificate. For application protocols where the server name is obtained indirectly via SRV records, MX records, or similar records, it is simplest to publish a single hostname as the target server name for all the hosted domains.
如果服务器仅使用DANE-EE（3）TLSA记录，且其所有客户端都是DANE客户端，则即使通过多个域名知道服务器，服务器也不需要使用SNI（即，它可能忽略客户端的SNI消息），否则需要单独的证书。相反，所有相关域名的TLSA RRSET足以匹配服务器的默认证书。对于通过SRV记录、MX记录或类似记录间接获取服务器名称的应用程序协议，最简单的方法是将单个主机名发布为所有托管域的目标服务器名称。
In organizations where it is practical to make coordinated changes in DNS TLSA records before server key rotation, it is generally best to publish end-entity DANE-EE(3) certificate associations in preference to other choices of certificate usage. DANE-EE(3) TLSA records support multiple server names without SNI, don't suddenly stop working when leaf or intermediate certificates expire, and don't fail when a server operator neglects to include all the required issuer certificates in the server certificate chain.
在可以在服务器密钥轮换之前对DNS TLSA记录进行协调更改的组织中，通常最好发布最终实体DANE-EE（3）证书关联，而不是其他证书使用选择。DANE-EE（3）TLSA记录支持无SNI的多个服务器名称，在叶证书或中间证书过期时不会突然停止工作，并且在服务器操作员忽略在服务器证书链中包含所有必需的颁发者证书时不会失败。
More specifically, it is RECOMMENDED that at most sites TLSA records published for DANE servers be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Selector SPKI(1) is chosen because it is compatible with raw public keys [RFC7250] and the resulting TLSA record need not change across certificate renewals with the same key. Matching type SHA2-256(1) is chosen because all DANE implementations are required to support SHA2-256. This TLSA record type easily supports hosting arrangements with a single certificate matching all hosted domains. It is also the easiest to implement correctly in the client.
更具体地说，建议在大多数站点上，为DANE服务器发布的TLSA记录应为“DANE-EE（3）SPKI（1）SHA2-256（1）”记录。选择选择器SPKI（1）是因为它与原始公钥[RFC7250]兼容，并且生成的TLSA记录不需要在使用相同密钥的证书续订期间更改。选择匹配类型SHA2-256（1），因为所有DANE实现都需要支持SHA2-256。此TLSA记录类型可以轻松地支持使用单个证书匹配所有托管域的托管安排。它也是最容易在客户机中正确实现的。
Clients that support raw public keys can use DANE TLSA records with certificate usage DANE-EE(3) and selector SPKI(1) to authenticate servers that negotiate the use of raw public keys. Provided the server adheres to the requirements of Section 8, the fact that raw public keys are not compatible with any other TLSA record types will not get in the way of successful authentication. Clients that employ DANE to authenticate the peer server SHOULD NOT negotiate the use of raw public keys unless the server's TLSA RRset includes "DANE-EE(3) SPKI(1)" TLSA records.
支持原始公钥的客户端可以使用DANE TLSA记录和证书使用DANE-EE（3）和选择器SPKI（1）对协商使用原始公钥的服务器进行身份验证。如果服务器遵守第8节的要求，则原始公钥与任何其他TLSA记录类型不兼容的事实将不会妨碍成功的身份验证。使用DANE对对等服务器进行身份验证的客户端不应协商原始公钥的使用，除非服务器的TLSA RRset包含“DANE-EE（3）SPKI（1）”TLSA记录。
While it is, in principle, also possible to authenticate raw public keys via "DANE-EE(3) Cert(0) Full(0)" records by extracting the public key from the certificate in DNS, extracting just the public key from a "3 0 0" TLSA record requires extra logic on clients that not all implementations are expected to provide. Servers that wish to support [RFC7250] raw public keys need to publish TLSA records with a certificate usage of DANE-EE(3) and a selector of SPKI(1).
虽然原则上也可以通过从DNS中的证书提取公钥，通过“DANE-EE（3）Cert（0）Full（0）”记录对原始公钥进行身份验证，但仅从“3 0”TLSA记录提取公钥需要客户端上的额外逻辑，并非所有实现都会提供这种逻辑。希望支持[RFC7250]原始公钥的服务器需要使用DANE-EE（3）和SPKI（1）选择器发布TLSA记录。
While DANE-EE(3) TLSA records are expected to be by far the most prevalent, as explained in Section 5.2, DANE-TA(2) records are a valid alternative for sites with many DANE services. Note, however, that virtual hosting is more complex with DANE-TA(2). Also, with DANE-TA(2), server operators MUST ensure that the server is configured with a sufficiently complete certificate chain and need to remember to replace certificates prior to their expiration dates.
正如第5.2节所述，虽然DANE-EE（3）TLSA记录预计是目前最普遍的记录，但DANE-TA（2）记录是具有许多DANE服务的现场的有效替代方案。然而，请注意，使用DANE-TA（2），虚拟主机更为复杂。此外，对于DANE-TA（2），服务器操作员必须确保服务器配置了足够完整的证书链，并且需要记住在证书过期之前更换证书。
This section updates [RFC6698] by specifying a new operational requirement for servers publishing TLSA records with a usage of DANE-TA(2): such servers MUST include the TA certificate in their TLS server certificate message unless all such TLSA records are "2 0 0" records that publish the server certificate in full.
本节通过指定使用DANE-TA（2）发布TLSA记录的服务器的新操作要求来更新[RFC6698]：此类服务器必须在其TLS服务器证书消息中包含TA证书，除非所有此类TLSA记录都是完整发布服务器证书的“2 0”记录。
Some domains may prefer to avoid the operational complexity of publishing unique TLSA RRs for each TLS service. If the domain employs a common issuing CA to create certificates for multiple TLS services, it may be simpler to publish the issuing authority as a TA
某些域可能希望避免为每个TLS服务发布唯一TLSA RRs的操作复杂性。如果域使用公共颁发CA为多个TLS服务创建证书，则将颁发机构发布为TA可能更简单
for the certificate chains of all relevant services. The TLSA query domain (TLSA base domain with port and protocol prefix labels) for each service issued by the same TA may then be set to a CNAME alias that points to a common TLSA RRset that matches the TA. For example:
用于所有相关服务的证书链。然后，可以将同一TA发布的每个服务的TLSA查询域（带有端口和协议前缀标签的TLSA基本域）设置为CNAME别名，该别名指向与TA匹配的公共TLSA RRset。例如：
; Two servers, each with its own certificate, that share
; a common issuer (TA).
;
www1.example.com. IN A 192.0.2.1
www2.example.com. IN A 192.0.2.2
_443._tcp.www1.example.com. IN CNAME tlsa._dane.example.com.
_443._tcp.www2.example.com. IN CNAME tlsa._dane.example.com.
tlsa._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14...
; Two servers, each with its own certificate, that share
; a common issuer (TA).
;
www1.example.com. IN A 192.0.2.1
www2.example.com. IN A 192.0.2.2
_443._tcp.www1.example.com. IN CNAME tlsa._dane.example.com.
_443._tcp.www2.example.com. IN CNAME tlsa._dane.example.com.
tlsa._dane.example.com. IN TLSA 2 0 1 e3b0c44298fc1c14...
The above configuration simplifies server key rotation, because while the servers continue to receive new certificates from a CA matched by the shared (target of the CNAMEs) TLSA record, server certificates can be updated without making any DNS changes. As the list of active issuing CAs changes, the shared TLSA record will be updated (much less frequently) by the administrators who manage the CAs. Those administrators still need to perform TLSA record updates with care, as described in Section 8.
上述配置简化了服务器密钥轮换，因为当服务器继续从与共享（CNAMEs的目标）TLSA记录匹配的CA接收新证书时，可以在不进行任何DNS更改的情况下更新服务器证书。随着活动颁发CA列表的更改，管理CA的管理员将更新共享TLSA记录（频率要低得多）。这些管理员仍然需要小心地执行TLSA记录更新，如第8节所述。
With usage DANE-TA(2), the server certificates will need to have names that match one of the client's reference identifiers (see [RFC6125]). When hosting multiple unrelated Customer Domains (that can't all appear in a single certificate), such a server SHOULD employ SNI to select the appropriate certificate to present to the client.
使用DANE-TA（2）时，服务器证书的名称必须与客户机的一个引用标识符相匹配（请参见[RFC6125]）。当托管多个不相关的客户域（这些域不能全部出现在一个证书中）时，这样的服务器应该使用SNI来选择适当的证书以呈现给客户端。
TLSA records with a matching type of Full(0) are NOT RECOMMENDED. While these potentially obviate the need to transmit the TA certificate in the TLS server certificate message, client implementations may not be able to augment the server certificate chain with the data obtained from DNS, especially when the TLSA record supplies a bare key (selector SPKI(1)). Since the server will need to transmit the TA certificate in any case, server operators SHOULD publish TLSA records with a matching type other than Full(0) and avoid potential DNS interoperability issues with large TLSA records containing full certificates or keys (see Section 10.1.1).
不建议使用匹配类型为Full（0）的TLSA记录。虽然这些可能消除了在TLS服务器证书消息中传输TA证书的需要，但客户端实现可能无法使用从DNS获得的数据来扩充服务器证书链，特别是当TLSA记录提供裸密钥时（选择器SPKI（1））。由于服务器在任何情况下都需要传输TA证书，因此服务器运营商应发布与完整（0）以外的匹配类型的TLSA记录，并避免与包含完整证书或密钥的大型TLSA记录存在潜在的DNS互操作性问题（见第10.1.1节）。
TLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of Cert(0). Such TLSA records are associated with the whole TA certificate, not just with the TA public key. In particular, when authenticating the peer certificate chain via such a TLSA record, the client SHOULD apply any relevant constraints from the TA certificate, such as, for example, path length constraints.
使用DANE-TA（2）记录的TLSA发布者应使用证书选择器（0）发布记录。此类TLSA记录与整个TA证书相关联，而不仅仅与TA公钥相关联。具体地，当通过这样的TLSA记录认证对等证书链时，客户端应该应用来自TA证书的任何相关约束，例如，路径长度约束。
While a selector of SPKI(1) may also be employed, the resulting TLSA record will not specify the full TA certificate content, and elements of the TA certificate other than the public key become mutable. This may, for example, enable a subsidiary CA to issue a chain that violates the TA's path length or name constraints.
虽然也可以使用SPKI（1）的选择器，但生成的TLSA记录将不会指定完整的TA证书内容，并且TA证书中除公钥以外的元素将变得可变。例如，这可能使附属CA能够发出违反TA路径长度或名称约束的链。
With DANE-TA(2), a complication arises when the TA certificate is omitted from the server's certificate chain, perhaps on the basis of Section 7.4.2 of [RFC5246]:
对于DANE-TA（2），当TA证书从服务器的证书链中省略时，可能根据[RFC5246]的第7.4.2节，会出现复杂情况：
The sender's certificate MUST come first in the list. Each following certificate MUST directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.
发件人的证书必须排在列表的第一位。下列证书必须直接证明其前面的证书。由于证书验证要求独立分发根密钥，因此可以从链中省略指定根证书颁发机构的自签名证书，前提是远程端必须已经拥有该证书，以便在任何情况下对其进行验证。
With TLSA certificate usage DANE-TA(2), there is no expectation that the client is preconfigured with the TA certificate. In fact, client implementations are free to ignore all locally configured TAs when processing usage DANE-TA(2) TLSA records and may rely exclusively on the certificates provided in the server's certificate chain. But, with a digest in the TLSA record, the TLSA record contains neither the full TA certificate nor the full public key. If the TLS server's certificate chain does not contain the TA certificate, DANE clients will be unable to authenticate the server.
在TLSA证书使用DANE-TA（2）的情况下，不期望客户机预先配置了TA证书。事实上，客户机实现在处理使用情况DANE-TA（2）TLSA记录时可以自由忽略所有本地配置的TA，并且可以完全依赖服务器证书链中提供的证书。但是，由于TLSA记录中有摘要，TLSA记录既不包含完整的TA证书，也不包含完整的公钥。如果TLS服务器的证书链不包含TA证书，DANE客户端将无法对服务器进行身份验证。
TLSA Publishers that publish TLSA certificate usage DANE-TA(2) associations with a selector of SPKI(1) or with a digest-based matching type (not Full(0)) MUST ensure that the corresponding server is configured to also include the TA certificate in its TLS handshake certificate chain, even if that certificate is a self-signed root CA and would have been optional in the context of the existing public CA PKI.
发布TLSA证书使用DANE-TA（2）与SPKI（1）选择器或基于摘要的匹配类型（不完整（0））关联的TLSA发布者必须确保相应的服务器配置为在其TLS握手证书链中也包含TA证书，即使该证书是自签名根CA，并且在现有公共CA PKI的上下文中是可选的。
Only when the server TLSA record includes a "DANE-TA(2) Cert(0) Full(0)" TLSA record containing a full TA certificate is the TA certificate optional in the server's TLS certificate message. This is also the only type of DANE-TA(2) record for which the client MUST be able to verify the server's certificate chain even if the TA certificate appears only in DNS and is absent from the TLS handshake server certificate message.
只有当服务器TLSA记录包含包含完整TA证书的“DANE-TA（2）证书（0）完整（0）”TLSA记录时，在服务器的TLS证书消息中TA证书才是可选的。这也是唯一一种DANE-TA（2）记录类型，客户机必须能够验证服务器的证书链，即使TA证书仅出现在DNS中，并且在TLS握手服务器证书消息中不存在。
TLSA records with TLSA certificate usage DANE-TA(2), selector SPKI(1), and a matching type of Full(0) publish the full public key of a TA via DNS. In Section 6.1.1 of [RFC5280], the definition of a TA consists of the following four parts:
具有TLSA证书使用DANE-TA（2）、选择器SPKI（1）和匹配的完整类型（0）的TLSA记录通过DNS发布TA的完整公钥。在[RFC5280]第6.1.1节中，TA的定义包括以下四部分：
1. the trusted issuer name,
1. 受信任的颁发者名称，
2. the trusted public key algorithm,
2. 可信公钥算法，
3. the trusted public key, and
3. 受信任的公钥，以及
4. optionally, the trusted public key parameters associated with the public key.
4. （可选）与公钥关联的受信任公钥参数。
Items 2-4 are precisely the contents of the subjectPublicKeyInfo published in the TLSA record. The issuer name is not included in the subjectPublicKeyInfo.
第2-4项正是TLSA记录中发布的主题PublicKeyInfo的内容。主体PublicKeyInfo中不包括发卡机构名称。
With TLSA certificate usage DANE-TA(2), the client may not have the associated TA certificate and cannot generally verify whether or not a particular certificate chain is "issued by" the TA described in the TLSA record.
使用TLSA证书使用DANE-TA（2），客户端可能没有关联的TA证书，并且通常无法验证特定证书链是否由TLSA记录中描述的TA“颁发”。
When the server certificate chain includes a CA certificate whose public key matches the TLSA record, the client can match that CA as the intended issuer. Otherwise, the client can only check that the topmost certificate in the server's chain is "signed by" the TA's public key in the TLSA record. Such a check may be difficult to implement and cannot be expected to be supported by all clients.
当服务器证书链包含其公钥与TLSA记录匹配的CA证书时，客户端可以将该CA作为目标颁发者进行匹配。否则，客户端只能检查服务器链中最顶层的证书是否由TLSA记录中TA的公钥“签名”。这样的检查可能难以实施，并且不能期望所有客户都支持。
Thus, servers cannot rely on "DANE-TA(2) SPKI(1) Full(0)" TLSA records to be sufficient to authenticate chains issued by the associated public key in the absence of a corresponding certificate in the server's TLS certificate message. Servers employing "2 1 0" TLSA records MUST include the corresponding TA certificate in their certificate chain.
因此，服务器不能依赖“DANE-TA（2）SPKI（1）完整（0）”TLSA记录来在服务器的TLS证书消息中没有相应证书的情况下对相关公钥颁发的链进行足够的身份验证。使用“2 1 0”TLSA记录的服务器必须在其证书链中包含相应的TA证书。
If none of the server's certificate chain elements match a public key specified in a TLSA record, and at least one "DANE-TA(2) SPKI(1) Full(0)" TLSA record is available, it is RECOMMENDED that clients check to see whether or not the topmost certificate in the chain is signed by the provided public key and has not expired, and in that case consider the server authenticated, provided the rest of the chain passes validation, including leaf certificate name checks.
如果服务器的证书链元素都与TLSA记录中指定的公钥不匹配，并且至少有一条“DANE-TA（2）SPKI（1）Full（0）”TLSA记录可用，建议客户端检查链中最顶端的证书是否由提供的公钥签名且未过期，在这种情况下，考虑服务器的身份验证，前提是链的其余部分通过验证，包括叶证书名称检查。
This certificate usage is similar to DANE-EE(3); but, in addition, PKIX verification is required. Therefore, name checks, certificate expiration, CT, etc. apply as they would without DANE.
该证书的用法类似于DANE-EE（3）；但是，此外，还需要PKIX验证。因此，名称检查、证书到期、CT等适用于没有DANE的情况。
This section updates [RFC6698] by specifying new client implementation requirements. Clients that trust intermediate certificates MUST be prepared to construct longer PKIX chains than would be required for PKIX alone.
本节通过指定新的客户机实施要求来更新[RFC6698]。信任中间证书的客户端必须准备构建比单独使用PKIX所需更长的PKIX链。
TLSA certificate usage PKIX-TA(0) allows a domain to publish constraints on the set of PKIX CAs trusted to issue certificates for its TLS servers. A PKIX-TA(0) TLSA record matches PKIX-verified trust chains that contain an issuer certificate (root or intermediate) that matches its Certificate Association Data field (typically a certificate or digest).
TLSA证书使用PKIX-TA（0）允许域发布受信任的PKIX CA集上的约束，以便为其TLS服务器颁发证书。PKIX-TA（0）TLSA记录与包含与其证书关联数据字段（通常为证书或摘要）匹配的颁发者证书（根证书或中间证书）的PKIX验证信任链相匹配。
PKIX-TA(0) requires more complex coordination (than with DANE-TA(2) or DANE-EE(3)) between the Customer Domain and the Service Provider in hosting arrangements. Thus, this certificate usage is NOT RECOMMENDED when the Service Provider is not also the TLSA Publisher (at the TLSA base domain obtained via CNAMEs, SRV records, or MX records).
PKIX-TA（0）要求客户域和服务提供商在托管安排中进行更复杂的协调（比与DANE-TA（2）或DANE-EE（3））。因此，当服务提供商不是TLSA发布者时（在通过CNAMEs、SRV记录或MX记录获得的TLSA基本域中），不建议使用此证书。
TLSA Publishers who publish TLSA records for a particular public root CA will expect that clients will only accept chains anchored at that root. It is possible, however, that the client's trusted certificate store includes some intermediate CAs, either with or without the corresponding root CA. When a client constructs a trust chain leading from a trusted intermediate CA to the server leaf certificate, such a "truncated" chain might not contain the trusted root published in the server's TLSA record.
发布特定公共根CA的TLSA记录的TLSA发布者希望客户端只接受锚定在该根上的链。然而，客户机的可信证书存储可能包括一些中间CA，包括或不包括相应的根CA。当客户机构建从可信中间CA到服务器叶证书的信任链时，这样的“截断”链可能不包含在服务器的TLSA记录中发布的受信任根。
If the omitted root is also trusted, the client may erroneously reject the server chain if it fails to determine that the shorter chain it constructed extends to a longer trusted chain that matches the TLSA record. Thus, when matching a usage PKIX-TA(0) TLSA record,
如果省略的根也受信任，则如果客户端无法确定其构造的较短链扩展到与TLSA记录匹配的较长受信任链，则客户端可能会错误地拒绝服务器链。因此，当匹配使用PKIX-TA（0）TLSA记录时，
so long as no matching certificate has yet been found, a client MUST continue extending the chain even after any locally trusted certificate is found. If no TLSA records have matched any of the elements of the chain and the trusted certificate found is not self-issued, the client MUST attempt to build a longer chain in case a certificate closer to the root matches the server's TLSA record.
只要尚未找到匹配的证书，即使在找到任何本地受信任的证书之后，客户端也必须继续扩展链。如果没有TLSA记录与链的任何元素匹配，并且找到的受信任证书不是自行颁发的，则客户端必须尝试构建更长的链，以防更靠近根的证书与服务器的TLSA记录匹配。
Whenever possible, the TLSA Publisher and the Service Provider should be the same entity. Otherwise, they need to coordinate changes to ensure that TLSA records published by the TLSA Publisher don't fall out of sync with the server certificate used by the Service Provider. Such coordination is difficult, and service outages will result when coordination fails.
只要有可能，TLSA发布者和服务提供商应为同一实体。否则，他们需要协调更改，以确保TLSA发布者发布的TLSA记录不会与服务提供商使用的服务器证书不同步。这种协调很困难，协调失败时会导致服务中断。
Publishing the TLSA record in the Service Provider's zone avoids the complexity of bilateral coordination of server certificate configuration and TLSA record management. Even when the TLSA RRset has to be published in the Customer Domain's DNS zone (perhaps the client application does not "chase" CNAMEs to the TLSA base domain), it is possible to employ CNAME records to delegate the content of the TLSA RRset to a domain operated by the Service Provider.
在服务提供商的区域中发布TLSA记录可以避免服务器证书配置和TLSA记录管理的双边协调的复杂性。即使必须在客户域的DNS区域中发布TLSA RRset（客户机应用程序可能不会“追逐”TLSA基本域的CNAME），也可以使用CNAME记录将TLSA RRset的内容委托给服务提供商操作的域。
Only certificate usages DANE-EE(3) and DANE-TA(2) work well with TLSA CNAMEs across organizational boundaries. With PKIX-TA(0) or PKIX-EE(1), the Service Provider would need to obtain certificates in the name of the Customer Domain from a suitable public CA (securely impersonate the customer), or the customer would need to provision the relevant private keys and certificates at the Service Provider's systems.
只有DANE-EE（3）和DANE-TA（2）的证书用法能够跨组织边界与TLSA CNAMEs很好地配合使用。使用PKIX-TA（0）或PKIX-EE（1），服务提供商需要从合适的公共CA（安全模拟客户）以客户域的名义获取证书，或者客户需要在服务提供商的系统上提供相关的私钥和证书。
Certificate Usage DANE-EE(3): In this case, the Service Provider can publish a single TLSA RRset that matches the server certificate or public key digest. The same RRset works for all Customer Domains because name checks do not apply with DANE-EE(3) TLSA records (see Section 5.1). A Customer Domain can create a CNAME record pointing to the TLSA RRset published by the Service Provider.
证书使用DANE-EE（3）：在这种情况下，服务提供商可以发布与服务器证书或公钥摘要匹配的单个TLSA RRset。相同的RRset适用于所有客户域，因为名称检查不适用于DANE-EE（3）TLSA记录（见第5.1节）。客户域可以创建指向服务提供商发布的TLSA RRset的CNAME记录。
Certificate Usage DANE-TA(2): When the Service Provider operates a private CA, the Service Provider is free to issue a certificate bearing any customer's domain name. Without DANE, such a certificate would not pass trust verification, but with DANE, the customer's TLSA RRset that is aliased to the provider's TLSA RRset can delegate authority to the provider's CA for the corresponding service. The Service Provider can generate appropriate
证书使用DANE-TA（2）：当服务提供商运营私人CA时，服务提供商可以自由发布包含任何客户域名的证书。如果没有DANE，此类证书将无法通过信任验证，但如果使用DANE，客户的TLSA RRset（别名为提供商的TLSA RRset）可以将相应服务的权限委托给提供商的CA。服务提供商可以生成适当的
certificates for each customer and use the SNI information provided by clients to select the right certificate chain to present to each client.
为每个客户提供证书，并使用客户提供的SNI信息选择要呈现给每个客户的正确证书链。
Below are example DNS records (assumed "secure" and shown without the associated DNSSEC information, such as record signatures) that illustrate both of the above models in the case of an HTTPS service whose clients all support DANE TLS. These examples work even with clients that don't "chase" CNAMEs when constructing the TLSA base domain (see Section 7 below).
下面是示例DNS记录（假定为“安全”且显示时没有相关的DNSSEC信息，如记录签名），在客户端均支持DANE TLS的HTTPS服务的情况下，说明了上述两种模型。这些示例甚至适用于在构建TLSA基本域时不“追逐”CNAMEs的客户机（请参见下面的第7节）。
; The hosted web service is redirected via a CNAME alias.
; The associated TLSA RRset is also redirected via a CNAME alias.
;
; Certificate usage DANE-EE(3) makes it possible to deploy
; a single provider certificate for all Customer Domains.
;
www1.example.com. IN CNAME w1.example.net.
_443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net.
_443._tcp.w1.example.net. IN TLSA 3 1 1 (
8A9A70596E869BED72C69D97A8895DFA
D86F300A343FECEFF19E89C27C896BC9 )
; The hosted web service is redirected via a CNAME alias.
; The associated TLSA RRset is also redirected via a CNAME alias.
;
; Certificate usage DANE-EE(3) makes it possible to deploy
; a single provider certificate for all Customer Domains.
;
www1.example.com. IN CNAME w1.example.net.
_443._tcp.www1.example.com. IN CNAME _443._tcp.w1.example.net.
_443._tcp.w1.example.net. IN TLSA 3 1 1 (
8A9A70596E869BED72C69D97A8895DFA
D86F300A343FECEFF19E89C27C896BC9 )
;
; A CA at the provider can also issue certificates for each Customer
; Domain and employ the DANE-TA(2) certificate usage to
; designate the provider's CA as a TA.
;
www2.example.com. IN CNAME w2.example.net.
_443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net.
_443._tcp.w2.example.net. IN TLSA 2 0 1 (
C164B2C3F36D068D42A6138E446152F5
68615F28C69BD96A73E354CAC88ED00C )
;
; A CA at the provider can also issue certificates for each Customer
; Domain and employ the DANE-TA(2) certificate usage to
; designate the provider's CA as a TA.
;
www2.example.com. IN CNAME w2.example.net.
_443._tcp.www2.example.com. IN CNAME _443._tcp.w2.example.net.
_443._tcp.w2.example.net. IN TLSA 2 0 1 (
C164B2C3F36D068D42A6138E446152F5
68615F28C69BD96A73E354CAC88ED00C )
With protocols that support explicit transport redirection via DNS MX records, SRV records, or other similar records, the TLSA base domain is based on the redirected transport endpoint rather than the origin domain. With SMTP, for example, when an email service is hosted by a Service Provider, the Customer Domain's MX hostnames will point at the Service Provider's SMTP hosts. When the Customer Domain's DNS zone is signed, the MX hostnames can be securely used as the base
对于支持通过DNS MX记录、SRV记录或其他类似记录进行显式传输重定向的协议，TLSA基域基于重定向的传输端点，而不是源域。例如，使用SMTP，当电子邮件服务由服务提供商托管时，客户域的MX主机名将指向服务提供商的SMTP主机。签署客户域的DNS区域后，MX主机名可以安全地用作基础
domains for TLSA records that are published and managed by the Service Provider. For example (without the required DNSSEC information, such as record signatures):
由服务提供商发布和管理的TLSA记录的域。例如（没有所需的DNSSEC信息，如记录签名）：
; Hosted SMTP service. ; example.com. IN MX 0 mx1.example.net. example.com. IN MX 0 mx2.example.net. _25._tcp.mx1.example.net. IN TLSA 3 1 1 ( 8A9A70596E869BED72C69D97A8895DFA D86F300A343FECEFF19E89C27C896BC9 ) _25._tcp.mx2.example.net. IN TLSA 3 1 1 ( C164B2C3F36D068D42A6138E446152F5 68615F28C69BD96A73E354CAC88ED00C )
; 托管SMTP服务；example.com。在MX 0 mx1.example.net中。example.com。在MX 0 mx2.example.net中_25._tcp.mx1.example.net。在TLSA 3 1中（8A9A70596E869BED72C69D97A8895DFA D86F300A343FECEFF19E89C27C896BC9）25.\u tcp.mx2.example.net。在TLSA 3 1中（C164B2C3F36D068D42A613E446152F5 68615F28C69BD96A73E354CAC88ED00C）
If redirection to the Service Provider's domain (via MX records, SRV records, or any similar mechanism) is not possible and aliasing of the TLSA record is not an option, then more complex coordination between the Customer Domain and Service Provider will be required. Either the Customer Domain periodically provides private keys and a corresponding certificate chain to the provider (after making appropriate changes in its TLSA records), or the Service Provider periodically generates the keys and certificates and needs to wait for matching TLSA records to be published by its Customer Domains before deploying newly generated keys and certificate chains. Section 7 below describes an approach that employs CNAME "chasing" to avoid the difficulties of coordinating key management across organizational boundaries.
如果无法重定向到服务提供商的域（通过MX记录、SRV记录或任何类似机制），并且TLSA记录的别名不是一个选项，则需要在客户域和服务提供商之间进行更复杂的协调。客户域定期向提供商提供私钥和相应的证书链（在对其TLSA记录进行适当更改后），或者，服务提供商定期生成密钥和证书，并需要等待其客户域发布匹配的TLSA记录，然后再部署新生成的密钥和证书链。下文第7节描述了一种采用CNAME“追踪”的方法，以避免跨组织边界协调关键管理的困难。
For further information about combining DANE and SRV, please see [RFC7673].
有关合并DANE和SRV的更多信息，请参阅[RFC7673]。
When the application protocol does not support service location indirection via MX, SRV, or similar DNS records, the service may be redirected via a CNAME. A CNAME is a more blunt instrument for this purpose because, unlike an MX or SRV record, it remaps the entire origin domain to the target domain for all protocols.
当应用程序协议不支持通过MX、SRV或类似DNS记录进行服务位置间接寻址时，可通过CNAME重定向服务。CNAME是一种更为直截了当的工具，因为与MX或SRV记录不同，它将所有协议的整个源域重新映射到目标域。
The complexity of coordinating key management is largely eliminated when DANE TLSA records are found in the Service Provider's domain, as discussed in Section 6. Therefore, DANE TLS clients connecting to a server whose domain name is a CNAME alias SHOULD follow the CNAME "hop by hop" to its ultimate target host (noting at each step whether or not the CNAME is DNSSEC validated). If at each stage of CNAME expansion the DNSSEC validation status is "secure", the final target name SHOULD be the preferred base domain for TLSA lookups.
如第6节所述，当在服务提供商的域中找到DANE TLSA记录时，协调密钥管理的复杂性基本上被消除。因此，连接到域名为CNAME别名的服务器的DANE TLS客户端应遵循CNAME“逐跳”到其最终目标主机（在每个步骤中注意CNAME是否经过DNSSEC验证）。如果在CNAME扩展的每个阶段，DNSSEC验证状态为“安全”，则最终目标名称应为TLSA查找的首选基本域。
Implementations failing to find a TLSA record using a base name of the final target of a CNAME expansion SHOULD issue a TLSA query using the original destination name. That is, the preferred TLSA base domain SHOULD be derived from the fully expanded name and, failing that, SHOULD be the initial domain name.
未能使用CNAME扩展的最终目标的基名称找到TLSA记录的实现应使用原始目标名称发出TLSA查询。也就是说，首选TLSA基本域应该从完全扩展的名称派生，如果扩展失败，则应该是初始域名。
When the TLSA base domain is the result of "secure" CNAME expansion, the resulting domain name MUST be used as the HostName in the client's SNI extension and MUST be the primary reference identifier for peer certificate matching with certificate usages other than DANE-EE(3).
当TLSA基本域是“安全”CNAME扩展的结果时，生成的域名必须用作客户端SNI扩展中的主机名，并且必须是与DANE-EE（3）以外的证书用法相匹配的对等证书的主要参考标识符。
Protocol-specific TLSA specifications may provide additional guidance or restrictions when following CNAME expansions.
协议特定的TLSA规范可在CNAME扩展后提供额外的指导或限制。
Though CNAMEs are illegal on the right-hand side of most indirection records, such as MX and SRV records, they are supported by some implementations. For example, if the MX or SRV host is a CNAME alias, some implementations may "chase" the CNAME. If they do, they SHOULD use the target hostname as the preferred TLSA base domain as described above (and, if the TLSA records are found there, also use the CNAME-expanded domain in SNI and certificate name checks).
尽管CNAME在大多数间接记录（如MX和SRV记录）的右侧是非法的，但一些实现支持CNAME。例如，如果MX或SRV主机是CNAME别名，则某些实现可能会“追逐”CNAME。如果他们这样做，他们应该使用目标主机名作为首选TLSA基本域，如上所述（如果在那里找到TLSA记录，还应该在SNI和证书名称检查中使用CNAME扩展域）。
This section updates [RFC6698] by specifying that the TLSA Publisher MUST ensure that each combination of certificate usage, selector, and matching type in the server's TLSA RRset includes at least one record that matches the server's current certificate chain. TLSA records that match recently retired or yet-to-be-deployed certificate chains will be present during key rollover. Such past or future records MUST NOT at any time be the only records published for any given combination of usage, selector, and matching type. The TLSA record update process described below ensures that this requirement is met.
本节通过指定TLSA发布者必须确保服务器TLSA RRset中的证书使用、选择器和匹配类型的每个组合至少包括一条与服务器当前证书链匹配的记录来更新[RFC6698]。密钥翻转期间，将出现与最近失效或尚未部署的证书链匹配的TLSA记录。此类过去或未来记录在任何时候都不得是针对任何给定的使用、选择器和匹配类型组合发布的唯一记录。下面描述的TLSA记录更新过程确保满足此要求。
While a server is to be considered authenticated when its certificate chain is matched by any of the published TLSA records, not all clients support all combinations of TLSA record parameters. Some clients may not support some digest algorithms; others may either not support or exclusively support the PKIX certificate usages. Some clients may prefer to negotiate [RFC7250] raw public keys, which are only compatible with TLSA records whose certificate usage is DANE-EE(3) with selector SPKI(1). The only other TLSA record type that is potentially compatible with raw public keys is "DANE-EE(3) Cert(0) Full(0)", but support for raw public keys with that TLSA record type is not expected to be broadly implemented.
虽然当服务器的证书链与任何已发布的TLSA记录匹配时，服务器将被视为经过身份验证，但并非所有客户端都支持TLSA记录参数的所有组合。某些客户端可能不支持某些摘要算法；其他人可能不支持或仅支持PKIX证书使用。一些客户端可能更喜欢协商[RFC7250]原始公钥，这些公钥仅与证书使用为DANE-EE（3）的TLSA记录兼容，并带有选择器SPKI（1）。唯一可能与原始公钥兼容的其他TLSA记录类型是“DANE-EE（3）Cert（0）Full（0）”，但预计不会广泛实现对该TLSA记录类型的原始公钥的支持。
A consequence of the above uncertainty as to which TLSA parameters are supported by any given client is that servers need to ensure that each and every parameter combination that appears in the TLSA RRset is, on its own, sufficient to match the server's current certificate chain. In particular, when deploying new keys or new parameter combinations, some care is required to not generate parameter combinations that only match past or future certificate chains (or raw public keys). The rest of this section explains how to update the TLSA RRset in a manner that ensures that the above requirement is met.
上述关于任何给定客户端支持哪些TLSA参数的不确定性的结果是，服务器需要确保TLSA RRset中出现的每个参数组合本身足以匹配服务器的当前证书链。特别是，在部署新密钥或新参数组合时，需要注意不要生成仅匹配过去或未来证书链（或原始公钥）的参数组合。本节其余部分解释了如何以确保满足上述要求的方式更新TLSA RRset。
The simplest case is key rollover while retaining the same set of published parameter combinations. In this case, TLSA records matching the existing server certificate chain (or raw public keys) are first augmented with corresponding records matching the future keys, at least two Times to Live (TTLs) or longer before the new chain is deployed. This allows the obsolete RRset to age out of client caches before the new chain is used in TLS handshakes. Once sufficient time has elapsed and all clients performing DNS lookups are retrieving the updated TLSA records, the server administrator may deploy the new certificate chain, verify that it works, and then remove any obsolete records matching the chain that is no longer active:
最简单的情况是键翻转，同时保留同一组已发布的参数组合。在这种情况下，与现有服务器证书链（或原始公钥）匹配的TLSA记录首先使用与未来密钥匹配的相应记录进行扩充，在部署新链之前，至少两次生存（TTLs）或更长时间。这允许过时的RRset在TLS握手中使用新链之前从客户端缓存中老化。一旦经过足够的时间并且所有执行DNS查找的客户端都在检索更新的TLSA记录，服务器管理员可以部署新的证书链，验证它是否有效，然后删除与不再活动的链匹配的任何过时记录：
; Initial TLSA RRset. ; _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
; 初始TLSA RRset_443._tcp.www.example.org。在TLSA 3 1 1 01d09d19c2139a46中。。。
; Transitional TLSA RRset published at least two TTLs before
; the actual key change.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; Transitional TLSA RRset published at least two TTLs before
; the actual key change.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; Final TLSA RRset after the key change. ; _443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; 密钥更改后的最终TLSA RRset_443._tcp.www.example.org。在TLSA 3 1 7aa7a5359173d05b中。。。
The next case to consider is adding or switching to a new combination of TLSA parameters. In this case, publish the new parameter combinations for the server's existing certificate chain first, and only then deploy new keys if desired:
下一个要考虑的问题是添加或切换到TLSA参数的新组合。在这种情况下，首先发布服务器现有证书链的新参数组合，然后根据需要部署新密钥：
; Initial TLSA RRset. ; _443._tcp.www.example.org. IN TLSA 1 1 1 01d09d19c2139a46...
; 初始TLSA RRset_443._tcp.www.example.org。在TLSA 1 01d09d19c2139a46中。。。
; New TLSA RRset, same key re-published as DANE-EE(3). ; _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
; 新TLSA RRset，与DANE-EE（3）重新发布的密钥相同_443._tcp.www.example.org。在TLSA 3 1 1 01d09d19c2139a46中。。。
This section explains how to migrate to a new certificate chain and TLSA record with usage DANE-TA(2) from a self-signed server certificate and a "DANE-EE(3) SPKI(1) SHA2-256(1)" TLSA record. This example assumes that a new private key is generated in conjunction with transitioning to a new certificate issued by the desired TA.
本节介绍如何从自签名服务器证书和“DANE-EE（3）SPKI（1）SHA2-256（1）”TLSA记录迁移到使用DANE-TA（2）的新证书链和TLSA记录。本例假设生成新私钥的同时转换为所需TA颁发的新证书。
The original "3 1 1" TLSA record supports [RFC7250] raw public keys, and clients may choose to negotiate their use. The use of raw public keys rules out the possibility of certificate chain verification. Therefore, the transitional TLSA record for the planned DANE-TA(2) certificate chain is a "3 1 1" record that works even when raw public keys are used. The TLSA RRset is updated to use DANE-TA(2) only after the new chain is deployed and the "3 1 1" record matching the original key is dropped.
原始的“3 1 1”TLSA记录支持[RFC7250]原始公钥，客户端可以选择协商它们的使用。使用原始公钥排除了证书链验证的可能性。因此，计划中的DANE-TA（2）证书链的过渡TLSA记录是一个“3 1”记录，即使在使用原始公钥时也能工作。只有在部署新链并删除与原始密钥匹配的“3 1 1”记录后，TLSA RRset才会更新为使用DANE-TA（2）。
This process follows the requirement that each combination of parameters present in the RRset is always sufficient to validate the server. It avoids publishing a transitional TLSA RRset in which "3 1 1" matches only the current key and "2 0 1" matches only the future certificate chain, because these might not work reliably during the initial deployment of the new keys.
此过程遵循以下要求：RRset中存在的每个参数组合始终足以验证服务器。它避免发布过渡TLSA RRset，其中“3 1 1”仅匹配当前密钥，“2 0 1”仅匹配未来证书链，因为这些可能在新密钥的初始部署期间无法可靠工作。
; Initial TLSA RRset. ; _443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
; 初始TLSA RRset_443._tcp.www.example.org。在TLSA 3 1 1 01d09d19c2139a46中。。。
; Transitional TLSA RRset, published at least two TTLs before the
; actual key change. The new keys are issued by a DANE-TA(2) CA
; but are initially specified via a DANE-EE(3) association.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; Transitional TLSA RRset, published at least two TTLs before the
; actual key change. The new keys are issued by a DANE-TA(2) CA
; but are initially specified via a DANE-EE(3) association.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; The final TLSA RRset after the key change. Now that the old
; self-signed EE key is out of the picture, publish the issuing
; TA of the new chain.
;
_443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...
; The final TLSA RRset after the key change. Now that the old
; self-signed EE key is out of the picture, publish the issuing
; TA of the new chain.
;
_443._tcp.www.example.org. IN TLSA 2 0 1 c57bce38455d9e3d...
When employing a new digest algorithm in the TLSA RRset, for compatibility with digest algorithm agility as specified in Section 9 below, administrators SHOULD publish the new digest algorithm with each combination of certificate usage and selector for each associated key or chain used with any other digest algorithm. When removing an algorithm, remove it entirely. Each digest algorithm employed SHOULD match the same set of chains (or raw public keys).
当在TLSA RRset中使用新的摘要算法时，为了与下面第9节中指定的摘要算法敏捷性兼容，管理员应发布新的摘要算法，并为与任何其他摘要算法一起使用的每个相关密钥或链的证书使用和选择器的每种组合。删除算法时，请将其完全删除。使用的每个摘要算法都应该匹配相同的链集（或原始公钥）。
; Initial TLSA RRset with "DANE-EE(3) SHA2-256(1)" associations
; for two keys.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; Initial TLSA RRset with "DANE-EE(3) SHA2-256(1)" associations
; for two keys.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
; New TLSA RRset, also with SHA2-512(2) associations
; for each key.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
_443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...
; New TLSA RRset, also with SHA2-512(2) associations
; for each key.
;
_443._tcp.www.example.org. IN TLSA 3 1 1 01d09d19c2139a46...
_443._tcp.www.example.org. IN TLSA 3 1 2 d9947c35089310bc...
_443._tcp.www.example.org. IN TLSA 3 1 1 7aa7a5359173d05b...
_443._tcp.www.example.org. IN TLSA 3 1 2 89a7486a4b6ae714...
In summary, server operators updating TLSA records should make one change at a time. The individual safe changes are as follows:
总之，更新TLSA记录的服务器操作员应该一次进行一次更改。个别安全更改如下所示：
o Pre-publish new certificate associations that employ the same TLSA parameters (usage, selector, and matching type) as existing TLSA records, but match certificate chains that will be deployed in the near future.
o 预发布新的证书关联，这些关联使用与现有TLSA记录相同的TLSA参数（用法、选择器和匹配类型），但匹配将在不久的将来部署的证书链。
o Wait for stale TLSA RRsets to expire from DNS caches before configuring servers to use the new certificate chain.
o 在配置服务器以使用新证书链之前，请等待过时的TLSA RRSET从DNS缓存中过期。
o Remove TLSA records matching any certificate chains that are no longer deployed.
o 删除与不再部署的任何证书链匹配的TLSA记录。
o Publish TLSA RRsets in which all parameter combinations (certificate usage, selector, and matching type) present in the RRset match the same set of current and planned certificate chains.
o 发布TLSA RRset，其中RRset中存在的所有参数组合（证书使用、选择器和匹配类型）与当前和计划的同一组证书链匹配。
The above steps are intended to ensure that at all times, and for each combination of usage, selector, and matching type, at least one TLSA record corresponds to the server's current certificate chain. Each combination of certificate usage, selector, and matching type in a server's TLSA RRset SHOULD NOT at any time (including unexpired RRsets in client caches) match only some combination of future or past certificate chains. As a result, no matter what combinations of usage, selector, and matching type may be supported by a given client, they will be sufficient to authenticate the server.
上述步骤旨在确保在任何时候，对于使用、选择器和匹配类型的每个组合，至少有一个TLSA记录对应于服务器的当前证书链。服务器TLSA RRset中的证书使用、选择器和匹配类型的每个组合在任何时候都不应仅匹配未来或过去证书链的某些组合（包括客户端缓存中未过期的RRset）。因此，无论给定客户机支持使用、选择器和匹配类型的何种组合，它们都足以对服务器进行身份验证。
While [RFC6698] specifies multiple digest algorithms, it does not specify a protocol by which the client and TLSA record publisher can agree on the strongest shared algorithm. Such a protocol would allow the client and server to avoid exposure to deprecated weaker algorithms that are published for compatibility with less capable clients but that SHOULD be avoided when possible. Such a protocol is specified below.
虽然[RFC6698]指定了多个摘要算法，但它没有指定一个协议，客户机和TLSA记录发布者可以通过该协议就最强的共享算法达成一致。这样的协议将允许客户机和服务器避免暴露于不推荐的较弱算法中，这些算法是为了与能力较差的客户机兼容而发布的，但在可能的情况下应该避免。下面具体说明了这种协议。
This section defines a protocol for avoiding deprecated digest algorithms when these are published in a peer's TLSA RRset alongside stronger digest algorithms. Note that this protocol never avoids RRs with a DANE matching type of Full(0), as these do not employ a digest algorithm that might someday be weakened by cryptanalysis.
本节定义了一个协议，以避免在对等方的TLSA RRset中发布不推荐的摘要算法以及更强的摘要算法。请注意，该协议从未避免使用完整（0）的DANE匹配类型的RRs，因为这些RRs不使用可能会被密码分析削弱的摘要算法。
Client implementations SHOULD implement a default order of digest algorithms by strength. This order SHOULD be configurable by the administrator or user of the client software. If possible, a configurable mapping from numeric DANE TLSA matching types to underlying digest algorithms provided by the cryptographic library SHOULD be implemented to allow new matching types to be used with software that predates their introduction. Configurable ordering of digest algorithms SHOULD be extensible to any new digest algorithms.
客户端实现应该按照强度实现默认的摘要算法顺序。此顺序应由客户端软件的管理员或用户进行配置。如果可能，应实现从数字DANE TLSA匹配类型到加密库提供的底层摘要算法的可配置映射，以允许新的匹配类型与引入之前的软件一起使用。摘要算法的可配置顺序应可扩展到任何新的摘要算法。
To make digest algorithm agility possible, all published DANE TLSA RRsets MUST conform to the requirements of Section 8. Clients SHOULD use digest algorithm agility when processing the peer's DANE TLSA records. Algorithm agility is to be applied after first discarding any unusable or malformed records (unsupported digest algorithm, or incorrect digest length). For each usage and selector, the client SHOULD process only any usable records with a matching type of Full(0) and the usable records whose digest algorithm is considered by the client to be the strongest among usable records with the given usage and selector.
为了使摘要算法的灵活性成为可能，所有已发布的丹麦TLSA RRSET必须符合第8节的要求。客户端在处理对等方的DANE TLSA记录时应使用摘要算法敏捷性。首先丢弃任何不可用或格式错误的记录（不支持摘要算法或不正确的摘要长度）后，将应用算法敏捷性。对于每个用法和选择器，客户端应仅处理匹配类型为Full（0）的任何可用记录，以及客户端认为其摘要算法在具有给定用法和选择器的可用记录中最强的可用记录。
Example: a client implements digest algorithm agility and prefers SHA2-512(2) over SHA2-256(1), while the server publishes an RRset that employs both digest algorithms as well as a Full(0) record.
示例：客户机实现了摘要算法的灵活性，并且更喜欢SHA2-512（2）而不是SHA2-256（1），而服务器则发布一个既使用摘要算法又使用完整（0）记录的RRset。
_25._tcp.mail.example.com. IN TLSA 3 1 1 ( 3FE246A848798236DD2AB78D39F0651D 6B6E7CA8E2984012EB0A2E1AC8A87B72 ) _25._tcp.mail.example.com. IN TLSA 3 1 2 ( D4F5AF015B46C5057B841C7E7BAB759C BF029526D29520C5BE6A32C67475439E 54AB3A945D80C743347C9BD4DADC9D8D 57FAB78EAA835362F3CA07CCC19A3214 ) _25._tcp.mail.example.com. IN TLSA 3 1 0 ( 3059301306072A8648CE3D020106082A 8648CE3D0301070342000471CB1F504F 9E4B33971376C005445DACD33CD79A28 81C3DED1981F18E7AAA76609DD0E4EF2 8265C82703030AD60C5DBA6FB8A9397A C0FCF06D424C885D484887 )
_25._tcp.mail.example.com。在TLSA 3 1（3FE246A848798236DD2AB78D39F0651D 6B6E7CA8E2984012EB0A2E1AC8A87B72）中，请访问tcp.mail.example.com。在TLSA 3 1 2中（D4F5AF015B46C5057B841C7E7BAB759C BF029526D29520C5BE6A32C674439E 54AB3A945D80C743347C9BD4DADC9D8D 57FAB78EA835362F3CA07CCC19A3214）_25._tcp.mail.example.com。在TLSA 3 1 0中（305930106072A8648CE3D0200106082A 8648CE3D0301070342000471CB1F504F 9E4B3397137C005445DACD33CD79A28 81C3DED1981F18E7AAA76609DD0E4EF2 8265C82703030AD60C5DBA6FB8A9397A C0FCF06D424C885D48484848887）
In this case, the client SHOULD accept a server public key that matches either the "3 1 0" record or the "3 1 2" record, but it SHOULD NOT accept keys that match only the weaker "3 1 1" record.
在这种情况下，客户端应接受与“3 1 0”记录或“3 1 2”记录匹配的服务器公钥，但不应接受仅与较弱的“3 1 1”记录匹配的密钥。
These guidelines provide guidance for using or designing protocols for DANE.
这些指南为使用或设计DANE协议提供了指导。
Selecting a combination of TLSA parameters to use requires careful thought. One important consideration to take into account is the size of the resulting TLSA record after its parameters are selected.
选择要使用的TLSA参数组合需要仔细考虑。需要考虑的一个重要因素是选择参数后产生的TLSA记录的大小。
Deployments SHOULD avoid TLSA record sizes that cause UDP fragmentation.
部署应避免导致UDP碎片的TLSA记录大小。
Although DNS over TCP would provide the ability to more easily transfer larger DNS records between clients and servers, it is not universally deployed and is still prohibited by some firewalls. Clients that request DNS records via UDP typically only use TCP upon receipt of a truncated response in the DNS response message sent over UDP. Setting the Truncation (TC) bit (Section 4.1.1 of [RFC1035]) alone will be insufficient if the response containing the TC bit is itself fragmented.
虽然TCP上的DNS能够更轻松地在客户端和服务器之间传输更大的DNS记录，但它并没有被普遍部署，并且仍然被某些防火墙禁止。通过UDP请求DNS记录的客户端通常仅在收到通过UDP发送的DNS响应消息中的截断响应时使用TCP。如果包含TC位的响应本身是分段的，仅设置截断（TC）位（RFC1035的第4.1.1节）是不够的。
Server operators SHOULD NOT publish TLSA records using both a TLSA selector of Cert(0) and a TLSA matching type of Full(0), as even a single certificate is generally too large to be reliably delivered via DNS over UDP. Furthermore, two TLSA records containing full certificates will need to be published simultaneously during a certificate rollover, as discussed in Section 8.1.
服务器运营商不应同时使用证书（0）的TLSA选择器和完整（0）的TLSA匹配类型发布TLSA记录，因为即使单个证书通常也太大，无法通过UDP通过DNS可靠传递。此外，如第8.1节所述，在证书展期期间，需要同时发布包含完整证书的两个TLSA记录。
While TLSA records using a TLSA selector of SPKI(1) and a TLSA matching type of Full(0) (which publish the bare public keys, i.e., without the overhead of encapsulating the keys in an X.509 certificate) are generally more compact, these are also best avoided when significantly larger than their digests. Rather, servers SHOULD publish digest-based TLSA matching types in their TLSA records, in which case the complete corresponding certificate MUST be transmitted to the client in-band during the TLS handshake. The certificate (or raw public key) can be easily verified using the digest value.
虽然使用SPKI（1）的TLSA选择器和完整（0）的TLSA匹配类型（发布裸公钥，即不需要将密钥封装在X.509证书中的开销）的TLSA记录通常更紧凑，但当它们明显大于摘要时，也最好避免。相反，服务器应该在其TLSA记录中发布基于摘要的TLSA匹配类型，在这种情况下，必须在TLS握手期间将完整的相应证书传输到带内客户端。可以使用摘要值轻松验证证书（或原始公钥）。
In summary, the use of a TLSA matching type of Full(0) is NOT RECOMMENDED, and a digest-based matching type, such as SHA2-256(1), SHOULD be used instead.
总之，不建议使用完整（0）的TLSA匹配类型，而应使用基于摘要的匹配类型，如SHA2-256（1）。
Certificates presented by a TLS server will generally contain a subjectAltName (SAN) extension or a Common Name (CN) element within the subject Distinguished Name (DN). The TLS server's DNS domain name is normally published within these elements, ideally within the SAN extension. (The use of the CN field for this purpose is deprecated.)
TLS服务器提供的证书通常包含subjectAltName（SAN）扩展名或subject可分辨名称（DN）中的Common Name（CN）元素。TLS服务器的DNS域名通常在这些元素中发布，最好是在SAN扩展中发布。（不推荐为此目的使用CN字段。）
When a server hosts multiple domains at the same transport endpoint, the server's ability to respond with the right certificate chain is predicated on correct SNI information from the client. DANE clients MUST send the SNI extension with a HostName value of the base domain of the TLSA RRset.
当服务器在同一传输端点承载多个域时，服务器使用正确的证书链进行响应的能力取决于来自客户端的正确SNI信息。DANE客户端必须发送SNI扩展，其主机名值为TLSA RRset的基本域。
With the exception of TLSA certificate usage DANE-EE(3), where name checks are not applicable (see Section 5.1), DANE clients MUST verify that the client has reached the correct server by checking that the server name is listed in the server certificate's SAN or CN (when still supported). The primary server name used for this comparison MUST be the TLSA base domain; however, additional acceptable names may be specified by protocol-specific DANE standards. For example, with SMTP, both the destination domain name and the MX hostname are acceptable names to be found in the server certificate (see [RFC7672]).
除TLSA证书使用DANE-EE（3）外，如果名称检查不适用（请参见第5.1节），DANE客户端必须通过检查服务器证书的SAN或CN中是否列出了服务器名称（仍受支持），验证客户端是否已到达正确的服务器。用于此比较的主服务器名称必须是TLSA基本域；但是，协议特定的丹麦标准可能会规定其他可接受的名称。例如，对于SMTP，目标域名和MX主机名都是可以在服务器证书中找到的可接受名称（请参阅[RFC7672]）。
It is the responsibility of the service operator, in coordination with the TLSA Publisher, to ensure that at least one of the TLSA records published for the service will match the server's certificate chain (either the default chain or the certificate that was selected based on the SNI information provided by the client).
服务运营商有责任与TLSA发布商协调，确保为服务发布的至少一条TLSA记录与服务器的证书链（默认链或根据客户端提供的SNI信息选择的证书）匹配。
Given the DNSSEC-validated DNS records below:
鉴于以下DNSSEC验证的DNS记录：
example.com. IN MX 0 mail.example.com. mail.example.com. IN A 192.0.2.1 _25._tcp.mail.example.com. IN TLSA 2 0 1 ( E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F5303EBFBB77D022F834C0 )
example.com。在MX 0 mail.example.com中。mail.example.com。在192.0.2.1_25._tcp.mail.example.com中。在TLSA 2 0 1中（E8B54E0B4BAA815B06D3462D65FBC7C0 CF556ECCF9F530EBFBB77D022F834C0）
The TLSA base domain is "mail.example.com" and is required to be the HostName in the client's SNI extension. The server certificate chain is required to be signed by a TA with the above certificate SHA2-256 digest. Finally, one of the DNS names in the server certificate is required to be either "mail.example.com" or "example.com" (this additional name is a concession to compatibility with prior practice; see [RFC7672] for details).
TLSA基本域是“mail.example.com”，必须是客户端SNI扩展中的主机名。服务器证书链需要由TA使用上述证书SHA2-256摘要进行签名。最后，服务器证书中的一个DNS名称必须是“mail.example.com”或“example.com”（此附加名称是为了与以前的做法兼容的让步；有关详细信息，请参阅[RFC7672]）。
[RFC6125] specifies the semantics of wildcards in server certificates for various application protocols. DANE does not change how wildcards are treated by any given application.
[RFC6125]为各种应用程序协议指定服务器证书中通配符的语义。DANE不会更改任何给定应用程序处理通配符的方式。
When a TLS client goes to the trouble of authenticating a certificate chain presented by a TLS server, it will typically not continue to use that server in the event of authentication failure, or else authentication serves no purpose. Some clients may, at times, operate in an "audit" mode, where authentication failure is reported to the user or in logs as a potential problem, but the connection proceeds despite the failure. Nevertheless, servers publishing TLSA records MUST be configured to allow correctly configured clients to successfully authenticate their TLS certificate chains.
当TLS客户端在验证TLS服务器提供的证书链时遇到麻烦时，它通常不会在验证失败的情况下继续使用该服务器，或者验证没有任何作用。有些客户端有时可能以“审核”模式运行，其中身份验证失败作为一个潜在问题报告给用户或在日志中，但尽管失败，连接仍会继续。但是，发布TLSA记录的服务器必须配置为允许正确配置的客户端成功验证其TLS证书链。
A service with DNSSEC-validated TLSA records implicitly promises TLS support. When all the TLSA records for a service are found "unusable" due to unsupported parameter combinations or malformed certificate association data, DANE clients cannot authenticate the service certificate chain. When authenticated TLS is mandatory, the client MUST NOT connect to the associated server.
具有DNSSEC验证的TLSA记录的服务隐式承诺TLS支持。如果由于不支持的参数组合或格式错误的证书关联数据而发现服务的所有TLSA记录“不可用”，则DANE客户端无法对服务证书链进行身份验证。如果必须使用经过身份验证的TLS，则客户端不得连接到关联的服务器。
If, on the other hand, the use of TLS and DANE is "opportunistic" [RFC7435], then when all TLSA records are unusable, the client SHOULD connect to the server via an unauthenticated TLS connection, and if TLS encryption cannot be established, the client MUST NOT connect to the server.
另一方面，如果TLS和DANE的使用是“机会主义的”[RFC7435]，则当所有TLSA记录不可用时，客户端应通过未经验证的TLS连接连接到服务器，如果无法建立TLS加密，客户端不得连接到服务器。
Standards for opportunistic DANE TLS specific to a particular application protocol may modify the above requirements. The key consideration is whether or not mandating the use of (unauthenticated) TLS even with unusable TLSA records is asking for more security than one can realistically expect. If expecting TLS support when unusable TLSA records are published is realistic for the application in question, then the application MUST avoid cleartext. If not realistic, then mandating TLS would cause clients (even in the absence of active attacks) to run into problems with various peers that do not interoperate "securely enough". That would create strong incentives to just disable Opportunistic Security and stick with cleartext.
特定于特定应用协议的机会性丹麦TLS标准可能会修改上述要求。关键考虑因素是，即使TLSA记录不可用，强制使用（未经验证的）TLS是否要求比实际期望的更高的安全性。如果在发布不可用的TLSA记录时期望TLS支持对于相关应用程序来说是现实的，那么应用程序必须避免明文。如果不现实，那么强制TLS将导致客户端（即使在没有主动攻击的情况下）遇到各种对等方的问题，这些对等方之间的互操作“不够安全”。这将产生强大的激励，让人们禁用机会主义安全，坚持使用明文。
Clearly, the security of the DANE TLSA PKI rests on the security of the underlying DNSSEC infrastructure. While this document is not a guide to DNSSEC security, a few comments may be helpful to TLSA implementers.
显然，丹麦TLSA PKI的安全性取决于底层DNSSEC基础设施的安全性。虽然本文档不是DNSSEC安全指南，但一些注释可能对TLSA实施者有所帮助。
With the existing public CA Web PKI, name constraints are rarely used, and a public root CA can issue certificates for any domain of its choice. With DNSSEC, under the Registry/Registrar/Registrant model, the situation is different: only the registrar of record can update a domain's DS record [RFC4034] in the registry parent zone (in some cases, however, the registry is the sole registrar). With many Generic Top-Level Domains (gTLDs) for which multiple registrars compete to provide domains in a single registry, it is important to make sure that rogue registrars cannot easily initiate an unauthorized domain transfer and thus take over DNSSEC for the domain. DNS operators are advised to set a registrar lock on their domains to offer some protection against this possibility.
对于现有的公共CA Web PKI，很少使用名称约束，并且公共根CA可以为其选择的任何域颁发证书。对于DNSSEC，在注册中心/注册中心/注册人模式下，情况有所不同：只有记录注册中心可以更新注册中心父区域中域的DS记录[RFC4034]（但在某些情况下，注册中心是唯一的注册中心）。由于许多通用顶级域（GTLD）的多个注册商竞争在单个注册中心中提供域，因此必须确保恶意注册商不能轻易发起未经授权的域转移，从而接管该域的DNSSEC。建议DNS运营商在其域上设置注册锁，以提供一些保护，防止这种可能性。
When the registrar is also the DNS operator for the domain, one needs to consider whether or not the registrar will allow orderly migration of the domain to another registrar or DNS operator in a way that will maintain DNSSEC integrity. TLSA Publishers are advised to seek out a DNS hosting registrar that makes it possible to transfer domains to another hosting provider without disabling DNSSEC.
当注册官也是域的DNS操作员时，需要考虑注册者是否允许以维护DNSSEC完整性的方式将域有序迁移到另一个注册者或DNS运营商。建议TLSA发布商寻找DNS托管注册商，该注册商可以在不禁用DNSSEC的情况下将域转移到另一个托管提供商。
DNSSEC-signed RRsets cannot be securely revoked before they expire. Operators need to plan accordingly and not generate signatures of excessively long duration. For domains publishing high-value keys, a signature lifetime (length of the "signature validity period" as described in Section 8.1 of [RFC4033]) of a few days is reasonable, and the zone can be re-signed daily. For domains with less critical data, a reasonable signature lifetime is a couple of weeks to a month, and the zone can be re-signed weekly.
DNSSEC签名的RRSET在过期之前无法安全地撤销。运营商需要进行相应的计划，而不是生成持续时间过长的签名。对于发布高值密钥的域，几天的签名生存期（如[RFC4033]第8.1节所述的“签名有效期”长度）是合理的，并且区域可以每天重新签名。对于数据不太关键的域，合理的签名生存期为几周到一个月，并且可以每周重新签名区域。
Short signature lifetimes require tighter synchronization of primary and secondary nameservers, to make sure that secondary servers never serve records with expired signatures. They also limit the maximum time for which a primary server that signs the zone can be down. Therefore, short signature lifetimes are more appropriate for sites with dedicated operations staff, who can restore service quickly in case of a problem.
短签名生存期要求主和辅助名称服务器进行更紧密的同步，以确保辅助服务器永远不会提供签名过期的记录。它们还限制签署区域的主服务器可以关闭的最长时间。因此，较短的签名生命周期更适合于有专门操作人员的站点，他们可以在出现问题时快速恢复服务。
Monitoring is important. If a DNS zone is not re-signed in a timely manner, a major outage is likely, as the entire domain and all its sub-domains become "bogus".
监测很重要。如果DNS区域未及时重新签名，则可能会出现重大停机，因为整个域及其所有子域都将成为“伪造的”。
o Section 3 updates [RFC6698] to specify a requirement for clients to support at least TLS 1.0 and to support SNI.
o 第3节更新了[RFC6698]，规定了客户机至少支持TLS 1.0和SNI的要求。
o Section 4 explains that application support for all four certificate usages is NOT RECOMMENDED. The recommended design is to support just DANE-EE(3) and DANE-TA(2).
o 第4节解释了不建议对所有四种证书使用提供应用程序支持。建议的设计仅支持DANE-EE（3）和DANE-TA（2）。
o Section 5.1 updates [RFC6698] to specify that peer identity matching and validity period enforcement are based solely on the TLSA RRset properties. It also specifies DANE authentication of raw public keys [RFC7250] via TLSA records with certificate usage DANE-EE(3) and selector SPKI(1).
o 第5.1节更新了[RFC6698]，规定对等身份匹配和有效期强制仅基于TLSA RRset属性。它还通过TLSA记录指定原始公钥[RFC7250]的DANE身份验证，证书使用DANE-EE（3）和选择器SPKI（1）。
o Section 5.2 updates [RFC6698] to require that servers publishing digest TLSA records with a usage of DANE-TA(2) MUST include the TA certificate in their TLS server certificate message. This extends to the case of "2 1 0" TLSA records that publish a full public key.
o 第5.2节更新了[RFC6698]，要求使用DANE-TA（2）发布摘要TLSA记录的服务器必须在其TLS服务器证书消息中包含TA证书。这扩展到发布完整公钥的“2 1 0”TLSA记录的情况。
o Section 5.4 observes that with usage PKIX-TA(0), clients may need to process extended trust chains beyond the first trusted issuer when that issuer is not self-signed.
o 第5.4节指出，使用PKIX-TA（0），当第一个受信任的颁发者未自签名时，客户端可能需要处理超出该颁发者的扩展信任链。
o Section 7 recommends that DANE application protocols specify that, when possible, securely CNAME-expanded names be used to derive the TLSA base domain.
o 第7节建议DANE应用程序协议规定，在可能的情况下，可以使用安全的CNAME扩展名来派生TLSA基本域。
o Section 8 specifies a strategy for managing TLSA records that interoperates with DANE clients regardless of what subset of the possible TLSA record types (combinations of TLSA parameters) is supported by the client.
o 第8节规定了管理TLSA记录的策略，该策略可与DANE客户端进行互操作，而不管客户端支持可能的TLSA记录类型的子集（TLSA参数的组合）。
o Section 9 specifies a digest algorithm agility protocol.
o 第9节指定了一个摘要算法敏捷协议。
o Section 10.1 recommends against the use of Full(0) TLSA records, as digest records are generally much more compact.
o 第10.1节建议不要使用完整（0）TLSA记录，因为摘要记录通常更紧凑。
The DNS TTL of TLSA records needs to be chosen with care. When an unplanned change in the server's certificate chain and TLSA RRset is required, such as when keys are compromised or lost, clients that cache stale TLSA records will fail to validate the certificate chain of the updated server. Publish TLSA RRsets with TTLs that are short enough to limit unplanned service disruption to an acceptable duration.
需要谨慎选择TLSA记录的DNS TTL。当需要对服务器的证书链和TLSA RRset进行计划外更改时，例如密钥泄露或丢失时，缓存过时TLSA记录的客户端将无法验证更新服务器的证书链。发布具有足够短的TTL的TLSA RRSET，以将计划外服务中断限制在可接受的持续时间内。
The signature lifetime (length of the signature validity period) for TLSA records SHOULD NOT be too long. Signed DNSSEC records can be replayed by an MITM attacker, provided the signatures have not yet expired. Shorter signature validity periods allow for faster invalidation of compromised keys. Zone refresh and expiration times for secondary nameservers often imply a lower bound on the signature validity period (Section 11). See Section 4.4.1 of [RFC6781].
TLSA记录的签名寿命（签名有效期长度）不应太长。如果签名尚未过期，则MITM攻击者可以重放已签名的DNSSEC记录。更短的签名有效期允许更快地使受损密钥失效。辅助名称服务器的区域刷新和过期时间通常意味着签名有效期的下限（第11节）。见[RFC6781]第4.4.1节。
Application protocols that cannot use the existing public CA Web PKI may choose to not implement certain TLSA record types defined in [RFC6698]. If such records are published despite not being supported by the application protocol, they are treated as "unusable". When TLS is opportunistic, the client MAY proceed to use the server with mandatory unauthenticated TLS. This is stronger than opportunistic TLS without DANE, since in that case the client may also proceed with a cleartext connection. When TLS is not opportunistic, the client MUST NOT connect to the server.
无法使用现有公共CA Web PKI的应用程序协议可能会选择不实现[RFC6698]中定义的某些TLSA记录类型。如果在应用程序协议不支持的情况下发布此类记录，则将其视为“不可用”。如果TLS是机会主义的，客户机可以继续使用带有强制性未经验证TLS的服务器。这比没有DANE的机会主义TLS更强大，因为在这种情况下，客户机也可以进行明文连接。如果TLS不是机会主义的，则客户端不得连接到服务器。
Thus, when TLSA records are used with opportunistic protocols where PKIX-TA(0) and PKIX-EE(1) do not apply, the recommended protocol design is for servers to not publish such TLSA records, and for opportunistic TLS clients to use them to only enforce the use of (albeit unauthenticated) TLS but otherwise treat them as unusable. Of course, when PKIX-TA(0) and PKIX-EE(1) are supported by the application protocol, clients MUST implement these certificate usages as described in [RFC6698] and this document.
因此，当TLSA记录与PKIX-TA（0）和PKIX-EE（1）不适用的机会主义协议一起使用时，建议的协议设计是服务器不发布此类TLSA记录，机会主义TLS客户端使用它们仅强制使用（尽管未经验证）TLS，但将其视为不可用。当然，当应用程序协议支持PKIX-TA（0）和PKIX-EE（1）时，客户端必须实现[RFC6698]和本文档中所述的这些证书使用。
[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>.
[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>.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 4034，DOI 10.17487/RFC4034，2005年3月<http://www.rfc-editor.org/info/rfc4034>.
[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>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[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>.
[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>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，DOI 10.17487/RFC6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[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>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RFC7250]Wouters，P.，Ed.，Tschofenig，H.，Ed.，Gilmore，J.，Weiler，S.，和T.Kivinen，“在传输层安全性（TLS）和数据报传输层安全性（DTLS）中使用原始公钥”，RFC 7250，DOI 10.17487/RFC72502014年6月<http://www.rfc-editor.org/info/rfc7250>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC Operational Practices, Version 2", RFC 6781, DOI 10.17487/RFC6781, December 2012, <http://www.rfc-editor.org/info/rfc6781>.
[RFC6781]Kolkman，O.，Mekking，W.和R.Gieben，“DNSSEC操作规程，第2版”，RFC 6781，DOI 10.17487/RFC6781，2012年12月<http://www.rfc-editor.org/info/rfc6781>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <http://www.rfc-editor.org/info/rfc6962>.
[RFC6962]Laurie，B.，Langley，A.和E.Kasper，“证书透明度”，RFC 6962，DOI 10.17487/RFC6962，2013年6月<http://www.rfc-editor.org/info/rfc6962>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <http://www.rfc-editor.org/info/rfc7435>.
[RFC7435]Dukhovni，V.，“机会主义安全：大部分时间的一些保护”，RFC 7435，DOI 10.17487/RFC7435，2014年12月<http://www.rfc-editor.org/info/rfc7435>.
[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>.
[RFC7673] Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records", RFC 7673, DOI 10.17487/RFC7673, October 2015, <http://www.rfc-editor.org/info/rfc7673>.
[RFC7673]Finch，T.，Miller，M.，和P.Saint Andre，“使用基于DNS的认证命名实体（丹麦）TLSA记录和SRV记录”，RFC 7673，DOI 10.17487/RFC7673，2015年10月<http://www.rfc-editor.org/info/rfc7673>.
Acknowledgements
致谢
The authors would like to thank Phil Pennock for his comments and advice on this document.
作者感谢Phil Pennock对本文件的评论和建议。
Acknowledgements from Viktor: Thanks to Tony Finch, who finally prodded me into participating in DANE working group discussions. Thanks to Paul Hoffman, who motivated me to produce this document and provided feedback on early draft versions of it. Thanks also to Samuel Dukhovni for editorial assistance.
维克多致谢：感谢托尼·芬奇，他最终促使我参加了丹麦工作组的讨论。感谢Paul Hoffman，他激励我编写了这份文档，并提供了关于早期草稿版本的反馈。还感谢塞缪尔·杜霍夫尼的编辑协助。
Authors' Addresses
作者地址
Viktor Dukhovni Two Sigma
维克多·杜霍夫尼二西格玛
Email: ietf-dane@dukhovni.org
Email: ietf-dane@dukhovni.org
Wes Hardaker Parsons P.O. Box 382 Davis, CA 95617 United States
美国加利福尼亚州戴维斯市韦斯·哈达克·帕森斯邮政信箱382号，邮编95617
Email: ietf@hardakers.net
Email: ietf@hardakers.net