1.1.1.1 for Families
blog.cloudflare.com
blog.cloudflare.com
Understanding the # of unique names, peak QPS, % of response types, etc will help.
I consider it a “bug” if you can take the same profile of DNS queries to another resolver and see no issues ;-)
I suspect you hit some sub-second ratelimit.
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.
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.
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.
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.
> 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."
Not sure how it’s 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.
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
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.
> we use a single resolver
Cloudflare is still doing BGP like your ISP.
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.
Cloudflare is not a telecom, which comes with regulation baggage that can be enforced. This matters a lot to a subpoena.
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.
[1] https://blog.cloudflare.com/announcing-the-results-of-the-1-...
[2] https://www.cloudflare.com/learning/privacy/what-is-warrant-...
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.
I have a ton of home automation, a few HD cameras, and household members who stream video (or play games) basically 24/7.
Plus, if you get so much bandwidth from your provider, are they really still messing about with your DNS?
Not a lot an option for many, most of my life I've lived in areas that only have a single choice.
I use the resolver of my ISP also, and they must recurse to cloudflare, because by default archive.is is broken for me at home.
I am not going to change my ISP and not going to bow down to a single website that chooses to go against the good faith of distributed systems.
I just don't visit their site anymore because that is the decision that they have made.
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.
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".)
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!
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.
Also, what about DNS resolvers that don’t support EDNS at all?
Just put the IPs on your hosts file, it's easy. https://dns.google/query?name=archive.is
54.37.18.234 archive.today
54.37.18.234 archive.is
While there try a hosts blocklisthttp://someonewhocares.org/hosts/
https://github.com/jmdugan/blocklists/tree/master/corporatio...
etc
Just wanted to say: Thank you for posting an actual solution!
It seems like you don’t fit the target audience for this service at all.
If you care about performance there is a pretty significant gap between them [0].
[0] https://community.spotify.com/t5/Desktop-Windows/Random-Stop...
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.
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.
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.
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.
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.
We need more devices that actually respect the user.
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?
Now obviously that's not impossible but is a VPN any better in that scenario?
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.
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.
server=/archive.is/8.8.8.8
server=/archive.is/8.8.4.4
server=/archive.li/8.8.8.8
server=/archive.li/8.8.4.4
server=/archive.to/8.8.8.8
server=/archive.to/8.8.4.4
server=/archive.today/8.8.8.8
server=/archive.today/8.8.4.4
And restart dnsmasq (or just reboot the pi)This will resolve the common archive.is domains using Google's DNS service rather than 1.1.1.1 but everything else via 1.1.1.1 as normal.
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]
You do you, I guess.
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.
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.
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.
This release claims:
> * Since launching 1.1.1.1, the number one request we have received is to provide a version of the product that automatically filters out bad sites.*
Really? More asked for than ad blocking or tracker blocking?
I switched all my networks back to google's dns.
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.
I'm not certain, but you might be able to figure out if it's C with this: https://rdap.cloudflare.com
Cisco at least release some low frequency summaries of the data they are able to collect: https://s3-us-west-1.amazonaws.com/umbrella-static/index.htm...
What legitimate uses would those be, and how is DNS involved in DoS mitigation?
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 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.
https://news.ycombinator.com/item?id=19828317
``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. ``
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.
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.
https://raw.githubusercontent.com/StevenBlack/hosts/master/a...
Noticed some of them weren't NSFW domains, just problematic ad-tech domains, but still very useful.
May well have been something else though.
https://developers.cloudflare.com/1.1.1.1/1.1.1.1-for-famili...
1.1.1.2 (1.1.1.1 for families)
Or more correct:
1.1.1.3 (1.1.1.1 for families)
1.1.1.1 - General
1.1.1.2 - No Malware
1.1.1.3 - No adult content
Personally I like how they laid this out, makes it super easy to remember.
1.1.2.2 - No Malware and no ads
1.1.2.3 - No adult content and no ads
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 consider Cloudflare a formidable player wedging between Big Tech corporations.
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.
* 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.
And they have a super generous free tier!
I have an article about setting it up via PiHole, too[1].
[0]: https://www.cira.ca/cybersecurity-services/canadian-shield
Also, people should really be using Dnscrypt-proxy/DoH/DoT. Otherwise it's really easy for your ISP just to read/capture your DNS requests.
FWIW, I'm one of today's lucky 10,000 and am thankful to have seen it.
With ad-blocking!
It's certainly not something for every circumstance, but given that most people (including family members) are just end users makes sense.
> 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.