I had to stop using 1.1.1.1 because I am getting rate limited when using their “cloudflared” dns-over-https proxy. My pretty modest home network and the various services running make 20-25k queries per day and I get a lot of REFUSED responses. Google on the other hand has no problem serving all of them. I even set a local cache to bypass the dns TTL but the problem is that sometimes 10 or more queries arrive at the same moment from a service.
That's not too many requests, but running any form of a home network would still benefit moderately from a local DNS server. You could even install something like dnsmasq on the most heavy-using boxes to cache lookups locally.
Granted, I'm saying this as yet another home-network admin who hasn't quite... ahem... gotten around to installing a DNS server. ^_^; I'm mostly sharing this here in case someone else has a similar problem and wants a solution.
I am running a pihole and I have set a minimum TTL of 40 minutes for the local cache, my setup is pihole --> local DoH proxy --> 1.1.1.1 as described here https://docs.pi-hole.net/guides/dns/cloudflared/
I used to use 1.1.1.1 till the day I realized that it doesn't resolve archive.is [1]. I don't particularly care what the details are, whose fault it is, etc., but as an end user, I see this a major problem because with 1.1.1.1 if my browser is unable to resolve a domain, I wouldn't know if it's my DNS's fault or if it's the site's without an explicit check. I also don't care much for family "protection", so right now I don't see a good reason for using Cloudflare over Quad9.
> In other words, Archive.is's nameservers throw a hissy fit and return a bogus IP when Cloudflare doesn't leak your geolocation info to them via the optional EDNS client subnet feature. The owner of Archive.is has plainly admitted this with a questionable claim (in my opinion) about the lack of EDNS information causing him "so many troubles."
The allegation is that Cloudflare's in the (anycast) CDN business, hence its customers do not require EDNS (ECS) to be steered to the geographically-nearest server, and so, they naturally want to kill EDNS (ECS) and that privacy's just an excuse.
As a consumer, I agree with what Cloudflare's doing (though they could potentially engineer a solution to send fake/blind EDNS (ECS)). Wearing my developer hat, I also agree with archive.is' decision to stage a protest.
It doesn't have the owner's side on it, though, which is not as evil as the article makes it sound. I can post more information when I'm home, but he basically uses that info to thwart attacks.
This has come up a few times. Mostly the owner is set in their ways and are mad at CF for not providing the DNS flags that allow outside CDNs to figure out what IP you are closest to. From a 2019 thread about this:
The archive.is owner has explained that he returns bad results to us because we don’t pass along the EDNS subnet information. This information leaks information about a requester’s IP and, in turn, sacrifices the privacy of users. This is especially problematic as we work to encrypt more DNS traffic since the request from Resolver to Authoritative DNS is typically unencrypted. We’re aware of real world examples where nationstate actors have monitored EDNS subnet information to track individuals, which was part of the motivation for the privacy and security policies of 1.1.1.1.
Can you explain the attack a bit more? One would (naively) expect that the process of the user connecting to my web server would expose their IP address (associated with their intent) to many more relevant actors (including "nationstate actors") than Cloudflare connecting to my DNS server... is the issue that the specific nationstate actor you have been concerned with is explicitly able to target and achieve surveillance on Cloudflare's outgoing traffic, but is expected to not be able to surveil the incoming traffic to my infrastructure on the other side (which sees the user's IP address way)?
Because DNS is still largely unencrypted. Nation state actors can read that information and map who is making requests for what domains.
It’s not so much a concern of the site host from getting the users IP, because the user is presumably going to visit it. This is an issue with Archive.is because they host their own DNS, not their web server.
I am sorry, can you explain this to me step by step? My computer makes a DNS request through Cloudflare, which forwards a request to archive.is's DNS server which is apparently going out of its way to carefully prevent anyone from figuring out that I wanted to access archive.is... and then my computer ruins all of that by making a direct connection to archive.is's web server. If you are a "nationstate actor" able to randomly sniff traffic in various places, the DNS request doesn't seem to add any value over the web request. What is the actual attack? Be more specific.
The "attack" is bad implementations revealing the whole IP, leaking that PII, to anybody watching DNS, instead of the query being masked to a /20, or some other subnet.
Not all VPNs route DNS queries over the VPN for performance reasons. Thus, knowing that a specific IP is visiting dissident net when that cannot be directly observed is very useful.
Your "VPN fails to prevent my ISP from seeing the DNS request" attack is already prevented by using 1.1.1.1 with DNS-over-HTTPS even if Cloudflare gives your IP address, unencrypted, to the upstream DNS server, as the only party in question there is your local ISP. I am asking after some detail on the specific attack that Cloudflare is claiming they caught nationstate actors doing wherein it matters that Cloudflare's DNS requests leak my IP address, as the only scenario I can come up with where that matters is a hypothetical attacker that specifically is monitoring Cloudflare's egress (which frankly sounds relatively difficult due to scale) but not the website's ingress (which for a website of interest seems absolutely trivial) nor the user's egress (such as many countries now seem to do routinely), either of which trivially out the user's address and intent due to the browser making a direct socket connection to the result of the DNS query.
> I used to use 1.1.1.1 till the day I realized that it doesn't resolve archive.is.
It does resolve archive.is, it’s just the archive.is nameservers return garbage if the source if CloudFlare. CloudFlare could simply fix this their end if they wanted but haven’t done so out of integrity. This looks good for CloudFlare and bad for archive.is from where I’m sitting.
Yes. From a technical standpoint, archive.is' stance is that it's actually important useful data that, more importantly, isn't a privacy violation. How much you agree with archive.is depends on a very technical understanding of the subject, or barring that, it depends on how much you buy Cloudflare's reasoning. Cloudflare's business would prefer you pay for Cloudflare (at large but specifically their anycast) instead of using an optimization available to you as a Internet business to route clients to a more optimal/closer server.
As far as the privacy implications, remember that the site you visit needs to know your IP address in order to respond to your request, so while there are some issues to be aware of, it's kind of hard to see it as a privacy violation and not Cloudflare trying to squash the little guy, imo.
The check archive.is uses to return garbage is specifically for cloudflare's IPs all other non-EDNS works fine. You can dig to there authoritative DNS server yourself to see.
There's an argument that CF benefits if that DNS extension is not in widespread usage. (Because CF sells a CDN but if sites can "just implement" that with DNS, then there's "nothing for them to sell".)
It leads to further centralization of the internet where a few have more data to make better decisions (and more money) and the smaller players are left out.
That's a fairly good argument IMO. Today's Cloudflare does not sell data. Tomorrow's, or our children's generation's, could.
As you say, this could become a monopoly and it's cool to see a popular website standing up for a future where littler guys can still make it. It's not clear to me that's the precise argument he's made so I'm just guessing.
When did HN get these new awesome nav buttons? Root, next, ... amazing!
I just installed pi-hole and it says version 4 doesn't use dnsmasq anymore [1].
edit: Nevermind, your configuration worked. I verified after flushing DNS cache that archive.is was at first inaccessible, and now after a pihole reboot it does resolve. Thanks!
I wonder if this is another way to set up the same thing with PiHole's "FTL-DNS" [2]
So if archive.is decided to also return garbage DNS results to Quad9 you would stop using them too?
I get your sentiment, but allowing one single webpage on the internet to dictate who you are allowed to use for DNS is going too far in the other direction, IMHO
It's a little ironic complaining about a single webpage on the internet, when you're suggesting that we use a single resolver on the internet instead of a distributed resolver system that we have otherwise.
FWIIW, I use the resolver of my ISP, and 100% happy with the results. If your ISP provides incorrect and fake data to make extra money on advertising, maybe you should vote with your wallet and change the ISP.
Millions of people in the US can't change their ISP. I live in a major city and would have to drop my speed by 90% if I switched to my other option. I have two options total.
Doesn't T-Mobile US offer home internet over 4G and 5G in most of the US now?
I've actually been using tethering for home internet, and it's often faster and cheaper than landline alternatives. Easily get 100Mbps in my location over 4G LTE on an old phone.
This is simply unsubstantiated — there's absolutely no reason to believe Cloudflare won't play ball with authorities.
If anything, ISP DNS being a distributed system with independent ISPs all across the world, it would be much more difficult for the major agencies to control all the individual ISPs than it would be to simply control a single global entity with a US HQ and offices and POPs worldwide — Cloudflare.
They certainly make better privacy commitments and have more transparency than my ISP.
Cloudflare DNS supports DNS-over-HTTPS and DNS-over-TLS.
Cloudflare DNS claims to anonymize IPs in logs and only retain anonymized logs for 25 hours.[1]
Cloudflare has warrant canaries[2] and publishes transparency reports[3].
Many (most?) of us do not have more than one to two choices for an ISP. Voting with our wallet is not possible and doesn't even make sense for DNS.
I agree that centralizing under Cloudflare is unideal and I would gladly switch back to my ISP's DNS servers if they provided the same level of service and made similar commitments.
DNS is distributed, by design. Your ISP operates no differently than Cloudflare, and receives routing information from peers in the exact same way. There is nothing special or unique about consumer ISP-provided DNS. A DNS provider is either the definitive source and the buck stops there for a lookup, or it forwards to a peer for resolution.
Cloudflare is not a telecom, which comes with regulation baggage that can be enforced. This matters a lot to a subpoena.
Cloudflare DNS also broke Spotify for me in a way that took me a while to discover. The Spotify desktop app would randomly stop playing music with no error message. I traced the issue back to changing my Pi-Hole upstream DNS to Cloudflare few days earlier. Switching to another DNS provider fixed the issue right away.
>I traced the issue back to changing my Pi-Hole upstream DNS to Cloudflare few days earlier. Switching to another DNS provider fixed the issue right away.
Since you're already using a pi-hole, why not just roll your own recursive DNS server.
The additional network traffic to do so is insignificant.
That way, you don't have to rely on someone else to resolve your DNS queries -- or deal with spats like that.
I've been meaning to do so for a while, but life has interrupted. As I'm going through an ISP change ATM, I will do so soon.
And I won't ever look back.
Edit: Since your post got me thinking about it, I just now went ahead and set up my recursive resolver and pointed my pi-hole at it. Took about 10 minutes on an existing VM.
I use Pi-Hole + Unbound forwarding to Cloudflare/Quad9 over TLS.
It would be nice if all servers supported DoT/DoH + DNSSEC and you could roll your own recursive DNS server and have more trust in traffic not being intercepted.
Post-Snowden revelations I feel pretty confident that DNS requests in the clear are being surveilled.
I don't know for sure that requests to Cloudflare or Quad9 are being surveilled.
>It would be nice if all servers supported DoT/DoH + DNSSEC and you could roll your own recursive DNS server and have more trust in traffic not being intercepted.
I love DNSSEC, but am not in favor of DoH/DoT. Mostly because I can't control DoH/DoT requests emanating from my network, as they're already encrypted and can't be differentiated from standard HTTPS traffic.
That's an issue (and will become a much bigger one as time passes) because vendors can use DoH/DoT to bypass local DNS controls like Pi-Hole, and short of blocking TCP/443, there's nothing you can do about it. Which is, IMNSHO, a big reason why DoT/DoH was developed.
>Post-Snowden revelations I feel pretty confident that DNS requests in the clear are being surveilled. I don't know for sure that requests to Cloudflare or Quad9 are being surveilled.
Your ISP can surveil whatever they want and there isn't much you can do about it unless you use a VPN.
>I don't think my ISP can easily intercept the content of DoT DNS requests.
No. But they can intercept connections to the IP addresses returned by such DNS queries.
>They would need a valid certificate for 1.1.1.1#cloudflare-dns.com or 9.9.9.9#dns.quad9.net from a trusted (by me) CA, correct?
In order to MiTM such requests, yes.
>Now obviously that's not impossible but is a VPN any better in that scenario?
You're only considering the DNS queries. Once you've received a response to your DoT/DoH query, presumably you'll want to connect to the returned IP address, right?
Your ISP can absolutely capture those packets, and even if the payload is encrypted, the headers are not -- so while they might not be able to access the data, they have full access to the metadata. Unless you use a VPN, which will encapsulate the headers as well.
All that said, my issue is with DoH/DoT, since devices can stealthily bypass my DNS controls (including ad/telemetry blockers like Pi-Hole) and unless I block all TLS/HTTPS traffic (making my internet link mostly useless), I can't stop surreptitious connectivity.
I'm not as concerned with my ISP as I am with not being able to block ads/tracking/telemetry. Apologies if I wasn't clear about that.
You can use eero secure+, which will intercept dns requests at the gateway to prevent devices and apps from bypassing the set dns servers. I won't work for apps which hardcore their own DoH/DoT clients and use their own servers, however.
>You can use eero secure+, which will intercept dns requests at the gateway to prevent devices and apps from bypassing the set dns servers.
I'm not familiar with eero secure+, but why would I want to pay for something like that, when a single firewall egress[0] rule can block outbound DNS requests that come from sources other than the "set dns servers"?
Note that I'm not trying to denigrate eero secure+, I don't know anything about it except that it's some sort of cloud-based (read: someone else's servers) security application.
I'm merely pointing out that limiting outbound DNS requests to specific hosts is trivial.
Post-Snowden, the lesson is the NSA is doing their damnedest to watch American's activities online. I would bet money that they're doinf everything they can to watch Cloudflare, despite no direct evidence, because of course they are.
If you can't control where your device is making DNS requests then it's not your device. It's the manufacturer's surveillance capitalist revenue generator.
We need more devices that actually respect the user.
Eh, not the GP but I had tried that and switched back to 1.1.1.1 with hosts rules for specific sites to fallback to 8.8.8.8.
Running my own DNS just proved to be too much of a troubleshooting headache, since if a site was broken it was one additional step. The pihole itself has been almost no trouble, but the diy DNS would occasionally fail to resolve a site. If I'm at home, the last thing I really want to do in the evening is troubleshoot network issues.
It was a fun project to setup, and I did learn more than I expected I would. I can recommend it as a weekend project, but not as a long-term solution.
>Running my own DNS just proved to be too much of a troubleshooting headache, since if a site was broken it was one additional step. The pihole itself has been almost no trouble, but the diy DNS would occasionally fail to resolve a site. If I'm at home, the last thing I really want to do in the evening is troubleshoot network issues.
A fair point.
That said, note the edit on the comment to which you replied.
I've been running my own authoritative DNS for (personal) domains I own for 15 years or so and have spent very little time managing that. I also run my own internal DNS servers (hybrid BIND/AD DNS) without issue.
As such, I don't expect to have many issues with a simple recursive resolver.
That said, I understand your point of view and know that managing DNS isn't for everyone.
However, I'd rather perform my own DNS lookups rather than relying on my ISP(s), Google or Cloudflare. Yes, my ISP could capture every single recursive query, but I'd rather have them do that than just log every DNS query I make.
No, it doesn't significantly add to my privacy, but (IMHO) it's better than the alternative.
I also run my own DNS servers, both internal caching resolvers and external authoritative, and and have done so since 1996. I run BIND. It takes almost zero maintenance. DNS is one of the easiest services to operate.
So you stopped using 1.1.1.1, because the owner of archive.is deliberately broke his domain so it wouldn't work on Cloudflare, specifically so he could mine your geolocation?
It seems that archive.is doesn't want to support 1.1.1.1 requests.
Solution: Resolve archive.is yourself if you want to use 1.1.1.1. For example with a host file, pihole, dnmasq, whatever. Look up archive.is once with a different DNS server then create a manual record for archive.is. Whatever.
Finally you could write a script to do this automatically in regular intervals to your taste.
Looks like a great alternative to NextDNS if you can do without any special configuration.
For me, NextDNS is still better. I can setup separate DNS zones for adults, children, IOT, etc. and it works across networks (unlike Pihole/AdguardHome). I can also setup DNS forwards for each zone.
NextDNS is fantastic. I love the level of control and flexibility it gives me to set network wide controls and then simple bypasses for the grown ups in the house.
Yeah, I would also love to get NextDNS-style offering fro CloudFlare. I'm currently have multiple malware/spyware/adds/annoyances filters enabled and I need them on DNS level because having uBlock Origin in my browser doesn't help me, for example, to prevent spying by my smart TV or phone apps.
NextDNS is great and all, but it's another third party that could be handing your data over to god knows who. PiHole is local and I don't have to worry about my data being misused.
PiHole also performs upstream DNS lookups, which could also be handed over to 3rd parties, be that Google (8.8.8.8), or Cloudflare (1.1.1.1), or even your own ISP.
With NextDNS you at least have a TOS that specifies
"1. We do not (and will never) sell, license, sublicense or share any of the data submitted directly or indirectly by our users with any person or entity.
NextDNS Inc. is an independent company 100% funded, owned and controlled by its founders and will never engage in any data sharing or selling activities, now or in the future."
As well as the option to keep logs in the EU, and thus place it under the GDPR, and since IP traffic information is generally classified as PIM, it will be covered.
Well one of my domains resolves to some dodgy russian website when using cloudflare's dns. I did everything in my power, including trying to contact them, but it still resolves to the russian host. On any other dns server it resolves correctly to gandi's parking page. Cloudflare did send me an email within 10 seconds to say that no support ticket can/will be logged since I'm not a paying customer (or just customer on their system) and that they case is closed. i get it, but it's still a nasty feeling. And yes I did use their dns flusher, it didn't help.
And the reason why it pissed me off was, I thought my mikrotik router or raspberry pi + pihole got compromised. I spent two hours trying to track down the problem, reset all dns setting on gandi, resetting and updating the router etc... just to find that it worked fine on my phone on MNO's network...then I digged further and found if I switch my dns to anything other than 1.1.1.1, it worked fine. So I don't care what features they are flinging at this point, dns being hijacked is no good.
That's an odd problem. A few possible causes jump to mind:
A. Someone is poisoning it between you and Cloudflare, but only for DNS requests directed towards Cloudflare.
B. Someone is poisoning it between Cloudflare and Gandi.
C. Someone was able to trick Cloudflare into thinking it is the authoritative DNS provider and its authoritative DNS servers are the same ones as its recursive resolvers.
D. Something got missed in troubleshooting. (Not trying to be a jerk, it's just always a possibility.)
You could probably surface whether it's A or B by playing around with DNSSEC.
All providers are in on this "free" public DNS scam for the same reason, and it makes me wonder why anyone would voluntarily donate their entire home's click analytics to a super-aggregator free of charge. Did I miss the link to the payment page?
That is almost 2 years old, and does not seem to cover aggregate processing applied before the logs are deleted. FWIW stripping the last octet is the same as happens in EDNS, it is far from anonymous.
So, they basically still collect, log and process the exact same data as Google DNS, but disallow anyone else from having it, breaking legitimate uses of DNS for GeoIP targeting and DoS mitigation? How convenient!
A good example is Cloudflare's own CDN business — they require you to delegate your domain name to their DNS servers by name, not by IP address with your own glue records on your own domain name. Because they want to be able to use all the resources available to stop DDoS, including EDNS Client Subnet provided by other resolvers.
Same goes for GeoIP — EDNS Client Subnet was specifically created for effective and cheap GeoIP. (BGP anycast isn't cheap.)
I mean, both issues are exactly why archive.is had to put the block in place. For sure both of these usecases are pretty legitimate.
BTW, what's the actual legitimate need to block ECS? After a domain name is resolved by DNS, you still have to connect directly to the hostname by an IP address, and your IP will be leaked — there's no way around this, that's how internet works. Cloudflare knowingly runs these marketing campaigns trying to obscure this simple fact that easily invalidates the need for their services, and invalidates the benefits of their service compared to competition.
The current product page still states that "a big four accounting firm" audits the service's privacy policy on a yearly retainer https://one.one.one.one/dns/
I'd much rather the opposite: an honest public DNS service that offers all data collected to the public, with some premium paid for high frequency data, and free from any conflict of interest. I would happily use a service like this since I could benefit from it.
The business case to collect DNS statistics is clear and imminently useful to numerous people and organizations, it's the complete lack of honesty about why they offer the service that bothers me.
``We are working with the small number of networks with a higher network/ISP density than Cloudflare (e.g., Netflix, Facebook, Google/YouTube) to come up with an EDNS IP Subnet alternative that gets them the information they need for geolocation targeting without risking user privacy and security. Those conversations have been productive and are ongoing. If archive.is has suggestions along these lines, we’d be happy to consider them. ``
It's a problem of their own making that doesn't require a solution.
After the client gets the IP address of the content web server from the DNS resolver, the client has to connect directly to the content web server, and the whole IP address — not just the subnet — is immediately shared with the content server anyways.
The market is supposed to regulate this abusive behaviour by showing how much slower the websites work when resolved through Cloudflare DNS compared to Google DNS or any other DNS providers that support EDNS Client Subnet. It seems that most of DNS benchmarks simply test how fast the names resolve, not how good of a resolution it is. So, it's a miss on the benchmark side.
I experimented with 1.1.1.3 on a small network segment by configuring DHCP to make 1.1.1.3 the default. I found that they resulted in numerous false-positives that turned out to be a real nuisance. As I went around to various machines and either overrode the DHCP settings with another DNS and/or added lines to the hosts file, I decided that just because you _can_ use DNS for content filtering, doesn't mean it's a particularly effective modality.
Cloudflare does have a tool that allows you to correct false positives...
https://radar.cloudflare.com/categorization-feedback/
But I found that the corrections I made were ignored with only one exception. The one I successfully corrected took many attempts over several weeks.
I ended up throwing in the towel on the whole thing and giving up on Cloudflare DNS altogether. That's not to say that others couldn't find value in it. I just found it to be more trouble than it was worth.
Who bears the brunt of the task of collecting every adult/NSFW domain out there? Doesn't such a list grow by huge numbers each day? What is the name of this list, and where can I get it?
I’m pretty sure adult sites register themselves for inclusion on this kind of blocklists because they have not a whole lot to gain and a lot to lose when serving their content to children.
I was happy to set up 1.1.1.1 for my daughter on her Iphone7 but it never seemed to work well with Mobile Data (Freedom Mobile Canada). Internet would always be spotty/non-existent. The app being used was Google Classroom. In the end we turned off 1.1.1.1 and Google Classroom started working. Anyone experience anything similar?
One thing I can think of is: perhaps some sections (all?) of their network is IPv6 only, and the carrier does XLAT64. In which case they would provide custom dns servers which resolve IPv4 dns records to IPv6 addresses. Custom DNS servers would not do that, therefore IPv4-only services would not work.
I know they consider "1.1.1.1" to also be a product name, but it's very confusing when the text says 1.1.1.1 50 times, and then there's 2 mentions of "Oh, the service is at 1.1.1.2".
This would be amazing if they have the guts to do it. I suspect they will one day when they become huge (they're already handling some 10% of global internet traffic). Today, I want a big corporate pi hole that is managed for me - enough fire power to block shitty ads.
Completely undercut Google, FB, Twitter ad machines. More eggregious are the media companies such as Adobe and their ad-tech.
For businesses ads are super important and we also need to consider the other side of the coin.
I'm not sure I follow why this would be a big deal. There are already ad filtering DNS resolvers and most people are better served by a browser extension.
It would be a huge deal. Sort of how Apple has the power to put in place a whole slew of privacy measures on the iPhone. Let Big Tech fight amongst themselves. The opposite would be terrifying.
I consider Cloudflare a formidable player wedging between Big Tech corporations.
I like it too. If Cloudflare posts become the impetus for reading the article, all the better. Their posts are well written and they don't burden the reader with what the editor wants you to know after hooking you with a headline.
It still results in kinda weird readings when the product name is also one of its subproducts but not all of them. Like a coffee shop called "The Big Cup" with a menu "The Big Cup", "The Medium Cup" and "The Small Cup".
I use a VPN to give my half-Danish children access to Danish TV from outside Denmark, and I also have, well, children who I might want to protect against evil content such as nipples. I don't do the latter but that has little to do with the fact that I use a VPN sometimes and more to do with the fact that we're not American and American ideas of what's "family friendly" feel extremely alien to us.
In fact, given that they have an option that blocks malware but not nipples, I might actually use this.
On the malware intelligence, it is a combination of first party threat intelligence (what we see on our own network) and third-party threat intelligence across open source intelligence, specialized malware intelligence vendors, and private threat sharing communities.
Any tips/ideas for configurations for selective content blocking by device? I'd like to block content on the kids' devices, but not for the adults in the household. I'm not concerned about circumvention at this point. I'm currently using a pi-hole for ad blocking, so I'd like to configure something at that level, unless there's a better way.
Put those devices on a separate subnet would be the easiest way. In order of technical complexity:
* Buy a second router, plug it into your existing one, set the DHCP options to point to 1.1.1.2
* Reconfigure your existing router to add a second subnet (192.168.2.0/24 etc) with its own SSID
* Use DHCP reservations to push 1.1.1.1 to known devices (adults) and 1.1.1.2 to all others; it could be done the other way, but all iPhones/Macs can randomize MAC addresses making evasion very simple
There may be a way to do this inside Pi-Hole, but it would probably be based on IP range rather than MAC address, which is much easier to circumvent.
Since I see from your domain name that you are in Canada, might I suggest Canadian Shield[0] from CIRA (the .ca registry) as an alternative to 1.1.1.1?
I have an article about setting it up via PiHole, too[1].
Completely off topic: These stupid illustrations (corporate memphis) are totally unneccessary. The whole blog post would read cleaner with less distraction.
If your 12 year old is getting a malicious link via whatsapp on their tablet it can make a difference. (e.g. they'll ask you why this doesn't work and you might explain malware etc)
It's certainly not something for every circumstance, but given that most people (including family members) are just end users makes sense.
If I recall, some sites providing help and information on certain things were flagged as adult content and blocked which made a bunch of people mad.
Cloudflare I think corrected a bunch, came out with a fairly reasonable explanation why, and then even showed how to setup special rules to override it.
They said that one of their providers for site-classifications had two feeds called "adult content", one which was a fairly clear porn-blocker, and one which included the LGBTQIA+ stuff as well. Apparently when they launched they flubbed which of those feeds was used because of the name-confusion.
> However, we've made it a tradition every April 1 to launch a new consumer product that leverages our network to bring more speed, reliability, and security to every Internet user.
