3 ms·

CAA is not the record for this. As @schoen already replied, it is only used by CA's to check if they are allowed to issue a certificate to a domain. But with D

CAA is not the record for this. As @schoen already replied, it is only used by CA's to check if they are allowed to issue a certificate to a domain. But with DANE TLSA Resource Records you can pin a public key to a website. Alas the implementation of TLSA-RR checking in browsers is dependent on extensions at this time. I wish it was native in browsers with a big red sign when violated. When done in combination with DNSSEC it's very hard to fake certificates. Or more precisely asymmetric cryptography key pairs used by servers. Certificates for TLS would not be needed anymore if TLSA-RR's were standard practice. A company might still use a certificate to attest it's identity beyond internet domain ownership. Edit: This is for TLSA 3 1 1 and 3 1 2 records. That's what I have experience with. Just read on Wikipedia a lot more is possible with TLSA-RR's including certificate and CA pinning. https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#TLSA_RR https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...

tptacek 6y ago
It's unlikely ever to be native in browsers. Native DANE code was proposed in Firefox and actually landed in Chrome, which later removed it, because it (a) didn't work reliably on the actual Internet, and (b) in fallback mode, amounts to adding just one more CA to the pile of CAs Chrome already has to trust. When a CA can be shown to have misissued a certificate, Google can (and has, as it did in the Symantec case) distrust it, nuking the CA from orbit. It has no such powers with a CA baked into the DNS; Google can't distrust .COM. People should be careful what they wish for. But not too careful in this case; DNSSEC is moribund, and unlikely to be revived.