Earlier quoted context omitted.
Its DNS over TLS. Android does not support DNS over HTTPS except Google's DNS
It does since Android 11.
For a limited set of DoH providers. It does not let you enter a custom DoH URL, only a DoT hostname.
Cloudflare 1.1.1.1 Incident on July 14, 2025
261–270 of 391 posts
Re: Cloudflare 1.1.1.1 Incident on July 14, 2025
#262Earlier quoted context omitted.
If you consume a service that's free of charge, it's at least not reasonable to complain if there's an outage. Like mentioned by other comments, do it on your own if you are not happy with the stability. Or just pay someone to provide it - like your ISP.. And TBH I trust my local ISP more than Google or CF. Not in availability, but it's covered by my local legislature. That's a huge difference - in a positive way.
> it's covered by my local legislature which might not be a good thing in some jurisdictions - see the porn block in the UK (it's done via dns iirc, and trivially bypassed with a third party dns like cloudflare's).
Yeah it has its pros and cons, sadly.
So far I'm lucky and the only ban I'm aware of is on gambling. Which is fine for me personally.
But in a UK case I'd using a non local one as well.
Re: Cloudflare 1.1.1.1 Incident on July 14, 2025
#263Earlier 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.
Quad9 is reselling the traffic logs, so it means if you connect to secret hosts (like for your work), they will be leaked
Im sorry... what is a secret hostname that is publicly resolvable?
The very idea strikes me as irresponsible and misguided.
Re: Cloudflare 1.1.1.1 Incident on July 14, 2025
#264Earlier quoted context omitted.
You know, I recently went through a period of thinking my MacBook was just broken. It had the janks. Everything on the browser was just slower than you're used to. After a week or two of pulling my hair, I figured it out. The newly-configured computer was using the DHCP-assigned DNS instead of Google DNS. Switched it, and it made a massive difference.
but that's the opposite of the request to move from a googDNS to a local one because of latency. so your ISP's DNS sucked, which is a broad statement, and is part of the why services like 1.1.1.1 or 8.8.8.8 exist. you didn't make the change of DNS because you were picking one based on nearest location.
There is more to latency than distance. Server response time is also important. In my case, the problem was that the DNS forwarder in the local wifi access point/router was very slow, even though the ICMP latency from my laptop to that device is obviously low.
Re: Cloudflare 1.1.1.1 Incident on July 14, 2025
#265>Even though this release was peer-reviewed by multiple engineers
I find it somewhat surprising that none of the multiple engineers who reviewed the original change in June noticed that they had added 1.1.1.0/24 to the list of prefixes that should be rerouted. I wonder what sort of human mistake or malice led to that original error.
Perhaps it would be wise to add some hard-coded special-case mitigations to DLS such that it would not allow 1.1.1.1/32 or 1.0.0.1/32 to be reassigned to a single location.
Re: Cloudflare 1.1.1.1 Incident on July 14, 2025
#266Earlier quoted context omitted.
They don't claim that. Less than a week ago HN discussed their top resolved domains report. Such a report implies they have logs.
From their homepage: > How Quad9 protects your privacy? > When your devices use Quad9 normally, no data containing your IP address is ever logged in any Quad9 system. Of course they have some kinds of logs. Aggregating resolved domains without logging client IPs is not what the implication of "Quad9 is reselling the traffic logs" seems to be.
We're not discussing IP addresses, we are discussing whether their logs can leak your secret domain name.
Re: Cloudflare 1.1.1.1 Incident on July 14, 2025
#267Earlier quoted context omitted.
Actually, it's about 20cm from my left elbow, which is physically several orders of magnitude closer than anything run by my ISP, and logically at least 2 network hops closer. And the closest resolving proxy DNS server for most of my machines is listening on their loopback interface. The closest such machine happens to be about 1m away, so is beaten out of first place by centimetres. (-: It's a shame that Microsoft a…
Is that really a win in terms of latency, considering that the chance of a cache hit increases with the number of users?
I used to run unbound at home as a full resolver, and ultimately this was my reason to go back to forwarding to other large public resolvers. So many domains seemed to be pretty slow to get a first query back, I had all kinds of odd behaviors from devices around the house getting a slow initial connection.
Changed back to just using big resolvers and all those issues disappeared.
Re: Cloudflare 1.1.1.1 Incident on July 14, 2025
#268It's no surprise that Cloudflare is having a service issue again. I use Cloudflare at work. Cloudflare has many bugs, and some technical decisions are absurd, such as the worker's cache.delete method, which only clears the cache contents in the data center where the Worker was invoked!!! https://developers.cloudflare.com/workers/runtime-apis/cache... In my experience, Cloudflare support is not helpful at all, trying…
> some technical decisions are absurd, such as the worker's cache.delete method, which only clears the cache contents in the data center where the Worker was invoked!!!
The Cache API is a standard taken from browsers. In the browser, cache.delete obviously only deletes that browser's cache, not all other browsers in the world. You could certainly argue that a global purge would be more useful in Workers, but it would be inconsistent with the standard API behavior, and also would be extraordinarily expensive. Code designed to use the standard cache API would end up being much more expensive than expected.
With all that said, we (Workers team) do generally feel in retrospect that the Cache API was not a good fit for our platform. We really wanted to follow standards, but this standard in this case is too specific to browsers and as a result does not work well for typical use cases in Cloudflare Workers. We'd like to replace it with something better.
Re: Cloudflare 1.1.1.1 Incident on July 14, 2025
#269Earlier 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.
Quad9 is reselling the traffic logs, so it means if you connect to secret hosts (like for your work), they will be leaked
We are fully committed to end-user privacy. As a result, Quad9 is intentionally designed to be incapable of capturing end-users' PII. Our privacy policy is clear that queries are never associated with individual persons or IP addresses, and this policy is embedded in the technical (in)capabilities of our systems.
Re: Cloudflare 1.1.1.1 Incident on July 14, 2025
#270Earlier quoted context omitted.
> 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 rela…
> A cross-organizational fallback is not possible with DoH in many clients, but it is with plain old DNS.
That's client implementation lacking, not some issue inherent to DoH?
The DoH client is configured with a URI Template, which describes how to construct the URL to use for resolution. Configuration, discovery, and updating of the URI Template is done out of band from this protocol.
Note that configuration might be manual (such as a user typing URI Templates in a user interface for "options") or automatic (such as URI Templates being supplied in responses from DHCP or similar protocols). DoH servers MAY support more than one URI Template. This allows the different endpoints to have different properties, such as different authentication requirements or service-level guarantees.