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.
It can be used alongside WebPKI. And as someone who is worried about other protocols, it sure would be nice if I could setup DNSSEC for my domain and have clients pick up on that automatically.
I've worked with small businesses and even small technical teams as a DNS consultant specifically.
DNS has only been a source of issues and confusion and not at all related to any requirements, just a form of checkbox implementation.
I do understand it's one of those technologies that are developed due to legitimate requirements, but it flows downstream and people just adopt it without really understanding the simpler solutions or what exactly it's meant to do.
That said if I had ever gotten a bigger client like a TLD registrar or a downstream registrar, then sure I would have had to work with it, but I've only ever had to learn how to uninstall it actually.
1. Need to change IP as soon as possible, but DNS record has huge TTL (e.g. 24h).
2. Client ISP DNS does not resolve my domain and it's absolutely not clear how to proceed from here. I don't have connections in huge ISPs, writing stuff to ISP support is as effective as throwing stones in the lake.
Funnily enough, for both cases, /etc/hosts or its Windows equivalent comes to the rescue.
1. 24 hours is not common at all for A records, it should be between 5 minutes to 60 minutes.
Perhaps you are thinking of NS records, which would only be changed very infrequently, and both the source and target systems should be up so that there's no loss of availability.
2. Never had that, it's more likely that you did something wrong rather it being an ISP issue.
Feel free to send me an email with specifics, the email is in my profile although in a cryptic format to avoid spam.
I'll share a couple of thoughts, but do read EKR's blog first:
- Web PKI is inherently insecure and can't be fixed on its own. The root problem is that the CAs we "trust" can issue certificates without technical controls. The best we can do is ask them to be nice and force them provide a degree of (certificate) transparency to enable monitoring. This is still being worked on. Further, certificates are issued without strong owner authentication, which can be subverted (and is subverted). [3]
- The (very, very) big advantage of Web PKI is that it operates online and supports handshake negotiation. As a result, iteration can happen quickly if people are motivated. A few large players can get together and effect a big change (e.g., X25519MLKEM768). DNSSEC was designed for offline operation and lacks negotiation, which means that everyone has to agree before changes can happen. Example: Kipp Hickman created SSL and Web PKI in 3 months, by himself [1]. DNSSEC took years and years.
- DNSSEC could have been fixed, but Web PKI was "good enough" and the remaining problem wasn't sufficiently critical.
- A few big corporations control this space, and they chose Web PKI.
- A humongous amount of resources has been spent on iterating and improving Web PKI in the last 30 years. So many people configuring certificates, breaking stuff, certificates expiring... we've wasted so much of our collective lives. There is a parallel universe in which encryption keys sit in DNS and, in it, no one has to care about certificate rotation.
- DNSSEC can't ever work end-to-end because of DNS ossification. End-user software (e.g., browsers) can't reliably obtain any new DNS resource records, be it DANE or SVCB/HTTPS.
- The one remaining realistic use for DNSSEC is to bootstrap Web PKI and, possibly, secure server-to-server communication. This is happening, now that CAs are required to validate DNSSEC. This one changes finally makes it possible to configure strong cryptographic validation before certificate issuance. [2]
> DNSSEC could have been fixed, but Web PKI was "good enough" and the remaining problem wasn't sufficiently critical.
People say this about every failed technology. If you have something that could have been fixed at any point in the last 30 years but somehow never has been, usually i suspect its not actually true.
> Further, certificates are issued without strong owner authentication
I dont think DNSSEC would fix this either and quite frankly i dont think its a super important problem to solve.
No, DNSSEC can enforce strong cryptographic validation _today_. Here's how:
1. Configure a CAA record that restricts issuance to two CAs that support locking down issuance to specific customer accounts. For example, Let's Encrypt supports RFC 8657; DigiCert has a proprietary mechanism. After this, you can only issue certificates when you properly authenticate against your selected CAs.
2. Use only ACME validation methods that rely on DNS. Avoiding HTTP-01, for example, ensures that a MITM can't intercept that unencrypted network traffic and approve certificates with key material under their control.
3. Deploy DNSSEC. Your DNS is now cryptographically validated, meaning your CAA records can't be spoofed and the validation methods from step 2 can't be spoofed either.
You know the funny thing about this is that I have talked, relatively recently, to one of the very few cryptographers who was an author on a DNSSEC standard, and they wouldn't work for the interview I want to do --- they're not sold enough on DNSSEC anymore.
The broader answer is: the relevant RFCs weren't authored by cryptography engineers. This was a major problem in the "old" IETF, before the cryptographers "took over" tls-wg and CFRG.
At any rate, the reason I asked in that particular place on the thread was that the preceding comment was attempting to draw a line between "sysadmins" who hate DNSSEC and the serious technologists who like it a lot.
You are going to complain that the key sizes are too small despite the guidelines being updated a long time ago. Then you will argue adoption of larger keys sizes is to low. Then you will argue that we should just not sign domain name authority delegation records at all (i.e. DNSSEC) and that we should abandon shoring up authenticated DNS because there is no adoption.
You have any cryptographers that are satisfied with unauthenticated name server checks?
You got a point: 1k isn't great and of course mainstream cryptographers will advocate for higher. That doesn't change that it's still acceptable within the existing security model nor that better alternatives are available. The cryptographic strength of DNSSEC isn't a limiting factor that fatally dooms the whole project. We have to upgrade the crypto used in large-scale infrastructure all the time!
And yes, uptake of better crypto is poor but I find chicken-and-egg arguments disingenuous when coming from someone who zealously advocates to make it worse. Furthermore, your alternative is no signing of DNS records. Find me a cryptographer who thinks no PKI is a better alternative. I know DJB griped about DNSSEC when proposing DNSCurve, which protects the privacy of the payload but not the intergrity of the payload.
The question was "can you find me some reputable cryptographers that support your position?" which is just ad hominem and should be ignored as such, except it does indicate that the person asking it doesn't have any better argument than ad hominem.
I dont really think it is. The original person claimed that the reason dnssec was unpopular was due to FUD. I think in that context its a fair question to ask what experts think.
For it to be an ad hominem, the person has to claim that the argument is wrong because of who they are. But that is not the claim here. The claim is that their argument that dnssec hate is unjustified FUD is wrong because experts (who presumably by virtue of being experts) are not susciptible to FUD, also do not think dnssec is a good idea. Thus it is directly attacking the argument and not the person, and hence not an ad hominem.
Sorry, but I asked who's the most reputable cryptographer you can think of who publicly supports DNSSEC? I asked because we'd like to interview them on SCW.
More random complaints instead of engaging with the substantive question.
You replied to a two sentence post asking for a name. What do you expect to happen when you do that? If you want to debate the merits, reply anywhere else.
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.
The key rollover part is what kills me about DNSSEC. I deal with key rotation in other contexts and it's already annoying, but at least if I mess up a TLS cert renewal the worst case is a browser warning. DNSSEC KSK rotation goes wrong and your whole domain stops resolving. And the old DS record is cached upstream so there's no quick fix.
> The key rollover part is what kills me about DNSSEC.
Key rollover is completely optional with DNSSEC (unlike with TLS where it's semi-mandatory). All of my domains use infinite lifetime DNSSEC keys, which probably isn't ideal from a security perspective, but it's still much better than no DNSSEC at all.
> but at least if I mess up a TLS cert renewal the worst case is a browser warning.
If you have HSTS enabled (which you probably should), then you're unable to bypass the browser warnings, so if you have a bad TLS certificate, then you'll be completely unable to connect to the website.
At least the error goes away immediately, for everyone, once you fix the cert.
.net seems to serve DS records with at least 18 hours TTL. so worst case it takes your monitoring up 18 hours to notice your record was broken, and then another 18 hours before your fixed record is server everywhere.
Aren't you supposed to keep the old and new KSK records for a while? Sorry if it's a dumb question since I don't regularly do this myself.
Worst case you can put the old records back until you figure out how to generate the new ones correctly, right? (Assuming it's not too close to the expiry time)
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.
Just wanted to add the latest data on DNSSEC [1]. 25 million zones is a drop in the bucket compared to the size of the internet, but it's also not nothing.
| Last updated. | 2026-03-16 05:04 -0700 |
|:--------------------------------------|:-----------------------|
| Total number of DS Records | 25,099,952 |
| Validatable DNSKEY record sets | 24,559,043 |
| Total DANE protected SMTP | 4,165,253 |
There's a graph of the growth of signed zones the past 7 years [2].
I get it that DNSSEC doesn’t make a lot of sense for large organizations with complex networks. that have been around for decades.
But if you're self-hosting a website for your personal use or for a small-ish organization and your registrar supports it (most do), there's no reason not to enable DNSSEC. I did it recently using Cloudflare and it was a single checkbox in the settings.
An estimated more than 90% of ICANN's ~1,400 top-level domains are DNSSEC enabled, so that shouldn't be a barrier.
Since most of us don't have a personal IT department at our disposal, for the small guy, DNSSEC prevents cache poisoning attacks, man-in-the-middle attacks and DNS spoofing. There are other ways to mitigate these attacks of course, but I've found DNSSEC to be pretty straightforward.
* The same reasons not to deploy DNSSEC that face large organizations apply to you: any mistake managing your DNSSEC configuration will take your domain off the Internet (in fact, you'll probably have a harder time recovering than large orgs, who can get Google and Cloudflare on the phone).
* Meanwhile, you get none of the theoretical upside, which in 2026 comes down to making it harder for an on-path attacker to MITM other readers of your site by tricking a CA into misissuing a DCV certificate for you --- an attack that has already gotten significantly harder over the last year due to multiperspective. The reason you don't get this upside is that nobody is going to run this attack on you.
Even if the costs are lower for small orgs (I don't buy it but am willing to stipulate), the upside is practically nonexistent.
"Cache poisoning attacks, man-in-the-middle attacks and DNS spoofing" are all basically the same attack, for what it's worth. DNSSEC attempts to address just a subset of these; most especially MITM attacks, for which there are a huge variety of vectors, only one of which is contemplated by DNSSEC.
Finally, I have to tediously remind you: when you're counting signed domains, it's important to keep in mind that not all zones are equally meaningful. Especially in Europe, plenty of one-off unused domains are signed, because registrars enable it automatically. The figure of merit is how many important zones are signed. Use whichever metric you like, and run in through a bash loop around dig ds +short. You'll find it's a low single-digit percentage.
> The same reasons not to deploy DNSSEC that face large organizations apply to you: any mistake managing your DNSSEC configuration will take your domain off the Internet (in fact, you'll probably have a harder time recovering than large orgs, who can get Google and Cloudflare on the phone).
Set your TTL to five minutes and/or hand over DNS management to a service provider.
> Meanwhile, you get none of the theoretical upside, which in 2026 comes down to making it harder for an on-path attacker to MITM other readers of your site by tricking a CA into misissuing a DCV certificate for you --- an attack that has already gotten significantly harder over the last year due to multiperspective. The reason you don't get this upside is that nobody is going to run this attack on you.
Didn't save Cloudflare from a bad TLS certificate being issued. I still think that reducing the number of bad actors from 300 to the root servers and your registrar is a meaningful reduction in attack surface.
> DNSSEC attempts to address just a subset of these; most especially MITM attacks, for which there are a huge variety of vectors, only one of which is contemplated by DNSSEC.
How would authenticating DNS records cryptographically not address cache poisoning, MITM, and DNS spoofing in relation to DNS lookups? Also, DNSSEC doesn't have to solve all problems to make it worth doing.
> Finally, I have to tediously remind you: when you're counting signed domains, it's important to keep in mind that not all zones are equally meaningful. Especially in Europe, plenty of one-off unused domains are signed, because registrars enable it automatically. The figure of merit is how many important zones are signed. Use whichever metric you like, and run in through a bash loop around dig ds +short. You'll find it's a low single-digit percentage.
Yet you complain about DNSSEC being to hard to deploy and not getting enough deployment. Wouldn't it be nice if they could leverage that automatic signing to also generate TLS, SSH, and other certificates?
> The same reasons not to deploy DNSSEC that face large organizations apply to you: any mistake managing your DNSSEC configuration will take your domain off the Internet (in fact, you'll probably have a harder time recovering than large orgs, who can get Google and Cloudflare on the phone).
There are several mistakes one can make to knock oneself off the Internet that have nothing to do with DNSSEC. These are not the bad old days; compared to 10 years ago, DNSSEC is a lot easier to administer.
If I accidentally yank the power cable out of my load balancer, I can plug it back in and I'm back up and running.
If I cock up my DNSSEC config, nobody can resolve any records under my org's domain (goodbye internal email!) and you've got to twiddle your thumbs for a period of time waiting for various timeouts to pass (go ask Slack how it went for them).
Largely, DNS integrity has been addressed by making it harder to spoof dns responses without visibility.
Resolvers have put in the effort to use most of the range of source ports and all of the range of request ids, as well as mixed caps, so predicting queries is difficult and blind spoofing requires an unreasonable number of packets.
Additionally, commercial DNS services tend to be well connected anycast. This means most queries can be served with a very low round trip time; reducing the spoofing window. Additionally, there's less opportunity to observe requests as they traverse fewer networks and less distance.
Generally, traffic has moved to certificate authenticated protocols. CAs are required to verify domain control from multiple locations, so an attacker asserting domain control would need to do so for the victim as well as multiple other locations in order to get a certificate issued.
Further; if we assume you plan to assert domain control by taking over or MITMing the IP of a DNS server, it seems likely you could do the same for the IP of an application server. DNSSEC doesn't help very much in that case. (DNSSEC with DANE could help in that case, but to a first approximation, nothing supports that, and there doesn't appear to be any movement towards it)
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.
Maybe what DNSSEC needs for it to take off, is for it to be made mandatory for EV certs?
Of course, EV certs aren’t as attractive as they used to be given browser UI changes no longer call them out like they used to. But if we are going to have “extra-verified” certs, it might make sense to mandate a higher level of DNS security for them
Wouldn’t it make more sense to design a new, simple API and glue for doing secure DNS lookups just for certificate issuance? It could look more like dnscurve or even like HTTPS: have a new resource, say NSS, in parallel with NS. To securely traverse to a subdomain, you would query the parent for NSS and, if the record is present, you would learn an IP address and a public key hash or certificate hash that you can query via HTTPS to read the next domain. And this whole spec would say that normal HTTPS clients and OS resolvers SHOULD NOT use it. So if you mess it up, your site doesn’t go offline.
(HTTPS really needs a way to make a URL where the URL itself encodes the keying information.)
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].
259 comments
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.
> Why are they (DNSSEC + WebPKI) never considered complimentary?
WebPKI works without DNSSEC, whereas DANE (a more secure WebPKI replacement) depends on a robust DNSSEC deployment.
I've worked with small businesses and even small technical teams as a DNS consultant specifically.
DNS has only been a source of issues and confusion and not at all related to any requirements, just a form of checkbox implementation.
I do understand it's one of those technologies that are developed due to legitimate requirements, but it flows downstream and people just adopt it without really understanding the simpler solutions or what exactly it's meant to do.
That said if I had ever gotten a bigger client like a TLD registrar or a downstream registrar, then sure I would have had to work with it, but I've only ever had to learn how to uninstall it actually.
1. Need to change IP as soon as possible, but DNS record has huge TTL (e.g. 24h).
2. Client ISP DNS does not resolve my domain and it's absolutely not clear how to proceed from here. I don't have connections in huge ISPs, writing stuff to ISP support is as effective as throwing stones in the lake.
Funnily enough, for both cases, /etc/hosts or its Windows equivalent comes to the rescue.
Perhaps you are thinking of NS records, which would only be changed very infrequently, and both the source and target systems should be up so that there's no loss of availability.
2. Never had that, it's more likely that you did something wrong rather it being an ISP issue.
Feel free to send me an email with specifics, the email is in my profile although in a cryptic format to avoid spam.
- Web PKI is inherently insecure and can't be fixed on its own. The root problem is that the CAs we "trust" can issue certificates without technical controls. The best we can do is ask them to be nice and force them provide a degree of (certificate) transparency to enable monitoring. This is still being worked on. Further, certificates are issued without strong owner authentication, which can be subverted (and is subverted). [3]
- The (very, very) big advantage of Web PKI is that it operates online and supports handshake negotiation. As a result, iteration can happen quickly if people are motivated. A few large players can get together and effect a big change (e.g., X25519MLKEM768). DNSSEC was designed for offline operation and lacks negotiation, which means that everyone has to agree before changes can happen. Example: Kipp Hickman created SSL and Web PKI in 3 months, by himself [1]. DNSSEC took years and years.
- DNSSEC could have been fixed, but Web PKI was "good enough" and the remaining problem wasn't sufficiently critical.
- A few big corporations control this space, and they chose Web PKI.
- A humongous amount of resources has been spent on iterating and improving Web PKI in the last 30 years. So many people configuring certificates, breaking stuff, certificates expiring... we've wasted so much of our collective lives. There is a parallel universe in which encryption keys sit in DNS and, in it, no one has to care about certificate rotation.
- DNSSEC can't ever work end-to-end because of DNS ossification. End-user software (e.g., browsers) can't reliably obtain any new DNS resource records, be it DANE or SVCB/HTTPS.
- The one remaining realistic use for DNSSEC is to bootstrap Web PKI and, possibly, secure server-to-server communication. This is happening, now that CAs are required to validate DNSSEC. This one changes finally makes it possible to configure strong cryptographic validation before certificate issuance. [2]
[1] https://www.feistyduck.com/newsletter/issue_131_the_legend_o...
[2] https://www.feistyduck.com/newsletter/issue_126_internet_pki...
[3] https://redsift.com/guides/a-guide-to-high-assurance-certifi...
>>do read EKR's blog first
If only I knew who EKR is and where his blog is.
EKR is https://educatedguesswork.org/about/
> DNSSEC could have been fixed, but Web PKI was "good enough" and the remaining problem wasn't sufficiently critical.
People say this about every failed technology. If you have something that could have been fixed at any point in the last 30 years but somehow never has been, usually i suspect its not actually true.
> Further, certificates are issued without strong owner authentication
I dont think DNSSEC would fix this either and quite frankly i dont think its a super important problem to solve.
1. Configure a CAA record that restricts issuance to two CAs that support locking down issuance to specific customer accounts. For example, Let's Encrypt supports RFC 8657; DigiCert has a proprietary mechanism. After this, you can only issue certificates when you properly authenticate against your selected CAs.
2. Use only ACME validation methods that rely on DNS. Avoiding HTTP-01, for example, ensures that a MITM can't intercept that unencrypted network traffic and approve certificates with key material under their control.
3. Deploy DNSSEC. Your DNS is now cryptographically validated, meaning your CAA records can't be spoofed and the validation methods from step 2 can't be spoofed either.
The broader answer is: the relevant RFCs weren't authored by cryptography engineers. This was a major problem in the "old" IETF, before the cryptographers "took over" tls-wg and CFRG.
At any rate, the reason I asked in that particular place on the thread was that the preceding comment was attempting to draw a line between "sysadmins" who hate DNSSEC and the serious technologists who like it a lot.
You have any cryptographers that are satisfied with unauthenticated name server checks?
You got a point: 1k isn't great and of course mainstream cryptographers will advocate for higher. That doesn't change that it's still acceptable within the existing security model nor that better alternatives are available. The cryptographic strength of DNSSEC isn't a limiting factor that fatally dooms the whole project. We have to upgrade the crypto used in large-scale infrastructure all the time!
And yes, uptake of better crypto is poor but I find chicken-and-egg arguments disingenuous when coming from someone who zealously advocates to make it worse. Furthermore, your alternative is no signing of DNS records. Find me a cryptographer who thinks no PKI is a better alternative. I know DJB griped about DNSSEC when proposing DNSCurve, which protects the privacy of the payload but not the intergrity of the payload.
And implying that someone is unqualified is not in fact ad hominem. The desire to interview a disagreeing expert doesn't look fake either.
> which is just ad hominem
I dont really think it is. The original person claimed that the reason dnssec was unpopular was due to FUD. I think in that context its a fair question to ask what experts think.
For it to be an ad hominem, the person has to claim that the argument is wrong because of who they are. But that is not the claim here. The claim is that their argument that dnssec hate is unjustified FUD is wrong because experts (who presumably by virtue of being experts) are not susciptible to FUD, also do not think dnssec is a good idea. Thus it is directly attacking the argument and not the person, and hence not an ad hominem.
You replied to a two sentence post asking for a name. What do you expect to happen when you do that? If you want to debate the merits, reply anywhere else.
DNSSEC protects email, webpki does not
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.
> The key rollover part is what kills me about DNSSEC.
Key rollover is completely optional with DNSSEC (unlike with TLS where it's semi-mandatory). All of my domains use infinite lifetime DNSSEC keys, which probably isn't ideal from a security perspective, but it's still much better than no DNSSEC at all.
> but at least if I mess up a TLS cert renewal the worst case is a browser warning.
If you have HSTS enabled (which you probably should), then you're unable to bypass the browser warnings, so if you have a bad TLS certificate, then you'll be completely unable to connect to the website.
.net seems to serve DS records with at least 18 hours TTL. so worst case it takes your monitoring up 18 hours to notice your record was broken, and then another 18 hours before your fixed record is server everywhere.
Worst case you can put the old records back until you figure out how to generate the new ones correctly, right? (Assuming it's not too close to the expiry 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.
(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.
I get it that DNSSEC doesn’t make a lot of sense for large organizations with complex networks. that have been around for decades.
But if you're self-hosting a website for your personal use or for a small-ish organization and your registrar supports it (most do), there's no reason not to enable DNSSEC. I did it recently using Cloudflare and it was a single checkbox in the settings.
An estimated more than 90% of ICANN's ~1,400 top-level domains are DNSSEC enabled, so that shouldn't be a barrier.
Since most of us don't have a personal IT department at our disposal, for the small guy, DNSSEC prevents cache poisoning attacks, man-in-the-middle attacks and DNS spoofing. There are other ways to mitigate these attacks of course, but I've found DNSSEC to be pretty straightforward.
[1]: https://stats.dnssec-tools.org/#/top=tlds
[2]: https://stats.dnssec-tools.org/#/top=dnssec?top=dane&trend_t...
* The same reasons not to deploy DNSSEC that face large organizations apply to you: any mistake managing your DNSSEC configuration will take your domain off the Internet (in fact, you'll probably have a harder time recovering than large orgs, who can get Google and Cloudflare on the phone).
* Meanwhile, you get none of the theoretical upside, which in 2026 comes down to making it harder for an on-path attacker to MITM other readers of your site by tricking a CA into misissuing a DCV certificate for you --- an attack that has already gotten significantly harder over the last year due to multiperspective. The reason you don't get this upside is that nobody is going to run this attack on you.
Even if the costs are lower for small orgs (I don't buy it but am willing to stipulate), the upside is practically nonexistent.
"Cache poisoning attacks, man-in-the-middle attacks and DNS spoofing" are all basically the same attack, for what it's worth. DNSSEC attempts to address just a subset of these; most especially MITM attacks, for which there are a huge variety of vectors, only one of which is contemplated by DNSSEC.
Finally, I have to tediously remind you: when you're counting signed domains, it's important to keep in mind that not all zones are equally meaningful. Especially in Europe, plenty of one-off unused domains are signed, because registrars enable it automatically. The figure of merit is how many important zones are signed. Use whichever metric you like, and run in through a bash loop around
dig ds +short. You'll find it's a low single-digit percentage.> The same reasons not to deploy DNSSEC that face large organizations apply to you: any mistake managing your DNSSEC configuration will take your domain off the Internet (in fact, you'll probably have a harder time recovering than large orgs, who can get Google and Cloudflare on the phone).
Set your TTL to five minutes and/or hand over DNS management to a service provider.
> Meanwhile, you get none of the theoretical upside, which in 2026 comes down to making it harder for an on-path attacker to MITM other readers of your site by tricking a CA into misissuing a DCV certificate for you --- an attack that has already gotten significantly harder over the last year due to multiperspective. The reason you don't get this upside is that nobody is going to run this attack on you.
Didn't save Cloudflare from a bad TLS certificate being issued. I still think that reducing the number of bad actors from 300 to the root servers and your registrar is a meaningful reduction in attack surface.
> DNSSEC attempts to address just a subset of these; most especially MITM attacks, for which there are a huge variety of vectors, only one of which is contemplated by DNSSEC.
How would authenticating DNS records cryptographically not address cache poisoning, MITM, and DNS spoofing in relation to DNS lookups? Also, DNSSEC doesn't have to solve all problems to make it worth doing.
> Finally, I have to tediously remind you: when you're counting signed domains, it's important to keep in mind that not all zones are equally meaningful. Especially in Europe, plenty of one-off unused domains are signed, because registrars enable it automatically. The figure of merit is how many important zones are signed. Use whichever metric you like, and run in through a bash loop around
dig ds +short. You'll find it's a low single-digit percentage.Yet you complain about DNSSEC being to hard to deploy and not getting enough deployment. Wouldn't it be nice if they could leverage that automatic signing to also generate TLS, SSH, and other certificates?
> The same reasons not to deploy DNSSEC that face large organizations apply to you: any mistake managing your DNSSEC configuration will take your domain off the Internet (in fact, you'll probably have a harder time recovering than large orgs, who can get Google and Cloudflare on the phone).
There are several mistakes one can make to knock oneself off the Internet that have nothing to do with DNSSEC. These are not the bad old days; compared to 10 years ago, DNSSEC is a lot easier to administer.
If I cock up my DNSSEC config, nobody can resolve any records under my org's domain (goodbye internal email!) and you've got to twiddle your thumbs for a period of time waiting for various timeouts to pass (go ask Slack how it went for them).
These things are not the same.
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?
Resolvers have put in the effort to use most of the range of source ports and all of the range of request ids, as well as mixed caps, so predicting queries is difficult and blind spoofing requires an unreasonable number of packets.
Additionally, commercial DNS services tend to be well connected anycast. This means most queries can be served with a very low round trip time; reducing the spoofing window. Additionally, there's less opportunity to observe requests as they traverse fewer networks and less distance.
Generally, traffic has moved to certificate authenticated protocols. CAs are required to verify domain control from multiple locations, so an attacker asserting domain control would need to do so for the victim as well as multiple other locations in order to get a certificate issued.
Further; if we assume you plan to assert domain control by taking over or MITMing the IP of a DNS server, it seems likely you could do the same for the IP of an application server. DNSSEC doesn't help very much in that case. (DNSSEC with DANE could help in that case, but to a first approximation, nothing supports that, and there doesn't appear to be any movement towards it)
I agree with them.
Of course, EV certs aren’t as attractive as they used to be given browser UI changes no longer call them out like they used to. But if we are going to have “extra-verified” certs, it might make sense to mandate a higher level of DNS security for them
(HTTPS really needs a way to make a URL where the URL itself encodes the keying information.)
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
[1]: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ [2]: https://easydns.com/blog/2015/08/06/for-dnssec/