Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1) >>19828317
- This particular discussion includes a comment from Cloudflare's CEO, referenced in the article: >>19828702
Why does 1.1.1.1 not resolve archive.is? >>21155056
- StackExchange question, on the subject
Does Cloudflare's 1.1.1.1 DNS Block Archive.is? (2019) >>28495204
- Discussion of this blog post
> 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.
Surfacing here for people who like to read comments before clicking through to the article.
TLDR: the site owner was returning wrong DNS responses for people using Cloudflare's 1.1.1.1 DNS service because the site owner doesn't like Cloudflare.
Most relevant piece but the whole comment is worth a read:
> 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.
Honestly it's that type of thing (the frankness, the presence on HN, willingness to participate, the principled stand on privacy) that got me into Cloudflare products. I now generate hundreds per month in revenue for them and that will likely be thousands in the next year or two. His time/effort on HN directly led to customer acquisition and revenue.
That said I do worry about the incentives Cloudflare has to their big customers. CF is a great tool for site owners, but like any tool has the potential to be a great evil (against the user) if the principles ever wane. It's already being used by a lot of sites to make life a living hell for people behind a VPN. As a site owner I absolutely get it: practically zero of my legitimate traffic comes from VPNs (our main demographic tend to skew older and much less technical than the average consumer), but all of the automated attacks against me do. Balancing freedom and rights is hard, but I deeply appreciate the thoughtfulness and principles that CF has displayed over the years.
[1] >>36197401
[2] https://www.ietf.org/archive/id/draft-private-access-tokens-...
[1] >>36972051
[2] >>36971869
That's a bit unfair, don't you think?
From what I remember of the saga, the original reason for Archive.is's block is that they run their own CDN, and by not knowing the location of the user, they can't determine the closest server to respond with.
edit: found source https://twitter.com/archiveis/status/1018691421182791680
So the alternative viewpoint is, that Cloudflare is being anti-competitive by technically preventing other CDN providers from working.
Disclosure: I'm a happy Cloudflare user, but all in all I think Archive.is service is far more fundamental for the internet (especially as it's 100% free!). So I would really appreciate if you could figure out a way of working together. Until then, 8.8.8.8 it is!
[1] >>36971650
This isn't true, because the request leaks the hostname in the handshake via SNI:
┌─(~/Projects/malware/triangulation)(ruby-2.5.0)────────────────────────────────────────────────────────────────────(c@c:s001)─┐
└─(12:32:59)──> nslookup archive.is 1.1.1.1 ──(Wed,Aug02)─┘
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: archive.is
Address: 89.253.237.217
┌─(~/Projects/malware/triangulation)(ruby-2.5.0)────────────────────────────────────────────────────────────────────(c@c:s001)─┐
└─(12:38:12)──> nslookup archive.is 1.0.0.1 ──(Wed,Aug02)─┘
Server: 1.0.0.1
Address: 1.0.0.1#53
Non-authoritative answer:
Name: archive.is
Address: 89.253.237.217
┌─(~/Projects/malware/triangulation)(ruby-2.5.0)────────────────────────────────────────────────────────────────────(c@c:s001)─┐
└─(12:38:14)──> whois 89.253.237.217 ──(Wed,Aug02)─┘
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
refer: whois.ripe.net
inetnum: 89.0.0.0 - 89.255.255.255
organisation: RIPE NCC
status: ALLOCATED
whois: whois.ripe.net
changed: 2005-06
source: IANA
# whois.ripe.net
inetnum: 89.253.232.0 - 89.253.239.255
org: ORG-RL31-RIPE
netname: RU-RUSONYX-NET6
descr: Network for Rusonyx infrastructure
country: RU
mnt-lower: MNT-RUSONYX
mnt-routes: MNT-RUSONYX
admin-c: VZ1716-RIPE
admin-c: VZ1717-RIPE
tech-c: VZ1716-RIPE
status: ASSIGNED PA
mnt-by: MNT-RUSONYX
created: 2018-10-10T09:53:33Z
last-modified: 2018-10-16T12:37:40Z
source: RIPE # Filtered
organisation: ORG-RL31-RIPE
org-name: Rusonyx, Ltd.
country: RU
org-type: LIR
address: 5th st. Yamskogo Polya, 9, office 19
address: 125040
address: Moscow
address: RUSSIAN FEDERATION
phone: +74951370701
fax-no: +74951370701
mnt-ref: RIPE-NCC-HM-MNT
mnt-ref: MNT-RUSONYX
mnt-by: RIPE-NCC-HM-MNT
mnt-by: MNT-RUSONYX
abuse-c: AD11015-RIPE
created: 2006-08-18T09:59:51Z
last-modified: 2022-10-06T11:18:08Z
source: RIPE # Filtered
person: Viktor Zverkov
address: P.O. Box 19
address: 127137, Moscow, Russia
address: Rusonyx ltd.
phone: +7 495 5089959
nic-hdl: VZ1716-RIPE
mnt-by: MNT-RUSONYX
created: 2017-09-20T11:29:16Z
last-modified: 2022-07-05T14:00:10Z
source: RIPE
person: Viktor Zaytsev
address: P.O. Box 19 , Russia
address: 127137, Moscow
address: Rusonyx ltd.
phone: +7 495 5089959
nic-hdl: VZ1717-RIPE
mnt-by: MNT-RUSONYX
mnt-by: AM65535-MNT
created: 2017-09-20T11:54:54Z
last-modified: 2018-08-02T17:21:31Z
source: RIPE
% Information related to '89.253.232.0/21AS41535'
route: 89.253.232.0/21
descr: RUSONYX-RU
origin: AS41535
mnt-by: MNT-RUSONYX
created: 2017-11-24T09:34:37Z
last-modified: 2017-11-24T09:34:37Z
source: RIPE
% This query was served by the RIPE Database Query Service version 1.107 (DEXTER)
[1] >>36971650
EDIT: This is outlined in [0], although it doesn't go into the depth I wish it did.
> By providing local Internet egress and by configuring internal DNS servers to provide local name resolution for Microsoft 365 endpoints, network traffic destined for Microsoft 365 can connect to Microsoft 365 front end servers as close as possible to the user.
[0] https://learn.microsoft.com/microsoft-365/enterprise/microso...
Archive.is' explanation is quoted in a comment below:
Works for me on Linux in Firefox and Chromium.
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.
> 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.
Cloudflare sends the closest city from where the request was made which ought to be sufficient to optimize for a cdn I guess? Appears that archive.is doesn't have a locus standii in this debate...
> 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.
0. https://medium.com/nextdns/how-we-made-dns-both-fast-and-pri...
For example in unbound the defaults, when EDNS0 is enabled (disabled by default), are:
max-client-subnet-ipv6: 56
max-client-subnet-ipv4: 24
ref: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound...
EDIT: another comment, though somewhat hearsay, suggests that Cloudflare's caching could make this difficult to implement: >>36971650
>>all requests for 7 archive.* domains are sent from Symantec USA IP
It might be that the archive.is only lies to that IP, which would explain why many users in this thread say that archive.is does resolve correctly for them with 1.1.1.1
Yes you can. After you put in the URL, you get a button to do so. I just did it for your comment: https://web.archive.org/web/20230802205505/https://news.ycom...
Archive.is believes that Cloudflare can simply provide the full EDNS data, and they're technically right. But Cloudflare won't budge because they believe this is hostile to user privacy. I haven't heard a counterargument that Cloudflare is wrong about this.
Cloudflare believes that Archive.is can simply live without the EDNS data, and they're technically right. But Archive.is won't budge because they believe it prevents their abuse prevention techniques. They mention that owning their own AS would solve the problem but that's too expensive.[1]
Blame is in the eye of the beholder, but it seems to me that Archive.is should find alternative abuse prevention techniques like other websites do. Cloudflare has an argument based on privacy. Archive.is has an argument based on the proper solution being too expensive. The expense of running an AS is disputed in this HN thread.[2]
[1] >>36971650
[2] >>36977654
IIRC WARP was only able to forward your origin IP to websites using Cloudflare. Then, as of Aug 2022, their FAQ[1] says your origin IP is hidden regardless of which website. Their IPs do reveal your geolocation though.
There was a bug[2] that revealed your IP to select websites; that seems to have been fixed by Nov 2022.
Disclaimer: I’m not knowledgeable enough to test every possible IP leak mechanism (like WebRTC), so I didn’t do that. I’m basically taking their word for it.
[1] https://developers.cloudflare.com/warp-client/known-issues-a...
[2] https://community.cloudflare.com/t/beware-cloudflare-warp-do...
archive.today - FAQ : https://archive.md/faq
archive.today - wiki : https://wiki.archiveteam.org/index.php/Archive.today
archiveteam wiki : https://wiki.archiveteam.org/
Tumblr : https://archive-is.tumblr.com/
Twitter : https://twitter.com/archiveis
archive.today
archive.ph
archive.is
archive.li
archive.vn
archive.fo
archive.md
archiveiya74codqgiixo33q62qlrqtkgmcitqx5u2oeqnmn5bpcbiyd.onion
True, but it's still the difference between being able to load all embedded resources from a server close to the user or potentially having to haul all of that across an ocean, considering TCP congestion window scaling (which is sensitive to round trip times) etc.
All that said, based on a purported comment by the maintainer of archive.is, the aim of their CDN is actually not improving responsivity, but delaying legal/law enforcement responses: >>36971650
> Archive says that privacy is preserved because they truncate the PII.
Personally, I don't have a lot of sympathy for either party here:
I think, especially given the comment linked above, Archive's latency/efficiency concerns are just pretext for quite different concerns of their own (having to deal with law enforcement).
And on the other hand, while Cloudflare's EDNS subnet truncation might help user privacy in a few edge cases (as many have said here, the visited site will get the user's IP as soon as they connect to their servers!), it also makes it that much harder for CDNs other than Cloudflare to efficiently serve content using DNS-based routing and forces them to also use Anycast, which is much harder to do.