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.
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?
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
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]
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
http://someonewhocares.org/hosts/
https://github.com/jmdugan/blocklists/tree/master/corporatio...
etc
Just wanted to say: Thank you for posting an actual solution!
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 seems like you don’t fit the target audience for this service at all.
[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.
If you care about performance there is a pretty significant gap between them [0].
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.