Even if you hate dnssec (and there are many legit criticisms to make) i think it does make sense for CA's to validate it if its there. Its low effort on the CA side, and there isn't really very much downside if its already active.
DNSSEC is one of very few topics where voices I respect on security seem completely opposed (WebPKI depends on DNS vs. DNS security does not matter). Is there any literature that demonstrates deep understanding of both arguments? Why are they (DNSSEC + WebPKI) never considered complimentary?
From my perspective, the challenge with DNSSEC is that it just doesn't have a very good cost/benefit ratio. Once the WebPKI exists, "critical path" use of DNSSEC only offers modest value. Now, obviously, this article is about requiring CAs to check DNSSEC, which is out of the critical path and of some value, but it's not clear to me it's of enough value to get people to actually roll out DNSSEC.
I enabled DNSSEC a couple of years ago on my self hosted powerdns setup. I sign the zone locally, than build docker containers via SSH on the target nodes.
I made a mistake once and signed with wrong keys which then broke DANE. It‘s good to validate your DNSSEC (and DANE, CAA etc.) setup through external monitoring.
In case the post is fuzzy: what's changed is that as of March 2026, CAs are required to validate DNSSEC if it's enabled when doing DCV or CAA. Previously, it was technically the case that a CA could ignore DNSSEC if you had it set up on your domains, though LetsEncrypt has (as I understand it) been checking DNSSEC pretty much this whole time.
If you own and host your own domain, it's probably very easy to have your DNS provider enable DNSSEC for you, maybe just a button click. They'd sure like you to do that, because DNSSEC is itself quite complicated, and once you press that button it's much less likely that you're going to leave your provider. DNSSEC mistakes take your entire domain off the Internet, as if it had never existed.
There's a research project, started at KU Leuven, that attempts an unbiased "top N" list of most popular domains; it's called the Tranco List. For the last year or so, I've monitored the top 1000 domains on the Tranco list to see which have DNSSEC enabled. You can see that here:
First, DNSSEC penetration in the top 1000 is single digits % (dropping sharply, down to 2%, as you scope down to the top 100).
Second, in a year of monitoring and recording every change in DNSSEC state on every domain in this list, I've seen just three Tranco Top 1000 domains change their DNSSEC state, and one of those changes was Canva disabling DNSSEC. (I think, as of a few weeks ago, they've re-enabled it again). Think about that: 1000 very popular domains, and just 0.3% of them thought even a second about DNSSEC.
That’s a fun list, the only hits in the top 100 are actually Cloudflare, for whom automatic DNSSEC is a feature, and would be a bad look not to dogfood it.
(I did a lot of the work of shipping that product in a past life. We had to fight the protocol and sometimes the implementers to beat it into something deployable. I am proud of that work from a technical point of view, but I agree DNSSEC adds little systemic value and haven’t thought about it since moving on from that project almost 10 years ago. It doesn’t look like DNSSEC itself has changed since, either.)
Then a few government sites, which have mandated it. The first hit after those is around #150.
It seems pretty clear to me that the industry, and particularly the slice of the industry that operates large, important sites and staffs big security teams, doesn't believe this is a meaningful problem at all.
The fact that it's 2026 and the CAs are only now getting around to requiring any CA to take DNSSEC, which has in its current form been operational for well over a decade, makes you take DNSSEC more seriously?
Why dodge the question? Clearly they care today, and I live in today.
If we're doing to defer to industry, does only the opinion of website operators matter, or do browsers and CAs matter too? Browsers and CAs tend to be pretty important and staff big security teams too.
Barely 5% of the internet have DNSSEC signed zones and a big chunk of that are handled by CDN's that do the signing automagically for the domain owner as they also host SOA DNS. Mandating DNSSEC would require years of planning and warning those that have not yet set it up and in my opinion DNSSEC tooling should become a better first class citizen in all of the authoritative DNS daemons. as in there should be so many levels of error handling and validation that it would be next to impossible for anyone to break their zones.
So do we wait for all the stragglers? Wait for the top 500 or top 2500 to make it mandatory? Who takes financial responsibility for those that fell through the cracks?
No CA requires DNSSEC. Obviously they can't: almost nothing is signed. The only change "today" is that technically CAs are now required to honor DNSSEC, where they weren't before.
I think the fact they don't require it shows it's moribund. If cert providers (or google with their big stick of chrome) specified it is required to have DNSSEC to get a certificate, everyone would jump in line and set it up because there'd be no other choice.
I agree that not checking it all is an even worse signal. I'm just saying the fact that this is officially enforced only in 2026 is itself a bad signal. At any rate, the CAs you'd have worked with were enforcing DNSSEC this whole time.
I agree that it's relatively easy for CAs to validate DNSSEC. I think the fact that they weren't technically required to, despite the sole remaining use case for DNSSEC being to protect against misissuance, is a pretty strong indicator of how cooked DNSSEC is.
> If you own and host your own domain, it's probably very easy to have your DNS provider enable DNSSEC for you
It isn't that easy on AWS.
It also generally is not that easy if your domain registrar is not the same as your dns host, because it involves both parties. And some registrers don't have APIs for automatic certificate rotation, so you have to manually rotate the certs periodically.
I have a setup with separated dns and domain since 2021. Using a CSK with unlimited lifetime, I never had to rotate. And could easily also migrate both parts (having a copy of the key material)
Register only has public material
The master is bind9, and any semi-trusted provider can be used as slave/redundency/cdn getting zonetransfers including the RRsigs
> DNSSEC mistakes take your entire domain off the Internet, as if it had never existed.
DNS mistakes take your entire domain off the Internet, as if it had never existed.
I'm preparing a proposal to add an advisory mode for DNSSEC. This will solve a lot of operational issues with its deployment. Enabling it will not have to be a leap of faith anymore.
I haven't had to edit the DNS zones for most of my domains in many years. DNSSEC adds an expiring, rotating key change regime to it. If you screw it up, the screwup is cached everywhere, and the failure mode isn't like HTTPS, where you get an annoying popup: you just get NXDOMAIN, as if your domain never existed.
This isn't so much as a scary story I'm telling so much as it is an empirically observable fact; it's happened many times, to very important domains, over the last several years.
I'm sure you can find several of those using the search bar. The argument has gotten a lot grimmer since 2015 --- DNSSEC lost deployment in North America over the last couple years. It didn't simply plateau off and stop growing: people have started turning it off. That corresponds with the success of CT in the WebPKI, with multi-perspective lookup, with the failure of DANE stapling in tls-wg, and with domain hijacking through registrar fixing.
> By assigning Decentralized Identifiers (like did:tdw or SSH-key DIDs) to individual time servers and managing their state with Key Event Receipt Infrastructure (KERI), we can completely bypass the TLS chicken-and-egg problem where a client needs the correct time to validate a server's certificate.
> To future-proof such a protocol, we can replace heavy certificate chains with stateless hash-based signatures (SPHINCS+, XMSS^MT) paired with lightweight zkSNARKs. If a node is compromised, its identity can be instantly revoked and globally broadcast via Merkle Tree Certificates and DID micro-ledgers, entirely removing DNS from the security dependency chain.
The system described there I think could replace NTP NTS, DNS, DNSSEC, and maybe CA PKI revocation;
PQ with Merkle Tree certificates
Was wondering how long it'd take you to come in and trash talk DNSSEC. And now with added FUD ("and once you press that button it's much less likely that you're going to leave your provider").
This is a topic I obviously pay a lot of attention to. Wouldn't it be weirder if I came here with a different take? What do you expect?
I don't think I'm out on a limb suggesting that random small domains should not enable DNSSEC. There's basically zero upside to it for them. I think there's basically never a good argument to enable it, but at least large, heavily targeted sites have a colorable argument.
Actually I think it probably is suspicious to have the exact same opinion after studying something over a long period of time. My opinions are more likely to remain consistent, rather than growing more nuanced or sophisticated, if all I've done is trot out the same responses over a longer period of time.
I've struggled to think of an especially unexamined example because after all they tend to sit out of conscious recall, I think the best I can do is probably that my favourite comic book character is Miracleman's daughter, Winter Moran. That's a consistent belief I've held for decades, I haven't spent a great deal of time thinking about it, but it's not entirely satisfactory and probably there is some introduced nuance, particularly when I re-examined the contrast between what Winter says about the humans to her father and what her step-sister Mist later says about them to her (human) mother because I was writing an essay during lockdown.
It would make them more secure and less vulnerable to attacks. But lazy sysadmins and large providers are too scared to do anything, in no small part due to your ... incorrect arguments against it.
No it wouldn't? How exactly would it make them more secure? It makes availability drastically more precarious and defends against a rare, exotic attack none of them actually face and which in the main is conducted by state-level adversaries for whom DNSSEC is literally a key escrow system. People are not thinking this through.
That entire post is that you should enable DNSSEC because it's "more secure", and there are no reasons not to.
"More secure" begs the question "against what?", which the blog post doesn't seem to want to go into. Maybe it's secure from hidden tigers.
My favourite DNSSEC "lolwut" is about how people argue that it's something "NIST recommends", whilst at the same time the most recent major DNSSEC outage was......... time.nist.gov! (https://ianix.com/pub/dnssec-outages.html)
You keep waving this blog post from 2015 at me. Not only have we discussed it before, but it was a top-level HN post with 79 comments, many of them from me.
Please don't stealth-edit your posts after I respond to them. If you need to edit, just leave a little note in your comment that you edited it.
Yes it did hit HN and you just said, "I stand by what I wrote." and then complain about buggy implementations and downtime connected to DNSSEC. As if that isn't true for all technologies, let alone /insecure/ DNS. DNS is connected to a lot of downtime because it undergirds the whole internet. Making the distributed database that delegates domain authority cryptographically secure makes everything above it more secure too.
I rebutted your arguments point-by-point. You don't update your blog post to reflect those arguments nor recent developments, like larger key sizes.
That doesn't make it correct. Imagine if someone had said, "We don't need to secure HTTP, we'll just rely on E2E encryption and trust-on-first-use". I would really like it if we had a way to automatically cryptographically verify non-web protocols when they connect.
But there is no money in making that a solution and a TON of money in selling you BS HTTPS certs. There is a lot of people spreading FUD about it. It's a shame.
Mark Shuttleworth paid for his ride to the space station by selling HTTPS certs.
The sad thing is that Mozilla and others have to spend millions bankrolling Let's Encrypt instead of using the free, high assurance PKI that is native to the internet!
It's not really free, though. Rather, the costs are distributed rather than centralized, but running DNSSEC and keeping it working incurs new operational costs for the domain holders, who need to manage keys and DNSSEC signing, etc. And of course there are additional marginal costs to the registrars of managing customer DNSSEC, both building automation and providing customer service when it fails.
It's of course possible that the total numbers are lower than the costs of the WebPKI -- I haven't run them -- but I don't think free is the right word.
You're not providing any explanation for why I wouldn't trust OP on DNSSEC. And the FUD is pretty reasonable if you've had a lot of experience setting up certificate chains, because the chain of trust can fail for a lot of reasons that have nothing to do with your certificate and are sometimes outside of your control. It would really suck to turn it on and have some 3rd-party provider not implement a feature you're relying on for your DNSSEC implementation and then suddenly it doesn't work and nobody can resolve your website anymore. I've had a lot of wonky experiences with different features in EG X.509 that I've come to really mistrust CA-based systems that I'm not in control of. When you get down to interoperability between different software implementations it gets even rougher.
Which is exactly what happened to Slack, and took them offline for most of a business day for a huge fraction of their customers. This is such a big problem that there's actually a subsidiary DNSSEC protocol (DNSSEC NTA's) that addresses it: tactically disabling DNSSEC at major resolvers for the inevitable cases where something breaks.
As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
> As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
Ah yes. Let's take something that's prone to causing service issues and strap more footguns to it.
It's not worth it, because the cost is extremely quantifiable and visible, whereas the benefits struggle to be coherent.
You can add multiple trust anchors to DNSSEC resolvers. Before the "." zone was signed, adding zone-specific anchors was the only way to get DNSSEC working.
Really? You're not concerned that someone might do a very specific kind of on-path DNS cache corruption attack, in 4-5 places simultaneously around the world to defeat multipath lookups at CAs, in order to misissue a certificate for your domain, which they can then leverage in MITM attacks they're somehow able to launch to get random people to think they're looking at your website when they're looking at something else? And that risk doesn't outweigh the fairly strong likelihood that at some point after you enable DNSSEC something will happen to break that configuration and make your entire domain fall off the Internet for several days?
I mean, now you've brought it up, I am concerned about it - but the level of concern is somewhere between "spontaneous combustion of myself leading to exploitation of my domain DNS because my bugger-i-ded.txt instructions are rubbish" and "cosmic rays hitting all the exact right bits at the exact right time to bugger my DNS deployment when I next do one which won't be for a while because even one a year is a fast pace for me to change something."
(Plus I'm perfectly capable of taking my sites and domains offline by incompetent flubbery as it is; I don't need -more- ways to fuck things up.)
It's great to see the free, cryptographically secure, and distributed keyval database that under-grids the entire internet being used to make it more secure. It's too bad lazy sys admins claim that it's not needed and spout a bunch of FUD [1] that is not true [2].
You haven't been a web developer since you posted that article either, since you won't retract silly arguments on your website:
"Government Controlled PKI!"
- Governments own the domains, you just rent them. They can kick your site off and validate their HTTPS certs regardless of DNSSEC.
"Weak Crypto!"
- 1K key sizes were fine given the threat model required cracking one in a year. They have since been increased.
"DNSSEC Doesn’t Protect Against MITM Attacks"
- DNSSEC protects against MITM attacks!
- It's just that most clients don't perform local validation due to low adoption.
- In reality, you are just making the circular argument to NOT adopt DNSSEC because adoption is low.
- There are LOTS more MITM opportunities with HTTPS. We spent a massive effort on cert transparency, yet even Cloudflare missed a rouge cert being issued.
"There are Better Alternatives to DNSSEC"
- There is no alternative to signing domain name data and you point to crypto systems that do something other than that.
- "There are better alternatives to HTTPS: E2E JS crypto with trust on first use"
- What about SSH? I guess we are doomed to run everything over HTTPS and pay dumb cert authorities for the privilege of doing so.
"Bloats record sizes"
- ECC sigs can be sent in a single packet.
- Caching makes first connect latency irrelevant.
On and on and on. These are trivially refutable but you just shut the conversation down and point out instances of downtime ... as if DNS doesn't cause a lot of downtime anyaway.
>We might see a day when HTTPS key pinning and the preload list is implemented across all major browsers, but we will never see these protections applied in a uniform fashion across all major runtime environments (Node.js, Java, .NET, etc.)[...]
You claim in a sibling comment that you have engaged with my points, yet when I talk to you about it you just shut down the conversation.
You really aren't going to respond to any of those points? You stand by your complaint DNSSEC being "government controlled PKI" when TLDs are a government controlled naming system? And your alternative is to advocate for privately owned PKI run by companies with no accountability that are also much more vulnerable to attack?
Campaigning against cryptographically signing DNS records is a weird life choice man.
You're on tilt. It's fine that we disagree about DNSSEC. You seem very angry that you? (it was you, I gather?) wrote a post disagreeing with my post, and I didn't go back and revise my post to capture all the arguments you had that I disagreed with. Sorry, but not sorry. This is just crudding up the thread now though.
If I've said something in this thread that you disagree with, say so and say why (you'll need something better than "I wrote about this 11 years ago and you weren't nice enough to me about it"). Right now, all you're doing is yelling about a post I wrote 11 years ago and haven't cited once on this thread.
Of course, as you know, I stand by that post. But it's not germane to the thread.
True, but DNSSEC doesn't need to worry about forward secrecy and it doesn't need quantum protection until someone can start breaking keys in under a year. Hopefully we will find more efficient PQC by then.
Even if you hate dnssec (and there are many legit criticisms to make) i think it does make sense for CA's to validate it if its there. Its low effort on the CA side, and there isn't really very much downside if its already active.
DNSSEC is one of very few topics where voices I respect on security seem completely opposed (WebPKI depends on DNS vs. DNS security does not matter). Is there any literature that demonstrates deep understanding of both arguments? Why are they (DNSSEC + WebPKI) never considered complimentary?
You'll have to judge for yourself whether this demonstrates deep understanding of both arguments, but I did try to be evenhanded in these posts:
https://educatedguesswork.org/posts/dns-security-dnssec/ https://educatedguesswork.org/posts/dns-security-dane/
From my perspective, the challenge with DNSSEC is that it just doesn't have a very good cost/benefit ratio. Once the WebPKI exists, "critical path" use of DNSSEC only offers modest value. Now, obviously, this article is about requiring CAs to check DNSSEC, which is out of the critical path and of some value, but it's not clear to me it's of enough value to get people to actually roll out DNSSEC.
Bad arguments and FUD when it was being rolled out. Sysadmins also don't want to touch working infra code, you can see that with AWS lagging on IPv6.
Who's the most reputable cryptographer you can think of who publicly supports DNSSEC? We'd like to interview them on SCW.
I enabled DNSSEC a couple of years ago on my self hosted powerdns setup. I sign the zone locally, than build docker containers via SSH on the target nodes.
I made a mistake once and signed with wrong keys which then broke DANE. It‘s good to validate your DNSSEC (and DANE, CAA etc.) setup through external monitoring.
In case the post is fuzzy: what's changed is that as of March 2026, CAs are required to validate DNSSEC if it's enabled when doing DCV or CAA. Previously, it was technically the case that a CA could ignore DNSSEC if you had it set up on your domains, though LetsEncrypt has (as I understand it) been checking DNSSEC pretty much this whole time.
If you own and host your own domain, it's probably very easy to have your DNS provider enable DNSSEC for you, maybe just a button click. They'd sure like you to do that, because DNSSEC is itself quite complicated, and once you press that button it's much less likely that you're going to leave your provider. DNSSEC mistakes take your entire domain off the Internet, as if it had never existed.
There's a research project, started at KU Leuven, that attempts an unbiased "top N" list of most popular domains; it's called the Tranco List. For the last year or so, I've monitored the top 1000 domains on the Tranco list to see which have DNSSEC enabled. You can see that here:
https://dnssecmenot.fly.dev/
There's 2 tl;dr's to this:
First, DNSSEC penetration in the top 1000 is single digits % (dropping sharply, down to 2%, as you scope down to the top 100).
Second, in a year of monitoring and recording every change in DNSSEC state on every domain in this list, I've seen just three Tranco Top 1000 domains change their DNSSEC state, and one of those changes was Canva disabling DNSSEC. (I think, as of a few weeks ago, they've re-enabled it again). Think about that: 1000 very popular domains, and just 0.3% of them thought even a second about DNSSEC.
DNSSEC is moribund.
That’s a fun list, the only hits in the top 100 are actually Cloudflare, for whom automatic DNSSEC is a feature, and would be a bad look not to dogfood it.
(I did a lot of the work of shipping that product in a past life. We had to fight the protocol and sometimes the implementers to beat it into something deployable. I am proud of that work from a technical point of view, but I agree DNSSEC adds little systemic value and haven’t thought about it since moving on from that project almost 10 years ago. It doesn’t look like DNSSEC itself has changed since, either.)
Then a few government sites, which have mandated it. The first hit after those is around #150.
What's your replacement if DNSSEC is moribund?
It seems to me like it actually solves a problem, what is the solution to "I want/need to be able to trust the DNS answer" without DNSSEC?
It seems pretty clear to me that the industry, and particularly the slice of the industry that operates large, important sites and staffs big security teams, doesn't believe this is a meaningful problem at all.
I agree with them.
Would this article not be evidence the part of the industry that makes up the CA/B Forum (i.e. CAs and Browsers) disagree?
Yeah but CAs want to sell you certificates, and browsers compete on their support for those certificates.
The fact that it's 2026 and the CAs are only now getting around to requiring any CA to take DNSSEC, which has in its current form been operational for well over a decade, makes you take DNSSEC more seriously?
Why dodge the question? Clearly they care today, and I live in today.
If we're doing to defer to industry, does only the opinion of website operators matter, or do browsers and CAs matter too? Browsers and CAs tend to be pretty important and staff big security teams too.
Are they requiring DNSSEC in order to acquire the certificate? That would be a better indicator to me that it's not security theater=security
Barely 5% of the internet have DNSSEC signed zones and a big chunk of that are handled by CDN's that do the signing automagically for the domain owner as they also host SOA DNS. Mandating DNSSEC would require years of planning and warning those that have not yet set it up and in my opinion DNSSEC tooling should become a better first class citizen in all of the authoritative DNS daemons. as in there should be so many levels of error handling and validation that it would be next to impossible for anyone to break their zones.
So do we wait for all the stragglers? Wait for the top 500 or top 2500 to make it mandatory? Who takes financial responsibility for those that fell through the cracks?
No CA requires DNSSEC. Obviously they can't: almost nothing is signed. The only change "today" is that technically CAs are now required to honor DNSSEC, where they weren't before.
I think the fact they don't require it shows it's moribund. If cert providers (or google with their big stick of chrome) specified it is required to have DNSSEC to get a certificate, everyone would jump in line and set it up because there'd be no other choice.
I agree that not checking it all is an even worse signal. I'm just saying the fact that this is officially enforced only in 2026 is itself a bad signal. At any rate, the CAs you'd have worked with were enforcing DNSSEC this whole time.
Which is really unfortunate, since it's pretty easy to do.
I agree that it's relatively easy for CAs to validate DNSSEC. I think the fact that they weren't technically required to, despite the sole remaining use case for DNSSEC being to protect against misissuance, is a pretty strong indicator of how cooked DNSSEC is.
It will change as soon as one of them gets meaningfully DNS hijacked.
Zones get meaningfully hijacked all the time. It just doesn't happen through cache poisoning; it happens through phished registrar accounts.
> If you own and host your own domain, it's probably very easy to have your DNS provider enable DNSSEC for you
It isn't that easy on AWS.
It also generally is not that easy if your domain registrar is not the same as your dns host, because it involves both parties. And some registrers don't have APIs for automatic certificate rotation, so you have to manually rotate the certs periodically.
I have a setup with separated dns and domain since 2021. Using a CSK with unlimited lifetime, I never had to rotate. And could easily also migrate both parts (having a copy of the key material)
Register only has public material
The master is bind9, and any semi-trusted provider can be used as slave/redundency/cdn getting zonetransfers including the RRsigs
> DNSSEC mistakes take your entire domain off the Internet, as if it had never existed.
DNS mistakes take your entire domain off the Internet, as if it had never existed.
I'm preparing a proposal to add an advisory mode for DNSSEC. This will solve a lot of operational issues with its deployment. Enabling it will not have to be a leap of faith anymore.
I haven't had to edit the DNS zones for most of my domains in many years. DNSSEC adds an expiring, rotating key change regime to it. If you screw it up, the screwup is cached everywhere, and the failure mode isn't like HTTPS, where you get an annoying popup: you just get NXDOMAIN, as if your domain never existed.
This isn't so much as a scary story I'm telling so much as it is an empirically observable fact; it's happened many times, to very important domains, over the last several years.
> DNSSEC is moribund.
You’ve clearly put a lot of effort into limiting adoption. I’d really value your thoughts on this response to your anti-DNSSEC arguments:
https://easydns.com/blog/2015/08/06/for-dnssec/
I'm sure you can find several of those using the search bar. The argument has gotten a lot grimmer since 2015 --- DNSSEC lost deployment in North America over the last couple years. It didn't simply plateau off and stop growing: people have started turning it off. That corresponds with the success of CT in the WebPKI, with multi-perspective lookup, with the failure of DANE stapling in tls-wg, and with domain hijacking through registrar fixing.
> DNSSEC
And NTP, which is basically a dependency for DNSSEC due to validity intervals too;
From https://news.ycombinator.com/item?id=47270665 :
> By assigning Decentralized Identifiers (like did:tdw or SSH-key DIDs) to individual time servers and managing their state with Key Event Receipt Infrastructure (KERI), we can completely bypass the TLS chicken-and-egg problem where a client needs the correct time to validate a server's certificate.
> To future-proof such a protocol, we can replace heavy certificate chains with stateless hash-based signatures (SPHINCS+, XMSS^MT) paired with lightweight zkSNARKs. If a node is compromised, its identity can be instantly revoked and globally broadcast via Merkle Tree Certificates and DID micro-ledgers, entirely removing DNS from the security dependency chain.
The system described there I think could replace NTP NTS, DNS, DNSSEC, and maybe CA PKI revocation; PQ with Merkle Tree certificates
Was wondering how long it'd take you to come in and trash talk DNSSEC. And now with added FUD ("and once you press that button it's much less likely that you're going to leave your provider").
At least you're consistent.
This is a topic I obviously pay a lot of attention to. Wouldn't it be weirder if I came here with a different take? What do you expect?
I don't think I'm out on a limb suggesting that random small domains should not enable DNSSEC. There's basically zero upside to it for them. I think there's basically never a good argument to enable it, but at least large, heavily targeted sites have a colorable argument.
Actually I think it probably is suspicious to have the exact same opinion after studying something over a long period of time. My opinions are more likely to remain consistent, rather than growing more nuanced or sophisticated, if all I've done is trot out the same responses over a longer period of time.
I've struggled to think of an especially unexamined example because after all they tend to sit out of conscious recall, I think the best I can do is probably that my favourite comic book character is Miracleman's daughter, Winter Moran. That's a consistent belief I've held for decades, I haven't spent a great deal of time thinking about it, but it's not entirely satisfactory and probably there is some introduced nuance, particularly when I re-examined the contrast between what Winter says about the humans to her father and what her step-sister Mist later says about them to her (human) mother because I was writing an essay during lockdown.
> I don't think I'm out on a limb suggesting that random small domains should not enable DNSSEC.
Why? I can see this argument for large domains that might be using things like anycast and/or geography-specific replies. But for smaller domains?
> There's basically zero upside to it for them.
It can reduce susceptibility to automated wormable attacks. Or to BGP-mediated attacks.
It would make them more secure and less vulnerable to attacks. But lazy sysadmins and large providers are too scared to do anything, in no small part due to your ... incorrect arguments against it.
No it wouldn't? How exactly would it make them more secure? It makes availability drastically more precarious and defends against a rare, exotic attack none of them actually face and which in the main is conducted by state-level adversaries for whom DNSSEC is literally a key escrow system. People are not thinking this through.
Boy, how would cryptographically the ROOT of the internet make it more secure? Right here dude: https://easydns.com/blog/2015/08/06/for-dnssec/
That entire post is that you should enable DNSSEC because it's "more secure", and there are no reasons not to.
"More secure" begs the question "against what?", which the blog post doesn't seem to want to go into. Maybe it's secure from hidden tigers.
My favourite DNSSEC "lolwut" is about how people argue that it's something "NIST recommends", whilst at the same time the most recent major DNSSEC outage was......... time.nist.gov! (https://ianix.com/pub/dnssec-outages.html)
You keep waving this blog post from 2015 at me. Not only have we discussed it before, but it was a top-level HN post with 79 comments, many of them from me.
Please don't stealth-edit your posts after I respond to them. If you need to edit, just leave a little note in your comment that you edited it.
Sorry, I thought my edit was fast enough.
Yes it did hit HN and you just said, "I stand by what I wrote." and then complain about buggy implementations and downtime connected to DNSSEC. As if that isn't true for all technologies, let alone /insecure/ DNS. DNS is connected to a lot of downtime because it undergirds the whole internet. Making the distributed database that delegates domain authority cryptographically secure makes everything above it more secure too.
I rebutted your arguments point-by-point. You don't update your blog post to reflect those arguments nor recent developments, like larger key sizes.
Did you write the article?
Its not like its just tptacek with this take, i would say its the majority view in the industry.
That doesn't make it correct. Imagine if someone had said, "We don't need to secure HTTP, we'll just rely on E2E encryption and trust-on-first-use". I would really like it if we had a way to automatically cryptographically verify non-web protocols when they connect.
But there is no money in making that a solution and a TON of money in selling you BS HTTPS certs. There is a lot of people spreading FUD about it. It's a shame.
> But there is no money in making that a solution and a TON of money in selling you BS HTTPS certs
Ah yes, because lets encrypt is rolling in the $$$$.
Mark Shuttleworth paid for his ride to the space station by selling HTTPS certs.
The sad thing is that Mozilla and others have to spend millions bankrolling Let's Encrypt instead of using the free, high assurance PKI that is native to the internet!
It's not really free, though. Rather, the costs are distributed rather than centralized, but running DNSSEC and keeping it working incurs new operational costs for the domain holders, who need to manage keys and DNSSEC signing, etc. And of course there are additional marginal costs to the registrars of managing customer DNSSEC, both building automation and providing customer service when it fails.
It's of course possible that the total numbers are lower than the costs of the WebPKI -- I haven't run them -- but I don't think free is the right word.
Yes, the whole point of LetsEncrypt was to prevent that from happening again, and it now dominates the market.
You're not providing any explanation for why I wouldn't trust OP on DNSSEC. And the FUD is pretty reasonable if you've had a lot of experience setting up certificate chains, because the chain of trust can fail for a lot of reasons that have nothing to do with your certificate and are sometimes outside of your control. It would really suck to turn it on and have some 3rd-party provider not implement a feature you're relying on for your DNSSEC implementation and then suddenly it doesn't work and nobody can resolve your website anymore. I've had a lot of wonky experiences with different features in EG X.509 that I've come to really mistrust CA-based systems that I'm not in control of. When you get down to interoperability between different software implementations it gets even rougher.
Which is exactly what happened to Slack, and took them offline for most of a business day for a huge fraction of their customers. This is such a big problem that there's actually a subsidiary DNSSEC protocol (DNSSEC NTA's) that addresses it: tactically disabling DNSSEC at major resolvers for the inevitable cases where something breaks.
As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
> As if DNS isn't a major contributing to A LOT of downtime. That doesn't mean it's not worth doing not investing in making deployment more seamless and less error prone.
Ah yes. Let's take something that's prone to causing service issues and strap more footguns to it.
It's not worth it, because the cost is extremely quantifiable and visible, whereas the benefits struggle to be coherent.
Is there non-ICANN DNSSEC
Everyone knows "WebPKI", e.g., self-appointed "cert authorities", generally relies on DNS
With an added DNSSEC step, perhaps this is now limited to ICANN DNS only
Self-appointed "cert authorities" checking with self-appointed domainname "authority". A closed system
You can add multiple trust anchors to DNSSEC resolvers. Before the "." zone was signed, adding zone-specific anchors was the only way to get DNSSEC working.
I'm too afraid to turn it on.
Really? You're not concerned that someone might do a very specific kind of on-path DNS cache corruption attack, in 4-5 places simultaneously around the world to defeat multipath lookups at CAs, in order to misissue a certificate for your domain, which they can then leverage in MITM attacks they're somehow able to launch to get random people to think they're looking at your website when they're looking at something else? And that risk doesn't outweigh the fairly strong likelihood that at some point after you enable DNSSEC something will happen to break that configuration and make your entire domain fall off the Internet for several days?
> You're not concerned that someone might do ...
I mean, now you've brought it up, I am concerned about it - but the level of concern is somewhere between "spontaneous combustion of myself leading to exploitation of my domain DNS because my bugger-i-ded.txt instructions are rubbish" and "cosmic rays hitting all the exact right bits at the exact right time to bugger my DNS deployment when I next do one which won't be for a while because even one a year is a fast pace for me to change something."
(Plus I'm perfectly capable of taking my sites and domains offline by incompetent flubbery as it is; I don't need -more- ways to fuck things up.)
> make your entire domain fall off the Internet for several days
Yes, exactly.
Can't tell if sarcasm.
It's sarcasm.
If you handle minimal traffic loads it should be fine.
On a busy site, the incurred additional load cost can bite hard.
A lot of people will leave it off for the same reasons as DoH or DoT. =3
It's great to see the free, cryptographically secure, and distributed keyval database that under-grids the entire internet being used to make it more secure. It's too bad lazy sys admins claim that it's not needed and spout a bunch of FUD [1] that is not true [2].
[1]: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ [2]: https://easydns.com/blog/2015/08/06/for-dnssec/
I hope you will never have to implement DNSSEC
I haven't been a "sysadmin" since 1996.
You haven't been a web developer since you posted that article either, since you won't retract silly arguments on your website:
"Government Controlled PKI!"
- Governments own the domains, you just rent them. They can kick your site off and validate their HTTPS certs regardless of DNSSEC.
"Weak Crypto!"
- 1K key sizes were fine given the threat model required cracking one in a year. They have since been increased.
"DNSSEC Doesn’t Protect Against MITM Attacks"
- DNSSEC protects against MITM attacks!
- It's just that most clients don't perform local validation due to low adoption.
- In reality, you are just making the circular argument to NOT adopt DNSSEC because adoption is low.
- There are LOTS more MITM opportunities with HTTPS. We spent a massive effort on cert transparency, yet even Cloudflare missed a rouge cert being issued.
"There are Better Alternatives to DNSSEC"
- There is no alternative to signing domain name data and you point to crypto systems that do something other than that.
- "There are better alternatives to HTTPS: E2E JS crypto with trust on first use"
- What about SSH? I guess we are doomed to run everything over HTTPS and pay dumb cert authorities for the privilege of doing so.
"Bloats record sizes"
- ECC sigs can be sent in a single packet.
- Caching makes first connect latency irrelevant.
On and on and on. These are trivially refutable but you just shut the conversation down and point out instances of downtime ... as if DNS doesn't cause a lot of downtime anyaway.
>It's just that most clients don't perform local validation due to low adoption.
From your link elsewhere, https://easydns.com/blog/2015/08/06/for-dnssec/
>We might see a day when HTTPS key pinning and the preload list is implemented across all major browsers, but we will never see these protections applied in a uniform fashion across all major runtime environments (Node.js, Java, .NET, etc.)[...]
Is this not the same flaw?
Sir, this is a Wendy's.
You claim in a sibling comment that you have engaged with my points, yet when I talk to you about it you just shut down the conversation.
You really aren't going to respond to any of those points? You stand by your complaint DNSSEC being "government controlled PKI" when TLDs are a government controlled naming system? And your alternative is to advocate for privately owned PKI run by companies with no accountability that are also much more vulnerable to attack?
Campaigning against cryptographically signing DNS records is a weird life choice man.
You're on tilt. It's fine that we disagree about DNSSEC. You seem very angry that you? (it was you, I gather?) wrote a post disagreeing with my post, and I didn't go back and revise my post to capture all the arguments you had that I disagreed with. Sorry, but not sorry. This is just crudding up the thread now though.
If I've said something in this thread that you disagree with, say so and say why (you'll need something better than "I wrote about this 11 years ago and you weren't nice enough to me about it"). Right now, all you're doing is yelling about a post I wrote 11 years ago and haven't cited once on this thread.
Of course, as you know, I stand by that post. But it's not germane to the thread.
> "Bloats record sizes"
> - ECC sigs can be sent in a single packet.
It's 2026. If you're deploying a cryptosystem and not considering post-quantum in your analysis, you'd best have a damn good reason.
ECC signs might be small, but the world will be moving to ML-DSA-44 in the near future. That needs to be in your calculus.
True, but DNSSEC doesn't need to worry about forward secrecy and it doesn't need quantum protection until someone can start breaking keys in under a year. Hopefully we will find more efficient PQC by then.
People tried to move DNSSEC from RSA to ECC more than a decade ago. How'd that migration go? If you like, I can give you APNIC's answer.
RSA is still fine given that you can't break it in a year and we aren't worried about forward secrecy.
Also, I worked for a DNS company. People stopped caring about ulta-low latency first connect times back in the 90s.
You are clearly very proud of your work devaluing DNSSEC. But pointing to lack of adoption doesn't make your arguments valid.