Live data from Hacker News

Cloudflare 1.1.1.1 Incident on July 14, 2025

blog.cloudflare.com

381–390 of 391 posts

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#381
post #368
post #280

Earlier quoted context omitted.

What is your ticket #? Let's see if we can get this resolved for you.

Oh hey, didn't expect this to actually be seen by many people, let alone you guys! There was no ticket number yet because I was mainly trying to resolve it upstream (whoever made it get into uBlock's default block list, Quad9, and probably other places) and then today when I checked your site specifically, the link in "False Positive? " (when you do a lookup for a blocked domain) just links back to itself so I couldn…

Glad to hear you were able to submit a ticket! The website form wasn't working a brief time ago. But YES, we want to help! You can DM me in the fedi if you need anything: https://mastodon.social/@quad9dns

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#382

Earlier quoted context omitted.

Why not address the REAL issue: > I haven't been able to find any recourse. [...] there seems to be no way to clear my name.

From the parent comment the path of recourse is a ticket. Does not help if hn is needed to have it looked at.

Looks like no ticket was actually created until now though.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#383
post #367

Earlier quoted context omitted.

DNS is just a look up service. You can filter it or not but in the end it is just a "source of truth". What are you trying to do on your wifi?

Many wifi networks redirect non-encrypted http traffic to their captive portal. For the redirect to work, your DNS needs to be the default one provided by the router so that http://neverssl.com resolves to the wifi's "Please accept our ToS to get online" page. If you aren't using their DNS, then your network requests just get dropped (as you're not approved yet). You need their DNS to learn how to access their captiv…

My clients use DHCP for everything and are always connected to my home VPN. If I'm away from home and need to connect to a captive network, I'll turn off the VPN, connect, then re-enable the VPN. I run unbound at home for DNS.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#384

Earlier quoted context omitted.

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

Running your own and being the sole user is the exact same thing as using a dns server (you need to obtain nameservers for any given domain which you have to contact a dns server for).

Except that your queries are spread out to different places instead of all being sent to a single server.

You ask .com resolver for domain.com's NS, and then you ask ns1.domain.com for foo.domain.com. Then you browse to wikipedia.org, and none of those DNS queries go to the same place as the previous site.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#385
post #367

Earlier quoted context omitted.

Many wifi networks redirect non-encrypted http traffic to their captive portal. For the redirect to work, your DNS needs to be the default one provided by the router so that http://neverssl.com resolves to the wifi's "Please accept our ToS to get online" page. If you aren't using their DNS, then your network requests just get dropped (as you're not approved yet). You need their DNS to learn how to access their captiv…

My clients use DHCP for everything and are always connected to my home VPN. If I'm away from home and need to connect to a captive network, I'll turn off the VPN, connect, then re-enable the VPN. I run unbound at home for DNS.

While I run a home VPN, I think using it exclusively runs into issues:

- frequently capture portals only permit access for 1-2hr. Your internet get cut off, then you have to realize its not a temporary issue, but portal issue, then you close the vpn, try to find the captive portal, and re-auth.

- latency is too high for my home vpn when I travel in asia

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#386

Earlier quoted context omitted.

It's illegal for a US company to lie to their investors, so if you believe they're lying to you, you should sue them for securities fraud.

You actually believe that this is how it works?

What do you mean "how it works"? It's up to you. You're the one who makes it work.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#387

Earlier quoted context omitted.

>cache.delete obviously only deletes that browser's cache, not all other browsers in the world. To me, it only makes sense if the put method creates a cache only in the datacenter where the Worker was invoked. Put and delete need to be related, in my opinion. Now I'm curious: what's the point of clearing the cache contents in the datacenter where the Worker was invoked? I can't think of any use for this method. My cr…

> To me, it only makes sense if the put method creates a cache only in the datacenter where the Worker was invoked. Put and delete need to be related, in my opinion. That is, in fact, how it works. cache.put() only writes to the local datacenter's cache. If delete() were global, it would be inconsistent with put(). > Now I'm curious: what's the point of clearing the cache contents in the datacenter where the Worker w…

> cache.put() only writes the local datacenter's cache.

Thanks, I didn't know that (I don't remember reading it in the documentation)

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#388

Earlier quoted context omitted.

If you think you can pontificate on DNS then I think you should be running your own service. Note how root "." just works and has done for decades - that's proper engineering and actually way more complicated than running 1.1.1.1. What 1.1.1.1 suffers from is anycast and not DNS. Cloudflare (and Google and co) insist on using one or more "vanity" IP addresses - that is very unfair of me but that it what it is, and to…

The root servers all use anycast addresses.

And yet they work - there is quite a lot of them!

It's in no-one's interest to destroy DNS root.

Are you sure they all use anycast? I probably ought to check.

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#389

Earlier quoted context omitted.

Running your own and being the sole user is the exact same thing as using a dns server (you need to obtain nameservers for any given domain which you have to contact a dns server for).

Except that your queries are spread out to different places instead of all being sent to a single server. You ask .com resolver for domain.com's NS, and then you ask ns1.domain.com for foo.domain.com. Then you browse to wikipedia.org, and none of those DNS queries go to the same place as the previous site.

That's arguably worse since you are now in direct contact with the nameservers (which are usually managed by non privacy orientated providers).

Re: Cloudflare 1.1.1.1 Incident on July 14, 2025

#390
post #273

Earlier quoted context omitted.

It is about the hostnames themselves like: git.nationalpolice.se but I understand that there is not much choice if you want to keep the service free to use so this is fair

Is that really a concern for most people? Trying to keep hostnames secret is a losing battle anyways these days. You should probably be using a trusted TLS certificate for your git hosting. And that means the host name will end up in certificate transparency logs which are even easier to scrape than DNS queries.

You would probably use wildcard certificates to NOT leak those subdomains
Post reply on HN