upvote

points

by tom133713 hours ago |
comments
upvoteby tptacek13 hours ago|
next
[-]
Welp. I think can call it on DNSSEC now.
reply
upvoteby fulafel7 hours ago|
parent|
next
[-]
OTOH there was recently a DNSSEC-saved-the-day piece of news: https://incrypted.com/en/dns-attack-on-eth-limo-was-stopped/
reply
upvoteby elp3 hours ago|
parent|
[-]
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.

reply
upvoteby thayne10 hours ago|
parent|
prev|
next
[-]
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.
reply
upvoteby tptacek9 hours ago|
parent|
next
[-]
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.)
reply
upvoteby thayne7 hours ago|
parent|
[-]
FedRAMP requires it, although like many requirements, you may be able to get out of it if you have a good reason and/or your sponsoring agency doesn't care about it.

There are also some large businesses that require, or strongly pressure SaaS providers to use DNSSEC. You can often contest that, but if you have DNSSEC, that's one less thing to argue about in the contract.

reply
upvoteby tptacek7 hours ago|
parent|
[-]
Which businesses are those? (I ask because if they're North American, I have a pretty good sense of which large North American businesses even have DNSSEC signatures set up, and it's not many; small enough that you can easily memorize the list.)
reply
upvoteby whh2 hours ago|
parent|
prev|
next
[-]
I found another reason... MS365 require DNSSEC to be enabled if you want DANE for TLS-enforced SMTP. You could also use MTA-STS.
reply
upvoteby pocksuppet9 hours ago|
parent|
prev|
[-]
Probably the most common reason to use TLS is to check a box on a list of compliance rules. Is that bad?
reply
upvoteby weird-eye-issue9 hours ago|
parent|
next
[-]
Do browsers even load non-HTTPS sites anymore without a massive warning?
reply
upvoteby red_admiral3 hours ago|
parent|
next
[-]
neverssl.com works fine for me, only a small warning in the place where the padlock usually is, that no-one checks anyway.

The browser would be very unhappy with an <input type="password"/> on a non-TLS site (localhost excepted). HSTS would trigger the "massive" warning and refuse to load the site, however.

reply
upvoteby weird-eye-issue1 hours ago|
parent|
[-]
It's more pronounced on desktop

Ah yes I think the HSTS issue is what I was thinking of

reply
upvoteby pocksuppet7 hours ago|
parent|
prev|
[-]
Yes, they do.
reply
upvoteby weird-eye-issue6 hours ago|
parent|
[-]
Yeah just ignore the big "not secure" warning in the URL bar
reply
upvoteby pocksuppet5 hours ago|
parent|
[-]
I just checked it. You mean the very small open padlock icon? The era of browsers warning loudly about HTTP was a decade ago, it got reversed due to pushback.
reply
upvoteby weird-eye-issue4 hours ago|
parent|
[-]
Well I checked both Chrome and Firefox on mobile and my desktop and they were all much more obvious than just an "open padlock". They both said "Not Secure" and in Firefox it was bright red text. Also in incognito mode Chrome refused to even open the site without a full screen warning. They all make it super clear non-HTTPS sites are not secure so I'm not really sure what your point is?
reply
upvoteby liveoneggs9 hours ago|
parent|
prev|
[-]
browsers pushed it, not compliance
reply
upvoteby jeroenhd5 hours ago|
parent|
prev|
next
[-]
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.

reply
upvoteby amluto13 hours ago|
parent|
prev|
[-]
Hahaha. You wish :-p
reply
upvoteby tptacek12 hours ago|
parent|
[-]
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.
reply
upvoteby farfatched9 hours ago|
parent|
next
[-]
Yes, it's a crappy outcome, but endpoints can still choose to enforce this. Further, it's not a persuasive argument against more DNSSEC usage, since if there was more DNSSEC usage then resolvers would be more reluctant to disable it.
reply
upvoteby pocksuppet9 hours ago|
parent|
prev|
[-]
If there's going to be a single point of failure in front of your website, that single point of failure may as well be the only single point of failure instead of having two single points of failure, and it's probably important that people can't spoof responses.
reply
upvoteby akerl_9 hours ago|
parent|
next
[-]
Nobody had to hack it. A system at DENIC broke, and so Cloudflare turned off DNSSEC validation for all of their users accessing .de. If DNSSEC was actually important for the security model of those users, that would be a huge deal.
reply
upvoteby phicoh4 hours ago|
parent|
[-]
If DNSSEC is part of your security model, you want local validation. Not relying on third party resolver that you don't have a contract with.

Beyond that, DNS has the AD bit. If you need DNSSEC secure data (for example for the TLSA record), then when Cloudflare turns off DNSSEC validation, the AD bit will be clear and things will stop working.

reply
upvoteby tptacek9 hours ago|
parent|
prev|
[-]
This is a non sequitur.
reply
upvoteby cluckindan13 hours ago|
prev|
next
[-]
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.
reply
upvoteby amluto13 hours ago|
parent|
[-]
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.
reply
upvoteby vendemiat12 hours ago|
parent|
next
[-]
Sorry! status message was not clear. DNSSEC validation is temporarily disabled only for .de domains.
reply
upvoteby tptacek12 hours ago|
parent|
[-]
That's not much better!
reply
upvoteby fastest96311 hours ago|
parent|
prev|
[-]
[flagged]
reply
upvoteby jonah-archive11 hours ago|
parent|
next
[-]
Originally it said:

---

The issue has been identified as a DNSSEC signing problem at DENIC, the organization responsible for the .DE top-level domain. Cloudflare has temporarily disabled DNSSEC validation on 1.1.1.1 resolver in order to allow .DE names to continue to resolve. DNSSEC validation will be re-enabled when the signing problems at DENIC are known to have been resolved.

---

(and in case it changes again, now it says)

---

The issue has been identified as a DNSSEC signing problem at DENIC, the organization responsible for the .DE top-level domain. Cloudflare has temporarily disabled DNSSEC validation for .de domains on 1.1.1.1 resolver (as per RFC 7646) in order to allow .DE names to continue to resolve. DNSSEC validation will be re-enabled when the signing problems at DENIC are known to have been resolved.

See RFC 7646 for more details: https://datatracker.ietf.org/doc/html/rfc7646

---

reply
upvoteby tptacek11 hours ago|
parent|
[-]
The RFC 7646 thing here is the funniest possible addition. This is the greatest day.
reply
upvoteby tptacek11 hours ago|
parent|
prev|
[-]
It didn't originally say that. They added the clarification just a few minutes ago. The guidelines ask you not to ask people these kinds of questions, for what it's worth.
reply
upvoteby petee1 hours ago|
prev|
next
[-]
Temporarily is a fairly important word to include with that link
reply
upvoteby account421 hours ago|
prev|
next
[-]
This seems like it should be the bigger news here. Disappointing knee jerk reaction from Cloudflare.
reply
upvoteby liveoneggs9 hours ago|
prev|
[-]
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
reply
upvoteby acdha40 minutes ago|
parent|
next
[-]
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.

reply
upvoteby weird-eye-issue9 hours ago|
parent|
prev|
[-]
They didn't disable SSL you dingus.
reply