Introduction to DANE and TLSA
Public Key Infrastructure relies on Certificate Authorities to vouch for the legitimacy of a TLS certificate. The problem is that any of the hundreds of CAs trusted by browsers can issue a certificate for any domain, regardless of whether that domain has any relationship with that CA. If even one of those CAs is compromised, misconfigured, or coerced, an attacker can obtain a fraudulent certificate for your domain that browsers will trust without question. This is the structural weakness at the center of the CA trust model, and it is not hypothetical. Mis-issuance incidents have happened before, and they will happen again.
DANE, which stands for DNS-Based Authentication of Named Entities, is a security protocol that helps fix that weakness. Defined in RFC 6698, DANE lets domain owners publish their TLS certificate information directly in the DNS, protected by DNSSEC signatures. In simple terms, instead of trusting any one of hundreds of Certificate Authorities to confirm a certificate is legitimate, DANE allows a domain owner to say: here is the exact certificate or key you should see from my server. Any other certificate should be rejected.
The way DANE shares this information is through a TLSA DNS record. A TLSA record lives in the DNS zone of a domain and tells connecting clients which TLS certificate or public key they should accept. Together, DANE and TLSA give domain owners much stronger control over certificate validation.
Why Traditional PKI Alone Is Not Enough
To understand why DANE matters, you first need to see where PKI falls short. The CA model is built on one idea: browsers and operating systems include a list of trusted root CAs, and any certificate signed by one of those CAs is treated as valid. That sounds fine, until you realize there are more than 100 trusted root CAs around the world.
Here is the problem: any one of those CAs can issue a certificate for any domain. If a CA gets compromised or pressured by a government or bad actor, it can create a fraudulent certificate for your domain. Most clients will trust it without question. This is not just a theory. In 2011, a CA called DigiNotar was breached, and fake certificates were issued for major domains including Google. The incident made it clear just how fragile the CA model can be.
Tools like Certificate Transparency (CT) logs and CAA records have made things better. But they mostly tell you after a bad certificate has already been issued. DANE is different. It is a preventive measure. It locks down which certificates are acceptable at the DNS level, before any TLS handshake can be manipulated.
How DNSSEC Enables DANE
DANE does not work on its own. It depends entirely on DNSSEC, the Domain Name System Security Extensions. Without DNSSEC, putting certificate information in DNS would not help much, because DNS records can be tampered with fairly easily.
DNSSEC adds cryptographic signatures across the DNS hierarchy. Every level of the DNS tree, from the root zone to the top-level domain (TLD) to your specific domain zone, signs the records below it. When a resolver fetches a TLSA record, DNSSEC lets it check that the record is genuine and unchanged.
Think of DNS without DNSSEC like a letter with no tamper-evident seal. Anyone handling it along the way could change the contents. DNSSEC adds that seal at every step. DANE then uses that sealed, trusted channel to deliver binding instructions about which TLS certificates are acceptable.
For DANE to actually protect you, DNSSEC must be fully deployed and validated end-to-end, from the authoritative DNS zone all the way to the resolving client. DANE built on unsigned DNS provides no real security.
Understanding TLSA Records and Their Fields
A TLSA record is published at a specific DNS name that includes the protocol, port, and domain of the service. For example, the TLSA record for HTTPS on port 443 at example.com would appear at:
_443._tcp.example.com. IN TLSA <Usage> <Selector> <MatchingType> <CertificateData>Each of the four fields has a specific job:
- Certificate Usage (0 to 3): This field sets what the record is pinning. Usage 3, known as DANE-EE, is the strictest option. It pins directly to the server’s own certificate or key, skipping traditional CA validation entirely.
- Selector (0 or 1): This tells the client whether to match against the full certificate (0) or just the SubjectPublicKeyInfo, meaning the public key (1). Pinning the public key is generally preferred, since it stays valid even when the certificate is renewed as long as the key pair stays the same.
- Matching Type (0, 1, or 2): This defines how the certificate data is represented. A value of 1 means SHA-256 and a value of 2 means SHA-512. Using a hash is strongly recommended to keep DNS record sizes practical.
- Certificate Association Data: This is the actual value, either a hash or the raw certificate or key, that the client compares against the certificate the server presents during the TLS handshake.
A server using a CA-signed certificate might use Usage 1 (DANE-TA) to pin to the issuing CA’s public key. A server running a self-signed certificate would typically use Usage 3 (DANE-EE) to pin directly to its own leaf certificate.
How DANE Protects Against MITM and Downgrade Attacks
DANE is most useful when you see how it blocks two of the most dangerous attack types in network security: Man-in-the-Middle (MITM) attacks and TLS downgrade attacks.
In a MITM attack, an attacker positions themselves between a client and a server. They intercept the connection and present their own certificate to the client while passing traffic along to the real server. If the attacker manages to get a fraudulent but CA-trusted certificate for the target domain, the client has no way to spot the intrusion. DANE closes this gap. Even if the fake certificate appears valid to the browser, it will not match the TLSA record in DNS, and a DANE-aware client will refuse to complete the connection.
Downgrade attacks work differently. The attacker interferes with the TLS handshake to push both sides into using an older, weaker protocol version or cipher suite, one that is easier to crack. Some downgrade attacks go further and strip encryption entirely through SSL stripping. DANE helps counter this when combined with SMTP security tools like STARTTLS. When a mail server publishes a TLSA record for its SMTP port, a sending mail transfer agent (MTA) that validates that record knows TLS is required and knows what certificate to expect. Any attempt to downgrade or strip TLS becomes detectable.
It is worth being honest about where DANE has limits. Browser support is inconsistent. Major browsers do not natively validate TLSA records for HTTPS, so everyday web browsing does not benefit from DANE without extra plugins or custom setups. DANE works best in server-to-server settings, especially email delivery, and in environments where the full technology stack is under your control.
How Encryption Consulting Can Help
DANE adds a meaningful layer of control over TLS certificate validation, but it introduces real operational complexity alongside it. DNSSEC must be fully deployed and validated. TLSA records must be updated in sync with every certificate renewal. And the underlying PKI foundation needs to be solid before pinning anything to DNS. These are not one-time tasks. They are ongoing operational responsibilities that compound as your certificate environment grows.
Encryption Consulting’s PKI Services and CertSecure Manager address both sides of that challenge — the architecture and the ongoing management.
For organizations building or hardening their PKI foundation:
Our PKI Services help you design and implement a Certificate Authority hierarchy that is built for environments requiring strict certificate control. Whether you are moving toward DANE-EE to pin directly to server certificates or using DANE-TA to anchor trust to an internal CA, the underlying PKI architecture needs to support that commitment. We ensure it does, with FIPS 140-3 compliant HSM backing, documented Certificate Policies, and an implementation that holds up under scrutiny.
For the ongoing operational challenge of keeping TLSA records aligned:
One of the most practical risks in a DANE deployment is a TLSA record going out of sync when a certificate is renewed. If the new certificate does not match the published TLSA record, connections fail. CertSecure Manager tracks every certificate across your environment, flags certificates approaching renewal, and gives your team the advance visibility needed to update TLSA records before a mismatch causes an outage. It does not matter which CA issued the certificate or where it is deployed — it surfaces everything in one place.
For organizations running DANE for SMTP security, where server-to-server email delivery depends on TLSA records being accurate and current, that kind of proactive certificate management is not optional. It is the operational layer that makes DANE sustainable rather than fragile.
Conclusion
DANE and TLSA records offer a meaningful step forward in how organizations handle TLS certificate authentication. By anchoring certificate expectations inside DNSSEC-signed DNS records, you gain the ability to enforce strict certificate pinning without relying entirely on the global CA system. For security teams that have always felt uneasy about trusting hundreds of CAs they cannot control, DANE is a practical and technically sound alternative.
That said, DANE is not a complete fix on its own. Deploying it properly means having solid DNSSEC in place, managing records carefully especially during certificate renewals, and understanding where client support exists and where it does not. For organizations handling sensitive communications, particularly email or server-to-server traffic, DANE is worth serious consideration as part of a layered security approach.
