DNSSEC has aged very poorly. I also believe it operates at the wrong layer. When you surf to chase.com you want to make be sure that the website you see is actually JPMorganChase and not Mallory’s fake bank site. That’s why we have HTTPS and the WebPKI. If your local DNS server is poisoned somehow that’s obviosly not good, but it cannot easily send you to a fake version of chase.com.
Part of why it’s so hard for Mallory to create a fake version of a bank site is Certificate Transparency. It makes it much much harder to issue a forged certificate that a browser such as Chrome, Safari or Firefox will accept.
There are a lot of things that are different for sure since that article's release, for example the crypto, but also the existence of DoH/DoT and that it is leaps and bounds more deployed. They also talk about key pinning, but key pinning has been dead for a while and replaced by exactly CT.
I'm also not sure how much to trust the author. The writing is very odd language wise and they seem to have quite the axe to grind even with just public CA-based PKI, let alone their combination. The FAQ they link to also makes no sense to me:
> Under DNSSEC/DANE, CA certificates still get validated. How could a SIGINT agency forge a TLS certificate solely using DNSSEC? By corrupting one of the hundreds of CAs trusted by browsers.
It's literally what I'd want TLSA enforcement for to combat.
The existence of DoH hurts DNSSEC, it doesn't help it. While privacy is the motivating use case for DoH, it's also the case that on-path attackers can't corrupt the results of a DoH query; they have to move upstream of it.
The dream of TLSA as a bulwark against suborned CAs has always been problematic, because the security of TLSA records collapses down to that of the TLD operators, the most popular of which are state actors or proxies for them, and most of the remainder are essentially e-commerce firms, not trust anchors.
But that doesn't matter, because TLSA as an alternative to the WebPKI is already dead on arrival. So many people have problematic access to DNS that no browser can ship hard-fail DANE; in the (extraordinarily unlikely) future world where mainstream browsers do DANE, everybody will have soft-fail DANE falling back to the WebPKI. So, instead of a small number of (state-run!) PKI roots, you'll have the thousands of legacy operators plus the state-run PKI roots.
This problem motivated the design of "stapling" protocols, where we'd basically throw away the DNS part of the protocol, and just keep the TLSA records, and attach them to the TLS handshake. For several years, this was the last best hope for DANE adoption (read Geoff Huston on this, he's a DANE supporter and he's great), and it all fell apart because nobody could get the security model right.
It's at this point I like to remind people that the browsers basically had to shake down the CAs to get Certificate Transparency to happen. They held almost all the cards (except for antitrust claims, which were wielded against them) --- "comply with CT, or we'll remove you from our root program". But browsers can't do that with DNS TLD operators; they hold none of the cards. So, in addition to the fact that there's no "DNS Transparency" on the horizon, there's also none of the leverage required to actually get it deployed.
DANE does not work. DNSSEC is a dead letter. It's long past time for people to move on. I have a lot of hope for what we can accomplish with ubiquitous DoH-like lookups.
The reason browsers didn't implement DANE is because most people's DNS servers are garbage, so if you do this the browser doesn't work and "if you changed last you own the problem".
At the time if you asked a typical DNS server e.g. at an ISP or built into a cheap home router - any type of question except "A? some.web.site.example" you get either no answer or a confused error. What do you mean records other than A exist? RFC what? These days most of them can also answer AAAA? but good luck for the records needed by DNSSEC.
Today we could do better where people have any sort of DNS privacy, whether that's over HTTPS or TLS or QUIC so long as it's encrypted it's probably not garbage and it isn't being intercepted by garbage at your ISP.
Once the non-adoption due to rusted-in-place infrastructure happened, you get (as you will probably see here on HN) people who have some imagined principle reasons not to do DNSSEC, remember always to ask them how their solution fixed the problem that they say DNSSEC hasn't fixed. The fact the problem still isn't fixed tells you everything you need to know.
> if you asked a typical DNS server e.g. at an ISP or built into a cheap home router - any type of question except "A? some.web.site.example" you get either no answer or a confused error.
Really? Because that would mean that anything using SRV records wouldn’t work on home routers, yet it’s an integral part of many protocols at this point.
There’s some room between “my DNS resolver doesn’t do DNSSEC” and “I can only resolve A records”.
Yes really. Like I said - even AAAA though better than it was isn't as reliable as A, the "Happy Eyeballs" tactic makes that tolerable, maybe 90% of your customers have IPv6, get the AAAA answer quickly, reach the IPv6 endpoint, awesome. 9% only have IPv4 anyway, get IPv4 endpoint, also fine, but 1% the AAAA query never returns, a few milliseconds later the IPv4 connection succeeds and the AAAA query is abandoned so who cares.
I'd guess that you if you build something which needs SRV? to "Just work" in 2025, not "nice to have" but as a requirement, you probably lose 1-2% of your potential users for that. It might be worth it. But if you need 100% you'll want a fallback. I suggest built-in DoH to, say, Cloudflare.
I guess I did forget that me using Cloudflare and Google as my DNS is not a normal setup to have...
But surely it doesn't have to be so black and white? TLSA enforcement is not even a hidden feature flag in mainstream web clients, it's just completely non-existent to my knowledge.
There are basically no rules on how to properly operate it, even if there were, there'd be no way to enforce them. There's also almost zero chance a leaked key would ever be detected.
I'm not sure I follow, could you please elaborate a bit more? I'm not really suggesting DNS to be exclusively used for PKI over the current Web PKI system of public CAs either.
What prevents me from putting the hash of the public key of my public CA certificate into the TLSA record? Nothing. What prevents clients from checking both that the public CA based certificate I'm showing is valid and is present on CT, as well as that it's hashes to the same value I have placed into the TLSA record? Also nothing.
Am I grossly misunderstanding something here? Feels like I missed a meta.
Nothing saying you can't, just when people talk about DANE that is usually not what they are proposing.
In terms of what you are saying, i think the main objection would be that HPKP feels a lot easier then putting it in DNS and we couldnt even get that to work. Otoh maybe dns could do a lot lower ttl which would counter some of the risks.
What benefit would that provide? It's just one more thing that has to be constantly maintained and could break while providing very little additional security.
Impractical in the sense that there are still TLDs (ccTLDs mind you, ICANN can't force anything for those countries) which do not have any form of DNSSEC, which makes DANE and TLSA useless for those TLDs.
Kind of disappointing if that is the actual stated reason by the various browser vendors, all or nothing doesn't sound like a good policy for this. Surely there is a middle ground possible.
Supporting DANE means you need to maintain both traditional CA validation and DANE simultaneously.
This may be controversial, but I believe that with CT logs already in place, DANE could potentially reduce security by leaving you without an audit trail of certificates issued to your hosts. If you actively monitor certificate issuance to your hosts using CT, you are in a much better security posture than what DANE would provide you with.
People praising DANE seem to be doing so as a political statement ("I don't want a 3rd party") rather than making a technical point.
Why not do both at the same time? I understand that a TLSA record in and of its own would suffice technically, but combined with the regular CA-based PKI, I figured the robustness would increase.
> Why not do both at the same time? I understand that a TLSA record in and of its own would suffice technically, but combined with the regular CA-based PKI, I figured the robustness would increase.
That seems quite complicated while not increasing security by much, or at all?
I don't necessarily see the complication. The benefit would be that I, the domain owner, would be able to communicate to clients what certificate they should be expecting, and in turn, clients would be able to tell if there's a mismatch. Sounds like a simple win to me.
According to my understanding, multiple CAs can issue a certificate covering the same domain just fine, so that on its own showing up on the CT logs is not a sign of CA compromise, just a clue. Could then check CAA, but that is optional and clients are never supposed to check that according to the standard, only the CAs (which again the idea is that one or more are compromised in this scenario). So there's a gap there. This gap to my knowledge is currently bridged by people auditing CT manually, and is the gap that would be filled with DANE in this setup in my thinking, automating it away (or just straight up providing it, because I can imagine that a lot of domain owners do not monitor CT for their domains whatsoever).
Part of why it’s so hard for Mallory to create a fake version of a bank site is Certificate Transparency. It makes it much much harder to issue a forged certificate that a browser such as Chrome, Safari or Firefox will accept.
For further info about the flaws of DNSSEC I can recommend this article: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ It’s from 2015 but I don’t think anything has really changed since that.