Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloudflare 1.1.1.1 Incident on July 14, 2025

blog.cloudflare.com

Post reply on HN
Print view View original

221–230 of 391 posts

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#221

Post by daneel_w »

gruez wrote: post #216
daneel_w wrote: post #169

Earlier quoted context omitted.

Could you show a citation? Your statement completely opposes Quad9's official information as published on quad9.net, and what's more it doesn't align at all with Bill Woodcock's known advocacy for privacy.

See: https://quad9.net/privacy/policy/ It doesn't say they sell traffic logs outright, but they do send telemetry on blocked domains to the blocklist provider, and provides "a sparse statistical sampling of timestamped DNS responses" to "a very few carefully vetted security researchers". That's not exactly "selling traffic logs", but is fairly close. Moreover colloquially speaking, it's not uncommon to claim "google…

Disagree that it's fairly close to the statement "they resell traffic logs" and the implication that they leak all queried hostnames ("secret hosts, like for your work, will be leaked"). Unless Quad9 is deceiving users, both statements are, in fact, completely false.

https://quad9.net/privacy/policy/#22-data-collected

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#222

Post by johnklos »

ripdog wrote: post #210
xpe wrote: post #201

Earlier quoted context omitted.

Ouch. What resolver? What hardware? With something like a N100- or N150-based single board computer (perhaps around $200) running any number of open source DNS resolvers, I would expect you can average around 30 ms for cold lookups and <1 ms for cache hits.

Not a hardware issue, but a physics problem. I live in NZ. I guess the root servers are all in the US, so that's 130ms per trip minimum.

They are not all in the US.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#223

Post by johnklos »

nness wrote: post #117

Interesting side-effect, the Gluetun docker image uses 1.1.1.1 for DNS resolution — as a result of the outage Gluetun's health checks failed and the images stopped. If there were some way to view torrenting traffic, no doubt there'd be a 20 minute slump.

Personally, I'd consider any Docker image that does its own DNS resolution outside of the OS a Trojan.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#224

Post by ripdog »

johnklos wrote: post #222
ripdog wrote: post #210

Earlier quoted context omitted.

Not a hardware issue, but a physics problem. I live in NZ. I guess the root servers are all in the US, so that's 130ms per trip minimum.

They are not all in the US.

Well that's the experience I had. Obviously caching was enabled (unbound), but most DNS keepalive times are so short as to be fairly useless for a single user.

Even if a root server wasn't in the US, it will still be pretty slow for me. Europe is far worse. Most of Asia has bad paths to me, except for Japan and Singapore which are marginally better than the US. Maybe Aus has one...?

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#226

Post by gruez »

daneel_w wrote: post #221
gruez wrote: post #216

Earlier quoted context omitted.

See: https://quad9.net/privacy/policy/ It doesn't say they sell traffic logs outright, but they do send telemetry on blocked domains to the blocklist provider, and provides "a sparse statistical sampling of timestamped DNS responses" to "a very few carefully vetted security researchers". That's not exactly "selling traffic logs", but is fairly close. Moreover colloquially speaking, it's not uncommon to claim "google…

Disagree that it's fairly close to the statement "they resell traffic logs" and the implication that they leak all queried hostnames ("secret hosts, like for your work, will be leaked"). Unless Quad9 is deceiving users, both statements are, in fact, completely false. https://quad9.net/privacy/policy/#22-data-collected

>and the implication that they leak all queried hostnames ("secret hosts, like for your work, will be leaked").

The part about sharing data with "a very few carefully vetted security researchers" doesn't preclude them from leaking domains. For instance if the security researcher exports a "SELECT COUNT(*) GROUP BY hostname" query that would arguably count as "summary form", and would include any secret hostnames.

>https://quad9.net/privacy/policy/#22-data-collected

If you're trying to imply that they can't possibly be leaking hostnames because they don't collect hostnames, that's directly contradicted by the subsequent sections, which specifically mention that they share metrics grouped by hostname basis. Obviously they'll need to collect hostname to provide such information.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#227

Post by johnklos »

bigiain wrote: post #101
CuteDepravity wrote: post #5

It's crazy that both 1.1.1.1 and 1.0.0.1 where affected by the same change I guess now we should start using a completely different provider as dns backup Maybe 8.8.8.8 or 9.9.9.9

I mean, aren't we already? My Pi-holes both use OpenDNS, Quad9, and CloudFlare for upstream. Most of my devices use both of my Pi-holes.

If you're already running Pi-hole, wny not just run your own recursive, caching resolver?

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#228

Post by ollien »

homero wrote: post #47
egamirorrim wrote: post #37

What's that about a hijack?

Related, non-causal event: BGP origin hijack of 1.1.1.0/24 exposed by withdrawal of routes from Cloudflare. This was not a cause of the service failure, but an unrelated issue that was suddenly visible as that prefix was withdrawn by Cloudflare.

I'm a bit uneducated here - why was the other 1.1.1.0/24 announcement previously suppressed? Did it just express a high enough cost that no one took it on compared to the CF announcement?

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#229

Post by crabique »

fs111 wrote: post #168
noduerme wrote: post #100

Earlier quoted context omitted.

right, this was announced about two weeks ago to some fanfare. So in principle there was no reason not to do it two decades ago? It would've been nice back then. I never heard of any certificate authority offering that.

> I never heard of any certificate authority offering that. DigiCert does. That is where 1.1.1.1 and 9.9.9.9 get their valid certificates from

Most CAs offer them, the only requirement is that it's at least an OV (not DV) level cert, and the subject organization proves it owns the IP address.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#230

Post by lxgr »

ignoramous wrote: post #196
lxgr wrote: post #191

Earlier quoted context omitted.

Yes, but you were talking about DoH. I don’t know how that could plausibly work.

> but you were talking about DoH DoH hosts can resolve to multiple IPs (and even different IPs for different clients)? Also see TFA 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. DoH remained available and traffic was mostly un…

> DoH hosts can resolve to multiple IPs (and even different IPs for different clients)?

Yes, but not from a different organization. That was GPs point with

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

A cross-organizational fallback is not possible with DoH in many clients, but it is with plain old DNS.

> It's worth noting that DoH (DNS-over-HTTPS) traffic remained relatively stable as most DoH users use the domain cloudflare-dns.com

Yes, but that has nothing to do with failovers to an infrastructurally/operationally separate secondary server.

Post reply on HN