What Is DANE? DNS-Based Authentication of Named Entities Explained
How a DNS record can let a domain assert its own certificate trust, independent of the public CA system — and why almost none of it works without DNSSEC.
Every certificate your browser trusts today ultimately traces back to one of a few hundred Certificate Authorities baked into your operating system or browser's root store. That model works, but it has a structural property worth naming plainly: trust is placed in "a CA," generically, rather than in a specific CA a domain owner actually chose. DANE (DNS-Based Authentication of Named Entities) offers a different foundation — publish the actual certificate or key trust data in DNS itself, secured by DNSSEC rather than by a third party's say-so.
🕑 Where DANE Came From
DANE emerged from a specific, well-documented weakness: the CA ecosystem's trust is flat. Any of several hundred publicly trusted CAs can, in principle, issue a valid certificate for any domain — a property that's been exploited in real, documented CA-compromise incidents over the years. The IETF's DANE working group defined RFC 6698 in 2012 as a mechanism that lets the domain owner assert trust directly, using the one channel every internet service already depends on: DNS, secured this time by DNSSEC rather than left unsigned.
🔑 TLSA: The Record Behind DANE
DANE isn't itself a DNS record type — it's the overall mechanism. The record type that implements it is TLSA, published at a service-specific name like _443._tcp.example.com or _25._tcp.mail.example.com, encoding four fields: certificate usage, selector, matching type, and the certificate association data. For the full field-by-field syntax and a live query tool, see our TLSA Lookup tool.
🔑 The Four Certificate Usage Modes
| Mode | Name | CA Still Required? |
|---|---|---|
| 0 | PKIX-TA | Yes — pins a CA in the chain |
| 1 | PKIX-EE | Yes — pins the exact certificate, still CA-validated |
| 2 | DANE-TA | No — pins a private/custom trust anchor |
| 3 | DANE-EE | No — pins the certificate directly, DNSSEC is the sole trust anchor |
This is the part people find counterintuitive at first: DANE isn't strictly "CA vs. no CA." Modes 0 and 1 add DNS-published pinning as an extra layer on top of the existing CA model, catching a mis-issued or substituted certificate that a CA would otherwise have validated normally. Modes 2 and 3 go further, letting the DNS record itself be the entire trust decision.
🔒 Why DANE Is Only as Strong as DNSSEC
This is the single most important thing to understand about DANE: a TLSA record on an unsigned zone provides no real protection. A network-position attacker who can already manipulate unsigned DNS responses can simply strip the TLSA record or substitute their own, and a relying party has no way to detect the tampering. DNSSEC is what turns "a DNS record claims X" into "a DNS record cryptographically proven to say X, signed by the zone's actual owner." Skipping DNSSEC and publishing TLSA anyway is a common early mistake — see our DNSSEC Checker to confirm a zone is properly signed before relying on any TLSA data operationally.
✅ Where DANE Is Actually Deployed
DANE's clearest, most widely enforced real-world use is SMTP mail delivery, formalized in RFC 7672. A sending mail server that supports DANE checks the receiving server's TLSA record before delivering mail and, when present, refuses to accept a connection that doesn't match — directly closing a gap where SMTP's opportunistic STARTTLS can otherwise be silently downgraded to plaintext by an attacker without either party necessarily noticing. See our companion guide, DANE for SMTP: Implementation Guide, for the practical setup steps.
❌ Where DANE Isn't Enforced
Despite RFC 6698 covering the web in principle, no major browser — Chrome, Firefox, Safari, or Edge — validates DANE/TLSA records during ordinary HTTPS browsing. A handful of historical browser extensions and non-browser clients have supported it, but it will not protect a typical website visitor the way it protects DANE-aware mail delivery. Server operators can still publish TLSA records for HTTPS services for defense-in-depth against non-browser clients, but shouldn't expect it to be enforced automatically for web visitors.
⚖️ DANE vs the Public CA Model
| Aspect | Public CA Model | DANE (usage 2–3) |
|---|---|---|
| Trust anchor | A curated set of ~a few hundred CAs | DNSSEC-signed DNS, controlled by the domain owner |
| Prerequisite | None beyond a CA relationship | DNSSEC must be correctly deployed and signed |
| Browser HTTPS support | Universal | None |
| SMTP support | Universal (opportunistic TLS) | Growing among DANE-aware mail platforms |
📊 Adoption in Practice
DANE adoption is uneven and concentrated. It's meaningfully more common among mail providers, DNSSEC-heavy country-code registries, and organizations with existing DNSSEC infrastructure already in place; it remains rare among typical small websites, largely because there's no browser enforcement rewarding the effort of deploying it for HTTPS specifically. The practical center of gravity for DANE today is mail delivery, not the web.
🚀 Getting Started
If you're considering DANE, start with DNSSEC — nothing else matters until the zone is correctly signed and validating. From there, SMTP is the highest-value place to deploy TLSA records, since DANE-aware mail servers will actually check and enforce them today. Our DANE for SMTP guide walks through the specific steps, and TLSA Lookup lets you verify any domain's current records, including your own after publishing.