Archive.is’s authoritative DNS servers return bad results to 1.1.1.1 when we query them. I’ve proposed we just fix it on our end but our team, quite rightly, said that too would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service.

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.

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. For a relatively small operator like archive.is, there would be no loss in geo load balancing fidelity relying on the location of the Cloudflare PoP in lieu of EDNS IP subnets.

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.

I hesitate to compare this to Apple calling themselves “courageous” when removing the headphone jack, but in this case, I think the word is appropriate. I’ll happily stand behind you guys if you take some PR hits while forcing the rest of the industry to make DNS safer – since it is understandable, admittedly, for users to conclude that “Cloudflare is blocking websites, sound the alarms!” at first glance.

(This is not meant to suggest that archive.is's DNS response is appropriate, or that CF's setup is inappropriate.)

(Just to check my understanding of ECS: it's an extension to DNS that sends the user's subject in the request, and gets relayed with the request, s.t. an authoritative server can respond with a geo-location appropriate response/IP.)

Since HTTPS traffic already reveals communicating IPs to nation-state actors, could you clarify what attack vector removing user IP info from authoritative DNS queries protects against?

In what way does Cloudflare publish its PoP geolocation? Is it a Cloudflare-specific API? Why not fake EDNS subnet info by providing the PoP’s?

I notice of course that Google, Facebook, and Netflix still work on 1.1.1.1. Does this mean they’re currently using Cloudflare PoP geolocation in lieu of EDNS subnet information?

The current effect is I stop using 1.1.1.1 when I need archive.is (often) and set it back the next time I’m messing with my network settings.

As an aside, I used to think that when Emerson said that “a foolish consistency is the hobgoblin of little minds” he meant that we were foolish to try and be consistent. Increasingly I wonder if instead he meant that when you’re trying to reason with people who may not have the same detailed knowledge of a problem as you, there’s an enhanced importance to being consistent. Unfortunately, most policy makers globally don’t have a detailed understanding of how technical systems like DNS work, so we think it’s especially important we be consistent.

Would like to point out that Cloudflare's resolver is EDNS compliant, it just doesn't send the client subnet.

See: https://twitter.com/archiveis/status/1018691421182791680 (picture of tweet https://aws1.discourse-cdn.com/cloudflare/optimized/3X/8/2/8... )

Based on that tweet, the owner has a personal grudge against Cloudflare and is choosing to return bad results.

"Having to do" is not so direct here. Absence of EDNS and massive mismatch (not only on AS/Country, but even on the continent level) of where DNS and related HTTP requests come from causes so many troubles so I consider EDNS-less requests from Cloudflare as invalid.

> EDNS Client Subnet > >1.1.1.1 is a privacy centric resolver so it does not send any client IP information and does not send the EDNS Client Subnet Header to authoritative servers.

Cloudflare's requests are of course perfectly valid, with @archiveis actively deciding not to service them.

> 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.

So it's not just "Cloudflare benefits from pushing anycast" (even if that's part of it).

Don't take Cloudflare's PR seriously, they are completely full of it. They used to be more honest, but those days are long gone.

Many setups proxy everything but dns traffic.

That's why this topic is a thing.

https://trac.torproject.org/projects/tor/wiki/doc/Preventing...

https://ednscomp.isc.org/ednscomp/6ed2aca587

EDNS Compliance Tester says that archive.is has some issues.

https://dnsflagday.net

> Minor problems detected! > This domain does not support latest DNS standards.

Cloudflare has decided for privacy reasons they will not relay eDNS0 client subnet data - which yes, can reveal a portion of the IP of the requestor - but is used by CDN services in order to provide nearest servers or (in some cases) country specific content.

My guess here is archive.is feels they have some need to restrict what content is provided to where in the world, and as a result, without ECS in the request, takes you to a cname which essentially null routes you back to your local loop interface.

Source: Founder of DNSFilter.com - we support ECS, I coded it.

Couldn't that be done later, by blocking the actual HTTP TCP connections instead of blocking the DNS requests? Maybe it's an efficiency issue, that they want the higher-efficiency blocking by DNS rather than lower-efficiency blocking during HTTP TCP, but that seems a little strange to me.

Unfortunately, Archive.is has to fix it from their nameservers and we cannot do anything from our side. You can ready more about it here: https://community.cloudflare.com/t/archive-is-error-1001/182...

Disclaimer: I work at Cloudflare

https://community.cloudflare.com/t/archive-is-error-1001/182...

> Nameservers responsible for archive.is (ben.archive.is, anna.archive.is) are returning answers tailored to the IP address of the requestor.

And indicate that anyone who knows how to contact archive.is can ask them to resolve the issue:

> If you have a contact on the domain owner, you can ask them to fix this.

EDIT: This is knowingly blocked by archive.is. Reasoning and discussion elsewhere in post comments. No need to contact archive.is about it, they’re clearly aware.

As soon as I realized they were causing this issue I just switched away. Other DNS providers don't have this issue.

What makes the response incorrect? I was under the impression that DNS implementations were under no "practical" obligation to return consistent queries to differing requester IP addresses (hence stuff like split-horizon DNS and EDNS: https://developers.google.com/speed/public-dns/docs/ecs )

archive.is has configured their nameservers to return invalid (127.0.0.0/8, from the looks of it) responses to Cloudflare requests because they’re protesting Cloudflare’s lack of EDNS, not because EDNS is somehow required to handle the requests.

For context: EDNS sends the origin IP address of the DNS client through the resolver. Cloudflare has it disabled because of the privacy implications of sending it along.

Maybe cloudflare doesn't want to code an ad-hoc solution just to fix one site. But that doesn't matter to the customer, who just wants it to work.

If a dev updates their code so it won’t run unless an kernel flag is enabled, the kernel hasn’t broken userspace, and kernel devs are unlikely to add a “fake-enabled-flag” to trick the userspace program, even if it’s popular.

Likewise, I don’t expect my DNS resolver to add in custom behavior if upstream DNS servers make breaking changes like this. In fact, I very much prefer the opposite: my DNS service should be as dumb as possible. I don’t want it making choices about how to modify DNS queries I do, or their results.

If an upstream site broke their DNSSEC config, would you lobby for Cloudflare to modify the results so resolution succeeded for their users?

Every other resolver supports EDNS

Archive.is only works with resolvers that support EDNS

Cloudflare decided not to support EDNS

That itself is a defendable decision but I do feel for a popular site they could implement some sort of fix.

    dig @carl.archive.is archive.is A +noedns

    curl http://134.119.220.26 -H 'Host: archive.is' -v

I'm not a dig expert, but I believe this means it works without EDNS. I think that means archive.is is specifically blocking Cloudflare's servers, not blocking all non-EDNS requests.

[1] https://developers.cloudflare.com/1.1.1.1/nitty-gritty-detai...

[2] https://twitter.com/archiveis/status/1018691421182791680

  nslookup archive.is 1.1.1.1
  Server:  1.1.1.1
  Address: 1.1.1.1#53

  Non-authoritative answer:
  Name: archive.is
  Address: 134.119.220.26

    dig @1.1.1.1 archive.is
    
    ; <<>> DiG 9.14.1 <<>> @1.1.1.1 archive.is
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46862
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,     ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1452
    ;; QUESTION SECTION:
    ;archive.is.                    IN      A

    ;; ANSWER SECTION:
    archive.is.             2998    IN      A       127.0.0.4

    ;; Query time: 52 msec
    ;; SERVER: 1.1.1.1#53(1.1.1.1)
    ;; WHEN: Sat May 04 21:03:36 CEST 2019
    ;; MSG SIZE  rcvd: 55

    dig @8.8.8.8 archive.is

    ; <<>> DiG 9.14.1 <<>> @8.8.8.8 archive.is
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5893
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0,     ADDITIONAL: 1

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;archive.is.                    IN      A

    ;; ANSWER SECTION:
    archive.is.             299     IN      A       94.16.117.236

    ;; Query time: 79 msec
    ;; SERVER: 8.8.8.8#53(8.8.8.8)
    ;; WHEN: Sat May 04 21:04:28 CEST 2019
    ;; MSG SIZE  rcvd: 55

https://www.dnsleaktest.com/what-is-transparent-dns-proxy.ht...

    Server:  1.1.1.1
    Address: 1.1.1.1#53

    Non-authoritative answer:
    Name: archive.is
    Address: 127.0.0.4

>EDNS Client Subnet

>1.1.1.1 is a privacy centric resolver so it does not send any client IP information and does not send the EDNS Client Subnet Header to authoritative servers.

What does this mean?

https://blog.cloudflare.com/why-we-terminated-daily-stormer/

And well, in any case this is unrelated to this thread...