DANE (DNS-Based Authentication of Named Entities)

DANE is defined in RFC 6698, and its use for mail transfer is specified in RFC 7672. A domain owner publishes TLSA records stating which certificate or key a service on a given port must present. Because those records are signed with DNSSEC, a client that validates DNSSEC can trust them without relying solely on the public CA system. Depending on the record's usage field, DANE either adds constraints to normal CA validation or replaces it, for example to authenticate a certificate from a private CA.

Why it matters

Its main real-world deployment is SMTP between mail servers. Without DANE, a sending server that sees STARTTLS usually encrypts without verifying the certificate, and an attacker can strip TLS entirely. With DANE, a validating sender knows that TLS is mandatory for that destination and which key to expect, so downgrade and interception fail. Postfix and other common mail transfer agents support it. Browsers, by contrast, do not use DANE for HTTPS. The price is operational: DNSSEC must work at every level of the domain, and TLSA records must be updated before keys change, or mail delivery to the domain stops.

Example

dig +dnssec TLSA _25._tcp.mail.example.com
# _25._tcp.mail.example.com. 3600 IN TLSA 3 1 1 <SHA-256 of the server public key>
# ... plus an RRSIG record, and the "ad" flag if your resolver validated it

Common misconceptions

• DANE works without DNSSEC. DANE clients ignore unsigned TLSA records, since anyone able to spoof DNS could forge them.
• Browsers check DANE. No mainstream browser validates TLSA records for HTTPS; DANE matters mostly for mail.
• DANE means CA-issued certificates are no longer needed. Only the DANE-TA and DANE-EE usages bypass CA validation, and many operators keep publicly trusted certificates so that clients without DANE support still work.