DANE

Definition: What is DANE?

DANE (DNS-Based Authentication of Named Entities) is a security protocol that uses the DNS system to secure online communications. It guarantees the authenticity and integrity of secure connections such as SSL/TLS connections. DANE is a standardised protocol designed to validate the certificate used in a TLS-secured connection. The machine initiating a connection will be able to retrieve the fingerprint of its correspondent’s certificate via a DNS record in order to confirm its integrity.

Why secure your SMTP servers with DANE?

Securing SMTP servers with DANE ensures that communications between mail servers are authentic and confidential. This prevents attacks such as message interception and falsification of server identities.

How is the DANE protocol used?

The DANE protocol uses specific DNS records to store information about the public keys of mail servers. Mail servers can use these records to verify that the public key presented by the remote mail server is authentic and has not been tampered with. To use the DANE protocol, you need a DANE-compatible DNS provider and a mail client that supports this protocol.

Setting up DANE means generating and maintaining an up-to-date certificate key fingerprint. It must be accessible via a TLSA record associated with the host name of the machine concerned. The DNS server managing this record must use DNSSEC to ensure the validity of the transaction and data. DANE is compatible with all communications using TLS, but is mainly used to secure exchanges between SMTP servers.

Examples

Here’s a concrete example of how DANE works when sending an e-mail from “from@exp.fr” to “to@dest.fr”:

– The exp.fr server sends a DNS request to find out the MX of dest.fr:
# dig MX dest.fr
dest.fr. 3600 IN MX 10 mail.dest.fr

– The sending server checks whether the destination server has a TLSA entry. To do this, it generates a request containing the port number (25), the protocol (TCP) and the host name:
# dig TLSA _25._tcp.mail.dest.fr
_25._tcp.mail.dest.fr. IN TLSA 3 1 1 42DDBACBE48CBB37…3D D53D2CB4

– It connects to the mail.dest.fr mail server, which transmits its public key (present in the certificate) during the TLS handshake. The sending server is then able to compare the fingerprint with the public key to verify its integrity. However, if the TLSA record is not signed by DNSSEC, or if an element is missing or incorrectly entered, the connection switches to conventional TLS.

Alternative to DANE: MTA-STS

MTA-STS (Mail Transfer Agent – Strict Transport Security) is a mechanism, initiated and promoted by Google, which enables policy, accessible via HTTPS, to inform sending servers if a destination server imposes TLS encryption. It uses a accessible via a Web server that indicates the servers of recipient’s mailbox. This document includes an identifier that must be updated in the event of policy changes. Unlike DANE, MTA-STS acts at the domain level rather than the server level, it is purely for messaging.

MTA-STS is considered less relevant than DANE, for two main reasons:

– The domain must integrate a Web server, which must be maintenance and safety.

– Certificate validation relies on known to the issuer, where DANE validates the certificate through its consistent with the footprint, taking into account, in particular, certificates self-signed or from certification authorities unknown to the issuer.

Fortunately, the two techniques do not interfere with each other. and are fully compatible. The ideal solution is to exploit both so that sending servers can choose which protocol to use to use.