9 ms·

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 wa

by tptacek 8mo ago

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/ 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.

SahAssar 8mo ago
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?
- tptacek 8mo ago
  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.
  - thenewnewguy 8mo ago
    Would this article not be evidence the part of the industry that makes up the CA/B Forum (i.e. CAs and Browsers) disagree?
    - throwway120385 8mo ago
      Yeah but CAs want to sell you certificates, and browsers compete on their support for those certificates.
      - ekr____ 8mo ago
        Huh? They really don't. It's actually kind of unfortunate that browsers don't have uniform policies about what certificates they accept, but for obvious reasons each browser wants to make their own decision.
        kbolino 8mo ago
        They do have uniform policies, those policies come from the aforementioned CA/Browser Forum, which has been issuing its Baseline Requirements for over a decade.
    - tptacek 8mo ago
      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?
      - thenewnewguy 8mo ago
        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.
- gzread 8mo ago
  It will change as soon as one of them gets meaningfully DNS hijacked.
  - tptacek 8mo ago
    Zones get meaningfully hijacked all the time. It just doesn't happen through cache poisoning; it happens through phished registrar accounts.
    - indolering 8mo ago
      Phishing existing isn't a good argument against cryptographically authenticating DNS records.
      - tptacek 8mo ago
        "Phishing existing" isn't the argument. "The dominant vector for actual domain takeover over the last 5 years is phishing" is.
        indolering 8mo ago
        But it also applies to every other part of the stack, including WebPKI. Would you accept this as a valid argument against using HTTPS everywhere?
        tptacek 8mo ago
        I can't even follow your argument anymore. DNSSEC is proposed as a feature to make DCV certificates more difficult to misissue. But DCV misisuance is overwhelmingly caused by registrar ATO. DNSSEC therefore can't address most DCV misissuance. And it has no other mainstream security proposition. That is obviously not a claim you can make of the WebPKI. Your problem here is that the WebPKI is a very large superset of the security capabilities of DNSSEC. Unlike with DNSSEC, people --- millions of them --- actually rely on it.
- toast0 8mo ago
  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)
  - hrmtst93837 8mo ago
    [flagged]
    - tptacek 8mo ago
      If an attacker owns a resolver DNSSEC stops mattering too; from the resolver to the stub-resolver, the protocol collapses down to a single "yes we did DNSSEC" bit in the header. The bigger thing here is DoH, which has very real penetration, and works for zones that don't do anything to opt-in. That's what a good design looks like: it just works without uninvolved people having to do extra stuff. I think DNSSEC supporters, what few of them are left, are really deep into cope about what transport security is doing to the the rationale for DNSSEC deployment. There's nothing about DoH that makes it complicated to speak it to an authority server. The only reason I can see that we're not going to get that is that multi-perspective kills the value proposition of even doing that much.
      - 8mo ago
FiloSottile 8mo ago
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.
dc396 8mo ago
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.
- tptacek 8mo ago
  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.
  - indolering 8mo ago
    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.
    - tptacek 8mo ago
      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.
      - indolering 8mo ago
        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/ https://easydns.com/blog/2015/08/06/for-dnssec/
        tptacek 8mo ago
westurner 8mo ago
> DNSSEC And NTP, which is basically a dependency for DNSSEC due to validity intervals too; From https://news.ycombinator.com/item?id=47270665 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
thayne 8mo ago
> 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.
- kro 8mo ago
  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
  - thayne 8mo ago
    > Using a CSK with unlimited lifetime Well in cases where I have had to deal with DNSSEC, I've had to rotate the KSK annually for compliance reasons.
indolering 8mo ago
> 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/ https://easydns.com/blog/2015/08/06/for-dnssec/
- tptacek 8mo ago
  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.
  - indolering 8mo ago
    No, no, you /refused/ to engage with me when I asked you to address these refutations of your arguments point-by-point. And it's sad that you have helped make weird workarounds more attractive than just doing the work to cryptographically secure how domain names are delegated. It would make the entire stack sitting on top of DNS more secure. Instead we have to have reinvent the wheel for each protocol and outsource security to the TLS certificate vendors. What a waste.
    - tptacek 8mo ago
      I feel pretty confident that the search bar refutes this claim you're making. What you're trying to argue is that I've avoided opportunities to argue about DNSSEC on HN. Seems... unlikely.
      - indolering 8mo ago
        [flagged]
  - gzread 8mo ago
cyberax 8mo ago
> 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.
- tptacek 8mo ago
  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.
  - cyberax 8mo ago
    Your objections basically boil down to: DNS is dangerous, and DNSSEC _is_ DNS. This is fair, but the conclusion for me is that we need to make _DNS_ more reliable. Not to keep treating it as a fragile Ming Dynasty vase. In particular, the long TTL of DNS records itself is a historic artifact and should be phased out. There's absolutely no reason to keep it above ~15 minutes for the leaf zones. The overhead of doing additional DNS lookups is completely negligible. > 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. So has the TLS cert expiration. And while you can (usually) click through it in browsers, it's not the case for mobile apps or for IoT/embedded devices. Or even for JS-rich webapps that use XMLHttpRequest/fetch. And we keep making Internet more fragile with the ".well-known" subtrees that are served over TLS. It's also now trivial for me to get a certificate for most domains if I can MITM their network. Edit: BTW, what is exactly _expiring_ in DNSSEC? I've been using the same private key on my HSM for DNSSEC signing for the last decade. You also can set up signing once, and then never touch it.
    - 8mo ago
alwillis 8mo ago
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. [1]: https://stats.dnssec-tools.org/#/top=tlds https://stats.dnssec-tools.org/#/top=tlds [2]: https://stats.dnssec-tools.org/#/top=dnssec?top=dane&trend_tab=0 https://stats.dnssec-tools.org/#/top=dnssec?top=dane&trend_t...
- tptacek 8mo ago
  Wait, that's not true: * 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.
gucci-on-fleek 8mo ago
> because DNSSEC is itself quite complicated I self-host my own DNS, and enabling DNSSEC was probably the easiest part of the entire process. I had to add 3 lines to my DNS server config, then copy a single value into my registrar, and that was it. > DNSSEC mistakes take your entire domain off the Internet, as if it had never existed Isn't that the same as any DNS mistake though?
- jcgl 8mo ago
  > Isn't that the same as any DNS mistake though? No, only the DNS mistakes that involve zone delegation; if you screw those up, then yes, it's pretty much the same. But most DNS mistakes are scoped to one or a handful of names within a zone. Intra-zone mistakes not only are more narrowly scoped to begin with, but they also use the TTLs that you, the zone admin, control. Whereas inter-zone/delegation mistakes (e.g. NS and DS records) use the cache policy of your parent zone. This is outside of your control as the zone admin, and the TTLs are often longer. So bigger blast-radius with longer-lasting consequences.
  - gucci-on-fleek 8mo ago
    Ah right, I forgot that you can't set the TTL on the DNSSEC records in the registry; my bad. But in theory, you shouldn't need to update your DS records much more often than you update your NS records, although this still means that the initial configuration can be a little risky.
    - jcgl 8mo ago
      > But in theory, you shouldn't need to update your DS records much more often than you update your NS records Maybe? You'd update DS whenever changing your key-signing keys. You'd update your NS records and/or glue records when changing your nameservers and/or their IP addresses respectively. In a parallel world with high DNSSEC adoption and well-oiled key management solutions, you're probably making DS changes far more often than NS changes. NS changes might never even happen after a domain's initial setup.

by tptacek 8mo ago

SahAssar 8mo ago

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?

tptacek 8mo ago
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.
- thenewnewguy 8mo ago
  Would this article not be evidence the part of the industry that makes up the CA/B Forum (i.e. CAs and Browsers) disagree?
  - throwway120385 8mo ago
    Yeah but CAs want to sell you certificates, and browsers compete on their support for those certificates.
    - ekr____ 8mo ago
      Huh? They really don't. It's actually kind of unfortunate that browsers don't have uniform policies about what certificates they accept, but for obvious reasons each browser wants to make their own decision.
      - kbolino 8mo ago
        They do have uniform policies, those policies come from the aforementioned CA/Browser Forum, which has been issuing its Baseline Requirements for over a decade.
  - tptacek 8mo ago
    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?
    - thenewnewguy 8mo ago
      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.
gzread 8mo ago
It will change as soon as one of them gets meaningfully DNS hijacked.
- tptacek 8mo ago
  Zones get meaningfully hijacked all the time. It just doesn't happen through cache poisoning; it happens through phished registrar accounts.
  - indolering 8mo ago
    Phishing existing isn't a good argument against cryptographically authenticating DNS records.
    - tptacek 8mo ago
      "Phishing existing" isn't the argument. "The dominant vector for actual domain takeover over the last 5 years is phishing" is.
      - indolering 8mo ago
        But it also applies to every other part of the stack, including WebPKI. Would you accept this as a valid argument against using HTTPS everywhere?
        tptacek 8mo ago
        I can't even follow your argument anymore. DNSSEC is proposed as a feature to make DCV certificates more difficult to misissue. But DCV misisuance is overwhelmingly caused by registrar ATO. DNSSEC therefore can't address most DCV misissuance. And it has no other mainstream security proposition. That is obviously not a claim you can make of the WebPKI. Your problem here is that the WebPKI is a very large superset of the security capabilities of DNSSEC. Unlike with DNSSEC, people --- millions of them --- actually rely on it.
toast0 8mo ago
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)
- hrmtst93837 8mo ago
  [flagged]
  - tptacek 8mo ago
    If an attacker owns a resolver DNSSEC stops mattering too; from the resolver to the stub-resolver, the protocol collapses down to a single "yes we did DNSSEC" bit in the header. The bigger thing here is DoH, which has very real penetration, and works for zones that don't do anything to opt-in. That's what a good design looks like: it just works without uninvolved people having to do extra stuff. I think DNSSEC supporters, what few of them are left, are really deep into cope about what transport security is doing to the the rationale for DNSSEC deployment. There's nothing about DoH that makes it complicated to speak it to an authority server. The only reason I can see that we're not going to get that is that multi-perspective kills the value proposition of even doing that much.
    - 8mo ago

FiloSottile 8mo ago

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.

dc396 8mo ago

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.

tptacek 8mo ago
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.
- indolering 8mo ago
  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.
  - tptacek 8mo ago
    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.
    - indolering 8mo ago
      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/ https://easydns.com/blog/2015/08/06/for-dnssec/
      - tptacek 8mo ago

westurner 8mo ago

> DNSSEC And NTP, which is basically a dependency for DNSSEC due to validity intervals too; From https://news.ycombinator.com/item?id=47270665 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

thayne 8mo ago

> 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.

kro 8mo ago
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
- thayne 8mo ago
  > Using a CSK with unlimited lifetime Well in cases where I have had to deal with DNSSEC, I've had to rotate the KSK annually for compliance reasons.

indolering 8mo ago

> 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/ https://easydns.com/blog/2015/08/06/for-dnssec/

tptacek 8mo ago
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.
- indolering 8mo ago
  No, no, you /refused/ to engage with me when I asked you to address these refutations of your arguments point-by-point. And it's sad that you have helped make weird workarounds more attractive than just doing the work to cryptographically secure how domain names are delegated. It would make the entire stack sitting on top of DNS more secure. Instead we have to have reinvent the wheel for each protocol and outsource security to the TLS certificate vendors. What a waste.
  - tptacek 8mo ago
    I feel pretty confident that the search bar refutes this claim you're making. What you're trying to argue is that I've avoided opportunities to argue about DNSSEC on HN. Seems... unlikely.
    - indolering 8mo ago
      [flagged]
- gzread 8mo ago

cyberax 8mo ago

> 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.

tptacek 8mo ago
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.
- cyberax 8mo ago
  Your objections basically boil down to: DNS is dangerous, and DNSSEC _is_ DNS. This is fair, but the conclusion for me is that we need to make _DNS_ more reliable. Not to keep treating it as a fragile Ming Dynasty vase. In particular, the long TTL of DNS records itself is a historic artifact and should be phased out. There's absolutely no reason to keep it above ~15 minutes for the leaf zones. The overhead of doing additional DNS lookups is completely negligible. > 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. So has the TLS cert expiration. And while you can (usually) click through it in browsers, it's not the case for mobile apps or for IoT/embedded devices. Or even for JS-rich webapps that use XMLHttpRequest/fetch. And we keep making Internet more fragile with the ".well-known" subtrees that are served over TLS. It's also now trivial for me to get a certificate for most domains if I can MITM their network. Edit: BTW, what is exactly _expiring_ in DNSSEC? I've been using the same private key on my HSM for DNSSEC signing for the last decade. You also can set up signing once, and then never touch it.
  - 8mo ago

alwillis 8mo ago

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. [1]: https://stats.dnssec-tools.org/#/top=tlds https://stats.dnssec-tools.org/#/top=tlds [2]: https://stats.dnssec-tools.org/#/top=dnssec?top=dane&trend_tab=0 https://stats.dnssec-tools.org/#/top=dnssec?top=dane&trend_t...

tptacek 8mo ago
Wait, that's not true: * 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.

gucci-on-fleek 8mo ago

> because DNSSEC is itself quite complicated I self-host my own DNS, and enabling DNSSEC was probably the easiest part of the entire process. I had to add 3 lines to my DNS server config, then copy a single value into my registrar, and that was it. > DNSSEC mistakes take your entire domain off the Internet, as if it had never existed Isn't that the same as any DNS mistake though?

jcgl 8mo ago
> Isn't that the same as any DNS mistake though? No, only the DNS mistakes that involve zone delegation; if you screw those up, then yes, it's pretty much the same. But most DNS mistakes are scoped to one or a handful of names within a zone. Intra-zone mistakes not only are more narrowly scoped to begin with, but they also use the TTLs that you, the zone admin, control. Whereas inter-zone/delegation mistakes (e.g. NS and DS records) use the cache policy of your parent zone. This is outside of your control as the zone admin, and the TTLs are often longer. So bigger blast-radius with longer-lasting consequences.
- gucci-on-fleek 8mo ago
  Ah right, I forgot that you can't set the TTL on the DNSSEC records in the registry; my bad. But in theory, you shouldn't need to update your DS records much more often than you update your NS records, although this still means that the initial configuration can be a little risky.
  - jcgl 8mo ago
    > But in theory, you shouldn't need to update your DS records much more often than you update your NS records Maybe? You'd update DS whenever changing your key-signing keys. You'd update your NS records and/or glue records when changing your nameservers and/or their IP addresses respectively. In a parallel world with high DNSSEC adoption and well-oiled key management solutions, you're probably making DS changes far more often than NS changes. NS changes might never even happen after a domain's initial setup.