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.