Notice: Undefined offset: 1 in /usr/local/src/wordpress/wp-content/themes/montezuma/includes/parse_php.php on line 79

Securing eMail With D.A.N.E.

Some day I’ll get time to do an article on setting up a complete email server with the most advanced security and spam protection, but for now we’ll focus on DNS-based Authentication of Named Entities (DANE).  Of all the methods of securing email, DANE is the most comprehensive and advanced to date.

In a nutshell, DANE is a way of to authenticate TLS client and server sessions (for both web and email) without the need of a Certificate Authority.  DANE has become more popular in recent years due to security breaches of some Certificate Authorities, which allowed encryption certificates to be issued to non-domain owners for malevolent purposes.  DANE provides an independent means of checking certs to make sure of their provenance, and therefore that the session is secure.

DANE is a protocol that links certificate verification to the domain name server.  The implementation of DANE relies on DNSSEC (which is a royal pain to set up and get right), and means that effectively DANE has the same operational model as X.509, because DNSSEC is a hierarchically rooted trust model.  It also means that the delegation record to your domain is managed by your registrar and could be compromised if your registrar is.  However, as long as you trust the DNSSEC root and your registrar, this is a second check on your certs.  In particular, any connecting email server which supports DANE will check your DNS TLSA record for a hash of your TLS cert, and compare that with a hash of the cert you’ve provided for that email domain.  If it compares, good to go.  With, or without, a Cert Authority.

The assumptions of this guide are that:

  • Your email server is Linux or Unix;
  • You have a properly functioning email system with Postfix => 2.11 and Dovecot => 2.2;
  • with operational TLS encryption (‘may’ or ‘required’);
  • Your domain registrar supports DNSSEC and TLSA;
  • And that you have control over your DNS records.

Let’s first set up DANE at our DNS registrar.  Log in to your domain’s management page;  Mine is at GKG.net | Domains | DNS (Zone) Hosting | Configure.  Select a domain and go to the TLSA tab.  Here is where we enter the details of our TLSA record, including type of DANE, selector, hash algo, and hash.  Make a new browser tab and go to Huque to gen your hash.  Set:

  • Usage Field:  3 – DANE-EE: Domain Issued Certificate
  • Selector Field:  1 – SPKI: Use subject public key
  • Matching-Type Field:  2 – SHA-512: SHA-512 hash
  • And paste all of the public cert for your mail domain into the white window.
  • The remaining values aren’t important unless you need the full DANE directive at your registrar, but you can enter Port: 25, Protocol: tcp, and Domain: mail.example.com for fun.
  • Generate

This will create a complete DANE directive record (called a ‘3-1-2 record’ in the parlance), but for GKG we only need the hash for our TLSA record.  

Back to our registrar tab.

  • Add a record;
  • Port:  587  (If you use that for sending, which you should)
  • Protocol:  tcp
  • Host:  mail  (You’re editing the domain, so it will be automatically appended)
  • Certificate Usage:  3 – DANE-EE
  • Selector:  1 – SPKI
  • Matching Type:  2 – SHA2-512
  • Cert Association:  (paste in the cert hash generated at Huque)
  • Time To Live:  1 day  (So updates propagate quickly, without too much noise)
  • Add Record.

You’ve now set an independent source for confirmation of your encryption cert for your mail domain on port 587.  Add similar records for ports 993, 25, and whatever else you use.  You can also enable DANE for HTTPS and although setting up your server is beyond this scope you can add a TLSA record with ‘@’ as domain and port 443 as port.  Make sure to change the hash of the cert for your web service if it’s different from mail. (Which it should be)

It will take up to a day for your changes to propagate throughout the DNS system.  But Postfix isn’t aware of this yet.  In /etc/postfix/main.cf you should already have your encryption certs set, for example:
smtpd_tls_cert_file = /etc/letsencrypt/live/example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/example.com/privkey.pem

So to configure opportunistic DANE, in main.cf add:
smtpd_use_tls = yes
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec

… and in /etc/postfix/master.cf add:
dane unix – – n – – smtp
-o smtp_dns_support_level=dnssec
-o smtp_tls_security_level=dane

And in the same file add below smtp:
smtp inet n – n – – smtpd
-o smtpd_enforce_tls=yes

Restart Postfix and check the log to make sure all is well.  You can now check your work at Huque Check.

An important point to understand is that DANE is a per MX-host security mechanism, and it is the main MX host (set in main.cf) that passes or fails, so it is not possible for virtual hosts to have different TLSA records for DANE.  So if you provide mail service for multiple domains on one IP address, for example mail.example.com and mail.test.com, you must make special provision.  This caveat does not apply if you have a dedicated IP for each domain.  To make DANE work in case of virtual domains, at your DNS registrar in the TLSA records of all virtual domains you must:

  • Set MX records of all served mail domains to the domain set as myhostname = in /etc/postfix/main.cf;
  • And set the TLSA hash to that of the domain set as myhostname = in /etc/postfix/main.cf, with a ‘.‘ immediately after to prevent appending anything.  For example, mail.example.com. in all virtual domains’ TLSA’s.

Now you’re rockin’ it with DANE like they do downtown!

,'after' => '

') )