Hacker News new | ask | show | jobs
by lucgagan 1123 days ago
I hope the situation gets resolved swiftly, and lessons learned from this incident can contribute to stronger and more reliable DNSSEC practices in the future.
3 comments

The root KSK rollover had to be postponed twice, for several years, because of operational problems pulling this off in the US. It's difficult to do because the nature of the DNS makes it difficult. The utility of DNSSEC is so marginal that it's kind of sad that you're right, and that engineers are gradually getting better doing this hard, stupid thing.
You're not learning if you're not failing, so failing is good actually.
I think the pithy saying is that we learn best from failure, not that there is no other way to learn.
Yep: "don't deploy DNSSEC, rely on TLS"
TLS security is rooted in DNS. It's ACME DNS-01. If your threat model includes nation states, this is a non-solution
Wrong, TLS security is independent from DNS. If my threat model includes nation states I'll trust my own certificates or my very own CA.
By trusting certificates, you implicitly trust all CAs, not just your own.
You trust your browser's root program, not "all CAs".
That’s what a “CA” is. If someone is not in a browser’s CA list, they’re not a CA. So yes, you do trust all CAs.
No, again in that threat model I can decide exactly which certificates and which CA I trust, one by one.
If your threat includes nation states then DNSSEC is double-useless?
If your threat model includes nation-states then DNSSEC won't help you either. WebPKI at least has a method for keeping track of and detecting misissuance, DNSSEC doesn't.