Hacker News Reader

Comment by muppetman | Hacker News Reader

DNSSec has caused so many outages at this point it's a joke.

You have to be so insanely careful and plan everything to the nth degree otherwise you break everything: https://internetnz.nz/news-and-articles/dnssec-chain-validat...

The idea is important. What it aims to protect is important. The current implementation is horrible, far too complex and fraught with so many landminds that no one wants to touch it.

If Geoff Huston is suggesting it might be time to stick a fork in DNSSec because it's done, then IMHO it's well cooked. https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/

View on HN

A common reason, if not the vast majority of cases, is that people mix up which key they publish and which key they are actually using. I don't doubt there are a lot of things they could do to improve the protocol, but this very common problem is fairly difficult to solve on a protocol level.

I remember back in the days when people discouraged people from using encrypted disks because of the situation that could happen if the user lost their passwords. No disk encryption algorithm can solve the issue if the user does not have the correct password, and so the recommendation was to not use it. Nowadays people usually have TPMs or key management software to manage keys, so people can forget the password and still access their encrypted disks.

DNSSEC software is still not really that developed that they automatically include basic tests and verification tools to make sure people don't simply mix up keys. They assume that people write those themselves. Too many times this happens after incidents rather than before (heard this in so many war stories). It also doesn't help that dns is full of caching and caching invalidation. A lot of the insane step-by-step plans comes from working around TTL's, lack of verification, basic tooling, and that much of the work is done manually.

> No disk encryption algorithm can solve the issue if the user does not have the correct password, and so the recommendation was to not use it.

This problem is accurate, but it's the framing that makes it wrong.

No disk encryption algorithm can simultaneously protect and not protect something encrypted, what you're missing is the protocol/practices around that, and those are far less limited.

There is heaps of encryption around these days, there are people losing access to their regular keys, and yet procedures that recover access to their data while not entirely removing the utility of having encrypted data/disks.

A TPM is absolutely not a reliable way to store your key. Think about how often you get asked for a BitLocker recovery code, and imagine if every time that happened, you lost all your data.

> You have to be so insanely careful and plan everything to the nth degree

If you're on the root/TLD end of things I agree. Certainly not if you're a domain owner or name server administrator on the customer end of things.

Yeah I'm by no means saying the implementation is good. RPKI is a joke as well in my opinion. But it's all we have right now.

I am saying it is dishonest to discount the real security threat of not having DNSSEC.

Right OK, I fully agree with you then.

What parts do you agree about? Someone making an argument that we should return to the drawing board and come up with a new protocol, one that doesn't make the "offline signers and authenticated denial" tradeoffs DNSSEC makes, would probably be saying something everybody here agrees with --- though I still don't think it would be one of the 5 most important security things to work on.

But the person you're replying to believes we should hasten deployment of DNSSEC, the protocol we have now.

I would love to go to back to the drawing board and solve the security pitfalls in BGP & DNS. I wish the organizations and committees involved did a better job back then.

Sadly, we live in this reality for now, so we do what we can with what we have. We have DNSSEC.

You understand that it is a little difficult for people to take seriously a claim that you're interested in going back to the drawing board while at the same time very stridently arguing that hundreds of millions of dollars of work should go in to getting a 1994 protocol design from 4% deployment to 40% deployment. The time to return to the drawing board is now.

I don't read that reply as them saying we should hasten deployment of DNSSEC. If that was the intention of the comment then no, I don't agree with that aspect of it.

I saying say I agree with the statement "I am saying it is dishonest to discount the real security threat of not having DNSSEC."

I believe we do need some way to secure/harden DNS against attacks, we can't pretend that DNS as it stands is OK. DNSSEC is trying to solve a real problem - I do think we need to go back to the drawing board on how we solve it though.

They definitely believe we should hasten deployment of DNSSEC --- read across the thread. For instance: Slack was taken down for a half a day owing to a deployment of DNSSEC that a government contract obligated them to undertake, and that commenter celebrated the contract.

It's fine that we all agree on some things and disagree on others! I don't think DNS security is a priority issue, but I'm fine with it conceptually. My opposition is to the DNSSEC protocol itself, which is a dangerous relic of premodern cryptography designed at a government-funded lab in the 1990s. The other commenter on this thread disagrees with that assessment.

slightly later

(My point here is just clarity about what we do and don't agree about. "Resolving" this conflict is pointless --- we're not making the calls, the market is. But from an intellectual perspective, understanding our distinctive positions on Internet security, even if that means recognizing intractable disputes, is more useful than just pretending we agree.)

>DNSSec has caused so many outages at this point it's a joke.

So has failing to renew TLS certificates. So what?

Unrenewed certs have not caused the kind of extended mass outages DNSSec has, it's not close.

If Let's Encrypt goes down, half of the Internet will stop working. Doubly so when we switch to certs that are valid for just a couple of days.

That is... not how certificates work. The part of LetsEncrypt that has to work continuously ships as part of your browser root store.

The proposal is to make LE certs 9 days long or something. Which means if LE is down for even a short time thousands and millions of certs will expire.

You don't wait till the last second to renew. 9 day certificates would mean 7 day renewals for example. And at that point you could have 2 or 3 ACME-compatible services configured as a backup.

I doubt 20% of the LE users even know other ACME services exist let alone what they may be.

That's ok, this scales with requirements / experience / money on the line. Most people won't care about a day of downtime that much. And those who really don't know anything about SSL will be using a platform solving this for them.

The eventual plan is to limit certs to 48 hours (AFAIR), right now they're already allowing 6-day certs: https://letsencrypt.org/2025/02/20/first-short-lived-cert-is... In this scenario, if Let's Encrypt goes down for just a couple of days, a lot of certs will expire.

There are also operational risks, as Let's Encrypt has to have their secret key material in close proximity to web-facing services. Of course, they use HSMs, but it might not be enough of a barrier for nation-state level attackers.

The offline signing feature of DNSSEC allows the root zone and, possibly, the TLDs to be signed fully offline.

That's why in my ideal world I want to keep DNSSEC as-is for the root zone and the TLD delegation records, but use something like DoH/DoT for the second-level domains. The privacy impact of TLD resolution is pretty much none, and everything else can be protected fully.

That is not why DNSSEC has offline signers. DNSSEC has offline signers because when the protocol was designed, its authors didn't believe computers would be able to keep up with the signing work. Starting sometime in the middle of the oughts, people started to retcon security rationales onto it, but that's not the purpose of the design.

Do you have links for that? I don't really doubt that, since the work was done mid 90-s. But I'm genuinely curious about the early history of failed protocols (like IPv6 and DNSSEC), and I read most of the early archived discussions about IPv6.

Yes, somewhere I do; I wrote a complete history of the protocol, including archives I found of 90s-vintage mailing lists. I'll have to dig it up, though.

Reply on news.ycombinator.com