From Halon, SMTP software for hosting providers
Jump to: navigation, search

DANE is a proposed standard that has the potential to make widespread email encryption a reality (today, most emails are transmitted unencrypted). It does not only provide a trust scheme (like the certificate authority system) using DNSSEC, but also the means to know if a domain supports encrypted email transfer. The Halon SMTP software supports DANE since 3.4-rocky-r2[1].

How DANE works

DANE is only available over DNSSEC, and uses the TLSA record type. An email server (MTA) only needs to make one extra DNS query to use DANE, namely

$ host -tmx freebsd.org
freebsd.org mail is handled by 10 mx1.freebsd.org.
$ host -ttlsa _25._tcp.mx1.freebsd.org
_25._tcp.mx1.freebsd.org has TLSA record 3 0 1 2B73BB905F1...

and the server's certificate is compared against the DNS record. The output (logs) from a Halon system with and without DANE look like

smtp_lookup_rcpt(["host" => "lookup-mx""tls"=>"dane"], """test@freebsd.org"); // DANE
smtp_lookup_rcpt(["host" => "lookup-mx""tls"=>"dane"], """test@gmail.com");   // Insecure 
freebsd.org gmail.com
Connecting to [2001:1900:2254:206a::19:1]:25 (DNSSEC)
X.509: /OU=Domain Control Validated/OU=Gandi Standard...
DANE: validated successfully
Connection is now using TLS
Connecting to [2a00:1450:4010:c06::1b]:25
DANE: insecure name gmail.com (falling back to optional TLS)
X.509: /C=US/ST=California/L=Mountain View/O=Google Inc...
X.509 error: unable to get local issuer certificate (20)
Connection is now using TLS

How to use DANE

It's fairly simple to start using DANE, and we encourage you to at least start sending email with (verifying) DANE right away.


To enable DANE verification in the Halon SMTP server, simply change the TLS mode to dane. It can be changed for the outbound (typically lookup-mx) transport profile, or using the SetTLS() function. We recommend that you enable the built-in DNS cache (with DNSSEC enabled) instead of relying on an external DNS server's AD-bit.


In order to allow others to send DANE verified email to your server, you domain needs to be DNSSEC signed. In theory, it's no more difficult than publishing your SMTP servers' certificate signatures as TLSA records in your DNS using the same name as the MX points at, but prefixed with _25._tcp. As usual, everything's a bit more complicated[2] in practice. The full certificate fingerprint (used with 3 0 1) can be extracted with

openssl x509 -noout -fingerprint -sha256 < path-to-cert | tr -d : 

or you can simply use Huque's TLSA generator. The result should look like:

         mx1.freebsd.org.  IN  A
_25._tcp.mx1.freebsd.org.  IN  TLSA  3 0 1 2B73BB905F...


Halon's DANE implementation is based on the NLnet Labs ldns library's DANE functions (which are included in FreeBSD). We couldn't use Postfix's implementation, because the Halon SMTP server only uses Postfix to accept connections (ensuring good SMTP conformity). Outbound SMTP connections are handled by the libh_smtp++ library, which is used by both HSL core functions such as smtp_lookup_rcpt() as well as the mailqueued process and its corresponding pre-delivery context.


DANE is proposed in RFC 6698 by Hoffman and Schlyter as an alternative to CAs[3]. The CA system has been subject to criticism[4][5] during the last years, following compromise and mishaps of several major CAs[6][7][8][9]. To make things worse, the revocation systems doesn't work very well in practice[10][11][12]. DANE builds on DNSSEC which provides a hierarchal scheme (the root, TLDs, domains and so on), as opposed to the flat CA system where any trusted CA can issue a certificate in the name of anyone.

As always, there are arguments for and against[13]. While a hierarchal system sure is preferable, the transfer of control and responsibility to the DNS system's owners (governments, DNS admins) is a topic much discussion[14]. There's also work to improve the CA system with supplementary techniques such as key pinning[15][16] and added perspective[17]. Nevertheless, DANE stands strong to improve the security in many areas, such as email.

Postfix was probably the first[18] email server to support RFC 7672 (DANE for SMTP), and Exim support is underway. The fact that those two are the most widely used[19] SMTP servers, and the somewhat strong[20][21] DNSSEC adoption, is a solid foundation for DANE.


  1. http://my.halon.se/support/softwareupdates/mailsecurity
  2. https://dane.sys4.de/common_mistakes
  3. http://ccnso.icann.org/node/38145
  4. https://www.schneier.com/blog/archives/2011/10/the_security_of_4.html
  5. https://en.wikipedia.org/wiki/Certificate_authority#CA_compromise
  6. http://arstechnica.com/security/2011/03/independent-iranian-hacker-claims-responsibility-for-comodo-hack/
  7. http://www.h-online.com/security/news/item/Trustwave-issued-a-man-in-the-middle-certificate-1429982.html
  8. http://www.theregister.co.uk/2011/09/06/diginotar_audit_damning_fail/
  9. http://arstechnica.com/security/2015/09/symantec-employees-fired-for-issuing-rogue-https-certificate-for-google/
  10. https://www.imperialviolet.org/2014/04/29/revocationagain.html
  11. http://news.netcraft.com/archives/2014/04/24/certificate-revocation-why-browsers-remain-affected-by-heartbleed.html
  12. http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html
  13. https://www.imperialviolet.org/2015/01/17/notdane.html
  14. http://sockpuppet.org/blog/2015/01/15/against-dnssec/
  15. https://www.imperialviolet.org/2011/05/04/pinning.html
  16. http://tack.io
  17. http://perspectives-project.org
  18. http://www.postfix.org/TLS_README.html#client_tls_dane
  19. http://www.securityspace.com/s_survey/data/man.201511/mxsurvey.html
  20. http://stats.labs.apnic.net/dnssec
  21. http://www.internetsociety.org/deploy360/wp-content/uploads/2015/06/cctlddnssec-2015-06-19.pdf