Live data from Hacker News

Cloudflare 1.1.1.1 Incident on July 14, 2025

blog.cloudflare.com

121–130 of 391 posts

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#121
post #39

I’m surprised at the delay in impact detection: it took their internal health service more than five minutes to notice (or at least alert) that their main protocol’s traffic had abruptly dropped to around 10% of expected and was staying there. Without ever having been involved in monitoring at that kind of scale, I’d have pictured alarms firing for something that extreme within a minute. I’m curious for description o…

I'm not surprised. Let's say you've got a metric aggregation service, and that service crashes. What does that result in? Metrics get delayed until your orchestration system redeploys that service elsewhere, which looks like a 100% drop in metrics. Most orchestration take a sec to redeploy in this case, assuming that it could be a temporary outage of the node (like a network blip of some sort). Sooo, if you alert aft…

It's not rocket science. You do a 2 stage thing: Why not check if the aggregation service has crashed before firing the alarm if it's within the first 5 minutes? How many types of false positives can there be? You just need to eliminate the most common ones and you gradually end up with fewer of them.

Before you fire a quick alarm, check that the node is up, check that the service is up etc.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#122

This was quite annoying for me, having only switched my DNS server to 1.1.1.1 approximately 3 weeks ago to get around my ISP having a DNS outage. Is reasonably stable DNS really so much to ask for these days?

A single incident means 1.1.1.1 is no longer reasonably stable? You are the unreasonable one

Two incidents from two completely different providers in three weeks means that my personal experience with DNS is remarkably less stable recently than the last 20-ish years I've been using the Internet.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#123
post #71

> For many users, not being able to resolve names using the 1.1.1.1 Resolver meant that basically all Internet services were unavailable. Don't you normally have 2 DnS servers listed on any device. So was the second also down, if not why didn't it go to that.

My Mikrotik router (and afaict all of them) don't support more than one DoH address.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#124
post #71

> For many users, not being able to resolve names using the 1.1.1.1 Resolver meant that basically all Internet services were unavailable. Don't you normally have 2 DnS servers listed on any device. So was the second also down, if not why didn't it go to that.

[deleted]

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#125
post #82

Earlier quoted context omitted.

what about certificate for IP address?

What about a route that gets hijacked? There is no HSTS for IP addresses.

Presumably the route hijacker wouldn't have a valid private key for the certificate so they wouldn't pass validation

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#126
post #88
post #71

> For many users, not being able to resolve names using the 1.1.1.1 Resolver meant that basically all Internet services were unavailable. Don't you normally have 2 DnS servers listed on any device. So was the second also down, if not why didn't it go to that.

I think normally you pair 1.1.1.1 with 1.0.0.1 and, if I understand this correctly, both were down.

Just pair 1.1.1.1 with 9.9.9.9 (Quad9) so you have fault tolerance in terms of provider as well.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#127

Interesting to see that they probably lost 20% of 1.1.1.1 usage from a roughly 20 minute incident. Not sure how cloudflare keeps struggling with issues like these, this isn't the first (and probably won't be the last) time they have these 'simple', 'deprecated', 'legacy' issues occuring. 8.8.8.8+8.8.4.4 hasn't had a global(1) second of downtime for almost a decade. 1: localized issues did exist, but that's really the…

There's more to DNS than just availability (granted, it's very important). There's also speed and privacy.

European users might prefer one of the alternatives listed at https://european-alternatives.eu/category/public-dns over US corporations subject to the CLOUD act.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#128
post #89

Earlier quoted context omitted.

I agree it's not "inscrutable corporatese" It's carefully written so my boss's boss thinks he understands it, and that we cannot possibly have that problem because we obviously don't have any "legacy components" because we are "modern and progressive". It is, in my opinion, closer to "intentionally misleading corporatese".

Joe Shmo committed the wrong config file to production. Innocent mistake. Sally caught it in 30 seconds. We were back up inside 2 minutes. Sent Joe to the margarita shop to recover his shattered nerves. Kid deserves a raise. Etc.

Yea the "timeline" indicating impact start/end is entirely false when you look at the traffic graph shared later in the post.

Or they have a different definition of impact than I do

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#130
post #9

Good writeup. > It’s worth noting that DoH (DNS-over-HTTPS) traffic remained relatively stable as most DoH users use the domain cloudflare-dns.com, configured manually or through their browser, to access the public DNS resolver, rather than by IP address. Interesting, I was affected by this yesterday. My router (supposedly) had Cloudflare DoH enabled but nothing would resolve. Changing the DNS server to 8.8.8.8 fixed…

Good writeup except the entirely false timeline shared at the beginning of the post
Post reply on HN