zlacker

If you're using a Pi-hole for your DNS (or anything else using dnsmasq I suppose), I worked around the issue by creating /etc/dnsmasq.d/02-archive.is.conf (with a Docker bind mount in my case) with the following content:

    server=/archive.today/8.8.8.8
    server=/archive.today/8.8.4.4
    server=/archive.ph/8.8.8.8
    server=/archive.ph/8.8.4.4
    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.vn/8.8.8.8
    server=/archive.vn/8.8.4.4
    server=/archive.fo/8.8.8.8
    server=/archive.fo/8.8.4.4
    server=/archive.md/8.8.8.8
    server=/archive.md/8.8.4.4
    server=/archive.to/8.8.8.8
    server=/archive.to/8.8.4.4

This way you use 1.1.1.1 for everything, except the domains listed above where it uses Google DNS instead.

>>Goz3rr+(OP)
And you leak your location, don't you?

>>croes+ka
as does your IP. Where is the win?

>>croes+ka
... less than when you connect to the archive.is servers for http requests

>>croes+ka
Do you know how DNS works ?

You as for a record, you get answer. You ask for IP adddress of archive.today, you get that IP

Then you connect to that IP

If your DNS doesn't leak client IP, the browser connecting to server IP will leak it.

It's entirely irrelevant protection that does nothing but makes competing on cdn harder.

>>Goz3rr+(OP)
Or you could just not use 1.1.1.1. There are other players in this space, and unless you are querying DNS but not connecting to the server to get content, the server is going to know your ip.

>>croes+ka
As you do when you connect to any website ?

>>adql+yk
I was willing to give CF the benefit of the doubt, until other posters (and you) pointed out that this is a red herring. Also given Stavros' note [1] on how archive.is needs the EDNS data to protect themselves from CSAM/ISIS material based attacks and that they suggested solutions but CF refused to cooperate, I'm unsure of the motives behind these posters claiming CF is protecting privacy. Matthew Prince's motives in his truth-but-not-full-truth response are obvious.

[1] >>36971650

>>ninjag+sm
I'm still giving cf the benefit of the doubt, but I need more research.

I always found the funding of archive.is unknown. Who is behind it and why do they want this info. Why and how they can provide this for free is a big unknown to me.

I'm giving cf the benefit of the doubt against archive. At least I know cloudflare and this would be the first "doubt-moment"...

It's weird that others don't have this issue that much, I would have thought that CDN's would scream from everywhere for years already, if archive.is his statement is "complete".

Edit: cloudflare does not seem to block what's needed though.

>>19828702

> EDNS IP subsets can be used to better geolocate responses for services that use DNS-based load balancing. However, 1.1.1.1 is delivered across Cloudflare’s entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results.

>>adql+yk
>If your DNS doesn't leak client IP, the browser connecting to server IP will leak it.

The issue isn't leaking your IP to archive.today. It's leaking your IP to any other dns servers along the way

Do you know how recursive DNS works?

>>ploxil+0g
It's like a cab driver being overly concerned that when I arrive at my destination, they will be able to know who I am just by looking at me.

"Yea.. thanks dude. Just.. drive the car, will ya?"

>>croes+ka
In addition to what others mentioned, typically EDNS0 edns-client-subnet is truncated before forwarding.

For example in unbound the defaults, when EDNS0 is enabled (disabled by default), are:

  max-client-subnet-ipv6: 56
  max-client-subnet-ipv4: 24

Forwarding can also be conditionally enabled for specific clients, upstream servers, specific zones, etc.

ref: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound...

>>ninjag+kl
It's not just about the server you're connecting to knowing your IP, that's a given. With ECS every recursive DNS server in the chain also knows which site you want to visit

>>akira2+NB
The problem is that there are more parties than you, your DNS server (the cab driver) and your destination (the website). The cab driver might have to ask a number of other people how to get to the destination.

Your DNS server probably doesn't have the exact record for you at the ready, but it does know another DNS server that gets you closer to an answer. That's how recursive DNS works and it might happen a few times before you actually get to a result. With ECS now every DNS server in this chain knows 12.45.56.x wanted to visit hacker news.