Archivedns
DNSSEC and DANE: Trust Anchors Without a CA
DNSSEC authenticates DNS answers; DANE can bind certificates to them. Both are powerful and operationally demanding.
- Published
- Reading time
- 1 min read
DNSSEC signs DNS records so a resolver can verify that an answer came from the zone and was not modified. DANE (TLSA records) then associates a TLS certificate or key with that name, removing the need for a public CA in some setups.
The chain
Root KSK → TLD DS → zone DNSKEY → signed records. A broken link makes the entire subtree unresolvable for validating resolvers — that is the operational risk.
DANE in practice
_443._tcp.example.com. TLSA 3 1 1 <sha256-of-spki>
3 1 1 means DANE-EE, SPKI, SHA-256. Clients that support DANE ignore the CA and match the pin. Mail (SMTP) is the most successful deployment.
Why adoption is slow
- Validating resolvers must be universal, and misconfiguration causes hard failures.
- Applications need DANE-aware TLS stacks.
- Key rollover requires coordinated DS updates.
Takeaway: DNSSEC turns DNS into a signed database; DANE lets you pin TLS to it. Only deploy with automated signing and rollover, or expect outages.