DNS-Based Authentication of Named Entities (DANE, RFC 6698) lets a domain owner publish, in DNS, which certificate or public key a service must present. The data lives in a TLSA record and is trusted only if the zone is protected by DNSSEC.
Why it matters
Normal TLS trusts any certificate authority in the client's root store, so a single compromised CA can mislead a client. DANE narrows that trust to what the domain owner has published. Its most important real-world use is SMTP: DANE for SMTP (RFC 7672) lets mail servers verify each other's certificates and prevents downgrade attacks on server-to-server mail. Web browsers do not use DANE, so it has no effect on normal HTTPS visits.
Because it depends on DNSSEC, a signing or key-rollover mistake can make records unverifiable and break mail delivery.
Example
A TLSA record for a mail server on port 25:
_25._tcp.mail.example.com. IN TLSA 3 1 1 <sha256-of-public-key>The 3 1 1 means: match the end-entity certificate (3), by its public key (1), using SHA-256 (1).
Common mistakes
- Publishing TLSA records without a valid DNSSEC chain.
- Changing the server key or certificate without updating the TLSA record first.
- Expecting browsers to honor it.
Related
Get notified when this term updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.