9 ms·

Cert Authorities Check for DNSSEC from Today

119 points by zdw 7mo ago

tptacek 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
        Yeah but CAs want to sell you certificates, and browsers compete on their support for those certificates.
        ekr____ 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
    It will change as soon as one of them gets meaningfully DNS hijacked.
    - tptacek 7mo ago
      Zones get meaningfully hijacked all the time. It just doesn't happen through cache poisoning; it happens through phished registrar accounts.
      - indolering 7mo ago
        Phishing existing isn't a good argument against cryptographically authenticating DNS records.
        tptacek 7mo ago
        "Phishing existing" isn't the argument. "The dominant vector for actual domain takeover over the last 5 years is phishing" is.
        indolering 7mo 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 7mo 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 7mo 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 7mo ago
      [flagged]
      - tptacek 7mo 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.
        7mo ago
- FiloSottile 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
- westurner 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
        [flagged]
    - gzread 7mo ago
- cyberax 7mo 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 7mo 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 7mo 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.
      - 7mo ago
- alwillis 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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.
baggy_trough 7mo ago
I'm too afraid to turn it on.
- tptacek 7mo ago
  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?
  - baggy_trough 7mo ago
    > make your entire domain fall off the Internet for several days Yes, exactly.
  - delfinom 7mo ago
    Can't tell if sarcasm.
    - tptacek 7mo ago
      It's sarcasm.
  - zimpenfish 7mo ago
    > 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.)
rmoriz 7mo ago
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.
- nulltrace 7mo ago
  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.
  - gzread 7mo ago
    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)
    - rmoriz 7mo ago
      „Pre-publish“ and „double signature“
  - gucci-on-fleek 7mo ago
    > 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.
indolering 7mo ago
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/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/ [2]: https://easydns.com/blog/2015/08/06/for-dnssec/ https://easydns.com/blog/2015/08/06/for-dnssec/
- tptacek 7mo ago
  I haven't been a "sysadmin" since 1996.
  - indolering 7mo ago
    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.
    - 7mo ago
bawolff 7mo ago
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.
ysnp 7mo ago
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?
- indolering 7mo ago
  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.
  - tptacek 7mo ago
    Who's the most reputable cryptographer you can think of who publicly supports DNSSEC? We'd like to interview them on SCW.
    - indolering 7mo ago
      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?
      - tptacek 7mo ago
        Yes? Lots of them? But also: you didn't answer my question.
        indolering 7mo ago
        Okay, but after this I have to go back to work. 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.
1vuio0pswjnm7 7mo ago
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
- cyberax 7mo ago
  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.
- 1vuio0pswjnm7 7mo ago
  For example, let's say ("hypothetically") that the party seeking the certificate wishes to avoid ICANN and uses a different root zone and a non-ICANN TLD
amluto 7mo ago
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.)
- tptacek 7mo ago
  Yes. WebPKI people have been talking about doing that for a long time. There's a couple different angles you can come up with on it, including things like RDAP to directly query registrars for ownership of a domain, and speaking DoH all the way up to authorities. Presumably the problem is that it just takes for-fucking-ever to make anything happen inside CA/BForum. Case in point: we were all today years old before CA/BForum required CAs to actually use DNSSEC if it's set up.
- gzread 7mo ago
  Basically reinventing DNSSEC?
  - amluto 7mo ago
    Nope. DNSSEC is a complex scheme that is designed to allow queries to be answered with no secrets know to the answering nameserver: everything is signed offline and signed records are served up. My (vague) suggestion is to use a much simpler online scheme with correspondingly lower performance, but to use it only for security-critical queries such as those made by CAs.
    - gzread 7mo ago
      So a whole alternative DNS tree just for verifying domain ownership to CAs? Or would it be the same tree? If it's the same tree why not extend it to all records, all the time?
rishabhjajoriya 7mo ago
[flagged]
- tptacek 7mo ago
  It is absolutely not true that everybody agrees DNSSEC adoption is important. Much of the failure of DNSSEC adoption is operators believing it's not important.
- indolering 7mo ago
  It's a lot like HTTP and every other early internet protocol that existed before the crypto. Everyone agrees that it's a problem but fixing all the existing infra is really hard and expensive.
anesxvito 7mo ago
[flagged]
skissane 7mo ago
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

119 points by zdw 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
      Yeah but CAs want to sell you certificates, and browsers compete on their support for those certificates.
      - ekr____ 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
  It will change as soon as one of them gets meaningfully DNS hijacked.
  - tptacek 7mo ago
    Zones get meaningfully hijacked all the time. It just doesn't happen through cache poisoning; it happens through phished registrar accounts.
    - indolering 7mo ago
      Phishing existing isn't a good argument against cryptographically authenticating DNS records.
      - tptacek 7mo ago
        "Phishing existing" isn't the argument. "The dominant vector for actual domain takeover over the last 5 years is phishing" is.
        indolering 7mo 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 7mo 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 7mo 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 7mo ago
    [flagged]
    - tptacek 7mo 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.
      - 7mo ago
FiloSottile 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
westurner 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo ago
        [flagged]
  - gzread 7mo ago
cyberax 7mo 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 7mo 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 7mo 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.
    - 7mo ago
alwillis 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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 7mo 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.

baggy_trough 7mo ago

I'm too afraid to turn it on.

tptacek 7mo ago
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?
- baggy_trough 7mo ago
  > make your entire domain fall off the Internet for several days Yes, exactly.
- delfinom 7mo ago
  Can't tell if sarcasm.
  - tptacek 7mo ago
    It's sarcasm.
- zimpenfish 7mo ago
  > 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.)

rmoriz 7mo ago

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.

nulltrace 7mo ago
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.
- gzread 7mo ago
  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)
  - rmoriz 7mo ago
    „Pre-publish“ and „double signature“
- gucci-on-fleek 7mo ago
  > 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.

indolering 7mo ago

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/ https://sockpuppet.org/blog/2015/01/15/against-dnssec/ [2]: https://easydns.com/blog/2015/08/06/for-dnssec/ https://easydns.com/blog/2015/08/06/for-dnssec/

tptacek 7mo ago
I haven't been a "sysadmin" since 1996.
- indolering 7mo ago
  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.
  - 7mo ago

bawolff 7mo ago

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.

ysnp 7mo ago

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?

indolering 7mo ago
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.
- tptacek 7mo ago
  Who's the most reputable cryptographer you can think of who publicly supports DNSSEC? We'd like to interview them on SCW.
  - indolering 7mo ago
    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?
    - tptacek 7mo ago
      Yes? Lots of them? But also: you didn't answer my question.
      - indolering 7mo ago
        Okay, but after this I have to go back to work. 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.

1vuio0pswjnm7 7mo ago

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

cyberax 7mo ago
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.
1vuio0pswjnm7 7mo ago
For example, let's say ("hypothetically") that the party seeking the certificate wishes to avoid ICANN and uses a different root zone and a non-ICANN TLD

amluto 7mo ago

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

tptacek 7mo ago
Yes. WebPKI people have been talking about doing that for a long time. There's a couple different angles you can come up with on it, including things like RDAP to directly query registrars for ownership of a domain, and speaking DoH all the way up to authorities. Presumably the problem is that it just takes for-fucking-ever to make anything happen inside CA/BForum. Case in point: we were all today years old before CA/BForum required CAs to actually use DNSSEC if it's set up.
gzread 7mo ago
Basically reinventing DNSSEC?
- amluto 7mo ago
  Nope. DNSSEC is a complex scheme that is designed to allow queries to be answered with no secrets know to the answering nameserver: everything is signed offline and signed records are served up. My (vague) suggestion is to use a much simpler online scheme with correspondingly lower performance, but to use it only for security-critical queries such as those made by CAs.
  - gzread 7mo ago
    So a whole alternative DNS tree just for verifying domain ownership to CAs? Or would it be the same tree? If it's the same tree why not extend it to all records, all the time?

rishabhjajoriya 7mo ago

[flagged]

tptacek 7mo ago
It is absolutely not true that everybody agrees DNSSEC adoption is important. Much of the failure of DNSSEC adoption is operators believing it's not important.
indolering 7mo ago
It's a lot like HTTP and every other early internet protocol that existed before the crypto. Everyone agrees that it's a problem but fixing all the existing infra is really hard and expensive.

anesxvito 7mo ago

[flagged]

skissane 7mo ago

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