DANE & TLSA: anchoring the certificate in DNS

When two mail servers talk to each other encrypted, the same question arises as on the web: is the presented certificate genuine? In a browser we trust a handful of certificate authorities for that. Server-to-server email often lacks that strict check — and that's exactly where DANE steps in.

The idea

DANE publishes a TLSA record in DNS: a fingerprint of the certificate (or the issuing key) the server is supposed to use. The other side looks it up before connecting: does the presented certificate match the published fingerprint? If not, the connection is aborted.

Why it needs DNSSEC

A fingerprint in DNS is only as trustworthy as DNS itself. That's why DNSSEC is the prerequisite: it guarantees the TLSA record is genuine and untampered. Without DNSSEC an attacker could simply slip in their own fingerprint — DANE would be worthless.

What it gives you

• Downgrade protection: an attacker can't quietly bend an encrypted connection to "unencrypted" or to a forged certificate.
• Independence from the CA landscape: you decide which certificate is valid.

Where DANE matters — and where not

For server-to-server email DANE is established and worthwhile. For the web (HTTPS) virtually no browser validates DANE — other mechanisms secure it there. So we check DANE strictly for the mail server but treat it as an optional bonus for the web server.