It's a fun site! I'm not entirely sure why the protagonist is a green taco, but I can see why a DNS provider would make a cartoon protocol explainer. It's just that this particular protocol is not as important as the name makes it sound.
Note that without DNS security, whoever controls your DNS server, or is reliably in the path to your DNS server, can issue certificates for your domain. The only countermeasure against this is certificate transparency, which lets you yell loudly that someone's impersonating you but doesn't stop them from actually doing it.
Unfortunately, DNSSEC is a bit expensive in terms of support burden, additional bugs, reduced performance, etc. It will take someone like Apple turning DNSSEC validation on by default to shake out all the problems. Or it will take an exploitable vulnerability akin to SIM-swapping to maybe convince Let's Encrypt! and similar services reliant on proof-by-dns that they must require DNSSEC signing.
"For instance, in April 2018, a Russian provider announced a number of IP prefixes (groups of IP addresses) that actually belong to Route53 Amazon DNS servers."
By BGP hijacking Route53, attackers were not only able to redirect a website to different IPs, globally, but also generate SSL certificates for that website. They used this to steal $152,000 in cryptocurrency. (I know I know, "crypto", but this can happen to any site: banking, medical, infrastructure)
Also, before you say, RPKI doesn't solve this either, although a step in the right direction. DNSSEC is a step in the right direction as well.
[1] https://www.cloudflare.com/learning/security/glossary/bgp-hi...
DNSSEC does greatly assist with this issue: It would have prevented the cited incident.
1. Hijack the HTTP/HTTPS server. For some IP ranges, this is completely infeasible. For example, hijacking a CloudFlare HTTP/HTTPS range would be almost impossible theoretically based on technical details that I won't go through listing.
2. Hijack the DNS server. Because there's a complete apathy towards DNS server security (as you are showing) this attack is very frequently overlooked. Which is exactly why in the cited incident attackers were capable of hijacking Amazon Route53 with ease. *DNSSEC solves this.*
If either 1 or 2 work, you have yourself a successful hijack of the site. Both need to be secure for you to prevent this.
At this point, you might as well just have the CABForum come up with a new blessed verification method based on RDAP. That might actually happen, unlike DNSSEC, which will not. DNSSEC has lost signed zones in North America over some recent intervals.
I do like that the threat model you propose is coherent only for sites behind Cloudflare, though.
The threat model I proposed is coherent for Cloudflare because they have done a lot of engineering to make it almost impossible to globally BGP hijack their IPs. This makes the multi-perspective validation actually help. Yes, other ISPs are much more vulnerable than Cloudflare, is there a point?
You are not saying DNSSEC doesn't serve a real purpose. You are saying it is annoying to implement and not widely deployed as such. That alone makes me believe your argument is a bit dishonest and I will abstain from additional discussion.
If we really wanted to address this particular attack vector in a decisive way, we'd move away, at the CA level, from relying on the DNS protocol browsers use to look up hostnames altogether, and replace it with direct attestation from registrars, which could be made _arbitrarily_ secure without the weird gesticulations DNSSEC makes to simultaneously serve mass lookups from browsers and this CA use case.
But this isn't about real threat models. It's about a tiny minority of technologists having a parasocial relationship with an obsolete protocol.
It is sounding more like you have a parasocial relationship with DNSSEC (and it isn't a good one it appears).
He does. Just examine his comment history regarding DNSSEC. It’s full of rhetoric and bluster, appeals to authority and dismissal of arguments not from what he considers an authority, and when he runs out of arguments entirely, he stops responding. And he’s somewhat of a celebrity, so his arguments are all upvoted, while his critics are all downvoted, regardless of merit.
If people were serious about this, they'd start by demanding that every DNS provider accept U2F and/or Passkeys, rather than the halfhearted TOTP many of them do right now. But it's not serious; it's just motivated reasoning in defense of DNSSEC, which some people have a weird stake in keeping alive.
The companies you're deriding as unserious about security in general spend drastically more on security than the companies that have adopted it. No part of your argument holds up.
Citation? A BGP hijack can be done for less than $100.
"You can't just name call your way to getting this protocol adopted"
I do not care if you adopt this protocol. I care that you accurately inform others of the documented risks of not adopting DNSSEC. There are organizations that can tolerate the risk. There are also organizations that are unaware because they are not accurately informed (due to individuals like yourself), and it is not covered by their security audits. That is unfortunate.
I don't understand why this is such a polarizing topic for individuals like you. It's as if DNSSEC burned down your house. It doesn't make sense to me.
When you frame the risk as "marginal benefit against one specific threat" Vs "removes us from the internet for 24 hours", the big players pass and move on. This is the sort of event the phrase "sev 1" gets applied to.
Some fun companies have a reg requirement to provide service on a minimum SLA, otherwise their license to operate is withdrawn. Those guys run the other way screaming when they hear things like "DNSSEC" (ask me how I know).
What percentage of the fortune 500 is served over DNSSEC?
For starters you could try `dig +short ds google.com`. It'll give you a flavor of what to expect.
An argument for DNSSEC is any service configured by SRV records. It might be totally legitimate for the srv record of some thing or other to point to an A record in a totally different zone. From a TLS perspective you can't tell, because the delegation happened by SRV records and you only know if that is authentic if you either have a signed record, or a direct encrypted connection to the authoritative server (the TLS connection to evil.service.example would be valid).
So it depends what you expect out of DNS.
You have to be so insanely careful and plan everything to the nth degree otherwise you break everything: https://internetnz.nz/news-and-articles/dnssec-chain-validat...
The idea is important. What it aims to protect is important. The current implementation is horrible, far too complex and fraught with so many landminds that no one wants to touch it.
If Geoff Huston is suggesting it might be time to stick a fork in DNSSec because it's done, then IMHO it's well cooked. https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/
I am saying it is dishonest to discount the real security threat of not having DNSSEC.
- ECC vs. non-ECC memory and bitsquatting when people said "oh, it doesn't matter and it's too expensive for no benefit."
- http:// was, for years, normalized pre-PRISM.
- Unsecured DNS over 53/tcp+udp (vs. DoH today) is a huge spoofing and metadata collection threat surface.
Genuinely curious:
What actor, in 2025, would exist in your threat model for DoH ... but wouldn't simultaneously be sniffing SNI ?
I can't think of any.
I cannot think of any good reason to be serious about DoH and DNS leakage in the presence of unencrypted SNI.
What am I missing ?
It is also public knowledge that certain ISPs (including Xfinity) sniff and log all DNS queries, even to other DNS servers. TLS SNI is less common, although it may be more widespread now, I haven't kept up with the times.
There is a huge demand for securing DNS-related things, but DNSSEC seems to be a poor answer. DoH is a somehow better answer, with any shortcomings it may have, and it's widely deployed.
I suspect that a contraption that would wrap the existing DNS protocol into TLS in a way that would be trivial to put in front of an existing DNS server and an existing DNS client (like TLS was trivial to put in front of an HTTP server), might be a runaway success. A solution that wins is a solution which is damn easy to deploy, and not easy to screw up. DNSSEC is not it, alas.
The problem is more in the fact that TLS assumes creation of a long-living connection with an ephemeral key pair, while DNS is usually a one-shot interaction.
Encrypting DNS would require caching of such key pairs for some time, and refreshing them regularly but not too often. Same for querying and verifying certificates.
See also IPv6. ;)
Edit: currently at "0 points". People, it was a joke. Chill.
I'm not. Neither is my home wireline PON ISP, even though they have it on their mobile network (but my previous ISP did).
Also, every time there's an IPv6 article on HN there are entire sub-threads of people saying it's never going to come along. ¯\_(ツ)_/¯
A lot of protocols get unstable behind layers of NAT too, even if they're not trying to do end to end / P2P. It adds all kinds of unpredictable timeouts and other nonsense.
Even if that wasn't the case --- and it emphatically is --- you'd still be contending with a "personal CA" that in most cases would have its root of trust in a PKI operated by world governments, most of which have a demonstrated aptitude for manipulating the DNS.
Without a way to measure, nothing happens. There was once a few, UX-hostile DNSSEC & DANE browser extensions but these never worked well and were discontinued.
Purveyors of functional DNSSEC: https://freebsd.org
The original registrar, Network Solutions, doesn't even fully support DNSSEC. You can only get it if you pay them an extra $5/mo and let them serve your DNS records for you. So for $5/mo you get DNSSEC, but you defer control of your records to them, which isn't really secure.
https://community.cloudflare.com/t/dnssec-on-network-solutio...
If one uses them.
One can alternatively use iterative queries where no "DNS resolver", i.e., recursive resolver, is used.
Many years ago I wrote a system for interative resolution for own use, as an experiment. I learnt that it can be faster than recursive resolution.
People have since written software for iterative resolution and reached similar conclusions, e.g., https://lizizhikevich.github.io/assets/papers/ZDNS.pdf
Unfortunately authoritative servers generally do not encrypt their responses. IMO this would be more useful than "DNSSEC".
"And that data is often provided by authoritative servers."
What are examples of data not provided by authoritative servers.
davidu•2h ago