I’m trying to understand DANE and TLSA records more accurately. Is it fair to call DANE the DNS-variant of (or at least a very similar technique to) HTTP Public Key Pinning (HPKP)?

Because with HPKP a SSL certificate can be pinned using a HTTP header and using DANE a certificate can be kind of “pinned” on the DNS-level, right?

2 Answers 2


While both DANE/TLSA and HPKP are somehow related to validation of the server using public keys or certificates, they address different aspects of the validation. This means DANE can not not considered the DNS equivalent of HPKP.

  • HPKP cares about future connections to the site.
    It specifies which keys will be expected in the future and thus makes it possible for the client to do pinning and protect against future man in the middle attacks which use certificates issued by a trusted but compromised CA (like in case of DigiNotar). It thus adds additional protection to the current PKI (with a trust store in each client) and does not work without it.
  • DANE/TLSA cares about the current connection.
    It specifies which keys/certificates should be used for the current connection. It can thus work as a replacement to the current PKI. Essentially it moves the trust from the current PKI to trust into DNSSec (which is essentially a different PKI).

From the perspective of the owner of the site HPKP allows to only add additional restrictions in order to harden the current PKI system. The owner still needs to get a certificate from a trusted CA. DANE/TLSA instead allows the owner to fully control the validation process (instead of only a small aspect of it) as long as the client trusts the PKI behind DNSSec and the domain is protected by DNSSec.

  • If a browser attempts to connect to www,example.com, and the DNS query shows that www.example.com has a DANE record containing a TLSA record - then wouldn't (or shouldn't) the browser then realize that the host supports https, and upgrade the connection to https accordingly?
    – mti2935
    Commented Dec 29, 2019 at 13:13
  • 2
    @mti2935: DNS does not provide all information about a domain. This means that the browser would need to do an explicit DNS lookup to get the DANE information and why should the browser do this if the URL is http:// and not https://. Apart from that currently browsers do not support DANE anyway but they support HSTS. Commented Dec 29, 2019 at 14:13
  • Steffen Ulrich, Thanks for your reply. Your points are well taken. But, I see no reason why DANE could not be used to prevent HTTPS stripping attacks (akin to what HPKP aims to prevent) - if the browser were to do an explicit DNS lookup to get the DANE info on http requests and upgrading the connection to https if DANE info is found, and browsers started supporting DANE, and sites started publishing DANE info - all as you point out. This would have the added benefit over HPKP of not being TOFU. In any case, thanks for your informative answers/comments, as always.
    – mti2935
    Commented Dec 29, 2019 at 14:26
  • 1
    @mti2935: Yes, DANE could be used in theory that way. But this is not part of the DANE specification. Commented Dec 29, 2019 at 17:13

To quote the RFC:


Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software.

Section 1.1

...DNS-Based Authentication of Named Entities (DANE) offers the option to use the DNSSEC infrastructure to store and sign keys and certificates that are used by TLS. DANE is envisioned as a preferable basis for binding public keys to DNS names, because the entities that vouch for the binding of public key data to DNS names are the same entities responsible for managing the DNS names in question. While the resulting system still has residual security vulnerabilities, it restricts the scope of assertions that can be made by any entity, consistent with the naming scope imposed by the DNS hierarchy. As a result, DANE embodies the security "principle of least privilege" that is lacking in the current public CA model...

DANE and TLSA give a way to trust a certificate for a domain without having it signed by a CA, this is different from HPKP because HPKP still requires a CA to sign the certificate, it just limits which signed certificates are trusted.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .