tl;dr: No. Quite the opposite, actually — Archive.is’s owner is intentionally blocking 1.1.1.1 users.

CloudFlare’s CEO had this to say on HackerNews:

We don’t block archive.is or any other domain via 1.1.1.1. […] 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.

I am mainly making this post so that admins/moderators at BeeHaw will consider using archive.org or ghostarchive.org links instead of archive.today links.

Because anyone using CloudFlare’s DNS for privacy is being denied access to archive.today links.

https://ghostarchive.org/archive/PmSkp

  • Hot Saucerman@lemmy.mlOP
    link
    fedilink
    English
    arrow-up
    56
    ·
    edit-2
    10 months ago

    https://news.ycombinator.com/item?id=19828702

    Here’s the full comment on HackerNews, the article quoting him only had the snippet. The larger comment makes more sense. Emphasis mine.

    We don’t block archive.is or any other domain via 1.1.1.1. Doing so, we believe, would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service.

    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.

    So it’s really more about metadata related to the IP, like geolocation.

    • jarfil@beehaw.org
      link
      fedilink
      arrow-up
      4
      ·
      10 months ago

      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.

      Couldn’t they just put that as the EDNS?

    • nyan@lemmy.cafe
      link
      fedilink
      English
      arrow-up
      4
      ·
      10 months ago

      That . . . really looks like a game of DNS chicken. In Cloudflare’s place, I’d just shrug, provide garbage EDNS data that meets the technical requirements (probably pointing at archive.is’s own location), and move on, but they’re apparently too wrapped up in their principles to blink first.