We don't. If we did, we'd have it by now. It's been over 25 years of making appeals like this.
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.
iscoelho · 3h ago
It is important. This is unfortunate rhetoric that is harming the safety of the internet.
"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.
I'm sorry, this is just such an incredibly fine-tuned threat model for me to take it seriously.
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.
muppetman · 3h ago
DNSSec has caused so many outages at this point it's a joke.
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.
A common reason, if not the vast majority of cases, is that people mix up which key they publish and which key they are actually using. I don't doubt there are a lot of things they could do to improve the protocol, but this very common problem is fairly difficult to solve on a protocol level.
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.
iscoelho · 3h ago
Yeah I'm by no means saying the implementation is good. RPKI is a joke as well in my opinion. But it's all we have right now.
I am saying it is dishonest to discount the real security threat of not having DNSSEC.
muppetman · 53m ago
Right OK, I fully agree with you then.
tptacek · 41m ago
What parts do you agree about? Someone making an argument that we should return to the drawing board and come up with a new protocol, one that doesn't make the "offline signers and authenticated denial" tradeoffs DNSSEC makes, would probably be saying something everybody here agrees with --- though I still don't think it would be one of the 5 most important security things to work on.
But the person you're replying to believes we should hasten deployment of DNSSEC, the protocol we have now.
iscoelho · 37m ago
I would love to go to back to the drawing board and solve the security pitfalls in BGP & DNS. I wish the organizations and committees involved did a better job back then.
Sadly, we live in this reality for now, so we do what we can with what we have. We have DNSSEC.
muppetman · 32m ago
I don't read that reply as them saying we should hasten deployment of DNSSEC. If that was the intention of the comment then no, I don't agree with that aspect of it.
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.
tptacek · 24m ago
They definitely believe we should hasten deployment of DNSSEC --- read across the thread. For instance: Slack was taken down for a half a day owing to a deployment of DNSSEC that a government contract obligated them to undertake, and that commenter celebrated the contract.
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.)
nine_k · 2h ago
There are two things mixed up. "We need secure DNS" != "we need DNSSEC".
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.
iscoelho · 2h ago
DoH does not solve anything that DNSSEC solves. They have almost no overlap.
ClumsyPilot · 2h ago
But TLS relies on having a domain
If domain intern depends on tls you have chicken and egg problem
nine_k · 1h ago
TLS internally does not depend on a domain in the DNS sense, it basically certifies a chain of signatures bound to a name. That chain can be verified, starting from the root servers.
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.
acdha · 25m ago
That quote is interesting because all of the period reporting I’ve seen says that the attackers did NOT successfully get an HTTPS certificate and the only people affected were those who ignored their browsers’ warnings.
> It is important. This is unfortunate rhetoric that is harming the safety of the internet.
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.
iscoelho · 45m ago
DNSSEC is about authentication & integrity. DNSCRYPT/DOH is about privacy. They solve completely different problems and have nothing to do with one another.
There is also no reason we can't have both.
tptacek · 40m ago
If you have secure channels from recursers all the way back to authority servers (you don't, but you could) then in fact DoH-like protocols do address most of the problems --- which I contend are pretty marginal, but whatever --- that DNSSEC solves.
iscoelho · 34m ago
Yessir, that isn't possible yet but it would absolutely be a solution! I'd love to see it.
tptacek · 21m ago
What's more, it's a software-only infrastructure upgrade: it wouldn't, in the simplest base case, require zone owners to reconfigure their zones, the way DNSSEC does. It doesn't require policy decisionmaking. DNS infrastructure operators could just enable it, and it would work --- unlike DNSSEC.
(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.)
tptacek · 3h ago
BGP attacks change the semantic meaning of IP addresses themselves. DNSSEC operates at a level above that. The one place this matters in a post-HTTPS-everywhere world is at the CAs, which are now all moving to multi-perspective validation.
iscoelho · 3h ago
As you should be aware, multi-perspective validation does not solve anything if your BGP hijack is accepted to be global. You will receive 100% of the traffic.
DNSSEC does greatly assist with this issue: It would have prevented the cited incident.
tptacek · 3h ago
A BGP attacker doesn't need to alter the DNS to intercept traffic; they're already intercepting targeted traffic at IP selectivity.
iscoelho · 3h ago
There are 2 ways to pull off this attack:
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.
tptacek · 3h ago
In summation, you propose a forklift upgrade of the DNS requiring hundreds of millions of dollars of effort from operators around the world, introducing a system that routinely takes some of the most sophisticated platforms off the Internet entirely when its brittle configuration breaks, to address the problem of someone pulling off a global hijack of all the Route53 addresses.
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.
iscoelho · 3h ago
"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.
tptacek · 3h ago
No, I'm saying it doesn't serve a real purpose. I've spent 30 years doing security work professionally and one of the basic things I've come to understand is that security is at bottom an economic problem. The job of the defender is to asymmetrically raise costs for attackers. Look at how DNS zones and certificates are hijacked today. You are proposing to drastically raise defender costs in a way that doesn't significantly alter attacker costs, because they aren't in the main using the exotic attack you're fixated on.
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.
iscoelho · 3h ago
What are you talking about? This is about real threat models. DNS hijacks are real and documented. DNSSEC solves them.
It is sounding more like you have a parasocial relationship with DNSSEC (and it isn't a good one it appears).
tptacek · 3h ago
Are you claiming that most DNS zone hijacks occur because an on-path attacker intercepts and spoofs replies to DNS queries? That's not the case.
tigerente · 2h ago
What would be the most common method of DNS zone hijacks, Kaminsky attacks?
tptacek · 2h ago
No, to a first approximation those attacks ~never happen. Most zones are hijacked by ATOs at registrars.
iscoelho · 3h ago
I never said "most". I said it happens and is documented.
tptacek · 3h ago
I'm pretty satisfied with how this part of the thread represents this part of my argument.
deknos · 1h ago
yeah, the same for the rest.
your fanboys are happy and the rest is just tired, because everyone who does not share your point of view has a invalid opinion.
growse · 11m ago
We could live in a world where they don't exist and the vast majority of major financial institutions still wouldn't implement DNSSEC.
You don't have to like, or agree with anyone. The data tells its own story.
teddyh · 2h ago
> 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.
daneel_w · 45m ago
>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.
Or his broken record commentary on how Signal absolutely needs to ask people for their mobile phone numbers in order to at all be able to provide a functional service, and how doing so does not at all provide Signal with a highly valuable social network map. Exact same story as soon as the arguments are dismantled.
iscoelho · 1h ago
I hope the facts speak for themselves.
xorcist · 3h ago
It does certainly make it easier. Sure, we can survive without it, but cryptographic signing of dns records is useful for a number of things.
tptacek · 3h ago
Counterpoint: no it isn't, which is why virtually nobody uses it. Even the attack this thread centers on --- BGP hijacking of targeted DNSSEC servers to spoof CA signatures --- is a rounding error sidenote compared to the way DNS zones actually get hijacked in practice (ATO attacks against DNS providers).
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.
iscoelho · 3h ago
You are again ignoring the fact that DNSSEC would have prevented a $152,000 hack. Yes, we are aware organizations are not always serious about security. For those that are though, DNSSEC is a helpful tool.
tptacek · 3h ago
No, it isn't. It attempts and mostly fails to address one ultra-exotic attack, at absolutely enormous expense, principally because the Internet standards community is so path-dependent they can't take a bad cryptosystem designed in the mid-1990s back to the drawing board. You can't just name call your way to getting this protocol adopted; people have been trying to do that for years, and the net result is that North American adoption fell.
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.
iscoelho · 3h ago
"at absolutely enormous expense"
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.
tptacek · 3h ago
The cost I'm talking about is the defender's.
iscoelho · 3h ago
Oh stop with the hyperbole. Fortune 500's almost all outsource DNS to UltraDNS/Route53/Dyn/Cloudflare. They will spend longer having meetings about implementing it, rebutting individuals like yourself, than spending 5 minutes actually implementing it.
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.
growse · 2h ago
Slack's house literally did burn down for 24 hours because of DNSSEC back into 2021.
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?
daneel_w · 26m ago
Oh. I thought it burned down because of their engineers not having fully acquainted themselves with the tool before applying it. It's misguided to hold DNSSEC culpable for Slack's engineers' goof-up. Like advising people against ever going near scissors because they might run with one in their hands.
Miserable list. Now share a link that shows all the successful deployments that never had any hiccups.
growse · 9m ago
Apparently the way to do sane risk management is just "don't be an idiot"?
iscoelho · 2h ago
and Slack.com still uses DNSSEC. They appear to not have come to the same conclusion.
tptacek · 2h ago
They added DNSSEC because of FedGov accounts that require it.
iscoelho · 1h ago
Happy to see security audits doing good work.
tptacek · 3h ago
I'm not sure what this has to do with anything I've said on this thread, but we don't have to keep pressing these arguments; I'm pretty satisfied with the case I've made so far.
phillipseamore · 3h ago
And at least Let's encrypt actually verifies DNSSEC before issuing certificates. IIRC it will become mandatory for all CA's soon. DNSSEC for a domain plus restrictive CAA rules should ensure that no reputable CA would issue a rogue cert.
tptacek · 3h ago
It absolutely will not. Most domains aren't hijacked by spoofing the DNS to begin with.
iscoelho · 3h ago
"Most domains". Yes, it is possible that nobody bothers to DNS hijack your domains. Sadly I've worked for organizations where it did happen, and now they have DNSSEC.
tptacek · 3h ago
I invite anybody who thinks this is a mic drop to pull down the Tranco research list of most popular/important domains on the Internet --- it's just a text file of zones, one per line --- and write the trivial bash `for` loop to `dig +short ds` each of those zones and count how many have DNSSEC.
For starters you could try `dig +short ds google.com`. It'll give you a flavor of what to expect.
daneel_w · 16m ago
And you still can't seem to make your mind up on whether this is because DNSSEC is still in its infancy or if it's because they all somehow already studied DNSSEC and ended up with the exact same opinion as you. I'm gonna go out on a limb and say that it's not the latter.
tptacek · 3m ago
What do I have to make my mind up about? I worked on the same floor as the TIS Labs people at Network Associates back in the 1990s. They designed DNSSEC and set the service model: offline signers, authenticated denial. We then went through DNSSEC-bis (with the typecode roll that allowed for scalable signing, something that hadn't been worked out as late as the mid-1990s) and DNSSEC-ter (NSEC3, whitelies). From 1994 through 2025 the protocol has never seen double-digit percentage adoption in North America or in the top 1000 zones, and its adoption has declined in recent years.
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.
growse · 8m ago
I've worked for these orgs on this exact problem.
It's the latter.
zahllos · 3h ago
The argument counter dnssec is that if you are trying to find some random A record for a server, to know if it is the right one, TLS does that fine provided you reasonably trust domain control validation works i.e. CAs see authentic DNS.
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.
iscoelho · 3h ago
TLS doesn't provide any security in this case because TLS certificates are generated based on DNS. See Lets Encrypt.
acdha · 22m ago
Isn’t this why validation is done from multiple locations on different networks? That blocked the 2018 attack and RPKI has made it even harder since.
burnt-resistor · 3h ago
Related:
- ECC vs. non-ECC memory and bitsquatting when people said "oh, it doesn't matter and it's too expensive for no benefit."
- Unsecured DNS over 53/tcp+udp (vs. DoH today) is a huge spoofing and metadata collection threat surface.
rsync · 2h ago
"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 ?
iscoelho · 2h ago
Not saying they are malicious actors, but easy answer would be any Public WiFi anywhere. They all intercept DNS, less than 1% intercept SNI.
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.
growse · 1h ago
Isn't the vast majority of TLS connections using SNI today?
iscoelho · 1h ago
Yes TLS SNI is ubiquitous. I am referring specifically to TLS SNI metadata collection.
ikiris · 2h ago
tls1.3 exists
throw0101d · 3h ago
> We don't. If we did, we'd have it by now. It's been over 25 years of making appeals like this.
See also IPv6. ;)
Edit: currently at "0 points". People, it was a joke. Chill.
acdha · 21m ago
As a joke, it’s not easily distinguishable from trolling and since IPv6 is approaching half of all traffic, more in many areas, the humor value is limited.
tptacek · 3h ago
We very definitely do have IPv6. I'm using IPv6 right now. Last numbers I saw, over 50% of North American hits to Google were IPv6. DNSSEC adoption in North America is below 4%, and that's by counting zones, most of which don't matter --- the number gets much lower if you filter it down to the top 1000 zones.
JdeBP · 2h ago
Well for some value of "we" and some value of "have". (-:
throw0101d · 3h ago
> We very definitely do have IPv6. I'm using IPv6 right now.
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. ¯\_(ツ)_/¯
One can hope that someone will give the ISPs in my country a metaphorical hefty kick up the arse, especially as some of the more niche ones have been happily providing IPv6, and business customers can get IPv6, and of course other countries are happily embracing IPv6. So I wouldn't say never.
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.
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.
api · 3h ago
If you want the net to support end to end connectivity we need IPv6. Otherwise you'll end up with layers and layers of NAT and it will become borderline impossible.
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.
immibis · 3h ago
We need a lot of things we don't have.
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.
tptacek · 3h ago
In this case, there's an avalanche of money and resources backing up the problem domain DNSSEC attempts to make contributions in, and the fact that it's deployed in practically 0% of organizations with large security teams is telling.
iscoelho · 3h ago
I would say it is more a testament to the unfortunate state of cybersecurity. These "theoretical" attacks happen. Everyone just thinks it won't be them.
tptacek · 3h ago
My rebuttal is that the DNSSEC root keys could hit Pastebin tonight and in almost every organization in the world nobody would need to be paged. That's not hyperbole.
avidiax · 3h ago
You are mostly right, but I would hope that certain core security companies and organizations would get paged. Root CAs and domain registrars and such should have DNSSEC validation.
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.
tptacek · 3h ago
SIM-swapping is a much more important attack vector than on-path/off-path traffic interception, and are closer to how DNS hijacking happens in practice (by account takeover at registrars).
immibis · 2h ago
If that happened, we'd revert to pre-DNSSEC security levels: an attack would still be hard to pull off (unless you own a root DNS server or are reliably in the path to one). It's like knowing the private key for news.ycombinator.com - it still doesn't do anything unless I can impersonate the Hacker News server. But that was still enough of a risk to justify TLS on the web. Mostly because ISPs were doing it to inject ads.
tptacek · 2h ago
We are demonstrably in "pre-DNSSEC" security levels today. DNSSEC has almost no serious adoption.
iscoelho · 58m ago
That’s false. Any organization that enables DNSSEC for their domains gains its security benefits and prevents any potential DNS hijacking.
At this point, your statements border on intentional dishonesty. Please be more truthful and responsible in your statements.
tptacek · 20m ago
This is an engineering/technical discussion and you're not going to be able to name-call your way through it.
1vuio0pswjnm7 · 1h ago
"DNS resolvers are the ones in charge of tracking down this information for you."
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.
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.
Avamander · 2h ago
We don't. It's just an another PKI with operators you can never get rid of if they misbehave. That alone makes it not possible to start relying on it.
growse · 5m ago
Everyone seems to miss the "single unbreakable pki" aspect that necessarily comes along with the design. :shrug:
anonymousiam · 3h ago
Dan Kaminsky showed us why we need DNSSEC. Without it, it's quite easy to MITM and/or spoof network traffic. Some governments like to do this, so they'll continue to make it difficult for DNSSEC to be fully adopted.
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.
It's trivial to spoof DNS even with DNSSEC set up, because DNSSEC is a server-to-server protocol. Your browser doesn't speak DNSSEC; it speaks plaintext DNS, and trusts a single bit in the response header that says whether the upstream caching resolver actually checked signatures.
burnt-resistor · 3h ago
Optional, alternative standards don't have visibility and don't get used.
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.
DNSSEC is very easy to setup on AWS Route53 and it lets you sign any txt record you have which can be very useful.
aspbee555 · 3h ago
because I can have my certificate authority in my DNS records and my app can verify the CA cert is from a trusted/verified source
tptacek · 2h ago
This would theoretically be possible if browsers did DANE and didn't, because of middlebox fuckery, have to have a fallback path to the X.509 WebPKI because DNSSEC requests get dropped like 5% of the time. But because that is the case, no browser does DANE validation today, and when they did, many years ago, those DANE CA certs were effectively yet another CA; they actually expanded your attack surface rather than constricting it.
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.
tialaramex · 2h ago
Parts of the inevitable Thomas Ptacek DNSSEC rant remind me of the years of denialism from C++ people before the period when they were "concerned" about safety and the past few years of at least paying lip service to the idea that C++ shouldn't be awful...
acdha · 15m ago
One thing I like about Thomas, history on this issue has been the focus on UX. I think that “can probably be used safely by an expert who understands the domain” as a failure mode is something we should spend more time thinking about as an architecture failure rather than a minor frictional cost.
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 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 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.
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.)
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.
https://doublepulsar.com/hijack-of-amazons-internet-domain-s...
https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/
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.)
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).
https://dnsinstitute.com/research/2020/banks-dnssec-202010.h...
You don't have to like, or agree with anyone. The data tells its own story.
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.
Or his broken record commentary on how Signal absolutely needs to ask people for their mobile phone numbers in order to at all be able to provide a functional service, and how doing so does not at all provide Signal with a highly valuable social network map. Exact same story as soon as the arguments are dismantled.
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?
https://ianix.com/pub/dnssec-outages.html
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.
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.
- 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.
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. ¯\_(ツ)_/¯
* https://news.ycombinator.com/item?id=44306792
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.
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.
At this point, your statements border on intentional dishonesty. Please be more truthful and responsible in your statements.
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, 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.
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...
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
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.