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.
"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...
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 remember back in the days when people discouraged people from using encrypted disks because of the situation that could happen if the user lost their passwords. No disk encryption algorithm can solve the issue if the user does not have the correct password, and so the recommendation was to not use it. Nowadays people usually have TPMs or key management software to manage keys, so people can forget the password and still access their encrypted disks.
DNSSEC software is still not really that developed that they automatically include basic tests and verification tools to make sure people don't simply mix up keys. They assume that people write those themselves. Too many times this happens after incidents rather than before (heard this in so many war stories). It also doesn't help that dns is full of caching and caching invalidation. A lot of the insane step-by-step plans comes from working around TTL's, lack of verification, basic tooling, and that much of the work is done manually.
This problem is accurate, but it's the framing that makes it wrong.
No disk encryption algorithm can simultaneously protect and not protect something encrypted, what you're missing is the protocol/practices around that, and those are far less limited.
There is heaps of encryption around these days, there are people losing access to their regular keys, and yet procedures that recover access to their data while not entirely removing the utility of having encrypted data/disks.
If you're on the root/TLD end of things I agree. Certainly not if you're a domain owner or name server administrator on the customer end of things.
I am saying it is dishonest to discount the real security threat of not having DNSSEC.
But the person you're replying to believes we should hasten deployment of DNSSEC, the protocol we have now.
Sadly, we live in this reality for now, so we do what we can with what we have. We have DNSSEC.
I saying say I agree with the statement "I am saying it is dishonest to discount the real security threat of not having DNSSEC."
I believe we do need some way to secure/harden DNS against attacks, we can't pretend that DNS as it stands is OK. DNSSEC is trying to solve a real problem - I do think we need to go back to the drawing board on how we solve it though.
It's fine that we all agree on some things and disagree on others! I don't think DNS security is a priority issue, but I'm fine with it conceptually. My opposition is to the DNSSEC protocol itself, which is a dangerous relic of premodern cryptography designed at a government-funded lab in the 1990s. The other commenter on this thread disagrees with that assessment.
slightly later
(My point here is just clarity about what we do and don't agree about. "Resolving" this conflict is pointless --- we're not making the calls, the market is. But from an intellectual perspective, understanding our distinctive positions on Internet security, even if that means recognizing intractable disputes, is more useful than just pretending we agree.)
So has failing to renew TLS certificates. So what?
There are also operational risks, as Let's Encrypt has to have their secret key material in close proximity to web-facing services. Of course, they use HSMs, but it might not be enough of a barrier for nation-state level attackers.
The offline signing feature of DNSSEC allows the root zone and, possibly, the TLDs to be signed fully offline.
That's why in my ideal world I want to keep DNSSEC as-is for the root zone and the TLD delegation records, but use something like DoH/DoT for the second-level domains. The privacy impact of TLD resolution is pretty much none, and everything else can be protected fully.
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.
You start with a BGP hijack, which lets you impersonate anybody, but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about. You then use that specific control to get a CA to forge a certificate for you (and if the CA is capable of using any information to detect that this might be a forgery, the attack breaks).
And of course, the proposed solution doesn't do anything to protect against other kinds of DNS hijacking--impersonating somebody to the nameserver and getting the account switched over to them.
You claim it is fine-tuned, but it has happened in the real world. It is actually even better for attackers that it is "obscure", because that means it is harder to detect.
> but assume that the hijacker is only so powerful as being able to impersonate a specific DNS server and not the server that the DNS server tells you about.
Yes, all layers of the stack need to be secure. I am not making assumptions about the other layers - this thread is about DNS.
> if the CA is capable of using any information to detect that this might be a forgery
They are not. The only mitigation is "multi-perspective validation", which only addresses a subset of this attack.
> And of course, the proposed solution doesn't do anything to protect against other kinds of DNS hijacking
Yes, because other kinds of DNS hijacking are solved by HTTPS TLS. If TLS and CAs are broken, nothing is secure.
Sure, but it seems like his comment is still responsive; if DNSSEC is deployed, they perform a BGP hijack & can impersonate everyone, and they just impersonate the server after the DNS step?
If that's the threat model you want to mitigate, it seems like DNSSEC won't address it.
Yes, there are different mitigations to prevent BGP hijacking the webserver itself. Preventing a rogue TLS certificate from being issued is the most important factor. CAA DNS records can help a bit with this. DNS itself however is easiest solved by DNSSEC.
There are a lot of mitigations to prevent BGP hijacks that I won't get too much into. None are 100%, but they are good enough to ensure multi-perspective validation refuses to issue a TLS certificate. The problem is that if those same mitigations are not deployed on your DNS servers (or you outsource DNS and they have not deployed these mitigations) it is a weak link.
So far your response to this has been "attackers can't do this to Cloudflare". I mean, stipulated? Good note? Now, can you draw the rest of the owl?
The thread is right here for everyone to read.
An attacker impersonating a DNS server still won't be able to forge the DNSSEC signatures.
The sequence there is:
1. I hijack traffic destined for an IP address
2. Anything whose DNS resolves to that IP, regardless of whether or not they use DNSSEC, starts coming to me
In this model, I don't bother trying to hijack the IP of a DNS server: that's a pain because with multi-perspective validation, I plausibly have to hijack a bunch of different IPs in a bunch of different spots. So instead I just hijack the IP of the service I want to get a malicious cert for, and serve up responses to let me pass the ALPN ACME challenge.
So DNSSEC still offers protection here.
That feels like a pretty narrow gain to justify strapping all this to all my zones and eating the operational cost and risk that if I mess it up, my site stops existing for a while
No. I'm saying that you can _not_ hijack a DNSSEC-enabled DNS name, even if you have a full control over the network.
The DNSSEC public keys for the domain are stored in the top-level domain zone. Which in turn is protected by a signature with the key from the root zone.
In the case of attacking the ALPN ACME validation, they hijack the IP address of the site they want a TLS certificate for: example.org resolves to 1.2.3.4, I hijack traffic to 1.2.3.4, the DNS flow is unchanged, the verification traffic comes to me, and I get a certificate for example.org
The DNS server hijack works the same way: I don’t try to change what ns1.example.org resolves to. I hijack traffic to the real IP that it resolves to and serve up responses for the site I want to hijack saying “yea, these are the records you want and don’t worry, the DS bit is set to true”.
Though it’s worth remembering that both DNS and BGP attacks are basically a rounding error compared to the instances of ATO-based attacks
> In the case of attacking the ALPN ACME validation, they hijack the IP address of the site they want a TLS certificate for: example.org resolves to 1.2.3.4, I hijack traffic to 1.2.3.4, the DNS flow is unchanged, the verification traffic comes to me, and I get a certificate for example.org
As I said, a CAA record in DNS will prohibit this, instructing the ACME CA to use the DNS challenge.
> I hijack traffic to the real IP that it resolves to and serve up responses for the site I want to hijack saying “yea, these are the records you want and don’t worry, the DS bit is set to true”.
And then your faked DNS replies will have a wrong signature because you don't have the private key for the DNS zone.
And DNSSEC-validating clients will detect this because the top-level domain will have a DNSKEY entry for the hijacked domain. You can't fake the replies from the top-level domain DNS because it in turn will have a DNSKEY entry in the root zone.
DNSSEC was built for exactly one use case: we have to put root/TLD authoritative servers in non-Western countries. It is simply a method for attesting that a mirror of a DNS server is serving what the zone author intended.
What people actually want and need is transport security. DNSCrypt solved this problem, but people were bamboozled by DNSSEC. Later people realized what they wanted was transport security and DoH and friends came into fashion.
There is also no reason we can't have both.
(Actually getting it to work reliably without downgrade attacks would be more work, but notably, that's work DNSSEC would have had to do too --- precisely the work that caused DANE-stapling to founder in tls-wg.)
There's still a chicken-and-egg problem with getting a valid TLS certificate for the DNS server, and limiting DNSSEC just for that role might be a valid approach. Just forget that it exists for all other entry types.
But if you have DoH chaining all the way from the recurser to the authority, it's tricky to say what stapled DANE signatures are even buying you. The first consumers of that system would be the CAs themselves.
This way, it can be used to guarantee the integrity of the resolution path without first getting a certificate from a CA.
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.
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.
Wait, wait, wait. How can you hijack a DNSSEC server? Its keys are enrolled in the TLD, and you can't spoof the TLD server, because its keys in turn are enrolled in the root zone. And the root zone trust anchor is statically configured on all machines.
High-end registrars that focus on portfolios and brand management generally do have any kind of authentication that the customers want, and the price will reflect that. Costumers are not just buying the service of a middle man that acts as a go-between the TLD and the domain owner.
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.
$ dig +short letsencrypt.org DS
$For starters you could try `dig +short ds google.com`. It'll give you a flavor of what to expect.
You're not going to take my word for it, but you could take Geoff Huston's, who recently recorded a whole podcast about this.
It's the latter.
https://doublepulsar.com/hijack-of-amazons-internet-domain-s...
https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/
https://blog.citp.princeton.edu/2022/03/09/attackers-exploit...
Noteworthy: "Additionally, some BGP attacks can still fool all of a CA’s vantage points. To reduce the impact of BGP attacks, we need security improvements in the routing infrastructure as well. In the short term, deployed routing technologies like the Resource Public Key Infrastructure (RPKI) could significantly limit the spread of BGP attacks and make them much less likely to be successful. ... In the long run, we need a much more secure underlying routing layer for the Internet."
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.
DCV is CA/B speak for domain-control validation; CAA = these are my approved CAs.
This seems to be optional in the sense that: if a DNS zone has DNSSEC, then validation must succeed. But if DNSSEC is not configured it is not required.
- 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.
they not only intercepted your traffic for profiling but also injected redirects to their branded search. honestly curious if you're just too young or was one of the maybe 10 people who never experienced this.
sending traffic to a third party like quad9 is much safer than to a company who have your name/address/credit card.
Now, this kind of attack would likely be more visible and thus detected sooner than one targeted at a specific site, and just because there is a threat like this doesn't mean other threats should be ignored or downplayed. But it seems to me that BGP security needs to be tackled in its own right, and DNSSEC would just be a leaky band-aid for that much bigger issue.
This is a problem with TLS too, of course, because of domain validation. But the WebPKI responded to that problem with Certificate Transparency, so you can detect and revoke misissued certificates. Not only does nothing like that exist for the DNS, nothing like it will exist for the DNS. How I know that is, Google and Mozilla had to stretch the bounds of antitrust law to force CAs to publish on CT logs. No such market force exists to force DNS TLD operators to do anything.
My (ahem) "advocacy" against DNSSEC is understandably annoying, but it really is the case that every corner of this system you look around, there's some new goblin. It's just bad.
Yes ASPA is new. Reference implementations in open source routing daemons and RPKI tools are being developed and rolled out. If you want to be a pioneer you can run a bird routing daemon and secure the routes with ASPA. Only experimenters have created ASPA records at this point, however once upon a time we were in the same position with RPKI.
https://serverfault.com/questions/1018543/dns-not-resolving-...
Unfortunately the basic thought process is that "it is a security feature, therefore it must be enabled" it is very hard to argue against that, but it is pretty similar to "we must have the latest version of everything as that is secure" and "we should add more passwords with more requirements and expire it often". One of those security theatres that optimizes for reducing accountability, but may end up with almost no security gains and huge tradeoffs that may end up even compromising security through secondary effects (how secure is a system that is down?)
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. ¯\_(ツ)_/¯
But the clear evidence is that past promises of it arriving at those major ISPs are very hollow indeed.
It's not the same with DNSSEC in the U.K., though. Many WWW hosting services (claim to) support that right now. And if anything, rather than there being years-old ineffective petition sites clamouring for IPv6 to be turned on, it is, even in 2025, the received wisdom to look to turning DNSSEC off in order to fix problems.
* https://codepoets.co.uk/2025/its-always-dns-unbound-domain-s...
* https://www.havevirginmediaenabledipv6yet.co.uk
One has to roll one's eyes at how many times the-corporation-disables-the-thread-where-customers-repeatedly-ask-for-simple-moderen-stuff-for-10-years is the answer. It was the answer for Google Chrome not getting SRV lookup support. Although that was a mere 5 years.
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.
And yet every article on IPv6 has entire brigades of folks of folks going on about IPv6 is DOA, and "I've been here about it for thirty years, where is it?", and "they should have done IPv4 just with larger addresses, adoption would have been much faster and more compatible".
I'm simply pointing out the parallel argument that was made between DNSSEC and IPv6.
IPv6 probably could have been done better and rolled out faster, and whoever works on IPvNEXT should study what went wrong, but eventually it became better than alternative ways of dealing with a lack of IPv4 addresses, and it started getting real deployment.
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.
(The biggest problem in this thread is that you can bypass the rate limit but nobody else can)
At this point, your statements border on intentional dishonesty. Please be more truthful and responsible in your statements.
Hijacking by whom? Very few are really running a validating recursive resolver.
Just create a secure path from CA to registrar. RDAP-based or DoH-based, or something from scratch, does not really matter. It will only need to cover few thousand CAs and TLDs, so it will be vastly simpler that upgrading billions of internet devices.