Live data from Hacker News

Cloudflare 1.1.1.1 Incident on July 14, 2025

blog.cloudflare.com

141–150 of 391 posts

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#141
post #41

Earlier quoted context omitted.

Who? Honest question

Realistically, either you ignore the privacy concerns and set up routing to multiple providers preferring the fastest, or you go all-in on privacy and route DNS over Tor over bridge. Although, perhaps, having an external VPS with a dns proxy could be a good middle ground?

Middle ground is ISP DNS, right?

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#142

Earlier quoted context omitted.

Unless the privacy policy changed recently, Google shouldn't be doing anything nefarious with 8.8.8.8 DNS queries.

They weren't supposed to do anything with our gmail data as well. That didn't stop them.

[citation needed]

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#143
post #134
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.

Cloudflare's own suggested config is to use their backup server 1.0.0.1 as the secondary DNS, which was also affected by this incident.

TBH at this point the failure modes in which 1.1.1.1 would go down and 1.0.0.1 would not are not that many. At CloudFlare’s scale, it’s hardly believable a single of these DNS servers would go down, and it’s rather a large-scale system failure.

But I understand why Cloudflare can’t just say “use 8.8.8.8 as your backup”.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#144
post #76

Earlier quoted context omitted.

Not all users have configured two DNS servers?

It is highly recommended to configure two or more DNS servers incase one is down. I would count not configuring at least two as 'user error'. Many systems require you to enter a primary and alternate server in order to save a configuration.

The default setting on most computers seems to be: use the (wifi) router. I suppose telcos like that because it keeps the number of DNS requests down. So I wouldn't necessarily see it as user error.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#145

Earlier quoted context omitted.

Its not wrong for smaller companies. But there's an argument that a big system critical company/provider like Cloudflare should be able to afford its own always on team with a night shift.

Please don’t. It doesn’t make sense, doesn’t help, doesn’t improve anything and is just waste of money, time, power and people. Now without crying: I saw multiple, big companies getting rid of NOC and replacing that with on duties in multiple, focused teams. Instead of 12 people sitting 24/7 in group of 4 and doing some basic analysis and steps before calling others - you page correct people in 3-5 minutes, with exac…

24/7 on-call is basically mandatory at any major network, which cloudflare is. Your contractual relations with other networks will require it.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#146
post #105

Earlier quoted context omitted.

Private DNS on Android refers to 'DNS over HTTPS' and would normally only accept a hostname. Normal DNS can normally be changed in your connection settings for a given connection on most flavours of Android.

> Private DNS on Android refers to 'DNS over HTTPS' Yes, sorry, I did not mention it. So if you want to use DNS over HTTPS on Android, it is not possible to provide a fallback.

> So if you want to use DNS over HTTPS on Android, it is not possible to provide a fallback.

Not true. If the (DoH) host has multiple A/AAAA records (multiple IPs), any decent DoH client would retry its requests over multiple or all of those IPs.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#147
post #41

Earlier quoted context omitted.

Depends who you trust more with your DNS traffic. I know who I trust more.

Who? Honest question

Myself, I suppose? Recursive resolvers are low-maintenance, and you get less exposure to ISP censorship (which "developed" countries also do).

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#148
post #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.

HN users might prefer to run their own. It's a low maintenance service. It's not like running a mail server.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#149

Earlier quoted context omitted.

1.1.1.1 and 1.0.0.1 are served by the same service. It's not advertised as a redundant fully separate backup or anything like that...

Wait, then why does 1.0.0.1 exist? I'll grant I've never seen it advertised/documented as a backup, but I just assumed it must be because why else would you have two? (Given that 1.1.1.1 already isn't actually a single point, so I wouldn't think you need a second IP for load balancing reasons.)

Because operating systems have two boxes for DNS server IP addresses, and Cloudflare wants to be in both positions.
Post reply on HN