Internet Engineering Task Force (IETF)                       V. Dukhovni
Request for Comments: 7672                                     Two Sigma
Category: Standards Track                                    W. Hardaker
ISSN: 2070-1721                                                  Parsons
                                                            October 2015
Internet Engineering Task Force (IETF)                       V. Dukhovni
Request for Comments: 7672                                     Two Sigma
Category: Standards Track                                    W. Hardaker
ISSN: 2070-1721                                                  Parsons
                                                            October 2015

SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)




This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS-Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS).

此备忘录描述了一种用于邮件传输代理(MTA)之间SMTP传输安全的抗降级协议,该协议基于基于命名实体的DNS身份验证(DANE)TLSA DNS记录。采用此协议可以将Internet电子邮件主干网增量转换为使用加密和认证传输层安全性(TLS)的主干网。

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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents


   1. Introduction ....................................................3
      1.1. Terminology ................................................4
      1.2. Background .................................................6
      1.3. SMTP Channel Security ......................................6
           1.3.1. STARTTLS Downgrade Attack ...........................7
           1.3.2. Insecure Server Name without DNSSEC .................7
           1.3.3. Sender Policy Does Not Scale ........................8
           1.3.4. Too Many Certification Authorities ..................9
   2. Identifying Applicable TLSA Records .............................9
      2.1. DNS Considerations .........................................9
           2.1.1. DNS Errors, "Bogus" Responses, and
                  "Indeterminate" Responses ...........................9
           2.1.2. DNS Error Handling .................................11
           2.1.3. Stub Resolver Considerations .......................12
      2.2. TLS Discovery .............................................13
           2.2.1. MX Resolution ......................................14
           2.2.2. Non-MX Destinations ................................16
           2.2.3. TLSA Record Lookup .................................18
   3. DANE Authentication ............................................20
      3.1. TLSA Certificate Usages ...................................20
           3.1.1. Certificate Usage DANE-EE(3) .......................21
           3.1.2. Certificate Usage DANE-TA(2) .......................22
           3.1.3. Certificate Usages PKIX-TA(0) and PKIX-EE(1) .......23
      3.2. Certificate Matching ......................................24
           3.2.1. DANE-EE(3) Name Checks .............................24
           3.2.2. DANE-TA(2) Name Checks .............................24
           3.2.3. Reference Identifier Matching ......................25
   4. Server Key Management ..........................................26
   5. Digest Algorithm Agility .......................................27
   6. Mandatory TLS Security .........................................27
   7. Note on DANE for Message User Agents ...........................28
   8. Interoperability Considerations ................................28
      8.1. SNI Support ...............................................28
      8.2. Anonymous TLS Cipher Suites ...............................29
   9. Operational Considerations .....................................29
      9.1. Client Operational Considerations .........................29
      9.2. Publisher Operational Considerations ......................30
   10. Security Considerations .......................................30
   11. References ....................................................31
      11.1. Normative References .....................................31
      11.2. Informative References ...................................33
   Acknowledgements ..................................................34
   Authors' Addresses ................................................34
   1. Introduction ....................................................3
      1.1. Terminology ................................................4
      1.2. Background .................................................6
      1.3. SMTP Channel Security ......................................6
           1.3.1. STARTTLS Downgrade Attack ...........................7
           1.3.2. Insecure Server Name without DNSSEC .................7
           1.3.3. Sender Policy Does Not Scale ........................8
           1.3.4. Too Many Certification Authorities ..................9
   2. Identifying Applicable TLSA Records .............................9
      2.1. DNS Considerations .........................................9
           2.1.1. DNS Errors, "Bogus" Responses, and
                  "Indeterminate" Responses ...........................9
           2.1.2. DNS Error Handling .................................11
           2.1.3. Stub Resolver Considerations .......................12
      2.2. TLS Discovery .............................................13
           2.2.1. MX Resolution ......................................14
           2.2.2. Non-MX Destinations ................................16
           2.2.3. TLSA Record Lookup .................................18
   3. DANE Authentication ............................................20
      3.1. TLSA Certificate Usages ...................................20
           3.1.1. Certificate Usage DANE-EE(3) .......................21
           3.1.2. Certificate Usage DANE-TA(2) .......................22
           3.1.3. Certificate Usages PKIX-TA(0) and PKIX-EE(1) .......23
      3.2. Certificate Matching ......................................24
           3.2.1. DANE-EE(3) Name Checks .............................24
           3.2.2. DANE-TA(2) Name Checks .............................24
           3.2.3. Reference Identifier Matching ......................25
   4. Server Key Management ..........................................26
   5. Digest Algorithm Agility .......................................27
   6. Mandatory TLS Security .........................................27
   7. Note on DANE for Message User Agents ...........................28
   8. Interoperability Considerations ................................28
      8.1. SNI Support ...............................................28
      8.2. Anonymous TLS Cipher Suites ...............................29
   9. Operational Considerations .....................................29
      9.1. Client Operational Considerations .........................29
      9.2. Publisher Operational Considerations ......................30
   10. Security Considerations .......................................30
   11. References ....................................................31
      11.1. Normative References .....................................31
      11.2. Informative References ...................................33
   Acknowledgements ..................................................34
   Authors' Addresses ................................................34
1. Introduction
1. 介绍

This memo specifies a new connection security model for Message Transfer Agents (MTAs). This model is motivated by key features of inter-domain SMTP delivery, principally, the fact that the destination server is selected indirectly via DNS Mail Exchange (MX) records and that neither email addresses nor MX hostnames signal a requirement for either secure or cleartext transport. Therefore, aside from a few manually configured exceptions, SMTP transport security is, by necessity, opportunistic (for a definition of "Opportunistic Security", see [RFC7435]).


This specification uses the presence of DANE TLSA records to securely signal TLS support and to publish the means by which SMTP clients can successfully authenticate legitimate SMTP servers. This becomes "opportunistic DANE TLS" and is resistant to downgrade and man-in-the-middle (MITM) attacks. It enables an incremental transition of the email backbone to authenticated TLS delivery, with increased global protection as adoption increases.

本规范使用DANE TLSA记录的存在来安全地表示TLS支持,并发布SMTP客户端可以成功验证合法SMTP服务器的方法。这将成为“机会主义丹麦TLS”,并抵抗降级和中间人(MITM)攻击。它支持电子邮件主干向经过身份验证的TLS传递的增量过渡,随着采用率的增加,全局保护也会增加。

With opportunistic DANE TLS, traffic from SMTP clients to domains that publish "usable" DANE TLSA records in accordance with this memo is authenticated and encrypted. Traffic from legacy clients or to domains that do not publish TLSA records will continue to be sent in the same manner as before, via manually configured security, (pre-DANE) opportunistic TLS, or just cleartext SMTP.

对于机会主义的DANE TLS,从SMTP客户端到根据本备忘录发布“可用”DANE TLSA记录的域的通信是经过身份验证和加密的。从旧客户端或到未发布TLSA记录的域的流量将继续以与以前相同的方式发送,通过手动配置的安全性、(丹麦之前)机会主义TLS,或仅通过明文SMTP。

Problems with the existing use of TLS in MTA-to-MTA SMTP that motivate this specification are described in Section 1.3. The specification itself follows, in Sections 2 and 3, which describe, respectively, how to locate and use DANE TLSA records with SMTP. In Section 6, we discuss the application of DANE TLS to destinations for which channel integrity and confidentiality are mandatory. In Section 7, we briefly comment on the potential applicability of this specification to Message User Agents.

第1.3节描述了MTA到MTA SMTP中TLS的现有使用问题,这些问题激发了本规范。规范本身在第2节和第3节中分别描述了如何在SMTP中定位和使用DANE TLSA记录。在第6节中,我们将讨论DANE TLS在强制要求信道完整性和保密性的目的地的应用。在第7节中,我们简要评论了该规范对消息用户代理的潜在适用性。

1.1. Terminology
1.1. 术语

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].


The following terms or concepts are used throughout this document:


Man-in-the-middle (MITM) attack: Active modification of network traffic by an adversary able to thereby compromise the confidentiality or integrity of the data.


Downgrade attack: (From [RFC4949].) A type of MITM attack in which the attacker can cause two parties, at the time they negotiate a security association, to agree on a lower level of protection than the highest level that could have been supported by both of them.


Downgrade-resistant: A protocol is "downgrade-resistant" if it employs effective countermeasures against downgrade attacks.


"Secure", "bogus", "insecure", "indeterminate": DNSSEC validation results, as defined in Section 4.3 of [RFC4035].


Validating security-aware stub resolver and non-validating security-aware stub resolver: Capabilities of the stub resolver in use, as defined in [RFC4033]; note that this specification requires the use of a security-aware stub resolver.


(Pre-DANE) opportunistic TLS: Best-effort use of TLS that is generally vulnerable to DNS forgery and STARTTLS downgrade attacks. When a TLS-encrypted communication channel is not available, message transmission takes place in the clear. MX record indirection generally precludes authentication even when TLS is available.


Opportunistic DANE TLS: Best-effort use of TLS that is resistant to downgrade attacks for destinations with DNSSEC-validated TLSA records. When opportunistic DANE TLS is determined to be unavailable, clients should fall back to pre-DANE opportunistic TLS. Opportunistic DANE TLS requires support for DNSSEC, DANE, and STARTTLS on the client side, and STARTTLS plus a DNSSEC published TLSA record on the server side.

机会主义DANE TLS:尽最大努力使用TLS,对具有DNSSEC验证的TLSA记录的目的地抵御降级攻击。当确定丹麦机会主义TLS不可用时,客户应退回到丹麦之前的机会主义TLS。机会主义的DANE TLS要求在客户端支持DNSSEC、DANE和STARTTLS,在服务器端支持STARTTLS和DNSSEC发布的TLSA记录。

Reference identifier: (Special case of [RFC6125] definition.) One of the domain names associated by the SMTP client with the destination SMTP server for performing name checks on the server certificate. When name checks are applicable, at least one of the reference identifiers MUST match an [RFC6125] DNS-ID (or, if none are present, the [RFC6125] CN-ID) of the server certificate (see Section 3.2.3).


MX hostname: The RRDATA of an MX record consists of a 16 bit preference followed by a Mail Exchange domain name (see [RFC1035], Section 3.3.9). We will use the term "MX hostname" to refer to the latter, that is, the DNS domain name found after the preference value in an MX record. Thus, an "MX hostname" is specifically a reference to a DNS domain name rather than any host that bears that name.


Delayed delivery: Email delivery is a multi-hop store-and-forward process. When an MTA is unable to forward a message that may become deliverable later, the message is queued and delivery is retried periodically. Some MTAs may be configured with a fallback next-hop destination that handles messages that the MTA would otherwise queue and retry. When a fallback next-hop destination is configured, messages that would otherwise have to be delayed may be sent to the fallback next-hop destination instead. The fallback destination may itself be subject to opportunistic or mandatory DANE TLS (Section 6) as though it were the original message destination.

延迟交付:电子邮件交付是一个多跳存储转发过程。当MTA无法转发可能稍后可交付的邮件时,邮件将排队并定期重试交付。某些MTA可能配置了回退下一跳目标,用于处理MTA将排队并重试的邮件。当配置了回退下一跳目的地时,否则必须延迟的消息可以改为发送到回退下一跳目的地。回退目的地本身可能受制于机会主义或强制性DANE TLS(第6节),就好像它是原始消息目的地一样。

Original next-hop destination: The logical destination for mail delivery. By default, this is the domain portion of the recipient address, but MTAs may be configured to forward mail for some or all recipients via designated relays. The original next-hop destination is, respectively, either the recipient domain or the associated configured relay.


MTA: Message Transfer Agent ([RFC5598], Section 4.3.2).


MSA: Message Submission Agent ([RFC5598], Section 4.3.1).


MUA: Message User Agent ([RFC5598], Section 4.2.1).


RR: A DNS resource record as defined in [RFC1034], Section 3.6.


RRset: An RRset ([RFC2181], Section 5) is a group of DNS resource records that share the same label, class, and type.


1.2. Background
1.2. 出身背景

The Domain Name System Security Extensions (DNSSEC) add data origin authentication, data integrity, and data nonexistence proofs to the Domain Name System (DNS). DNSSEC is defined in [RFC4033], [RFC4034], and [RFC4035].


As described in the introduction of [RFC6698], TLS authentication via the existing public Certification Authority (CA) PKI suffers from an overabundance of trusted parties capable of issuing certificates for any domain of their choice. DANE leverages the DNSSEC infrastructure to publish public keys and certificates for use with the Transport Layer Security (TLS) [RFC5246] protocol via the "TLSA" DNS record type. With DNSSEC, each domain can only vouch for the keys of its delegated sub-domains.


The TLS protocol enables secure TCP communication. In the context of this memo, channel security is assumed to be provided by TLS. Used without authentication, TLS provides only privacy protection against eavesdropping attacks. Otherwise, TLS also provides data origin authentication to guard against MITM attacks.


1.3. SMTP Channel Security
1.3. SMTP通道安全

With HTTPS, TLS employs X.509 certificates [RFC5280] issued by one of the many CAs bundled with popular web browsers to allow users to authenticate their "secure" websites. Before we specify a new DANE TLS security model for SMTP, we will explain why a new security model is needed. In the process, we will explain why the familiar HTTPS security model is inadequate to protect inter-domain SMTP traffic.

通过HTTPS,TLS使用了许多与流行web浏览器捆绑在一起的CA之一颁发的X.509证书[RFC5280],允许用户对其“安全”网站进行身份验证。在为SMTP指定新的DANE TLS安全模型之前,我们将解释为什么需要新的安全模型。在此过程中,我们将解释为什么熟悉的HTTPS安全模型不足以保护域间SMTP通信。

The subsections below outline four key problems with applying traditional Web PKI [RFC7435] to SMTP; these problems are addressed by this specification. Since an SMTP channel security policy is not explicitly specified in either the recipient address or the MX record, a new signaling mechanism is required to indicate when channel security is possible and should be used. The publication of TLSA records allows server operators to securely signal to SMTP clients that TLS is available and should be used. DANE TLSA makes it possible to simultaneously discover which destination domains support secure delivery via TLS and how to verify the authenticity of the associated SMTP services, providing a path forward to ubiquitous SMTP channel security.

以下小节概述了将传统Web PKI[RFC7435]应用于SMTP的四个关键问题;本规范解决了这些问题。由于SMTP通道安全策略未在收件人地址或MX记录中明确指定,因此需要一种新的信令机制来指示何时可以使用通道安全。TLSA记录的发布允许服务器操作员安全地向SMTP客户端发出TLS可用且应使用的信号。DANE TLSA使我们能够同时发现哪些目标域支持通过TLS进行安全传递,以及如何验证相关SMTP服务的真实性,从而提供一条通向无处不在的SMTP通道安全的路径。

1.3.1. STARTTLS Downgrade Attack
1.3.1. STARTTLS降级攻击

SMTP [RFC5321] is a single-hop protocol in a multi-hop store-and-forward email delivery process. An SMTP envelope recipient address does not correspond to a specific transport-layer endpoint address; rather, at each relay hop, the transport-layer endpoint is the next-hop relay, while the envelope recipient address typically remains the same. Unlike HTTP and its corresponding secured version, HTTPS, where the use of TLS is signaled via the URI scheme, email recipient addresses do not directly signal transport security policy. Indeed, no such signaling could work well with SMTP, since TLS encryption of SMTP protects email traffic on a hop-by-hop basis while email addresses could only express end-to-end policy.


With no mechanism available to signal transport security policy, SMTP relays employ a best-effort "opportunistic" security model for TLS. A single SMTP server TCP listening endpoint can serve both TLS and non-TLS clients; the use of TLS is negotiated via the SMTP STARTTLS command [RFC3207]. The server signals TLS support to the client over a cleartext SMTP connection, and, if the client also supports TLS, it may negotiate a TLS-encrypted channel to use for email transmission. The server's indication of TLS support can be easily suppressed by an MITM attacker. Thus, pre-DANE SMTP TLS security can be subverted by simply downgrading a connection to cleartext. No TLS security feature can prevent this. The attacker can simply disable TLS.

由于没有可用于信号传输安全策略的机制,SMTP中继为TLS采用了尽力而为的“机会主义”安全模型。单个SMTP服务器TCP侦听端点可以同时服务于TLS和非TLS客户端;TLS的使用通过SMTP STARTTLS命令[RFC3207]协商。服务器通过明文SMTP连接向客户机发送TLS支持信号,如果客户机也支持TLS,它可以协商TLS加密通道以用于电子邮件传输。服务器对TLS支持的指示很容易被MITM攻击者压制。因此,丹麦以前的SMTP TLS安全性可以通过简单地降级到明文的连接而被破坏。没有任何TLS安全功能可以防止这种情况。攻击者只需禁用TLS即可。

1.3.2. Insecure Server Name without DNSSEC
1.3.2. 没有DNSSEC的服务器名称不安全

With SMTP, DNS MX records abstract the next-hop transport endpoint and allow administrators to specify a set of target servers to which SMTP traffic should be directed for a given domain.

使用SMTP,DNS MX记录下一跳传输端点,并允许管理员指定一组目标服务器,SMTP通信应定向到给定域。

A TLS client is vulnerable to MITM attacks unless it verifies that the server's certificate binds the public key to a name that matches one of the client's reference identifiers. A natural choice of reference identifier is the server's domain name. However, with SMTP, server names are not directly encoded in the recipient address; instead, they are obtained indirectly via MX records. Without DNSSEC, the MX lookup is vulnerable to MITM and DNS cache poisoning attacks. Active attackers can forge DNS replies with fake MX records and can redirect email to servers with names of their choice. Therefore, secure verification of SMTP TLS certificates matching the server name is not possible without DNSSEC.

TLS客户端容易受到MITM攻击,除非它验证服务器的证书是否将公钥绑定到与客户端引用标识符之一匹配的名称。引用标识符的自然选择是服务器的域名。但是,使用SMTP时,服务器名称不会直接编码到收件人地址中;相反,它们是通过MX记录间接获得的。如果没有DNSSEC,MX查找容易受到MITM和DNS缓存中毒攻击。主动攻击者可以伪造带有虚假MX记录的DNS回复,并可以将电子邮件重定向到具有其选择名称的服务器。因此,如果没有DNSSEC,则无法安全验证与服务器名称匹配的SMTP TLS证书。

One might try to harden TLS for SMTP against DNS attacks by using the envelope recipient domain as a reference identifier and by requiring each SMTP server to possess a trusted certificate for the envelope recipient domain rather than the MX hostname. Unfortunately, this is impractical, as email for many domains is handled by third parties that are not in a position to obtain certificates for all the domains they serve. Deployment of the Server Name Indication (SNI) extension to TLS (see Section 3 of [RFC6066]) is no panacea, since SNI key management is operationally challenging except when the email service provider is also the domain's registrar and its certificate issuer; this is rarely the case for email.


Since the recipient domain name cannot be used as the SMTP server reference identifier, and neither can the MX hostname without DNSSEC, large-scale deployment of authenticated TLS for SMTP requires that the DNS be secure.

由于收件人域名不能用作SMTP服务器引用标识符,没有DNSSEC的MX主机名也不能用作SMTP服务器引用标识符,因此,大规模部署经过身份验证的SMTP TLS要求DNS是安全的。

Since SMTP security depends critically on DNSSEC, it is important to point out that SMTP with DANE is consequently the most conservative possible trust model. It trusts only what must be trusted and no more. Adding any other trusted actors to the mix can only reduce SMTP security. A sender may choose to further harden DNSSEC for selected high-value receiving domains by configuring explicit trust anchors for those domains instead of relying on the chain of trust from the root domain. However, detailed discussion of DNSSEC security practices is out of scope for this document.


1.3.3. Sender Policy Does Not Scale
1.3.3. 发件人策略不可扩展

Sending systems are in some cases explicitly configured to use TLS for mail sent to selected peer domains, but this requires configuring sending MTAs with appropriate subject names or certificate content digests from their peer domains. Due to the resulting administrative burden, such statically configured SMTP secure channels are used rarely (generally only between domains that make bilateral arrangements with their business partners). Internet email, on the other hand, requires regularly contacting new domains for which security configurations cannot be established in advance.


The abstraction of the SMTP transport endpoint via DNS MX records, often across organizational boundaries, limits the use of public CA PKI with SMTP to a small set of sender-configured peer domains. With little opportunity to use TLS authentication, sending MTAs are rarely configured with a comprehensive list of trusted CAs. SMTP services that support STARTTLS often deploy X.509 certificates that are self-signed or issued by a private CA.

通过DNS MX记录抽象SMTP传输端点(通常跨越组织边界)将公共CA PKI与SMTP的使用限制在一小部分发送方配置的对等域。由于几乎没有机会使用TLS身份验证,发送MTA很少配置一个完整的可信CA列表。支持STARTTLS的SMTP服务通常部署由私人CA自签名或颁发的X.509证书。

1.3.4. Too Many Certification Authorities
1.3.4. 认证机构太多

Even if it were generally possible to determine a secure server name, the SMTP client would still need to verify that the server's certificate chain is issued by a trusted CA (a trust anchor). MTAs are not interactive applications where a human operator can make a decision (wisely or otherwise) to selectively disable TLS security policy when certificate chain verification fails. With no user to "click OK", the MTA's list of public CA trust anchors would need to be comprehensive in order to avoid bouncing mail addressed to sites that employ unknown CAs.


On the other hand, each trusted CA can issue certificates for any domain. If even one of the configured CAs is compromised or operated by an adversary, it can subvert TLS security for all destinations. Any set of CAs is simultaneously both overly inclusive and not inclusive enough.


2. Identifying Applicable TLSA Records
2. 确定适用的TLSA记录
2.1. DNS Considerations
2.1. DNS注意事项
2.1.1. DNS Errors, "Bogus" Responses, and "Indeterminate" Responses
2.1.1. DNS错误、“虚假”响应和“不确定”响应

An SMTP client that implements opportunistic DANE TLS per this specification depends critically on the integrity of DNSSEC lookups, as discussed in Section 1.3.2. This section lists the DNS resolver requirements needed to avoid downgrade attacks when using opportunistic DANE TLS.

如第1.3.2节所述,根据本规范实施投机性DANE TLS的SMTP客户端在很大程度上取决于DNSSEC查找的完整性。本节列出了在使用机会主义DANE TLS时避免降级攻击所需的DNS解析程序要求。

A DNS lookup may signal an error or return a definitive answer. A security-aware resolver MUST be used for this specification. Security-aware resolvers will indicate the security status of a DNS RRset with one of four possible values defined in Section 4.3 of [RFC4035]: "secure", "insecure", "bogus", and "indeterminate". In [RFC4035], the meaning of the "indeterminate" security status is:

DNS查找可能会发出错误信号或返回最终答案。此规范必须使用具有安全意识的解析器。安全感知解析器将使用[RFC4035]第4.3节中定义的四个可能值之一指示DNS RRset的安全状态:“安全”、“不安全”、“伪造”和“不确定”。在[RFC4035]中,“不确定”安全状态的含义是:

An RRset for which the resolver is not able to determine whether the RRset should be signed, as the resolver is not able to obtain the necessary DNSSEC RRs. This can occur when the security-aware resolver is not able to contact security-aware name servers for the relevant zones.

由于解析程序无法获得必要的DNSSEC RRs,因此解析程序无法确定是否应对其进行签名的RRset。当安全感知解析器无法联系相关区域的安全感知名称服务器时,可能会发生这种情况。

Note that the "indeterminate" security status has a conflicting definition in Section 5 of [RFC4033]:


There is no trust anchor that would indicate that a specific portion of the tree is secure.


In this document, the term "indeterminate" will be used exclusively in the [RFC4035] sense. Therefore, obtaining "indeterminate" lookup results is a (transient) failure condition, namely, the inability to locate the relevant DNS records. DNS records that would be classified "indeterminate" in the sense of [RFC4035] are simply classified as "insecure".


We do not need to distinguish between zones that lack a suitable ancestor trust anchor, and delegations (ultimately) from a trust anchor that designate a child zone as being "insecure". All "insecure" RRsets MUST be handled identically: in either case, non-validated data for the query domain is all that is and can be available, and authentication using the data is impossible. As the DNS root zone has been signed, we expect that validating resolvers used by Internet-facing MTAs will be configured with trust anchor data for the root zone and that therefore domains with no ancestor trust anchor will not be possible in most deployments.


As noted in Section 4.3 of [RFC4035], a security-aware DNS resolver MUST be able to determine whether a given non-error DNS response is "secure", "insecure", "bogus", or "indeterminate". It is expected that most security-aware stub resolvers will not signal an "indeterminate" security status (in the sense of [RFC4035]) to the application and will instead signal a "bogus" or error result. If a resolver does signal an [RFC4035] "indeterminate" security status, this MUST be treated by the SMTP client as though a "bogus" or error result had been returned.


An MTA using a non-validating security-aware stub resolver MAY use the stub resolver's ability, if available, to signal DNSSEC validation status based on information the stub resolver has learned from an upstream validating recursive resolver. Security-oblivious stub resolvers [RFC4033] MUST NOT be used. In accordance with Section 4.9.3 of [RFC4035]:


... a security-aware stub resolver MUST NOT place any reliance on signature validation allegedly performed on its behalf, except when the security-aware stub resolver obtained the data in question from a trusted security-aware recursive name server via a secure channel.

... 安全感知存根解析器不得依赖于据称代表其执行的签名验证,除非安全感知存根解析器通过安全通道从可信的安全感知递归名称服务器获得相关数据。

To avoid much repetition in the text below, we will pause to explain the handling of "bogus" or "indeterminate" DNSSEC query responses. These are not necessarily the result of a malicious actor; they can, for example, occur when network packets are corrupted or lost in transit. Therefore, "bogus" or "indeterminate" replies are equated in this memo with lookup failure.


There is an important non-failure condition we need to highlight in addition to the obvious case of the DNS client obtaining a non-empty "secure" or "insecure" RRset of the requested type. Namely, it is not an error when either "secure" or "insecure" nonexistence is determined for the requested data. When a DNSSEC response with a validation status that is either "secure" or "insecure" reports either no records of the requested type or nonexistence of the query domain, the response is not a DNS error condition. The DNS client has not been left without an answer; it has learned that records of the requested type do not exist.


Security-aware stub resolvers will, of course, also signal DNS lookup errors in other cases, for example, when processing a "SERVFAIL" [RFC2136] response code (RCODE) [RFC1035], which will not have an associated DNSSEC status. All lookup errors are treated the same way by this specification, regardless of whether they are from a "bogus" or "indeterminate" DNSSEC status or from a more generic DNS error: the information that was requested cannot be obtained by the security-aware resolver at this time. Thus, a lookup error is either a failure to obtain the relevant RRset if it exists or a failure to determine that no such RRset exists when it does not.


In contrast to a "bogus" response or an "indeterminate" response, an "insecure" DNSSEC response is not an error; rather, as explained above, it indicates that the target DNS zone is either delegated as an "insecure" child of a "secure" parent zone or not a descendant of any of the configured DNSSEC trust anchors in use by the SMTP client. "Insecure" results will leave the SMTP client with degraded channel security but do not stand in the way of message delivery. See Section 2.2 for further details.


2.1.2. DNS Error Handling
2.1.2. DNS错误处理

When a DNS lookup failure (an error, "bogus", or "indeterminate", as defined above) prevents an SMTP client from determining which SMTP server or servers it should connect to, message delivery MUST be delayed. This naturally includes, for example, the case when a "bogus" or "indeterminate" response is encountered during MX resolution. When multiple MX hostnames are obtained from a successful MX lookup but a later DNS lookup failure prevents network address resolution for a given MX hostname, delivery may proceed via any remaining MX hosts.


When a particular SMTP server is securely identified as the delivery destination, a set of DNS lookups (Section 2.2) MUST be performed to locate any related TLSA records. If any DNS queries used to locate TLSA records fail (due to "bogus" or "indeterminate" records, timeouts, malformed replies, SERVFAIL responses, etc.), then the SMTP


client MUST treat that server as unreachable and MUST NOT deliver the message via that server. If no servers are reachable, delivery is delayed.


In the text that follows, we will only describe what happens when all relevant DNS queries succeed. If any DNS failure occurs, the SMTP client MUST behave as described in this section, by "skipping" the SMTP server or destination that is problematic. Queries for candidate TLSA records are explicitly part of "all relevant DNS queries", and SMTP clients MUST NOT continue to connect to an SMTP server or destination whose TLSA record lookup fails.


2.1.3. Stub Resolver Considerations
2.1.3. 存根解析器注意事项

A note about DNAME aliases: a query for a domain name whose ancestor domain is a DNAME alias returns the DNAME RR for the ancestor domain along with a CNAME that maps the query domain to the corresponding sub-domain of the target domain of the DNAME alias [RFC6672]. Therefore, whenever we speak of CNAME aliases, we implicitly allow for the possibility that the alias in question is the result of an ancestor domain DNAME record. Consequently, no explicit support for DNAME records is needed in SMTP software; it is sufficient to process the resulting CNAME aliases. DNAME records only require special processing in the validating stub resolver library that checks the integrity of the combined DNAME + CNAME reply. When DNSSEC validation is handled by a local caching resolver rather than the MTA itself, even that part of the DNAME support logic is outside the MTA.

关于DNAME别名的注意事项:对其祖先域为DNAME别名的域名的查询将返回祖先域的DNAME RR以及将查询域映射到DNAME别名的目标域的相应子域的CNAME[RFC6672]。因此,每当我们谈到CNAME别名时,我们都会隐式地考虑到所讨论的别名可能是祖先域DNAME记录的结果。因此,SMTP软件中不需要明确支持DNAME记录;处理生成的CNAME别名就足够了。DNAME记录只需要在验证存根解析器库中进行特殊处理,以检查组合DNAME+CNAME回复的完整性。当DNSSEC验证由本地缓存解析程序而不是MTA本身处理时,即使是DNAME支持逻辑的这一部分也在MTA之外。

When a stub resolver returns a response containing a CNAME alias that does not also contain the corresponding query results for the target of the alias, the SMTP client will need to repeat the query at the target of the alias and should do so recursively up to some configured or implementation-dependent recursion limit. If at any stage of CNAME expansion an error is detected, the lookup of the original requested records MUST be considered to have failed.


Whether a chain of CNAME records was returned in a single stub resolver response or via explicit recursion by the SMTP client, if at any stage of recursive expansion an "insecure" CNAME record is encountered, then it and all subsequent results (in particular, the final result) MUST be considered "insecure", regardless of whether or not any earlier CNAME records leading to the "insecure" record were "secure".


Note that a security-aware non-validating stub resolver may return to the SMTP client an "insecure" reply received from a validating recursive resolver that contains a CNAME record along with additional answers recursively obtained starting at the target of the CNAME. In


this case, the only possible conclusion is that some record in the set of records returned is "insecure", and it is, in fact, possible that the initial CNAME record and a subset of the subsequent records are "secure".


If the SMTP client needs to determine the security status of the DNS zone containing the initial CNAME record, it will need to issue a separate query of type "CNAME" that returns only the initial CNAME record. Specifically, as discussed in Section 2.2.2, when "insecure" A or AAAA records are found for an SMTP server via a CNAME alias, the SMTP client will need to perform an additional CNAME query in order to determine whether or not the DNS zone in which the alias is published is DNSSEC signed.


2.2. TLS Discovery
2.2. TLS发现

As noted previously (in Section 1.3.1), opportunistic TLS with SMTP servers that advertise TLS support via STARTTLS is subject to an MITM downgrade attack. Also, some SMTP servers that are not, in fact, TLS capable erroneously advertise STARTTLS by default, and clients need to be prepared to retry cleartext delivery after STARTTLS fails. In contrast, DNSSEC-validated TLSA records MUST NOT be published for servers that do not support TLS. Clients can safely interpret their presence as a commitment by the server operator to implement TLS and STARTTLS.


This memo defines four actions to be taken after the search for a TLSA record returns "secure" usable results, "secure" unusable results, "insecure" or no results, or an error signal. The term "usable" in this context is in the sense of Section 4.1 of [RFC6698]. Specifically, if the DNS lookup for a TLSA record returns:


A "secure" TLSA RRset with at least one usable record: Any connection to the MTA MUST employ TLS encryption and MUST authenticate the SMTP server using the techniques discussed in the rest of this document. Failure to establish an authenticated TLS connection MUST result in falling back to the next SMTP server or delayed delivery.

至少有一条可用记录的“安全”TLSA RRset:与MTA的任何连接都必须采用TLS加密,并且必须使用本文档其余部分讨论的技术对SMTP服务器进行身份验证。未能建立经过身份验证的TLS连接必须导致退回到下一个SMTP服务器或延迟传递。

A "secure" non-empty TLSA RRset where all the records are unusable: Any connection to the MTA MUST be made via TLS, but authentication is not required. Failure to establish an encrypted TLS connection MUST result in falling back to the next SMTP server or delayed delivery.

“安全”非空TLSA RRset,其中所有记录都不可用:必须通过TLS建立与MTA的任何连接,但不需要身份验证。未能建立加密的TLS连接必须导致退回到下一个SMTP服务器或延迟传递。

An "insecure" TLSA RRset or DNSSEC-authenticated denial of existence of the TLSA records: A connection to the MTA SHOULD be made using (pre-DANE) opportunistic TLS; this includes using cleartext delivery when the remote SMTP server does not appear to support TLS. The MTA MAY retry in cleartext when delivery via TLS fails during the handshake or even during data transfer.

“不安全”TLSA RRset或DNSSEC认证的TLSA记录不存在:应使用(丹麦之前)机会主义TLS连接到MTA;这包括在远程SMTP服务器似乎不支持TLS时使用明文传递。在握手过程中,甚至在数据传输过程中,通过TLS传递失败时,MTA可能会在明文中重试。

Any lookup error: Lookup errors, including "bogus" and "indeterminate" as explained in Section 2.1.1, MUST result in falling back to the next SMTP server or delayed delivery.


An SMTP client MAY be configured to mandate DANE-verified delivery for some destinations. With mandatory DANE TLS (Section 6), delivery proceeds only when "secure" TLSA records are used to establish an encrypted and authenticated TLS channel with the SMTP server.

SMTP客户端可能被配置为强制某些目的地的DANE验证传递。对于强制性的DANE TLS(第6节),只有在使用“安全”TLSA记录与SMTP服务器建立加密和认证的TLS通道时,才能进行交付。

When the original next-hop destination is an address literal rather than a DNS domain, DANE TLS does not apply. Delivery proceeds using any relevant security policy configured by the MTA administrator. Similarly, when an MX RRset incorrectly lists a network address in lieu of an MX hostname, if an MTA chooses to connect to the network address in the nonconformant MX record, DANE TLSA does not apply for such a connection.

当原始下一跳目的地是地址文字而不是DNS域时,DANE TLS不适用。使用MTA管理员配置的任何相关安全策略进行交付。类似地,当MX RRset错误地列出网络地址而不是MX主机名时,如果MTA选择连接到不符合MX记录中的网络地址,则DANE TLSA不适用于此类连接。

In the subsections that follow, we explain how to locate the SMTP servers and the associated TLSA records for a given next-hop destination domain. We also explain which name or names are to be used in identity checks of the SMTP server certificate.


2.2.1. MX Resolution
2.2.1. MX分辨率

In this section, we consider next-hop domains that are subject to MX resolution and have MX records. The TLSA records and the associated base domain are derived separately for each MX hostname that is used to attempt message delivery. DANE TLS can authenticate message delivery to the intended next-hop domain only when the MX records are obtained securely via a DNSSEC-validated lookup.

在这一节中,我们考虑下一跳域的MX分辨率和MX记录。TLSA记录和关联的基本域分别为用于尝试消息传递的每个MX主机名派生。只有通过DNSSEC验证的查找安全地获取MX记录时,DANE TLS才能对发送到预期下一跳域的消息进行身份验证。

MX records MUST be sorted by preference; an MX hostname with a worse (numerically higher) MX preference that has TLSA records MUST NOT preempt an MX hostname with a better (numerically lower) preference that has no TLSA records. In other words, prevention of delivery loops by obeying MX preferences MUST take precedence over channel security considerations. Even with two equal-preference MX records, an MTA is not obligated to choose the MX hostname that offers more


security. Domains that want secure inbound mail delivery need to ensure that all their SMTP servers and MX records are configured accordingly.


In the language of [RFC5321], Section 5.1, the original next-hop domain is the "initial name". If the MX lookup of the initial name results in a CNAME alias, the MTA replaces the initial name with the resulting name and performs a new lookup with the new name. MTAs typically support recursion in CNAME expansion, so this replacement is performed repeatedly (up to the MTA's recursion limit) until the ultimate non-CNAME domain is found.


If the MX RRset (or any CNAME leading to it) is "insecure" (see Section 2.1.1) and DANE TLS for the given destination is mandatory (Section 6), delivery MUST be delayed. If the MX RRset is "insecure" and DANE TLS is not mandatory, the SMTP client is free to use pre-DANE opportunistic TLS (possibly even cleartext).

如果MX RRset(或任何通向它的CNAME)是“不安全的”(见第2.1.1节),并且指定目的地的DANE TLS是强制性的(第6节),则必须延迟交付。如果MX RRset是“不安全的”,并且DANE TLS不是强制性的,SMTP客户端可以自由使用前DANE机会主义TLS(甚至可能是明文)。

Since the protocol in this memo is an Opportunistic Security protocol [RFC7435], the SMTP client MAY elect to use DANE TLS (as described in Section 2.2.2 below), even with MX hosts obtained via an "insecure" MX RRset. For example, when a hosting provider has a signed DNS zone and publishes TLSA records for its SMTP servers, hosted domains that are not signed may still benefit from the provider's TLSA records. Deliveries via the provider's SMTP servers will not be subject to active attacks when sending SMTP clients elect to use the provider's TLSA records (active attacks that tamper with the "insecure" MX RRset are of course still possible in this case).

由于本备忘录中的协议是一种机会主义安全协议[RFC7435],因此SMTP客户端可以选择使用DANE TLS(如下文第2.2.2节所述),即使使用通过“不安全”MX RRset获得的MX主机也是如此。例如,当托管提供程序具有签名DNS区域并为其SMTP服务器发布TLSA记录时,未签名的托管域仍可能受益于提供程序的TLSA记录。当发送SMTP客户端选择使用提供商的TLSA记录时,通过提供商的SMTP服务器进行的传递不会受到主动攻击(在这种情况下,篡改“不安全”MX RRset的主动攻击当然仍然是可能的)。

When the MX records are not (DNSSEC) signed, an active attacker can redirect SMTP clients to MX hosts of his choice. Such redirection is tamper-evident when SMTP servers found via "insecure" MX records are recorded as the next-hop relay in the MTA delivery logs in their original (rather than CNAME-expanded) form. Sending MTAs SHOULD log unexpanded MX hostnames when these result from "insecure" MX lookups. Any successful authentication via an insecurely determined MX host MUST NOT be misrepresented in the mail logs as secure delivery to the intended next-hop domain.


In the absence of DNS lookup errors (Section 2.1.1), if the MX RRset is not "insecure", then it is "secure", and the SMTP client MUST treat each MX hostname as described in Section 2.2.2. When, for a given MX hostname, no TLSA records are found or only "insecure" TLSA records are found, DANE TLSA is not applicable with the SMTP server in question, and delivery proceeds to that host as with pre-DANE opportunistic TLS. To avoid downgrade attacks, any errors during TLSA lookups MUST, as explained in Section 2.1.2, cause the SMTP server in question to be treated as unreachable.

在没有DNS查找错误的情况下(第2.1.1节),如果MX RRset不是“不安全的”,则它是“安全的”,SMTP客户端必须按照第2.2.2节中的说明处理每个MX主机名。对于给定的MX主机名,如果找不到TLSA记录或只找到“不安全”的TLSA记录,则DANE TLSA不适用于所述SMTP服务器,并与前DANE机会主义TLS一样将传递到该主机。为避免降级攻击,如第2.1.2节所述,TLSA查找过程中的任何错误都必须导致相关SMTP服务器被视为无法访问。

2.2.2. Non-MX Destinations
2.2.2. 非MX目的地

This section describes the algorithm used to locate the TLSA records and associated TLSA base domain for an input domain that is not subject to MX resolution, that represents a hostname from a "secure" MX RRset, or that lacks MX records. Such domains include:

本节描述了用于定位输入域的TLSA记录和相关TLSA基本域的算法,该输入域不受MX解析的约束,表示“安全”MX RRset中的主机名,或者缺少MX记录。这些领域包括:

o Any host that is configured by the sending MTA administrator as the next-hop relay for some or all domains and that is not subject to MX resolution.

o 由发送MTA管理员配置为某些或所有域的下一跳中继且不受MX解析约束的任何主机。

o A domain that has MX records. When a domain has MX records, we treat each MX host listed in those MX records as though it were a non-MX destination -- that is, in the same way as we would treat an administrator-configured relay that handles mail for that domain. (Unlike administrator-specified relays, MTAs are not required to support CNAME expansion of next-hop names found via MX lookups.)

o 具有MX记录的域。当一个域有MX记录时,我们将这些MX记录中列出的每个MX主机视为非MX目的地——也就是说,与处理该域邮件的管理员配置的中继相同。(与管理员指定的中继不同,MTA不需要支持通过MX查找找到的下一跳名称的CNAME扩展。)

o A next-hop destination domain subject to MX resolution that has no MX records. In this case, the domain's name is implicitly also its sole SMTP server name.

o 受MX解析约束的下一跳目标域,没有MX记录。在本例中,域名隐式地也是其唯一的SMTP服务器名。

Note that DNS queries with type TLSA are mishandled by load-balancing nameservers that serve the MX hostnames of some large email providers. The DNS zones served by these nameservers are not signed and contain no TLSA records. These nameservers SHOULD provide "insecure" negative replies that indicate the nonexistence of the TLSA records, but instead they fail by not responding at all or by responding with a DNS RCODE [RFC1035] other than NXDOMAIN, e.g., SERVFAIL or NOTIMP [RFC2136].

请注意,为某些大型电子邮件提供商的MX主机名提供服务的负载平衡名称服务器错误地处理了TLSA类型的DNS查询。这些名称服务器服务的DNS区域没有签名,并且不包含TLSA记录。这些名称服务器应提供“不安全”的否定回复,表明TLSA记录不存在,但它们完全不响应或使用NXDOMAIN以外的DNS RCODE[RFC1035]响应而失败,例如SERVFAIL或NOTIMP[RFC2136]。

To avoid problems delivering mail to domains whose SMTP servers are served by these problematic nameservers, the SMTP client MUST perform any A and/or AAAA queries for the destination before attempting to locate the associated TLSA records. This lookup is needed in any case to determine (1) whether or not the destination domain is reachable and (2) the DNSSEC validation status of the chain of CNAME queries required to reach the ultimate address records.


If no address records are found, the destination is unreachable. If address records are found but the DNSSEC validation status of the first query response is "insecure" (see Section 2.1.3), the SMTP client SHOULD NOT proceed to search for any associated TLSA records. In the case of these problematic domains, TLSA queries would lead to DNS lookup errors and would cause messages to be consistently delayed and ultimately returned to the sender. We don't expect to find any


"secure" TLSA records associated with a TLSA base domain that lies in an unsigned DNS zone. Therefore, skipping TLSA lookups in this case will also reduce latency, with no detrimental impact on security.


If the A and/or AAAA lookup of the initial name yields a CNAME, we replace it with the resulting name as if it were the initial name and perform a lookup again using the new name. This replacement is performed recursively (up to the MTA's recursion limit).


We consider the following cases for handling a DNS response for an A or AAAA DNS lookup:

我们考虑以下情况来处理A或AAAA DNS查找的DNS响应:

Not found: When the DNS queries for A and/or AAAA records yield neither a list of addresses nor a CNAME (or CNAME expansion is not supported), the destination is unreachable.


Non-CNAME: The answer is not a CNAME alias. If the address RRset is "secure", TLSA lookups are performed as described in Section 2.2.3 with the initial name as the candidate TLSA base domain. If no "secure" TLSA records are found, DANE TLS is not applicable and mail delivery proceeds with pre-DANE opportunistic TLS (which, being best-effort, degrades to cleartext delivery when STARTTLS is not available or the TLS handshake fails).


Insecure CNAME: The input domain is a CNAME alias, but the ultimate network address RRset is "insecure" (see Section 2.1.1). If the initial CNAME response is also "insecure", DANE TLS does not apply. Otherwise, this case is treated just like the non-CNAME case above, where a search is performed for a TLSA record with the original input domain as the candidate TLSA base domain.

不安全的CNAME:输入域是CNAME别名,但最终网络地址RRset是“不安全的”(参见第2.1.1节)。如果初始CNAME响应也“不安全”,则DANE TLS不适用。否则,这种情况就像上面的非CNAME情况一样处理,其中对原始输入域作为候选TLSA基域的TLSA记录执行搜索。

Secure CNAME: The input domain is a CNAME alias, and the ultimate network address RRset is "secure" (see Section 2.1.1). Two candidate TLSA base domains are tried: the fully CNAME-expanded initial name and, failing that, the initial name itself.


In summary, if it is possible to securely obtain the full, CNAME-expanded, DNSSEC-validated address records for the input domain, then that name is the preferred TLSA base domain. Otherwise, the unexpanded input domain is the candidate TLSA base domain. When no "secure" TLSA records are found at either the CNAME-expanded or unexpanded domain, then DANE TLS does not apply for mail delivery via the input domain in question. And, as always, errors, "bogus" results, or "indeterminate" results for any query in the process MUST result in delaying or abandoning delivery.

总之,如果可以安全地获取输入域的完整、CNAME扩展、DNSSEC验证的地址记录,则该名称是首选TLSA基域。否则,未扩展的输入域是候选TLSA基域。如果在CNAME扩展域或未扩展域中均未找到“安全”TLSA记录,则DANE TLS不会通过相关输入域申请邮件传递。而且,一如既往,流程中任何查询的错误、“虚假”结果或“不确定”结果都必须导致延迟或放弃交付。

2.2.3. TLSA Record Lookup
2.2.3. TLSA记录查找

When the SMTP server's hostname is not a CNAME or DNAME alias, the list of associated candidate TLSA base domains (see below) consists of just the server hostname.


When the hostname is an alias with a "secure" (at every stage) full expansion, the list of candidate TLSA base domains (see below) is a pair of domains: the fully expanded server hostname first, and the unexpanded server hostname second.


Each candidate TLSA base domain (alias-expanded or original) is in turn prefixed with service labels of the form "_<port>._tcp". The resulting domain name is used to issue a DNSSEC query with the query type set to TLSA ([RFC6698], Section 7.1).

每个候选TLSA基本域(扩展别名或原始别名)的前缀依次为格式为“\u<port>\u tcp”的服务标签。生成的域名用于发出DNSSEC查询,查询类型设置为TLSA([RFC6698],第7.1节)。

The first of these candidate domains to yield a "secure" TLSA RRset becomes the actual TLSA base domain.

产生“安全”TLSA RRset的第一个候选域成为实际的TLSA基域。

For SMTP, the destination TCP port is typically 25, but this may be different with custom routes specified by the MTA administrator, in which case the SMTP client MUST use the appropriate number in the "_<port>" prefix in place of "_25". If, for example, the candidate base domain is "" and the SMTP connection is to port 25, the TLSA RRset is obtained via a DNSSEC query of the form:

对于SMTP,目标TCP端口通常为25,但这可能与MTA管理员指定的自定义路由不同,在这种情况下,SMTP客户端必须在“\u<port>”前缀中使用适当的数字来代替“\u 25”。例如,如果候选基本域为“”,SMTP连接为端口25,则通过DNSSEC查询获得TLSA RRset,其形式如下: IN TLSA ?。在TLSA?

The query response may be a CNAME or the actual TLSA RRset. If the response is a CNAME, the SMTP client (through the use of its security-aware stub resolver) restarts the TLSA query at the target domain, following CNAMEs as appropriate, and keeps track of whether or not the entire chain is "secure". If any "insecure" records are encountered or the TLSA records don't exist, the next candidate TLSA base domain is tried instead.

查询响应可以是CNAME或实际TLSA RRset。如果响应是CNAME,SMTP客户端(通过使用其安全感知的存根解析器)在目标域上重新启动TLSA查询,并根据需要跟踪CNAMEs,并跟踪整个链是否“安全”。如果遇到任何“不安全”记录或TLSA记录不存在,则尝试下一个候选TLSA基域。

If the ultimate response is a "secure" TLSA RRset, then the candidate TLSA base domain will be the actual TLSA base domain, and the TLSA RRset will constitute the TLSA records for the destination. If none of the candidate TLSA base domains yield "secure" TLSA records, then the SMTP client is free to use pre-DANE opportunistic TLS (possibly even cleartext).

如果最终响应是“安全”TLSA RRset,则候选TLSA基本域将是实际的TLSA基本域,并且TLSA RRset将构成目标的TLSA记录。如果候选TLSA基本域中没有一个产生“安全”的TLSA记录,则SMTP客户端可以自由使用丹麦以前的机会主义TLS(甚至可能是明文)。

TLSA record publishers may leverage CNAMEs to reference a single authoritative TLSA RRset specifying a common CA or a common end-entity certificate to be used with multiple TLS services. Such CNAME expansion does not change the SMTP client's notion of the TLSA base domain; thus, when is a CNAME, the base

TLSA记录发布者可以利用CNAMEs引用一个权威TLSA RRset,指定一个公共CA或一个公共终端实体证书,用于多个TLS服务。此类CNAME扩展不会改变SMTP客户端对TLSA基本域的概念;因此,当是CNAME时

domain remains, and this is still the reference identifier used together with the next-hop domain in peer certificate name checks.


Note that shared end-entity certificate associations expose the publishing domain to substitution attacks, where an MITM attacker can reroute traffic to a different server that shares the same end-entity certificate. Such shared end-entity TLSA records SHOULD be avoided unless the servers in question are functionally equivalent or employ mutually incompatible protocols (an active attacker gains nothing by diverting client traffic from one such server to another).


A better example, employing a shared trust anchor rather than shared end-entity certificates, is illustrated by the DNSSEC-validated records below:

下面的DNSSEC验证记录说明了使用共享信任锚而非共享终端实体证书的更好示例: IN MX 0 IN MX 0 IN CNAME IN CNAME IN TLSA 2 0 1 e3b0c44298fc1c149a...。在MX 0 mx1.example.com中。。在MX 0 mx2.example.com中。在CNAME tlsa201._dane.example.com中。在CNAME tlsa201._dane.example.com中。。在TLSA 2 0 1 e3b0c44298fc1c149a中。。。

The SMTP servers and will be expected to have certificates issued under a common trust anchor, but each MX hostname's TLSA base domain remains unchanged despite the above CNAME records. Correspondingly, each SMTP server will be associated with a pair of reference identifiers consisting of its hostname plus the next-hop domain "".


If, during TLSA resolution (including possible CNAME indirection), at least one "secure" TLSA record is found (even if not usable because it is unsupported by the implementation or support is administratively disabled), then the corresponding host has signaled its commitment to implement TLS. The SMTP client MUST NOT deliver mail via the corresponding host unless a TLS session is negotiated via STARTTLS. This is required to avoid MITM STARTTLS downgrade attacks.

如果在TLSA解析期间(包括可能的CNAME间接寻址),发现至少一条“安全”TLSA记录(即使由于实现不支持而不可用,或者支持被管理性禁用),则相应的主机已发出信号表示其承诺实现TLS。除非通过STARTTLS协商TLS会话,否则SMTP客户端不得通过相应的主机传递邮件。这是避免MITM STARTTLS降级攻击所必需的。

As noted previously (in Section 2.2.2), when no "secure" TLSA records are found at the fully CNAME-expanded name, the original unexpanded name MUST be tried instead. This supports customers of hosting providers where the provider's zone cannot be validated with DNSSEC but the customer has shared appropriate key material with the hosting provider to enable TLS via SNI. Intermediate names that arise during CNAME expansion that are neither the original name nor the final name are never candidate TLSA base domains, even if "secure".


3. DANE Authentication
3. 丹麦认证

This section describes which TLSA records are applicable to SMTP opportunistic DANE TLS and how to apply such records to authenticate the SMTP server. With opportunistic DANE TLS, both the TLS support implied by the presence of DANE TLSA records and the verification parameters necessary to authenticate the TLS peer are obtained together. In contrast to protocols where channel security policy is set exclusively by the client, authentication via this protocol is expected to be less prone to connection failure caused by incompatible configuration of the client and server.

本节介绍哪些TLSA记录适用于SMTP投机性DANE TLS,以及如何应用这些记录对SMTP服务器进行身份验证。对于机会主义的DANE TLS,可以同时获得DANE TLSA记录所暗示的TLS支持和认证TLS对等方所需的验证参数。与通道安全策略由客户端专门设置的协议相比,通过此协议进行的身份验证预计不太容易因客户端和服务器的配置不兼容而导致连接失败。

3.1. TLSA Certificate Usages
3.1. TLSA证书使用

The DANE TLSA specification [RFC6698] defines multiple TLSA RR types via combinations of three numeric parameters. The numeric values of these parameters were later given symbolic names in [RFC7218]. The rest of the TLSA record is the "certificate association data field", which specifies the full or digest value of a certificate or public key.

丹麦TLSA规范[RFC6698]通过三个数字参数的组合定义了多个TLSA RR类型。这些参数的数值后来在[RFC7218]中给出了符号名称。TLSA记录的其余部分是“证书关联数据字段”,它指定证书或公钥的完整值或摘要值。

Since opportunistic DANE TLS will be used by non-interactive MTAs, with no user to "click OK" when authentication fails, reliability of peer authentication is paramount. Server operators are advised to publish TLSA records that are least likely to fail authentication due to interoperability or operational problems. Because DANE TLS relies on coordinated changes to DNS and SMTP server settings, the best choice of records to publish will depend on site-specific practices.

由于机会主义DANE TLS将由非交互式MTA使用,当身份验证失败时,用户无需“单击确定”,因此对等身份验证的可靠性至关重要。建议服务器运营商发布由于互操作性或操作问题导致身份验证失败的可能性最小的TLSA记录。由于DANE TLS依赖于对DNS和SMTP服务器设置的协调更改,因此发布记录的最佳选择将取决于特定于站点的做法。

The certificate usage element of a TLSA record plays a critical role in determining how the corresponding certificate association data field is used to authenticate a server's certificate chain. Sections 3.1.1 and 3.1.2 explain the process for certificate usages DANE-EE(3) and DANE-TA(2), respectively. Section 3.1.3 briefly explains why certificate usages PKIX-TA(0) and PKIX-EE(1) are not applicable with opportunistic DANE TLS.

TLSA记录的certificate usage元素在确定如何使用相应的证书关联数据字段对服务器的证书链进行身份验证方面起着关键作用。第3.1.1节和第3.1.2节分别解释了DANE-EE(3)和DANE-TA(2)的证书使用流程。第3.1.3节简要解释了为什么证书使用PKIX-TA(0)和PKIX-EE(1)不适用于机会主义丹麦TLS。

In summary, we RECOMMEND the use of "DANE-EE(3) SPKI(1) SHA2-256(1)", with "DANE-TA(2) Cert(0) SHA2-256(1)" TLSA records as a second choice, depending on site needs. See Sections 3.1.1 and 3.1.2 for more details. Other combinations of TLSA parameters either (1) are explicitly unsupported or (2) offer little to recommend them over these two.


3.1.1. Certificate Usage DANE-EE(3)
3.1.1. DANE-EE证书使用(3)

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.


The expiration date of the server certificate MUST be ignored: the validity period of the TLSA record key binding is determined by the validity interval of the TLSA record DNSSEC signature.


With DANE-EE(3), servers need not employ SNI (they may ignore the client's SNI message) even when the server is known under independent names that would otherwise require separate certificates. It is instead sufficient for the TLSA RRsets for all the domains in question to match the server's default certificate. Of course, with SMTP servers it is simpler still to publish the same MX hostname for all the hosted domains.

对于DANE-EE(3),服务器不需要使用SNI(它们可能会忽略客户端的SNI消息),即使服务器是以独立名称命名的,否则需要单独的证书。相反,所有相关域的TLSA RRSET都足以匹配服务器的默认证书。当然,对于SMTP服务器,为所有托管域发布相同的MX主机名更简单。

For domains where it is practical to make coordinated changes in DNS TLSA records during SMTP server key rotation, it is often best to publish end-entity DANE-EE(3) certificate associations. DANE-EE(3) certificates don't suddenly stop working when leaf or intermediate certificates expire, nor do they fail when the server operator neglects to configure all the required issuer certificates in the server certificate chain.

对于在SMTP服务器密钥轮换期间对DNS TLSA记录进行协调更改是可行的域,通常最好发布最终实体DANE-EE(3)证书关联。DANE-EE(3)证书不会在叶证书或中间证书过期时突然停止工作,也不会在服务器操作员忽略配置服务器证书链中所有必需的颁发者证书时失败。

TLSA records published for SMTP servers SHOULD, in most cases, be "DANE-EE(3) SPKI(1) SHA2-256(1)" records. Since all DANE implementations are required to support SHA2-256, this record type works for all clients and need not change across certificate renewals with the same key.


3.1.2. Certificate Usage DANE-TA(2)
3.1.2. DANE-TA证书使用(2)

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 trust anchor (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:

某些域可能希望避免为每个TLS服务发布唯一TLSA RRs的操作复杂性。如果域使用公共颁发CA为多个TLS服务创建证书,则将颁发机构发布为所有相关服务的证书链的信任锚(TA)可能更简单。然后,可以将同一TA发布的每个服务的TLSA查询域(带有端口和协议前缀标签的TLSA基本域)设置为CNAME别名,该别名指向与TA匹配的公共TLSA RRset。例如:                IN MX 0                IN MX 0   IN CNAME   IN CNAME  IN TLSA 2 0 1 e3b0c44298fc1c14....
                     IN MX 0                IN MX 0   IN CNAME   IN CNAME  IN TLSA 2 0 1 e3b0c44298fc1c14....

With usage DANE-TA(2), the server certificates will need to have names that match one of the client's reference identifiers (see [RFC6125]). The server MAY employ SNI to select the appropriate certificate to present to the client.


SMTP servers that rely on certificate usage DANE-TA(2) TLSA records for TLS authentication MUST include the TA certificate as part of the certificate chain presented in the TLS handshake server certificate message even when it is a self-signed root certificate. Many SMTP servers are not configured with a comprehensive list of trust anchors, nor are they expected to be at any point in the future. Some MTAs will ignore all locally trusted certificates when processing usage DANE-TA(2) TLSA records. Thus, even when the TA happens to be a public CA known to the SMTP client, authentication is likely to fail unless the TA certificate is included in the TLS server certificate message.


With some SMTP server software, it is not possible to configure the server to include self-signed (root) CA certificates in the server certificate chain. Such servers either MUST publish DANE-TA(2) records for an intermediate certificate or MUST instead use DANE-EE(3) TLSA records.


TLSA records with a matching type of Full(0) are discouraged. 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 interoperability issues with large TLSA records containing full certificates or keys.


TLSA Publishers employing DANE-TA(2) records SHOULD publish records with a selector of Cert(0). Such TLSA records are associated with the whole trust anchor certificate, not just with the trust anchor public key. In particular, the SMTP client SHOULD then apply any relevant constraints from the trust anchor certificate, such as, for example, path length constraints.


While a selector of SPKI(1) may also be employed, the resulting TLSA record will not specify the full trust anchor certificate content, and elements of the trust anchor certificate other than the public key become mutable. This may, for example, allow a subsidiary CA to issue a chain that violates the trust anchor's path length or name constraints.


3.1.3. Certificate Usages PKIX-TA(0) and PKIX-EE(1)
3.1.3. 证书使用PKIX-TA(0)和PKIX-EE(1)

Note that this section applies to MTA-to-MTA SMTP, which is normally on port 25 -- that is, to servers that are the SMTP servers for one or more destination domains. Other uses of SMTP, such as in MUA-to-MSA submission on ports 587 or 465, are out of scope for this document. Where those other uses also employ TLS opportunistically and/or depend on DNSSEC as a result of DNS-based discovery of service location, the relevant specifications should, as appropriate, arrive at similar conclusions.

请注意,本节适用于MTA到MTA SMTP(通常位于端口25上),也就是说,适用于作为一个或多个目标域的SMTP服务器的服务器。SMTP的其他用途,如端口587或465上的MUA到MSA提交,不在本文档的范围内。如果由于基于DNS的服务位置发现,这些其他用途也有机会使用TLS和/或依赖DNSSEC,则相关规范应酌情得出类似结论。

As noted in Sections 1.3.1 and 1.3.2, sending MTAs cannot, without relying on DNSSEC for "secure" MX records and DANE for STARTTLS support signaling, perform server identity verification or prevent STARTTLS downgrade attacks. The use of PKIX CAs offers no added security, since an attacker capable of compromising DNSSEC is free to replace any PKIX-TA(0) or PKIX-EE(1) TLSA records with records bearing any convenient non-PKIX certificate usage. Finally, as explained in Section 1.3.4, there is no list of trusted CAs agreed upon by all MTAs and no user to "click OK" when a server's CA is not trusted by a client.

如第1.3.1节和第1.3.2节所述,如果不依赖DNSSEC的“安全”MX记录和DANE的STARTTLS支持信令,发送MTA无法执行服务器身份验证或防止STARTTLS降级攻击。使用PKIX CA不提供额外的安全性,因为能够破坏DNSSEC的攻击者可以自由地将任何PKIX-TA(0)或PKIX-EE(1)TLSA记录替换为包含任何方便的非PKIX证书用法的记录。最后,如第1.3.4节所述,没有所有MTA同意的受信任CA列表,当客户端不信任服务器的CA时,没有用户“单击确定”。

Therefore, TLSA records for the port 25 SMTP service used by client MTAs SHOULD NOT include TLSA RRs with certificate usage PKIX-TA(0) or PKIX-EE(1). SMTP client MTAs cannot be expected to be configured with a suitably complete set of trusted public CAs. Lacking a complete set of public CAs, MTA clients would not be able to verify the certificates of SMTP servers whose issuing root CAs are not trusted by the client.

因此,客户端MTA使用的端口25 SMTP服务的TLSA记录不应包括证书使用PKIX-TA(0)或PKIX-EE(1)的TLSA RRs。SMTP客户端MTA不能配置为具有适当完整的受信任公共CA集。由于缺少一套完整的公共CA,MTA客户端将无法验证SMTP服务器的证书,这些服务器的颁发根CA不受客户端信任。

Opportunistic DANE TLS needs to interoperate without bilateral coordination of security settings between client and server systems. Therefore, parameter choices that are fragile in the absence of bilateral coordination are unsupported. Nothing is lost; since the PKIX certificate usages cannot aid SMTP TLS security, they can only impede SMTP TLS interoperability.

机会主义的DANE TLS需要在客户端和服务器系统之间不进行双边安全设置协调的情况下进行互操作。因此,不支持在缺乏双边协调的情况下脆弱的参数选择。什么都没有失去;由于PKIX证书的使用不能帮助SMTP TLS的安全性,它们只能阻碍SMTP TLS的互操作性。

SMTP client treatment of TLSA RRs with certificate usages PKIX-TA(0) or PKIX-EE(1) is undefined. As with any other unsupported certificate usage, SMTP clients MAY treat such records as "unusable".

未定义证书使用PKIX-TA(0)或PKIX-EE(1)的TLSA RRs的SMTP客户端处理。与任何其他不受支持的证书使用一样,SMTP客户端可能会将此类记录视为“不可用”。

3.2. Certificate Matching
3.2. 证书匹配

When at least one usable "secure" TLSA record is found, the SMTP client MUST use TLSA records to authenticate the SMTP server. Messages MUST NOT be delivered via the SMTP server if authentication fails; otherwise, the SMTP client is vulnerable to MITM attacks.


3.2.1. DANE-EE(3) Name Checks
3.2.1. DANE-EE(3)姓名检查

The SMTP client MUST NOT perform certificate name checks with certificate usage DANE-EE(3) (Section 3.1.1).


3.2.2. DANE-TA(2) Name Checks
3.2.2. DANE-TA(2)姓名检查

To match a server via a TLSA record with certificate usage DANE-TA(2), the client MUST perform name checks to ensure that it has reached the correct server. In all DANE-TA(2) cases, the SMTP client MUST employ the TLSA base domain as the primary reference identifier for matching the server certificate.


TLSA records for MX hostnames: If the TLSA base domain was obtained indirectly via a "secure" MX lookup (including any CNAME-expanded name of an MX hostname), then the original next-hop domain used in the MX lookup MUST be included as a second reference identifier. The CNAME-expanded original next-hop domain MUST be included as a third reference identifier if different from the original next-hop domain. When the client MTA is employing DANE TLS security despite "insecure" MX redirection, the MX hostname is the only reference identifier.

MX主机名的TLSA记录:如果TLSA基本域是通过“安全”MX查找间接获得的(包括MX主机名的任何CNAME扩展名),则MX查找中使用的原始下一跳域必须包含为第二个参考标识符。如果CNAME扩展的原始下一跳域与原始下一跳域不同,则必须将其作为第三个参考标识符包括在内。尽管MX重定向“不安全”,但当客户端MTA使用DANE TLS安全性时,MX主机名是唯一的参考标识符。

TLSA records for non-MX hostnames: If MX records were not used (e.g., if none exist) and the TLSA base domain is the CNAME-expanded original next-hop domain, then the original next-hop domain MUST be included as a second reference identifier.


Accepting certificates with the original next-hop domain in addition to the MX hostname allows a domain with multiple MX hostnames to field a single certificate bearing a single domain name (i.e., the email domain) across all the SMTP servers. This also aids interoperability with pre-DANE SMTP clients that are configured to look for the email domain name in server certificates -- for example, with "secure" DNS records as shown below:

除了MX主机名之外,接受具有原始下一跳域的证书允许具有多个MX主机名的域跨所有SMTP服务器输入具有单个域名(即电子邮件域)的单个证书。这也有助于与配置为在服务器证书中查找电子邮件域名的丹麦之前的SMTP客户端的互操作性,例如,与“安全”DNS记录的互操作性,如下所示:            IN CNAME                IN CNAME                     IN MX    10                     IN MX    15                     IN MX    20
      ;                IN A       IN TLSA  2 0 1 ...
      ;                IN CNAME            IN A
      ; IN TLSA ? (NXDOMAIN)       IN TLSA  2 0 1 ...
      ;                IN CNAME            IN A   IN TLSA  2 0 1 ...
                 IN CNAME                IN CNAME                     IN MX    10                     IN MX    15                     IN MX    20
      ;                IN A       IN TLSA  2 0 1 ...
      ;                IN CNAME            IN A
      ; IN TLSA ? (NXDOMAIN)       IN TLSA  2 0 1 ...
      ;                IN CNAME            IN A   IN TLSA  2 0 1 ...

Certificate name checks for delivery of mail to via any of the associated SMTP servers MUST accept at least the names "" and "", which are, respectively, the original and fully expanded next-hop domain. When the SMTP server is, name checks MUST accept the TLSA base domain "". If, despite the fact that MX hostnames are required to not be aliases, the MTA supports delivery via "" or "", then name checks MUST accept the respective TLSA base domains "" and "".


3.2.3. Reference Identifier Matching
3.2.3. 参考标识符匹配

When name checks are applicable (certificate usage DANE-TA(2)), if the server certificate contains a Subject Alternative Name extension [RFC5280] with at least one DNS-ID [RFC6125], then only the DNS-IDs are matched against the client's reference identifiers. The CN-ID [RFC6125] is only considered when no DNS-IDs are present. The server certificate is considered matched when one of its presented identifiers [RFC5280] matches any of the client's reference identifiers.

当名称检查适用时(证书使用DANE-TA(2)),如果服务器证书包含具有至少一个DNS-ID[RFC6125]的使用者替代名称扩展[RFC5280],则只有DNS ID与客户端的参考标识符匹配。CN-ID[RFC6125]仅在不存在DNS ID时才被考虑。当服务器证书的一个标识符[RFC5280]与客户端的任何参考标识符匹配时,服务器证书被视为匹配。

Wildcards are valid in either DNS-IDs or the CN-ID when applicable. The wildcard character must be the entire first label of the DNS-ID or CN-ID. Thus, "*" is valid, while "smtp*" and "*" are not. SMTP clients MUST support wildcards that match the first label of the reference identifier, with the remaining labels matching verbatim. For example, the DNS-ID "*" matches the reference identifier "". SMTP clients MAY, subject to local policy, allow wildcards to match multiple reference identifier labels, but servers cannot expect broad support for such a policy. Therefore, any wildcards in server certificates SHOULD match exactly one label in either the TLSA base domain or the next-hop domain.

适用时,通配符在DNS ID或CN-ID中有效。通配符必须是DNS-ID或CN-ID的整个第一个标签。因此,“*”有效,而“smtp*”和“*”无效。SMTP客户端必须支持与引用标识符的第一个标签匹配的通配符,其余标签与逐字匹配。例如,DNS-ID“*”与参考标识符“”匹配。根据本地策略,SMTP客户端可能允许通配符匹配多个引用标识符标签,但服务器不能期望此类策略得到广泛支持。因此,服务器证书中的任何通配符都应该与TLSA基本域或下一跳域中的一个标签完全匹配。

4. Server Key Management
4. 服务器密钥管理

Two TLSA records MUST be published before employing a new EE or TA public key or certificate: one matching the currently deployed key and the other matching the new key scheduled to replace it. Once sufficient time has elapsed for all DNS caches to expire the previous TLSA RRset and related signature RRsets, servers may be configured to use the new EE private key and associated public key certificate or may employ certificates signed by the new trust anchor.

在使用新的EE或TA公钥或证书之前,必须发布两个TLSA记录:一个匹配当前部署的密钥,另一个匹配计划替换的新密钥。一旦经过足够的时间使所有DNS缓存使以前的TLSA RRset和相关签名RRset过期,服务器可以配置为使用新的EE私钥和相关公钥证书,或者可以使用由新的信任锚签名的证书。

Once the new public key or certificate is in use, the TLSA RR that matches the retired key can be removed from DNS, leaving only RRs that match keys or certificates in active use.

使用新公钥或证书后,可以从DNS中删除与失效密钥匹配的TLSA RR,只保留与密钥或证书匹配的RRs处于活动使用状态。

As described in Section 3.1.2, when server certificates are validated via a DANE-TA(2) trust anchor and CNAME records are employed to store the TA association data at a single location, the responsibility of updating the TLSA RRset shifts to the operator of the trust anchor. Before a new trust anchor is used to sign any new server certificates, its certificate (digest) is added to the relevant TLSA RRset. After enough time elapses for the original TLSA RRset to age out of DNS caches, the new trust anchor can start issuing new server certificates. Once all certificates issued under the previous trust anchor have expired, its associated RRs can be removed from the TLSA RRset.

如第3.1.2节所述,当通过DANE-TA(2)信任锚验证服务器证书并使用CNAME记录在单个位置存储TA关联数据时,更新TLSA RRset的责任转移到信任锚的操作员。在使用新的信任锚点签署任何新的服务器证书之前,其证书(摘要)将添加到相关的TLSA RRset。在经过足够的时间使原始TLSA RRset从DNS缓存中过期后,新的信任锚可以开始颁发新的服务器证书。在前一个信任锚点下颁发的所有证书过期后,可以从TLSA RRs集中删除其关联的RRs。

In the DANE-TA(2) key management model, server operators do not generally need to update DNS TLSA records after initially creating a CNAME record that references the centrally operated DANE-TA(2) RRset. If a particular server's key is compromised, its TLSA CNAME SHOULD be replaced with a DANE-EE(3) association until the certificate for the compromised key expires, at which point it can return to using a CNAME record. If the central trust anchor is compromised, all

在DANE-TA(2)密钥管理模型中,服务器运营商通常不需要在最初创建引用集中操作的DANE-TA(2)RRset的CNAME记录后更新DNS TLSA记录。如果某个特定服务器的密钥被泄露,其TLSA CNAME应替换为DANE-EE(3)关联,直到泄露密钥的证书过期,此时它可以返回使用CNAME记录。如果中央信任锚受损,则所有

servers need to be issued new keys by a new TA, and an updated DANE-TA(2) TLSA RRset needs to be published containing just the new TA.

服务器需要由新TA颁发新密钥,并且需要发布仅包含新TA的更新DANE-TA(2)TLSA RRset。

SMTP servers cannot expect broad Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) support from SMTP clients. As outlined above, with DANE, compromised server or trust anchor keys can be "revoked" by removing them from the DNS without the need for client-side support for OCSP or CRLs.


5. Digest Algorithm Agility
5. 摘要算法敏捷性

While [RFC6698] specifies multiple digest algorithms, it does not specify a protocol by which the SMTP 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. When stronger algorithms are an option, deprecated algorithms SHOULD be avoided. Such a protocol is specified in [RFC7671]. SMTP clients and servers that implement this specification MUST comply with the requirements outlined in Section 9 of [RFC7671].


6. Mandatory TLS Security
6. 强制TLS安全

An MTA implementing this protocol may require a stronger security assurance when sending email to selected destinations. The sending organization may need to send sensitive email and/or may have regulatory obligations to protect its content. This protocol is not in conflict with such a requirement and, in fact, can often simplify authenticated delivery to such destinations.


Specifically, with domains that publish DANE TLSA records for their MX hostnames, a sending MTA can be configured to use the receiving domain's DANE TLSA records to authenticate the corresponding SMTP server. Authentication via DANE TLSA records is easier to manage, as changes in the receiver's expected certificate properties are made on the receiver end and don't require manually communicated configuration changes. With mandatory DANE TLS, when no usable TLSA records are found, message delivery is delayed. Thus, mail is only sent when an authenticated TLS channel is established to the remote SMTP server.

具体而言,对于为其MX主机名发布DANE TLSA记录的域,可以将发送MTA配置为使用接收域的DANE TLSA记录对相应的SMTP服务器进行身份验证。通过DANE TLSA记录进行身份验证更易于管理,因为接收方的预期证书属性的更改是在接收方端进行的,不需要手动进行配置更改。对于强制的DANE TLS,当找不到可用的TLSA记录时,消息传递会延迟。因此,只有在向远程SMTP服务器建立经过身份验证的TLS通道时,才会发送邮件。

Administrators of mail servers that employ mandatory DANE TLS need to carefully monitor their mail logs and queues. If a partner domain unwittingly misconfigures its TLSA records, disables DNSSEC, or misconfigures SMTP server certificate chains, mail will be delayed and may bounce if the issue is not resolved in a timely manner.

使用强制DANE TLS的邮件服务器的管理员需要仔细监视其邮件日志和队列。如果合作伙伴域无意中错误配置其TLSA记录、禁用DNSSEC或错误配置SMTP服务器证书链,则邮件将被延迟,如果问题未及时解决,邮件可能会反弹。

7. Note on DANE for Message User Agents
7. 关于消息用户代理的DANE说明

We note that SMTP is also used between Message User Agents (MUAs) and Message Submission Agents (MSAs) [RFC6409]. In [RFC6186], a protocol is specified that enables an MUA to dynamically locate the MSA based on the user's email address. SMTP connection security considerations for MUAs implementing [RFC6186] are largely analogous to connection security requirements for MTAs, and this specification could be applied largely verbatim with DNS MX records replaced by corresponding DNS Service (SRV) records [RFC7673].

我们注意到,SMTP也用于消息用户代理(MUA)和消息提交代理(MSA)[RFC6409]。在[RFC6186]中,指定了一种协议,使MUA能够根据用户的电子邮件地址动态定位MSA。实现[RFC6186]的MUA的SMTP连接安全注意事项在很大程度上类似于MTA的连接安全要求,本规范可以在很大程度上逐字应用,DNS MX记录被相应的DNS服务(SRV)记录所取代[RFC7673]。

However, until MUAs begin to adopt the dynamic configuration mechanisms of [RFC6186], they are adequately served by more traditional static TLS security policies. Specification of DANE TLS for MUA-to-MSA SMTP is left to future documents that focus specifically on SMTP security between MUAs and MSAs.

然而,在MUA开始采用[RFC6186]的动态配置机制之前,更多传统的静态TLS安全策略足以为其提供服务。针对MUA到MSA SMTP的DANE TLS规范将留待将来的文档专门关注MUA和MSA之间的SMTP安全性。

8. Interoperability Considerations
8. 互操作性注意事项
8.1. SNI Support
8.1. SNI支持

To ensure that the server sends the right certificate chain, the SMTP client MUST send the TLS SNI extension containing the TLSA base domain. This precludes the use of the Secure Socket Layer (SSL) HELLO that is SSL 2.0 compatible by the SMTP client.

为确保服务器发送正确的证书链,SMTP客户端必须发送包含TLSA基本域的TLS SNI扩展。这排除了SMTP客户端使用与SSL 2.0兼容的安全套接字层(SSL)HELLO。

Each SMTP server MUST present a certificate chain (see [RFC5246], Section 7.4.2) that matches at least one of the TLSA records. The server MAY rely on SNI to determine which certificate chain to present to the client. Clients that don't send SNI information may not see the expected certificate chain.


If the server's TLSA records match the server's default certificate chain, the server need not support SNI. In either case, the server need not include the SNI extension in its TLS HELLO, as simply returning a matching certificate chain is sufficient. Servers MUST NOT enforce the use of SNI by clients, as the client may be using unauthenticated opportunistic TLS and may not expect any particular certificate from the server. If the client sends no SNI extension or sends an SNI extension for an unsupported domain, the server MUST simply send some fallback certificate chain of its choice. The reason for not enforcing strict matching of the requested SNI hostname is that DANE TLS clients are typically willing to accept multiple server names but can only send one name in the SNI extension. The server's fallback certificate may match a different name acceptable to the client, e.g., the original next-hop domain.

如果服务器的TLSA记录与服务器的默认证书链匹配,则服务器不需要支持SNI。无论哪种情况,服务器都不需要在其TLS HELLO中包含SNI扩展,因为只需返回匹配的证书链就足够了。服务器不得强制客户端使用SNI,因为客户端可能正在使用未经验证的机会主义TL,并且可能不希望服务器提供任何特定证书。如果客户端不发送SNI扩展或为不受支持的域发送SNI扩展,则服务器必须只发送其选择的一些回退证书链。不强制严格匹配请求的SNI主机名的原因是,DANE TLS客户端通常愿意接受多个服务器名称,但只能在SNI扩展中发送一个名称。服务器的回退证书可能与客户端可接受的不同名称相匹配,例如,原始下一跳域。

8.2. Anonymous TLS Cipher Suites
8.2. 匿名TLS密码套件

Since many SMTP servers either do not support or do not enable any anonymous TLS cipher suites, SMTP client TLS HELLO messages SHOULD offer to negotiate a typical set of non-anonymous cipher suites required for interoperability with such servers. An SMTP client employing pre-DANE opportunistic TLS MAY also include one or more anonymous TLS cipher suites in its TLS HELLO. SMTP servers that need to interoperate with opportunistic TLS clients SHOULD be prepared to interoperate with such clients by either always selecting a mutually supported non-anonymous cipher suite or correctly handling client connections that negotiate anonymous cipher suites.

由于许多SMTP服务器不支持或不启用任何匿名TLS密码套件,SMTP客户端TLS HELLO messages应提供协商与此类服务器互操作性所需的一组典型非匿名密码套件。采用前丹麦投机性TLS的SMTP客户端也可能在其TLS HELLO中包含一个或多个匿名TLS密码套件。需要与投机取巧的TLS客户端进行互操作的SMTP服务器应准备好与此类客户端进行互操作,方法是始终选择相互支持的非匿名密码套件或正确处理协商匿名密码套件的客户端连接。

Note that while SMTP server operators are under no obligation to enable anonymous cipher suites, no security is gained by sending certificates to clients that will ignore them. Indeed, support for anonymous cipher suites in the server makes audit trails more informative. Log entries that record connections that employed an anonymous cipher suite record the fact that the clients did not care to authenticate the server.


9. Operational Considerations
9. 业务考虑
9.1. Client Operational Considerations
9.1. 客户操作注意事项

An operational error on the sending or receiving side that cannot be corrected in a timely manner may, at times, lead to consistent failure to deliver time-sensitive email. The sending MTA administrator may have to choose between allowing email to queue until the error is resolved and disabling opportunistic or mandatory DANE TLS (Section 6) for one or more destinations. The choice to disable DANE TLS security should not be made lightly. Every reasonable effort should be made to determine that problems with mail delivery are the result of an operational error and not an attack. A fallback strategy may be to configure explicit out-of-band TLS security settings if supported by the sending MTA.

发送或接收端的操作错误无法及时纠正,有时可能导致发送时间敏感电子邮件的持续失败。发送MTA的管理员可能必须在允许电子邮件排队直到错误得到解决和禁用一个或多个目的地的机会性或强制性DANE TLS(第6节)之间做出选择。不应轻易选择禁用DANE TLS安全性。应尽一切合理努力确定邮件传递问题是操作错误而不是攻击造成的。如果发送MTA支持,回退策略可能是配置显式带外TLS安全设置。

SMTP clients may deploy opportunistic DANE TLS incrementally by enabling it only for selected sites or may occasionally need to disable opportunistic DANE TLS for peers that fail to interoperate due to misconfiguration or software defects on either end. Some implementations MAY support DANE TLS in an "audit only" mode in which failure to achieve the requisite security level is logged as a warning and delivery proceeds at a reduced security level. Unless local policy specifies "audit only" or specifies that opportunistic DANE TLS is not to be used for a particular destination, an SMTP

SMTP客户端可以通过仅为选定站点启用Opportunity DANE TLS来增量部署Opportunity DANE TLS,或者可能偶尔需要为由于配置错误或两端软件缺陷而无法互操作的对等方禁用Opportunity DANE TLS。一些实现可能以“仅审核”模式支持DANE TLS,在这种模式下,未达到必要的安全级别将被记录为警告,并以降低的安全级别进行交付。除非本地策略指定“仅审核”或指定投机性DANE TLS不用于特定目标,否则SMTP

client MUST NOT deliver mail via a server whose certificate chain fails to match at least one TLSA record when usable TLSA records are found for that server.


9.2. Publisher Operational Considerations
9.2. 发布者操作注意事项

Some MTAs enable STARTTLS selectively. For example, they might only support STARTTLS with clients that have previously demonstrated "proper MTA behavior", e.g., by retrying the delivery of deferred messages (greylisting). If such an MTA publishes DANE TLSA records, sending MTAs that implement this specification will not attempt the initial cleartext SMTP transaction needed to establish the "proper MTA behavior", because they cannot establish the required channel security. Server operators MUST NOT implement selective STARTTLS if they also want to support DANE TLSA.

有些MTA选择性地启用STARTTLS。例如,他们可能只支持StartTL,其客户端以前已经证明“正确的MTA行为”,例如,通过重试延迟消息的传递(greylisting)。如果此类MTA发布DANE TLSA记录,则发送实现此规范的MTA将不会尝试建立“正确MTA行为”所需的初始明文SMTP事务,因为它们无法建立所需的通道安全性。如果服务器运营商也想支持DANE TLSA,则不得实施选择性STARTTLS。

TLSA Publishers MUST follow the guidelines in Section 8 of [RFC7671].


TLSA Publishers SHOULD follow the TLSA publication size guidance found in Section 10.1 of [RFC7671].


TLSA Publishers SHOULD follow the TLSA record TTL and signature lifetime recommendations found in Section 13 of [RFC7671].


10. Security Considerations
10. 安全考虑

This protocol leverages DANE TLSA records to implement MITM-resistant Opportunistic Security [RFC7435] for SMTP. For destination domains that sign their MX records and publish signed TLSA records for their MX hostnames, this protocol allows sending MTAs to securely discover both the availability of TLS and how to authenticate the destination.

该协议利用DANE TLSA记录为SMTP实现抗MITM的机会主义安全[RFC7435]。对于签署其MX记录并发布其MX主机名的已签署TLSA记录的目标域,此协议允许发送MTA以安全地发现TLS的可用性以及如何验证目标。

This protocol does not aim to secure all SMTP traffic, as that is not practical until DNSSEC and DANE adoption are universal. The incremental deployment provided by following this specification is a best possible path for securing SMTP. This protocol coexists and interoperates with the existing insecure Internet email backbone.


The protocol does not preclude existing non-opportunistic SMTP TLS security arrangements, which can continue to be used as before via manual configuration with negotiated out-of-band key and TLS configuration exchanges.

该协议不排除现有的非机会主义SMTP TLS安全安排,该安排可以通过协商带外密钥和TLS配置交换的手动配置继续使用。

Opportunistic SMTP TLS depends critically on DNSSEC for downgrade resistance and secure resolution of the destination name. If DNSSEC is compromised, it is not possible to fall back on the public CA PKI to prevent MITM attacks. A successful breach of DNSSEC enables the attacker to publish TLSA usage 3 certificate associations and thereby

机会主义SMTP TLS在抗降级和安全解析目标名称方面严重依赖DNSSEC。如果DNSSEC遭到破坏,则不可能依靠公共CA PKI来防止MITM攻击。成功违反DNSSEC使攻击者能够发布TLSA用法3证书关联,从而

bypass any security benefit the legitimate domain owner might hope to gain by publishing usage 0 or usage 1 TLSA RRs. Given the lack of public CA PKI support in existing MTA deployments, avoiding certificate usages 0 and 1 simplifies implementation and deployment with no adverse security consequences.

绕过合法域所有者可能希望通过发布使用0或使用1 TLSA RRs获得的任何安全好处。鉴于现有MTA部署中缺少公共CA PKI支持,避免证书使用0和1简化了实施和部署,而不会产生不利的安全后果。

Implementations must strictly follow Sections 2.1.2, 2.1.3, 2.2, 2.2.1, 2.2.2, 2.2.3, 3.2, and 9.1 of this specification; these sections indicate when it is appropriate to initiate a non-authenticated connection or cleartext connection to an SMTP server. Specifically, in order to prevent downgrade attacks on this protocol, implementations must not initiate a connection when this specification indicates that a particular SMTP server must be considered unreachable.


11. References
11. 工具书类
11.1. Normative References
11.1. 规范性引用文件

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <>.

[RFC1034]Mockapetris,P.,“域名-概念和设施”,STD 13,RFC 1034,DOI 10.17487/RFC1034,1987年11月<>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<>.

[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, <>.

[RFC3207]Hoffman,P.,“传输层安全SMTP的SMTP服务扩展”,RFC 3207,DOI 10.17487/RFC3207,2002年2月<>.

[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, <>.

[RFC4033]Arends,R.,Austein,R.,Larson,M.,Massey,D.,和S.Rose,“DNS安全介绍和要求”,RFC 4033,DOI 10.17487/RFC4033,2005年3月<>.

[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, <>.

[RFC4034]Arends,R.,Austein,R.,Larson,M.,Massey,D.,和S.Rose,“DNS安全扩展的资源记录”,RFC 4034,DOI 10.17487/RFC4034,2005年3月<>.

[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, <>.

[RFC4035]Arends,R.,Austein,R.,Larson,M.,Massey,D.,和S.Rose,“DNS安全扩展的协议修改”,RFC 4035,DOI 10.17487/RFC4035,2005年3月<>.

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <>.

[RFC5246]Dierks,T.和E.Rescorla,“传输层安全(TLS)协议版本1.2”,RFC 5246,DOI 10.17487/RFC5246,2008年8月<>.

[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, <>.

[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月<>.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, <>.

[RFC5321]Klensin,J.,“简单邮件传输协议”,RFC 5321DOI 10.17487/RFC5321,2008年10月<>.

[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, DOI 10.17487/RFC5598, July 2009, <>.

[RFC5598]Crocker,D.,“互联网邮件体系结构”,RFC 5598,DOI 10.17487/RFC5598,2009年7月<>.

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <>.

[RFC6066]Eastlake 3rd,D.,“传输层安全(TLS)扩展:扩展定义”,RFC 6066,DOI 10.17487/RFC6066,2011年1月<>.

[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, <>.

[RFC6125]Saint Andre,P.和J.Hodges,“在传输层安全(TLS)环境下使用X.509(PKIX)证书在互联网公钥基础设施内表示和验证基于域的应用程序服务身份”,RFC 6125,DOI 10.17487/RFC6125,2011年3月<>.

[RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, <>.

[RFC6186]Daboo,C.“使用SRV记录查找电子邮件提交/访问服务”,RFC 6186,DOI 10.17487/RFC6186,2011年3月<>.

[RFC6672] Rose, S. and W. Wijngaards, "DNAME Redirection in the DNS", RFC 6672, DOI 10.17487/RFC6672, June 2012, <>.

[RFC6672]Rose,S.和W.Wijngaards,“DNS中的DNAME重定向”,RFC 6672,DOI 10.17487/RFC6672,2012年6月<>.

[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, <>.

[RFC6698]Hoffman,P.和J.Schlyter,“基于DNS的命名实体认证(DANE)传输层安全(TLS)协议:TLSA”,RFC 6698,DOI 10.17487/RFC6698,2012年8月<>.

[RFC7218] Gudmundsson, O., "Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)", RFC 7218, DOI 10.17487/RFC7218, April 2014, <>.

[RFC7218]Gudmundsson,O.,“添加首字母缩略词以简化有关基于DNS的命名实体身份验证(DANE)的对话”,RFC 7218,DOI 10.17487/RFC7218,2014年4月<>.

[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <>.

[RFC7671]Dukhovni,V.和W.Hardaker,“基于DNS的命名实体认证(DANE)协议:更新和操作指南”,RFC 7671,DOI 10.17487/RFC7671,2015年10月<>.

11.2. Informative References
11.2. 资料性引用

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <>.

[RFC1035]Mockapetris,P.,“域名-实现和规范”,STD 13,RFC 1035,DOI 10.17487/RFC1035,1987年11月<>.

[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, DOI 10.17487/RFC2136, April 1997, <>.

[RFC2136]Vixie,P.,Ed.,Thomson,S.,Rekhter,Y.,和J.Bound,“域名系统中的动态更新(DNS更新)”,RFC 2136,DOI 10.17487/RFC2136,1997年4月<>.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <>.

[RFC2181]Elz,R.和R.Bush,“DNS规范的澄清”,RFC 2181,DOI 10.17487/RFC2181,1997年7月<>.

[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, <>.

[RFC4949]Shirey,R.,“互联网安全词汇表,第2版”,FYI 36,RFC 4949,DOI 10.17487/RFC4949,2007年8月<>.

[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, <>.

[RFC6409]Gellens,R.和J.Klensin,“邮件的邮件提交”,STD 72,RFC 6409,DOI 10.17487/RFC6409,2011年11月<>.

[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <>.

[RFC7435]Dukhovni,V.,“机会主义安全:大部分时间的一些保护”,RFC 7435,DOI 10.17487/RFC7435,2014年12月<>.

[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, <>.

[RFC7673]Finch,T.,Miller,M.,和P.Saint Andre,“使用基于DNS的认证命名实体(丹麦)TLSA记录和SRV记录”,RFC 7673,DOI 10.17487/RFC7673,2015年10月<>.



The authors would like to extend great thanks to Tony Finch, who started the original version of a DANE SMTP document. His work is greatly appreciated and has been incorporated into this document. The authors would like to additionally thank Phil Pennock for his comments and advice on this document.

作者非常感谢Tony Finch,他创建了丹麦SMTP文档的原始版本。他的工作深受赞赏,并已纳入本文件。作者还要感谢Phil Pennock对本文件的评论和建议。

Acknowledgements from Viktor: Thanks to Paul Hoffman, who motivated me to begin work on this memo and provided feedback on early draft versions of this document. Thanks to Patrick Koetter, Perry Metzger, and Nico Williams for valuable review comments. Thanks also to Wietse Venema, who created Postfix, and whose advice and feedback were essential to the development of the Postfix DANE implementation.

维克多致谢:感谢保罗·霍夫曼,他激励我开始编写这份备忘录,并就这份文件的早期草稿提供了反馈。感谢Patrick Koetter、Perry Metzger和Nico Williams的宝贵评论。还要感谢创建Postfix的Wietse Venema,他的建议和反馈对于Postfix DANE实现的开发至关重要。

Authors' Addresses


Viktor Dukhovni Two Sigma



Wes Hardaker Parsons P.O. Box 382 Davis, CA 95617 United States