[HN Gopher] Cert Authorities Check for DNSSEC from Today
___________________________________________________________________
Cert Authorities Check for DNSSEC from Today
Author : zdw
Score : 76 points
Date : 2026-03-15 22:10 UTC (1 days ago)
(HTM) web link (www.grepular.com)
(TXT) w3m dump (www.grepular.com)
| tptacek wrote:
| In case the post is fuzzy: what's changed is that as of March
| 2026, CAs are required to validate DNSSEC _if it 's enabled_ when
| doing DCV or CAA. Previously, it was technically the case that a
| CA could ignore DNSSEC if you had it set up on your domains,
| though LetsEncrypt has (as I understand it) been checking DNSSEC
| pretty much this whole time.
|
| If you own and host your own domain, it's probably very easy to
| have your DNS provider enable DNSSEC for you, maybe just a button
| click. They'd sure like you to do that, because DNSSEC is itself
| quite complicated, and once you press that button it's much less
| likely that you're going to leave your provider. DNSSEC mistakes
| take your entire domain off the Internet, as if it had never
| existed.
|
| There's a research project, started at KU Leuven, that attempts
| an unbiased "top N" list of most popular domains; it's called the
| Tranco List. For the last year or so, I've monitored the top 1000
| domains on the Tranco list to see which have DNSSEC enabled. You
| can see that here:
|
| https://dnssecmenot.fly.dev/
|
| There's 2 tl;dr's to this:
|
| First, DNSSEC penetration in the top 1000 is single digits %
| (dropping sharply, down to 2%, as you scope down to the top 100).
|
| Second, in a year of monitoring and recording every change in
| DNSSEC state on every domain in this list, I've seen just three
| Tranco Top 1000 domains change their DNSSEC state, and one of
| those changes was Canva disabling DNSSEC. (I think, as of a few
| weeks ago, they've re-enabled it again). Think about that: 1000
| very popular domains, and just 0.3% of them thought even a second
| about DNSSEC.
|
| DNSSEC is moribund.
| SahAssar wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Yeah but CAs want to sell you certificates, and browsers
| compete on their support for those certificates.
| ekr____ wrote:
| 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.
| tptacek wrote:
| 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 wrote:
| 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.
| rstupek wrote:
| Are they requiring DNSSEC in order to acquire the
| certificate? That would be a better indicator to me that
| it's not security theater=security
| tptacek wrote:
| No CA requires DNSSEC. Obviously they can't: almost
| nothing is signed. The only change "today" is that
| technically CAs are now required to honor DNSSEC, where
| they weren't before.
| indolering wrote:
| Which is really unfortunate, since it's pretty easy to
| do.
| tptacek wrote:
| I agree that it's relatively easy for CAs to validate
| DNSSEC. I think the fact that they weren't technically
| required to, despite the sole remaining use case for
| DNSSEC being to protect against misissuance, is a pretty
| strong indicator of how cooked DNSSEC is.
| rstupek wrote:
| I think the fact they don't require it shows it's
| moribund. If cert providers (or google with their big
| stick of chrome) specified it is required to have DNSSEC
| to get a certificate, everyone would jump in line and set
| it up because there'd be no other choice.
| tptacek wrote:
| I agree that not checking it all is an even worse signal.
| I'm just saying the fact that this is officially enforced
| only in 2026 is itself a bad signal. At any rate, the CAs
| you'd have worked with were enforcing DNSSEC this whole
| time.
| Bender wrote:
| Barely 5% of the internet have DNSSEC signed zones and a
| big chunk of that are handled by CDN's that do the
| signing automagically for the domain owner as they also
| host SOA DNS. Mandating DNSSEC would require years of
| planning and warning those that have not yet set it up
| and in my opinion DNSSEC tooling should become a better
| first class citizen in all of the authoritative DNS
| daemons. _as in there should be so many levels of error
| handling and validation that it would be next to
| impossible for anyone to break their zones._
|
| So do we wait for all the stragglers? Wait for the top
| 500 or top 2500 to make it mandatory? Who takes financial
| responsibility for those that fell through the cracks?
| mindslight wrote:
| Big sites don't have the same concerns as individual end
| users, in this case specifically about centralized servers
| surveilling DNS queries.
|
| DNSSEC zone signing lets one resolve records without having
| to directly go through trusted (ie centralizing)
| nameservers. (If you run your own recursive resolver this
| just changes the set of trusted servers to the zones'
| servers).
|
| I've made this argument in the context of your poo-pooing
| DNSSEC before, and I don't expect you to be receptive to it
| this time. Rather I just really wish I could get around to
| writing code to demonstrate what I mean.
| gzread wrote:
| It will change as soon as one of them gets meaningfully DNS
| hijacked.
| tptacek wrote:
| Zones get meaningfully hijacked all the time. It just
| doesn't happen through cache poisoning; it happens through
| phished registrar accounts.
| indolering wrote:
| Phishing existing isn't a good argument against
| cryptographically authenticating DNS records.
| tptacek wrote:
| "Phishing existing" isn't the argument. "The dominant
| vector for actual domain takeover over the last 5 years
| is phishing" is.
| toast0 wrote:
| 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 wrote:
| Port randomization helps against blind spoofing, but once
| an attacker is on-path or owns a resolver, it stops
| mattering.
| tptacek wrote:
| 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.
| amluto wrote:
| > There's nothing about DoH that makes it complicated to
| speak it to an authority server.
|
| There's a problem with HTTPS, though. HTTPS uses URLs
| that use WebPKI to tie the URL to the certificate
| validation algorithm. Which means you need WebPKI
| certificates, which needs DNS. Chicken, meet egg.
|
| Maybe there could be a new URL scheme that doesn't need
| WebPKI. It could be spelled like:
| https_explicit:[key material]//host.name/path
|
| or maybe something slightly crazy and even somewhat
| backwards compatible if the CA/browser people wouldn't
| blow a fuse: https://1.2.3.4.ipv4.[key
| material].explicit_key.net
|
| explicit_key.net would be some appropriate reserved
| domain, and some neutral party (ICANN?) could actually
| register it, expose the appropriate A records and, using
| a trusted and name-constrained intermediate CA, issue
| actual certificates that allow existing browsers to
| validate the key material in the domain name.
| tptacek wrote:
| I think stuff like this is more than promising; I think
| it's likely to happen relatively soon.
| indolering wrote:
| Which is a problem with the OS and browser, not with
| DNSSEC.
| tptacek wrote:
| Eric Rescorla's post, linked upthread, goes into detail
| about why "OS's and browsers" can't easily solve this
| problem without breaking the Internet for materially
| large fractions of their users. In practice, browsers
| that care about DNS security just use DoH.
| FiloSottile wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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/
| tptacek wrote:
| You keep waving this blog post from 2015 at me. Not only
| have we discussed it before, but it was a top-level HN
| post with 79 comments, many of them from me.
|
| Please don't stealth-edit your posts after I respond to
| them. If you need to edit, just leave a little note in
| your comment that you edited it.
| indolering wrote:
| Sorry, I thought my edit was fast enough.
|
| Yes it did hit HN and you just said, "I stand by what I
| wrote." and then complain about buggy implementations and
| downtime connected to DNSSEC. As if that isn't true for
| all technologies, let alone /insecure/ DNS. DNS is
| connected to a lot of downtime because it undergirds the
| whole internet. Making the distributed database that
| delegates domain authority cryptographically secure makes
| everything above it more secure too.
|
| I rebutted your arguments point-by-point. You don't
| update your blog post to reflect those arguments nor
| recent developments, like larger key sizes.
| tptacek wrote:
| Did you write the article?
| indolering wrote:
| Yup.
| tptacek wrote:
| So: I wrote a blog post in January of 2015, and 7 months
| later you wrote a blog post responding to it in August of
| 2015, and 10 years later you're still angry that I didn't
| update my blog post to point to the post that you wrote?
|
| I write things people disagree with all the time. I can't
| recall ever having been mad that people didn't cite me
| for things we disagree about. Should I have expected all
| the people who hated coding agents to update their
| articles when I wrote "My AI Skeptic Friends Are All
| Nuts"? I didn't realize I was supposed to be complaining
| about that.
| indolering wrote:
| I advocate for DNSSEC in my personal life and you happen
| to jump on every DNSSEC HN submission and repeat your
| claims. So I post a link to my article debunking them.
| You won't engage in the substantive points here but
| insist that you have in the past and that you stand by
| your post. So I suggest your update your post to address
| my critiques.
|
| I'm frustrated that you seem to blow me off and insult me
| when I try to engage in good faith discussion, but I'm
| not angry at you. I just ran into this post while
| procrastinating at work and here we are, in the same
| loop.
|
| I think we are both trying to make the internet a safer
| place. It's sad we can't seem to have a productive
| conversation on the matter.
| tptacek wrote:
| I advocate against DNSSEC in my personal life. I write
| about DNSSEC on HN because I write on HN a lot, and
| because this is a topic I have invested a lot of time in,
| going back _long before the existence of HN itself_. You
| can find stuff about it from me on NANOG in the 1990s.
| Your frustration seems like a "you" problem.
| growse wrote:
| That entire post is that you should enable DNSSEC because
| it's "more secure", and there are no reasons not to.
|
| "More secure" begs the question "against what?", which
| the blog post doesn't seem to want to go into. Maybe it's
| secure from hidden tigers.
|
| My favourite DNSSEC "lolwut" is about how people argue
| that it's something "NIST recommends", whilst at the same
| time the most recent major DNSSEC outage was.........
| time.nist.gov! (https://ianix.com/pub/dnssec-
| outages.html)
| tialaramex wrote:
| Actually I think it probably is suspicious to have the
| exact same opinion after studying something over a long
| period of time. My opinions are more likely to remain
| consistent, rather than growing more nuanced or
| sophisticated, if all I've done is trot out the same
| responses over a longer period of time.
|
| I've struggled to think of an especially unexamined example
| because after all they tend to sit out of conscious recall,
| I think the best I can do is probably that my favourite
| comic book character is Miracleman's daughter, Winter
| Moran. That's a consistent belief I've held for decades, I
| haven't spent a great deal of time thinking about it, but
| it's not entirely satisfactory and probably there is some
| introduced nuance, particularly when I re-examined the
| contrast between what Winter says about the humans to her
| father and what her step-sister Mist later says about them
| to her (human) mother because I was writing an essay during
| lockdown.
| cyberax wrote:
| > I don't think I'm out on a limb suggesting that random
| small domains should not enable DNSSEC.
|
| Why? I can see this argument for large domains that might
| be using things like anycast and/or geography-specific
| replies. But for smaller domains?
|
| > There's basically zero upside to it for them.
|
| It can reduce susceptibility to automated wormable attacks.
| Or to BGP-mediated attacks.
| throwway120385 wrote:
| You're not providing any explanation for why I wouldn't trust
| OP on DNSSEC. And the FUD is pretty reasonable if you've had
| a lot of experience setting up certificate chains, because
| the chain of trust can fail for a lot of reasons that have
| nothing to do with your certificate and are sometimes outside
| of your control. It would really suck to turn it on and have
| some 3rd-party provider not implement a feature you're
| relying on for your DNSSEC implementation and then suddenly
| it doesn't work and nobody can resolve your website anymore.
| I've had a lot of wonky experiences with different features
| in EG X.509 that I've come to really mistrust CA-based
| systems that I'm not in control of. When you get down to
| interoperability between different software implementations
| it gets even rougher.
| tptacek wrote:
| Which is exactly what happened to Slack, and took them
| offline for most of a business day for a huge fraction of
| their customers. This is such a big problem that there's
| actually a subsidiary DNSSEC protocol (DNSSEC NTA's) that
| addresses it: tactically disabling DNSSEC at major
| resolvers for the inevitable cases where something breaks.
| indolering wrote:
| As if DNS isn't a major contributing to A LOT of
| downtime. That doesn't mean it's not worth doing not
| investing in making deployment more seamless and less
| error prone.
| growse wrote:
| > As if DNS isn't a major contributing to A LOT of
| downtime. That doesn't mean it's not worth doing not
| investing in making deployment more seamless and less
| error prone.
|
| Ah yes. Let's take something that's prone to causing
| service issues and strap more footguns to it.
|
| It's not worth it, because the cost is extremely
| quantifiable and visible, whereas the benefits struggle
| to be coherent.
| indolering wrote:
| The benefits are huge: there are lots of attacks that
| DNSSEC trivially prevents and it would help secure more
| than just web browsers.
| ekr____ wrote:
| Can you expand on this a bit, under the assumption that
| the traffic is using some form of transport security
| (e.g., TLS, SSH, etc.)?
| indolering wrote:
| DNS underlies domain authority and the validity of
| _every_ connection to _every_ domain name ultimately
| traces back to DNS records. The amount of infra needed to
| shore up HTTPS is huge and thus SSH and other protocols
| rely on trust-on-first-use (unless you manually hard-code
| public keys yourself - which doesn 't happen). DNS offers
| a standard, delegable PKI that is available to all
| clients regardless of the transport protocol.
|
| With DNSSEC, a host with control over a domain's DNS
| records could use that to issue verifiable public keys
| without having to contact a third party.
|
| I ran into this while working on decentralized web
| technologies and building a parallel to WebPKI just
| wasn't feasible. Whereas we could totally feed clients
| DNSSEC validated certs, but it wasn't supported.
| ekr____ wrote:
| Thanks for the explanation. It seems like there are two
| cases here:
|
| 1. Things that use TLS and hence the WebPKI 2. Other
| things.
|
| None of what you've written here applies to the TLS and
| WebPKI case, so I'm going to take it that you're not
| arguing that DNSSEC validation by clients provides a
| security improvement in that case.
|
| That leaves us with the non-WebPKI cases like SSH. I
| think you've got a somewhat stronger case there, but not
| much of one, because those cases can _also_ basically go
| back to the WebPKI, either directly, by using WebPKI-
| based certificates, or indirectly, by hosting
| fingerprints on a Web server.
| tptacek wrote:
| In practice, fleet operators run their own PKIs for SSH,
| so tying them to the DNSSEC PKI is a strict step
| backwards for SSH security.
|
| There may be other applications where a global public PKI
| makes sense; presumably those applications will be
| characterized by the need to make frequent introductions
| between unrelated parties, which is distinctly not an
| attribute of the SSH problem.
| indolering wrote:
| And for everyone else that just wants to connect to an
| SSH session without having to setup PKI themselves? Tying
| that to the records used to find the domain seems like
| the obvious place to put that information to me!
|
| DNSSEC lets you delegate a subtree in the namespace to a
| given public key. You can hardcode your DNSSEC signing
| key for clients too.
|
| Don't get me started on how badly VPN PKI is handled....
| tptacek wrote:
| Yes, modern fleetwide SSH PKIs all do this; what you're
| describing is table stakes and doesn't involve anybody
| delegating any part of their security to a global PKI run
| by other organizations.
|
| The WebPKI and DNSSEC run global PKIs because they
| routinely introduce untrusting strangers to each other.
| That's precisely _not_ the SSH problem. Anything you do
| to bring up a new physical (or virtual) involves
| installing trust anchors on it; if you 're in that
| position already, it actually harms security to have it
| trust a global public PKI.
|
| The arguments for things like SSHFP and SSH-via-DNSSEC
| are really telling. It's like arguing that code signing
| certificates should be in the DNS PKI.
| indolering wrote:
| DNSSEC PKI does not preclude one from hardcoding specific
| keys in the client as well.
|
| Providing global PKI and enabling end-to-end
| authentication by default for all clients and protocols
| certainly would make the internet a safer place.
| tptacek wrote:
| So now we're running two PKIs? What does the second one
| do? Why not three?
| indolering wrote:
| > None of what you've written here applies to the TLS and
| WebPKI case, so I'm going to take it that you're not
| arguing that DNSSEC validation by clients provides a
| security improvement in that case.
|
| It would benefit the likes of Wikileaks. You could do all
| the crypto in your basement with an HSM without involving
| anyone else.
|
| > That leaves us with the non-WebPKI cases like SSH. I
| think you've got a somewhat stronger case there, but not
| much of one, because those cases can also basically go
| back to the WebPKI, either directly, by using WebPKI-
| based certificates, or indirectly, by hosting
| fingerprints on a Web server.
|
| But do they? That requires adding support for another
| protocol.
|
| I would like to live in a world where I don't have to
| copy/paste SSH keys from an AWS console just to have the
| piece-of-mind that my SSH connection hasn't been
| hijacked.
| twelvedogs wrote:
| The difference is DNS provides a fairly obvious up side
| bawolff wrote:
| Its not like its just tptacek with this take, i would say its
| the majority view in the industry.
| indolering wrote:
| That doesn't make it correct. Imagine if someone had said,
| "We don't need to secure HTTP, we'll just rely on E2E
| encryption and trust-on-first-use". I would really like it
| if we had a way to automatically cryptographically verify
| non-web protocols when they connect.
|
| But there is no money in making that a solution and a TON
| of money in selling you BS HTTPS certs. There is a lot of
| people spreading FUD about it. It's a shame.
| bawolff wrote:
| > But there is no money in making that a solution and a
| TON of money in selling you BS HTTPS certs
|
| Ah yes, because lets encrypt is rolling in the $$$$.
| indolering wrote:
| Mark Shuttleworth paid for his ride to the space station
| by selling HTTPS certs.
|
| The sad thing is that Mozilla and others have to spend
| millions bankrolling Let's Encrypt instead of using the
| free, high assurance PKI that is native to the internet!
| tptacek wrote:
| Yes, the whole point of LetsEncrypt was to prevent that
| from happening again, and it now dominates the market.
| ekr____ wrote:
| It's not really free, though. Rather, the costs are
| distributed rather than centralized, but running DNSSEC
| and keeping it working incurs new operational costs for
| the domain holders, who need to manage keys and DNSSEC
| signing, etc. And of course there are additional marginal
| costs to the registrars of managing customer DNSSEC, both
| building automation and providing customer service when
| it fails.
|
| It's of course possible that the total numbers are lower
| than the costs of the WebPKI -- I haven't run them -- but
| I don't think free is the right word.
| indolering wrote:
| I mean, I guess the costs are paid for by the domain name
| fee. But at least it doesn't have to be a charitable
| activity covered by non-profits. The early HTTPS certs
| were especially worthless and price-gouging.
| ekr____ wrote:
| > But at least it doesn't have to be a charitable
| activity covered by non-profits.
|
| LE isn't primarily funded by non-profits, as you can see
| from the sponsor list here: https://isrg.org/sponsors/
|
| Anyway, I think there's a reasonable case that it would
| be better to have the costs distributed the way DNSSEC
| does, but my point is just that it's not free. Rather,
| you're moving the costs around. Like I said, it may be
| cheaper in aggregate, but I think you'd need to make that
| case.
| indolering wrote:
| > LE isn't primarily funded by non-profits, as you can
| see from the sponsor list here:
| https://isrg.org/sponsors/
|
| I mean, Mozilla got the ball rolling and it's still run
| on donations (even if they come from private actors).
|
| > Like I said, it may be cheaper in aggregate, but I
| think you'd need to make that case.
|
| The PKI is already there: we have 7 people who can do a
| multisig for new root keys. There is a signing ceremony
| in a secure bunker somewhere that gets live streamed. The
| HSMs and servers are already paid for. Cert
| transparency/monitoring is nice but now it's hard-coded
| to HTTPS instead of being done more generically. There's
| a lot of duplicated effort.
| ekr____ wrote:
| > > LE isn't primarily funded by non-profits, as you can
| see from the sponsor list here:
| https://isrg.org/sponsors/ > > I mean, Mozilla got the
| ball rolling
|
| Among others: Let's Encrypt was created
| through the merging of two simultaneous efforts to
| build a fully automated certificate authority. In 2012, a
| group led by Alex Halderman at the University of Michigan
| and Peter Eckersley at EFF was developing a
| protocol for automatically issuing and renewing
| certificates. Simultaneously, a team at Mozilla led
| by Josh Aas and Eric Rescorla was working on creating a
| free and automated certificate authority. The
| groups learned of each other's efforts and joined
| forces in May 2013. ... Initially,
| ISRG was funded almost entirely through large dona-
| tions from technology companies. In late 2014, it secured
| financial commitments from Akamai, Cisco, EFF, and
| Mozilla, allowing the organization to purchase
| equipment, secure hosting contracts, and pay
| initial staff. Today, ISRG has more diverse funding
| sources; in 2018 it received 83% of its funding
| from corporate sponsors, 14% from grants and major
| gifts, and 3% from individual giving.
|
| Except for the period before the launch when Mozilla and
| EFF were paying people's salaries, including mine, it was
| never really the case that Let's Encrypt was primarily
| funded by non-profits.
|
| > and it's still run on donations (even if they come from
| private actors).
|
| I agree, but I think it's important to be precise about
| what's happening here, and like I said, it's never been
| the case that LE was really funded by non-profits.
|
| > > Like I said, it may be cheaper in aggregate, but I
| think you'd need to make that case. > > The PKI is
| already there: we have 7 people who can do a multisig for
| new root keys. There is a signing ceremony in a secure
| bunker somewhere that gets live streamed. The HSMs and
| servers are already paid for. Cert
| transparency/monitoring is nice but now it's hard-coded
| to HTTPS instead of being done more generically. There's
| a lot of duplicated effort.
|
| I think this is a category error. The main operational
| cost for DNSSEC is not really the root, which is
| comparatively low load, but rather the distributed
| operations for every registry/registrar, and server to
| register keys, sign domains, etc.
|
| One way to think about this is that running a TLD with
| DNSSEC is conceptually similar to operating a CA in that
| you have to take in everyone's keys and sign them. It's
| true you don't need to validate their domains, but that's
| not the expensive part. Operating this machinery isn't
| free, especially when you have to handle exceptional
| cases like people who screw up their domains and need
| manual help to recover. Now, it's possible that it's a
| marginal incremental cost, but I doubt it's zero.
| Upthread, you suggested that people are already paying
| for this in their domain registrations, but that just
| means that the TLD operator is going to have to absorb
| the incremental cost.
| westurner wrote:
| > _DNSSEC_
|
| And NTP, which is basically a dependency for DNSSEC due to
| validity intervals too;
|
| From https://news.ycombinator.com/item?id=47270665 :
|
| > _By assigning Decentralized Identifiers (like did:tdw or SSH-
| key DIDs) to individual time servers and managing their state
| with Key Event Receipt Infrastructure (KERI), we can completely
| bypass the TLS chicken-and-egg problem where a client needs the
| correct time to validate a server 's certificate._
|
| > _To future-proof such a protocol, we can replace heavy
| certificate chains with stateless hash-based signatures
| (SPHINCS+, XMSS^MT) paired with lightweight zkSNARKs. If a node
| is compromised, its identity can be instantly revoked and
| globally broadcast via Merkle Tree Certificates and DID micro-
| ledgers, entirely removing DNS from the security dependency
| chain._
|
| The system described there I think could replace NTP NTS, DNS,
| DNSSEC, and maybe CA PKI revocation; PQ with Merkle Tree
| certificates
| thayne wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| > 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/
| tptacek wrote:
| 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.
| cyberax wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| tptacek wrote:
| This drills into the core problem: technologists like you
| look at DNSSEC and say "there is a problem, something
| must be done, this is something". But it's not enough to
| identify a problem and solution. The solution has to be
| worth the cost. Rollout can't be more costly than the
| original problem.
|
| There's ample evidence that the cost/benefit math simply
| doesn't work out for DNSSEC.
|
| You can design new DNSSECs with different cost profiles.
| I think a problem you'll run into is that the cost of the
| problem it solves is very low, so you won't have much
| headroom to maneuver in. But I'm not reflexively against
| ground-up retakes on DNSSEC.
|
| Where you'll see viscerally negative takes from me is on
| attempts to take the current gravely flawed design ---
| offline signers+authenticated denial --- as a basis for
| those new solutions. The DNSSEC we're working with now
| has failed in the marketplace. In fact, it's failed more
| comprehensively than any IETF technology ever attempted:
| DNSSEC dates back into the early-mid 1990s. It's long
| past time to cut bait.
| ekr____ wrote:
| > In fact, it's failed more comprehensively than any IETF
| technology ever attempted
|
| Now here is where I disagree. Just off the top of my
| head, how about HIP, IP multicast and PEM?
| tptacek wrote:
| PEM actually gets used? People depend on it? It hasn't
| been a market success, but if the root keys for DNSSEC
| ended up on Pastebin this evening, almost nobody would
| need to be paged, and you can't say that about PEM.
|
| Multicast gets used (I think unwisely) in
| campus/datacenter scenarios. Interdomain multicast was a
| total failure, but interdomain multicast is more recent
| than DNSSEC.
|
| HIP is mid-aughts, isn't it?
| ekr____ wrote:
| Fair enough on Multicast and HIP. I'm less sure about the
| case for PEM.
|
| S-HTTP was a bigger failure in absolute terms (I should
| know!) but it was eventually published as Experimental
| and the IETF never really pushed it, so I don't think you
| could argue it was a bigger failure overall.
| tptacek wrote:
| There really has been a 30+ year full-court press to make
| DNSSEC happen, including high-effort coordination with
| both operators and developers. I think the only
| comparable effort might be IPv6. But IPv6 is succeeding
| (slowly), and DNSSEC seems to have finally failed.
|
| (I hate to IETFsplain anything to you so think of this as
| me baiting you into correcting me.)
| ekr____ wrote:
| Oh, I was basically agreeing with you.
|
| To really nerd out about it, it seems to me there are two
| metrics.
|
| 1. How much it failed (i.e., how low adoption was). 2.
| How much effort the IETF and others put into selling it.
|
| From that perspective, I think DNSSEC is the clear
| winner. There are other IETF protocols that have less
| usage, but none that have had anywhere near the amount of
| thrust applied as DNSSEC.
| cyberax wrote:
| > There's ample evidence that the cost/benefit math
| simply doesn't work out for DNSSEC.
|
| Why? What is the real difference between DNSSEC and
| HTTPS?
|
| I'd argue that the only difference is that browser
| vendors care about protecting against MITM on the client
| side. They're fine with MITM on the server side or with
| (potentially state-sponsored) BGP prefix hijacks. And I'm
| not fine with that personally.
|
| > Where you'll see viscerally negative takes from me is
| on attempts to take the current gravely flawed design ---
| offline signers+authenticated denial --- as a basis for
| those new solutions.
|
| Yes, I agree with that. In particular, NSEC3 was a huge
| mistake, along with the complexity it added.
|
| I think that we should have stuck with NSEC for the cases
| where enumeration is OK or with a "black lies"-like
| approach and online signing. It's also ironic because now
| many companies proactively publish all their internal
| names in the CT logs, so attackers don't even need to
| interact with the target's DNS to find out all its
| internal names.
|
| > In fact, it's failed more comprehensively than any IETF
| technology ever attempted: DNSSEC dates back into the
| early-mid 1990s. It's long past time to cut bait.
|
| I would say that IPv6 failed even more. It's also unfair
| to say that DNSSEC dates back to the 90-s, the root zone
| was signed only in 2008.
|
| The good news is that DNSSEC can be improved a lot by
| just deprecating bad practices. And this will improve DNS
| robustness in general, regardless of DNSSEC use.
| tptacek wrote:
| Seriously? I'll give you two differences right off the
| bat:
|
| 1. DNSSEC only protects the name lookup for a host, and
| TLS/HTTPS protects the entire session.
|
| 2. People actually rely on TLS/HTTPS, and nobody relies
| on DNSSEC, to the point where the root keys for DNSSEC
| could be posted on Pastebin tonight and almost nobody
| would have to be paged. If the private key for a CA in
| any mainstream browser root program got published that
| way, it would be all hands on deck across the whole
| industry.
| indolering wrote:
| > DNSSEC only protects the name lookup for a host, and
| TLS/HTTPS protects the entire session.
|
| It only provides privacy, it doesn't verify that the
| resolver didn't tamper with the record.
|
| >to the point where the root keys for DNSSEC could be
| posted on Pastebin tonight and almost nobody would have
| to be paged.
|
| This would very much be a major issue and lots of people
| would immediately scramble to address it. The root
| servers are very highly audited and there is an absurd
| amount of protocol and oversight of the process.
| tptacek wrote:
| Who? Outside of DNS providers, which organizations would
| need an emergency response to the collapse of DNSSEC
| security? Be specific; name one. If TLS security
| collapsed, I could pick a company from the Fortune 1000
| at random, and they'd have an emergency response going.
| indolering wrote:
| If DNS PKI is compromised, so is HTTPS. So yes, they
| would be scrambling too.
| tptacek wrote:
| This is obviously not true.
| indolering wrote:
| DNS is where domain name authority is delegated. Anything
| you build on top of that is also going to be a world of
| hurt if it gets compromised.
| cyberax wrote:
| DNSSEC can be trivially used with DANE to protect the
| entire session. The browser vendors quite consciously
| decided to NOT do that.
|
| > 2. People actually rely on TLS/HTTPS, and nobody relies
| on DNSSEC
|
| Sure. But I treat it as a failing of the overall
| ecosystem rather than just the technical failure of
| DNSSEC. It's not the _best_ technology, but it's also no
| worse than many others.
|
| This is the outcome of browser vendors not caring at all
| about privacy and security. Step back and look at the
| current TLS infrastructure from the viewpoint of somebody
| in the 90-s:
|
| You're saying that to provide service for anything over
| the Web, you have to publish all your DNS names in a
| globally distributed immutable log that will be preserved
| for all eternity? And that you can't even have a purely
| static website anymore because you need to update the TLS
| cert every 7 days? This is just some crazy talk!
|
| (yes, you technically can get a wildcard cert, but it
| requires ...drumroll... messing with the DNS)
|
| The amount of just plain brokenness and centralization in
| TLS is mind-boggling, but we somehow just deal with it
| without even noticing it anymore. Because browser vendors
| were able to apply sufficient thrust to that pig.
| ekr____ wrote:
| > I'd argue that the only difference is that browser
| vendors care about protecting against MITM on the client
| side. They're fine with MITM on the server side or with
| (potentially state-sponsored) BGP prefix hijacks. And I'm
| not fine with that personally.
|
| Speaking as someone who was formerly responsible for
| deciding what a browser vendor cared about in this area,
| I don't think this is quite accurate. What browser
| vendors care about is that the traffic is securely
| conveyed to and from the server that the origin wanted it
| to be conveyed to. So yes, they definitely do care about
| active attack between the client and the server, but
| that's not the only thing.
|
| To take the two examples you cite, they do care about BGP
| prefix hijacks. It's not generally the browser's job to
| do something about it directly, but in general
| misissuance of all stripes is one of the motivations for
| Certificate Transparency, and of course the BRs now
| require multi-perspective validation.
|
| I'm not sure precisely what you mean by "MITM on the
| server side". Perhaps you're referring to CDNs which TLS
| terminate and then connect to the origin? If so, you're
| right that browser vendors aren't trying to stop this,
| because it's not the business of the browser how the
| origin organizes its infrastructure. I would note that
| DNSSEC does nothing to stop this either because the whole
| concept is the origin wants it.
| daneel_w wrote:
| I run DNSSEC (to facilitate DANE) and with regards to
| DNSSEC I haven't had to manually edit my zones in years
| either. Unlike yourself I don't consider DNSSEC deployment
| or ZSK rotation / KSK roll-over scary or complex, and
| seeing an adept technician dole out warnings on the level
| of "don't run with scissors" is pretty peculiar.
| indolering wrote:
| HTTPS also has expiring keys that also need to be
| rotated. Most people outsource this to a service provider
| for them - as is the case with DNS. It's weird how people
| gripe about standard cryptography/PKI when it comes to
| DNSSEC but not HTTPS.
| baggy_trough wrote:
| I'm too afraid to turn it on.
| tptacek wrote:
| 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 wrote:
| > make your entire domain fall off the Internet for several
| days
|
| Yes, exactly.
| delfinom wrote:
| Can't tell if sarcasm.
| tptacek wrote:
| It's sarcasm.
| zimpenfish wrote:
| > 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.)
| Joel_Mckay wrote:
| It is not like some cheeky kids would just DDoS the signing
| authority itself, or hammer bleed the host TLS library yet
| again.
|
| There are also good reasons many serious admins don't trust
| signing authorities. If you know... you know why... =3
| Joel_Mckay wrote:
| If you handle minimal traffic loads it should be fine.
|
| On a busy site, the incurred additional load cost can bite
| hard.
|
| A lot of people will leave it off for the same reasons as DoH
| or DoT. =3
| rmoriz wrote:
| 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 wrote:
| 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.
| indolering wrote:
| It's great to see the free, cryptographically secure, and
| distributed keyval database that under-grids the entire internet
| being used to make it more secure. It's too bad lazy sys admins
| claim that it's not needed and spout a bunch of FUD [1] that is
| not true [2].
|
| [1]: https://sockpuppet.org/blog/2015/01/15/against-dnssec/ [2]:
| https://easydns.com/blog/2015/08/06/for-dnssec/
| tptacek wrote:
| I haven't been a "sysadmin" since 1996.
| indolering wrote:
| 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.
| some_furry wrote:
| > "Bloats record sizes"
|
| > - ECC sigs can be sent in a single packet.
|
| It's 2026. If you're deploying a cryptosystem and not
| considering post-quantum in your analysis, you'd best have
| a damn good reason.
|
| ECC signs might be small, but the world will be moving to
| ML-DSA-44 in the near future. That needs to be in your
| calculus.
| indolering wrote:
| True, but DNSSEC doesn't need to worry about forward
| secrecy and it doesn't need quantum protection until
| someone can start breaking keys in under a year.
| Hopefully we will find more efficient PQC by then.
| tptacek wrote:
| People tried to move DNSSEC from RSA to ECC more than a
| decade ago. How'd that migration go? If you like, I can
| give you APNIC's answer.
| indolering wrote:
| RSA is still fine given that you can't break it in a year
| and we aren't worried about forward secrecy.
|
| Also, I worked for a DNS company. People stopped caring
| about ulta-low latency first connect times back in the
| 90s.
|
| You are clearly very proud of your work devaluing DNSSEC.
| But pointing to lack of adoption doesn't make your
| arguments valid.
| tptacek wrote:
| I don't know about "valid". "Correct", maybe?
| "Prescient"?
| ekr____ wrote:
| > People stopped caring about ulta-low latency first
| connect times back in the 90s.
|
| They did? That's certainly going to be news to the people
| at Google, Mozilla, Cloudflare, etc. who put enormous
| amounts of effort into building 0-RTT into TLS 1.3 and
| QUIC.
| indolering wrote:
| I did a large data analysis of DNS caching times across
| the web. Hyperscalers are the only ones who care and they
| fix that with insanely long DNS caching.
| ekr____ wrote:
| I'm not trying to just nitpick you here, but, the message
| I was responding to said "People stopped caring about
| ulta-low latency first connect times back in the 90s.".
|
| It seems to me that you're saying here that (1) the
| hyperscalers do care but (2) it's under control. I'm not
| necessarily arguing with (2) but as far as the
| hyperscalers go: (1) they drive a lot of traffic on their
| own (2) in many cases they care so their users don't have
| to.
| indolering wrote:
| Sorry, the point I was trying to make is that this isn't
| a problem operationally.
|
| Hyperscalers go to crazy lengths because they can measure
| monetary losses due to milliseconds of less view time and
| it's much easier when they have distributed cloud
| infrastructure anyway. But it's not really solving a
| _problem_ for their customers. At least when I worked in
| DNS land ... latency micro-benchmarking was something of
| a joke. Like, sure, you _can_ shave off a few tens of
| milliseconds, but it 's super expensive. If you want to
| reduce latency, just up your TTL times and/or enable pre-
| fetching.
|
| As a blocker for DNSSEC ... people made arguments about
| HTTPS overhead back in the day too. DoH also introduces
| latency, yet people aren't worried about that being a
| deal killer.
| ekr____ wrote:
| > As a blocker for DNSSEC ... people made arguments about
| HTTPS overhead back in the day too.
|
| They did, and then we spent an enormous amount of time to
| shave off a few round trip times in TLS 1.3 and QUIC. So
| I'm not sure this is as strong an argument as you seem to
| think it is.
|
| > DoH also introduces latency, yet people aren't worried
| about that being a deal killer.
|
| Actually, it really depends. It can actually be faster.
| Here are Mozilla's numbers from when we first rolled out
| DoH.
| https://blog.mozilla.org/futurereleases/2019/04/02/dns-
| over-...
|
| And here are some measurements from Hounsel et al.
| https://arxiv.org/abs/1907.08089
| indolering wrote:
| > They did, and then we spent an enormous amount of time
| to shave off a few round trip times in TLS 1.3 and QUIC.
|
| But if it's worth doing for HTTP, why not for DNS?
|
| > Actually, it really depends. It can actually be faster.
| Here are Mozilla's numbers from when we first rolled out
| DoH.
|
| Oh fun!
| ekr____ wrote:
| > But if it's worth doing for HTTP, why not for DNS?
|
| I'm sorry I don't understand your question.
| indolering wrote:
| The engineering effort! ECC solves the theoretical
| concerns around latency _anyway_ yet we have people
| arguing that it shouldn 't be done. But if it was worth
| making HTTPS faster to secure HTTP, why not DNS?
| tptacek wrote:
| Sir, this is a Wendy's.
| indolering wrote:
| You claim in a sibling comment that you _have_ engaged
| with my points, yet when I talk to you about it _you just
| shut down the conversation_.
|
| You really aren't going to respond to _any_ of those
| points? You stand by your complaint DNSSEC being
| "government controlled PKI" when TLDs are a government
| controlled naming system? And your alternative is to
| advocate for privately owned PKI run by companies with no
| accountability that are also much more vulnerable to
| attack?
|
| Campaigning against cryptographically signing DNS records
| is a weird life choice man.
| tptacek wrote:
| You're on tilt. It's fine that we disagree about DNSSEC.
| You seem very angry that you? (it was you, I gather?)
| wrote a post disagreeing with my post, and I didn't go
| back and revise my post to capture all the arguments you
| had that I disagreed with. Sorry, but not sorry. This is
| just crudding up the thread now though.
|
| If I've said something in this thread that you disagree
| with, say so and say why (you'll need something better
| than "I wrote about this 11 years ago and you weren't
| nice enough to me about it"). Right now, all you're doing
| is yelling about a post I wrote 11 years ago and haven't
| cited once on this thread.
|
| Of course, as you know, I stand by that post. But it's
| not germane to the thread.
| indolering wrote:
| > You're on tilt.
|
| I'm upset that your incorrect arguments have gotten so
| much traction that the internet is a less safe place for
| it.
|
| > wrote a post disagreeing with my post, and I didn't go
| back and revise my post to capture all the arguments you
| had that I disagreed with. Sorry, but not sorry.
|
| You in a sibling thread:
|
| > 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.
|
| It seemed like you wanted to have this discussion but I
| guess not.
|
| > yelling about a post I wrote 11 years ago and haven't
| cited once on this thread. ... Of course, as you know, I
| stand by that post. But it's not germane to the thread.
|
| Do you know what comment thread you are in? I complained
| about FUD and cited your blogpost. This is what this
| thread is about.
| tptacek wrote:
| Have you considered that telling me how influential my
| writing on this topic has been is not a great way to get
| me to stop writing?
| thunderfork wrote:
| >It's just that most clients don't perform local validation
| due to low adoption.
|
| From your link elsewhere,
| https://easydns.com/blog/2015/08/06/for-dnssec/
|
| >We might see a day when HTTPS key pinning and the preload
| list is implemented across all major browsers, but we will
| never see these protections applied in a uniform fashion
| across all major runtime environments (Node.js, Java, .NET,
| etc.)[...]
|
| Is this not the same flaw?
| indolering wrote:
| No! Because it's totally possible for operating system
| vendors to flip that switch without requiring _every_
| upstream project to adopt key pinning. It 's MUCH less
| infrastructure to upgrade.
| ekr____ wrote:
| It's actually not safe for clients to perform local
| validation because a quite significant fraction of
| middleboxes and the like strip out RRSIG and the like or
| otherwise tamper with the records in such a way that the
| signatures don't validate.
| tryauuum wrote:
| I hope you will never have to implement DNSSEC
| indolering wrote:
| I worked at a DNS provider, does that count?
| bawolff wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Who's the most reputable cryptographer you can think of who
| publicly supports DNSSEC? We'd like to interview them on SCW.
| indolering wrote:
| 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 wrote:
| Yes? Lots of them? But also: you didn't answer my
| question.
| indolering wrote:
| 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.
| tptacek wrote:
| Sorry, but I asked who's the most reputable cryptographer
| you can think of who publicly supports DNSSEC? I asked
| because we'd like to interview them on SCW.
| ekr____ wrote:
| You'll have to judge for yourself whether this demonstrates
| deep understanding of both arguments, but I did try to be
| evenhanded in these posts:
|
| https://educatedguesswork.org/posts/dns-security-dnssec/
| https://educatedguesswork.org/posts/dns-security-dane/
|
| From my perspective, the challenge with DNSSEC is that it just
| doesn't have a very good cost/benefit ratio. Once the WebPKI
| exists, "critical path" use of DNSSEC only offers modest value.
| Now, obviously, this article is about requiring CAs to check
| DNSSEC, which is out of the critical path and of some value,
| but it's not clear to me it's of enough value to get people to
| actually roll out DNSSEC.
| winstonwinston wrote:
| > Why are they (DNSSEC + WebPKI) never considered
| complimentary?
|
| WebPKI works without DNSSEC, whereas DANE (a more secure WebPKI
| replacement) depends on a robust DNSSEC deployment.
| ivanr wrote:
| I'll share a couple of thoughts, but do read EKR's blog first:
|
| - Web PKI is inherently insecure and can't be fixed on its own.
| The root problem is that the CAs we "trust" can issue
| certificates without technical controls. The best we can do is
| ask them to be nice and force them provide a degree of
| (certificate) transparency to enable monitoring. This is still
| being worked on. Further, certificates are issued without
| strong owner authentication, which can be subverted (and is
| subverted). [3]
|
| - The (very, very) big advantage of Web PKI is that it operates
| online and supports handshake negotiation. As a result,
| iteration can happen quickly if people are motivated. A few
| large players can get together and effect a big change (e.g.,
| X25519MLKEM768). DNSSEC was designed for offline operation and
| lacks negotiation, which means that everyone has to agree
| before changes can happen. Example: Kipp Hickman created SSL
| and Web PKI in 3 months, by himself [1]. DNSSEC took years and
| years.
|
| - DNSSEC could have been fixed, but Web PKI was "good enough"
| and the remaining problem wasn't sufficiently critical.
|
| - A few big corporations control this space, and they chose Web
| PKI.
|
| - A humongous amount of resources has been spent on iterating
| and improving Web PKI in the last 30 years. So many people
| configuring certificates, breaking stuff, certificates
| expiring... we've wasted so much of our collective lives. There
| is a parallel universe in which encryption keys sit in DNS and,
| in it, no one has to care about certificate rotation.
|
| - DNSSEC can't ever work end-to-end because of DNS
| ossification. End-user software (e.g., browsers) can't reliably
| obtain any new DNS resource records, be it DANE or SVCB/HTTPS.
|
| - The one remaining realistic use for DNSSEC is to bootstrap
| Web PKI and, possibly, secure server-to-server communication.
| This is happening, now that CAs are required to validate
| DNSSEC. This one changes finally makes it possible to configure
| strong cryptographic validation before certificate issuance.
| [2]
|
| [1]
| https://www.feistyduck.com/newsletter/issue_131_the_legend_o...
|
| [2]
| https://www.feistyduck.com/newsletter/issue_126_internet_pki...
|
| [3] https://redsift.com/guides/a-guide-to-high-assurance-
| certifi...
| TZubiri wrote:
| To add a dissenting voice.
|
| I've worked with small businesses and even small technical
| teams as a DNS consultant specifically.
|
| DNS has only been a source of issues and confusion and not at
| all related to any requirements, just a form of checkbox
| implementation.
|
| I do understand it's one of those technologies that are
| developed due to legitimate requirements, but it flows
| downstream and people just adopt it without really
| understanding the simpler solutions or what exactly it's meant
| to do.
|
| That said if I had ever gotten a bigger client like a TLD
| registrar or a downstream registrar, then sure I would have had
| to work with it, but I've only ever had to learn how to
| uninstall it actually.
| 1vuio0pswjnm7 wrote:
| 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 wrote:
| 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.
| amluto wrote:
| 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 wrote:
| 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.
| rishabhjajoriya wrote:
| DNSSEC adoption always felt like one of those things everyone
| agrees is important but operational complexity slows it down in
| practice.
| tptacek wrote:
| 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 wrote:
| 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 wrote:
| Love seeing small focused tools that do one thing well. The
| Electron vs native debate is interesting here too. FFmpeg
| wrappers are a common Tauri use case precisely because you get
| the native binary performance without the webview overhead for
| media processing. What made you go the FFmpeg CLI route rather
| than a library binding?
___________________________________________________________________
(page generated 2026-03-16 23:01 UTC)