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

211–220 of 391 posts

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#211

Post by mnordhoff »

Aachen wrote: post #209
moontear wrote: post #126

Earlier quoted context omitted.

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

I became a bit disillusioned with quad9 when they started refusing to resolve my website. It's like wetransfer but supporting wget and without the AI scanning or interstitials. A user had uploaded malware and presumably sent the link to a malware scanner. Instead of reporting the malicious upload or blocking the specific URL¹, the whole domain is now blocked on a DNS level. The competing wetransfer.com resolves just…

You should email them about the form and about your domain. Their email address is listed on the website. https://quad9.net/support/contact/>

Sometimes the upstream blocklist provider will be easy to contact directly as well. Sometimes not so much.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#212

Post by karel-3d »

homebrewer wrote: post #180

This is a good time to mention that dnsmasq lets you setup several DNS servers, and can race them. The first responder wins. You won't ever notice one of the services being down: all-servers server=8.8.8.8 server=9.9.9.9 server=1.1.1.1

dnsdist is AMAZINGLY easy to set up as a secure local resolver that forwards all queries to DoH (and checks SSL) and checks liveliness every second

I need to do a write-up one day

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#213

Post by chrisgeleven »

I been lazy and was using Cloudflare's resolver only recently. In hindsight I probably should just setup two instances of Unbound on my home network that don't rely on upstream resolvers and call it a day. It's unlikely both will go down at the same time and if I'm having an total Internet outage (unlikely as I have Comcast as primary + T-Mobile Home Internet as a backup), it doesn't matter if DNS is or isn't resolving.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#214

Post by Aachen »

homebrewer wrote: post #175
Algent wrote: post #115

Earlier quoted context omitted.

After trying both several time I since stayed with google due to cloudflare always returning really bad IPs for anything involving CDN. Having users complain stuff take age to load because you got matched to an IP on opposite side of planet is a bit problematic especially when it rarely happen on other dns providers. Maybe there is a way to fix this but I admit I went for the easier option of going back to good old 8…

No, it's deliberately not implemented: https://developers.cloudflare.com/1.1.1.1/faq/#does-1111-sen... I've also changed to 9.9.9.9 and 8.8.8.8 after using 1.1.1.1 for several years because connectivity here is not very good, and being connected to the wrong data center means RTT in excess of 300 ms. Makes the web very sluggish.

Does that setup fall back to 8.8.8.8 if 9.9.9.9 fails to resolve?

Quad9 has a very aggressive blocking policy (my site with user-uploaded content was banned without even reporting the malicious content; if you're a big brand name it seems to be fine to have user-uploaded content though) which this would be a possible workaround for, but it may not take an nxdomain response as a resolver failure

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#215

Post by ta1243 »

yjftsjthsd-h wrote: post #30
ta1243 wrote: post #27

Earlier quoted context omitted.

Far quicker to type ping 1.1 than ping 1.1.1.1 1.0.0.0/24 is a different network than 1.1.1.0/24 too, so can be hosted elsewhere. Indeed right now 1.1.1.1 from my laptop goes via 141.101.71.63 and 1.0.0.1 via 141.101.71.121, which are both hosts on the same LINX/LON1 peer but presumably from different routers, so there is some resilience there. Given DNS is about the easiest thing to avoid a single point of failure o…

> Far quicker to type ping 1.1 than ping 1.1.1.1 I guess. I wouldn't have thought it worthwhile for 4 chars, but yes. > 1.0.0.0/24 is a different network than 1.1.1.0/24 too, so can be hosted elsewhere. I thought anycast gave them that on a single IP, though perhaps this is even more resilient?

In the internet world you can't really advertise subnets smaller than a /24, so 1.1.1.1/32 isn't a route, it's via 1.1.1.0/24

You can see they are separate routes, say looking at Telia's routing IP

https://lg.telia.net/?type=bgp&router=fre-peer1.se&address=1...

https://lg.telia.net/?type=bgp&router=fre-peer1.se&address=1...

In this case they both are advertised from the same peer above, I suspect they usually are - they certainly come from the same AS, but they don't need to. You could have two peers with cloudflare with different weights for each /24

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#216

Post by gruez »

daneel_w wrote: post #169
rvnx wrote: post #137

Earlier quoted context omitted.

Quad9 is reselling the traffic logs, so it means if you connect to secret hosts (like for your work), they will be leaked

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 sells your data", even they don't provide dumps and only disclose aggregated data.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#217

Post by SemioticStandrd »

woutifier wrote: post #90
kylestanfield wrote: post #81

Earlier quoted context omitted.

So someone just started advertising the prefix when it was up for grabs? That’s pretty funny

No they were already doing that, the global withdrawal of the legitimate route just exposed it.

How is there absolutely no further comment about that in their RCA? That seems like a pretty major thing...

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#218

Post by SketchySeaBeast »

quacksilver wrote: post #95
rat9988 wrote: 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 funny part with that is that sites like cloudflare say "Oh, yeah, just use 1.0.0.1 as your alternate", when, in reality, it should be an entirely different service.
Post reply on HN