Comment by tom1337
14 hours ago
Cloudflare has now disabled DNSSEC validation on their 1.1.1.1 resolver: https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz
14 hours ago
Cloudflare has now disabled DNSSEC validation on their 1.1.1.1 resolver: https://www.cloudflarestatus.com/incidents/vjrk8c8w37lz
Welp. I think can call it on DNSSEC now.
OTOH there was recently a DNSSEC-saved-the-day piece of news: https://incrypted.com/en/dns-attack-on-eth-limo-was-stopped/
That only worked because the attacker didn't understand dnssec. If they had unsigned the domain first and then hijacked it they would have succeeded.
I haven't been able to find any cases of genuine dns hijack attacks in the last few years. Would love to know if anyone else can?
Only about 40% of the crypto companies seem to use dnssec. Seems like a target rich environment.
Probably the most common reason to use DNSSEC is to check a box on a list of compliance rules. And I don't think this will change anything for people who need DNSSEC for compliance.
There's no commercial compliance regime that requires DNSSEC (FedRAMP might be the only exception --- I'm uncertain about the current state of FedRAMP DNSSEC rules --- but that makes sense given that DNSSEC is a giant key escrow scheme.)
2 replies →
I found another reason... MS365 require DNSSEC to be enabled if you want DANE for TLS-enforced SMTP. You could also use MTA-STS.
Probably the most common reason to use TLS is to check a box on a list of compliance rules. Is that bad?
8 replies →
I doubt it. The root cause of this was a root server misconfiguration or bug. It happened to DNSSEC records this time, which is a pain, but next time it might as well flip bits or point to wrong IP addresses instead.
Paradoxically, resolvers wouldn't have noticed the misconfiguration if it weren't for DNSSEC.
Hahaha. You wish :-p
It's a pretty hard argument to work around: WebPKI certificates should go in the DNS, and also the largest DNS providers might at any moment decide not to validate DNSSEC anymore to get through an outage.
5 replies →
If it turns out the DNSSEC issue was caused by threat actors, this downstream effect could very well have been the reason to do it.
It is indeed a bit sad that Cloudflare had to turn off DNSSEC completely. But I completely understand that they don't have a production-ready, tested path to override DNSSEC validation for only some domains.
Sorry! status message was not clear. DNSSEC validation is temporarily disabled only for .de domains.
1 reply →
[flagged]
3 replies →
Temporarily is a fairly important word to include with that link
This seems like it should be the bigger news here. Disappointing knee jerk reaction from Cloudflare.
We only disabled SSL on all the websites in one country for a little bit.. I'm sure those credit card numbers were perfectly safe over the wire
That comparison really makes the contrast clear: losing TLS would’ve put millions of people either into full downtime or immediately at significant risk (you can’t uncapture data). Losing DNSSEC, however, placed no one at risk and improved uptime.
There’s a reason why one of the two has roughly 10% adoption after three decades and the other is high 90-something percent.
They didn't disable SSL you dingus.
it was an analogy to try highlighting how silly "security" is when it's opt-in and any intermediary can just disable it