
Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1) - ikeboy
I noticed I couldn&#x27;t connect to archive.is, eventually I figured out it was an issue with cloudflare DNS, 1.1.1.1. Checking nslookup confirms this:<p>nslookup archive.is 1.1.1.1
Server:  1.1.1.1
Address: 1.1.1.1#53<p>Non-authoritative answer:
Name: archive.is
Address: 127.0.0.4<p>nslookup archive.is 8.8.8.8
Server:  8.8.8.8
Address: 8.8.8.8#53<p>Non-authoritative answer:
Name: archive.is
Address: 94.16.117.236<p>Cloudflare is returning a localhost address which prevents you from accessing the website.
======
eastdakota
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.

~~~
CodeWriter23
@eastdakota what about just failing without response on archive.is calls so
the second resolver address configured in the client will be used? I
understand this is also a DNS integrity violation, however the result for the
end user would be either the same if they don’t have a second resolver
configured or enhanced if they do.

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.

~~~
eastdakota
DNS either has integrity or it doesn’t. We get a response from an
Authoritative server and, as a Resolver, we believe our responsibility is to
return it. If we start making exceptions because of bad PR, how can you trust
us to do the right thing when the stakes are even higher (e.g., nationstate
pressure)?

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.

~~~
CodeWriter23
My take on the Emerson quote you mention is to be mindful instead of mindless
when it comes to consistency. I respect the commitment to consistency you
convey (and I do think it is mindful).

------
judge2020
The problem is the archive.is (and other TLDs) server not returning _any_ Good
IP if the EDNS client subnet isn't present.

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](https://twitter.com/archiveis/status/1018691421182791680)
(picture of tweet [https://aws1.discourse-
cdn.com/cloudflare/optimized/3X/8/2/8...](https://aws1.discourse-
cdn.com/cloudflare/optimized/3X/8/2/82f80904fab6661263389595d60ef7d9b7f16eaa_2_442x500.png)
)

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

~~~
floatingatoll
Text of tweet by @archiveis:

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

~~~
arghwhat
For additional context, here is the Cloudflare explanation about EDNS client
subnets:

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

~~~
zzzcpan
It has nothing to do with privacy, as the next thing following DNS resolution
is establishing a TCP connection which always leaks full IP address to the
same person or organization controlling authoritative servers. Basically EDNS
is just a convenient way for DNS-based CDNs to provide a better edge node. But
this is directly competing with Cloudflare, so Cloudflare invents excuses not
to implement something that helps other CDNs.

~~~
judge2020
See the CEO's comment:
[https://news.ycombinator.com/item?id=19828702](https://news.ycombinator.com/item?id=19828702)

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

~~~
zzzcpan
So, what he claims is that state actors monitor traffic at certain locations,
extract subnet information from DNS packets that only large centralized DNS
resolvers include when query some authoritative servers that where probed to
support that feature. That subnet is not a subnet of an end user IP address,
but an IP address of a recursive resolver of that user's ISP. They have to
correlate that information with a connection made from that ISP to a web
server to track the user. What 1.1.1.1 brings here? State actors now can
correlate an actual IP address sending data to 1.1.1.1, with a clear text DNS
query going out of it, making tracking more reliable and simple and worse for
privacy. And still worse for other CDNs.

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.

~~~
MrStonedOne
1.1.1.1 supports dns/https. It is entirely possible to make a request to
1.1.1.1 for an ip and have nobody be able to know what you made the request
for.

There is no guarantee the name server they are querying is the same as the
server in the A result, and the idea is to reduce the number of points where
people other than the A result and the client know that they plan to talk to
each other.

It's not bullshit.

~~~
zzzcpan
> There is no guarantee the name server they are querying is the same as the
> server in the A result

That's ok. Let me try to explain a bit more:

Queries to 1.1.1.1 are going over public internet. And even though they are
encrypted, they also carry metadata with them, including IP addresses of who
is doing them, precise time, rough size, various OS specific stuff, etc. And
packets going out to authoritative servers from 1.1.1.1 are in clear text.
There is a very tiny window of possible queries out of 1.1.1.1 for encrypted
data coming in from some IP address and therefore only a tiny number of
possible responses from authoritative servers. Given that and enough
intercepted data all over the world it is easy to correlate clear text DNS
responses with IP addresses or who got responses from cache and on which
popular website ended up, etc.

~~~
Aeolun
Not quite as easy as when you just have to intercept traffic at one of the
intermediate nodes though, it seems.

I think that makes the privacy argument a fairly valid thing.

~~~
zzzcpan
You seem to misunderstand it. There are less points to intercept traffic at
with 1.1.1.1, than without it. Much more feasible to spy on a massive scale,
much less privacy and usefulness of client subnet EDNS option completely
disappears. In 1.1.1.1 case it's literally irrelevant for privacy whether they
do it or not. 1.1.1.1 already hurts privacy massively and not passing client
subnet only hurts competing CDNs.

~~~
arghwhat
This is no longer a factual discussion. You mention two separate issues:

1\. Use of EDNS client subnet information harms user privacy, by providing
information that would not otherwise be there.

2\. Many users on a single global DNS provider lowers the amount of _points_
that needs to be attacked to obtain DNS information.

However, you position your statement as if #2 somehow render #1 moot, which is
an entirely subjective evaluation from the perspective of a user, and also not
at all relevant to the discussion of #1, as that on its own is not 1.1.1.1
specific.

For an example of why this is very subjective, the user may believe that the
security of ISP DNS servers is likely not trustable, and that infiltrating
countless ISP DNS services would likely be much less work than infiltrating
one of the larger providers, such as 1.1.1.1, with better security practices.

The only things relevant to this discussion is whether or not it is sensible
to respond with bogus data to a valid request that does not contain optional
fields, and _separately_ whether or not it is sensible for a DNS provider to
not contain these fields.

------
LogicX
For those curious about what is going on here...

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.

~~~
Thorrez
>My guess here is archive.is feels they have some need to restrict what
content is provided to where in the world

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.

------
irtefa
This has been a known issue for a while.

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...](https://community.cloudflare.com/t/archive-is-
error-1001/18227/8)

Disclaimer: I work at Cloudflare

~~~
9HZZRfNlpR
The person or persons running the site have a history of very stubborn
behaviour. I do appreciate the service they are running.

One time they blocked the whole Finland because the owner had problems with
customs and somehow related the incident with Russia while saying Finnish gov
and bur businesses can never be independent.

------
rmdoss
Archive.is is very interesting. I was checking and they block (by responding
back with 127.0.0.3):

\- 1.1.1.1

\- Neustar DNS

\- AdGuard DNS

But they don't block Quad9 or CleanBrowsing that also do not send the EDNS
subnet. Very curious way of blocking itself out of the Internet. OpenDNS
blocks it (sends to their block page):

[https://dnsblacklist.org/?domain=archive.is](https://dnsblacklist.org/?domain=archive.is)

Would love to hear from someone from archive.is what is going on.

------
derimagia
I remember reading this a while back. It sounded more that archive.is was
blocking Cloudflare (or at least not supporting it):
[https://community.cloudflare.com/t/archive-is-
error-1001/182...](https://community.cloudflare.com/t/archive-is-
error-1001/18227)

~~~
ignoranceprior
Does anyone know why archive.is would block Cloudflare? Is it a technical
issue, or does the owner of archive.is have some kind of grudge against them?

~~~
altfredd
Cloudflare uses "privacy" and "caring about users" as excuses to sabotage
competing CDNs (including whatever CDN is used by archive.is).

Most recursive DNS severs on Internet can be categorized in two groups: local
DNS servers, offered by Internet providers to their users, and enormous
"generic" DNS like Google's 8.8.8.8. When someone makes a DNS request to those
servers, they will in turn forward it to DNS servers of web page you are
requesting. Content Delivery Networks use DNS to determine, which server
should serve your request: if your DNS request arrived from Africa, CDN's DNS
server will return IP in Africa. Of course, _users_ don't send DNS requests to
CDN's server — recursive DNS servers do. In the past almost everyone used DNS,
offered by their Internet provider, — CDN's had to use GeoIP or even static
lists of providers to determine origin of that request. When world-wide DNS
servers like Google's 8.8.8.8 started to gain popularity, that approach was
broken, so EDNS was developed.

Cloudflare is a CDN. They are selling their CDN services for money. At the
same time they are encouraging end users to use free DNS server, that does not
support EDNS _on purpose_ (they admit so on their website). In effect they are
creating a situation, when competing CDNs are at disadvantage and can't
determine, what country user comes from. Cloudflare itself does not suffer
from that disadvantage, because they control both 1.1.1.1 and DNS, used by
their clients' websites.

~~~
tambre
I think your accusations are factually incorrect. EDNS was created back in
1999 (RFC2671[0]) waaaaay before Google's 8.8.8.8 in 2009.

And Cloudflare _is_ EDNS-compliant. They simply choose not to enable the
optional EDNS extension released in 2016 for sending the client subnet for
privacy reasons.

Here's what RFC7871 – Client Subnet in DNS Queries[1] says about itself
(emphasis mine):

This document defines an EDNS0 [RFC6891] option to convey network information
that is relevant to the DNS message. It will carry sufficient network
information about the originator for the Authoritative Nameserver to tailor
responses. It will also provide for the Authoritative Nameserver to indicate
the scope of network addresses for which the tailored answer is intended. This
EDNS0 option is intended for those Recursive Resolvers and Authoritative
Nameservers that would benefit from the extension and _not for general purpose
deployment_. This is _completely optional_ and can safely be ignored by
servers that choose not to implement or enable it.

As far as I know, the standard practice, before this optional EDNS extension
was to do GeoDNS based on the resolver's IP. This works just fine, including
in the case of Cloudflare, since they've got 150+ POPs with each resolving on
their own. That's higher density than most CDNs.

[0]:
[https://tools.ietf.org/html/rfc2671](https://tools.ietf.org/html/rfc2671)

[1]:
[https://tools.ietf.org/html/rfc7871](https://tools.ietf.org/html/rfc7871)

------
ikeboy
Looks like it's a known issue [https://community.cloudflare.com/t/archive-is-
error-1001/182...](https://community.cloudflare.com/t/archive-is-
error-1001/18227/4), yet not been fixed for at least a year

~~~
floatingatoll
In response to that "unfixed" issue, they noted - in a timely manner, last
year - that archive.is is returning bad IPs to them, which is preventing them
from serving good IPs:

[https://community.cloudflare.com/t/archive-is-
error-1001/182...](https://community.cloudflare.com/t/archive-is-
error-1001/18227/3)

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

~~~
ikeboy
Just like we consider it the kernel's fault if user applications break due to
a change, I think it's the DNS resolver's fault if they're using a protocol
that some popular sites don't support.

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

~~~
akerl_
It doesn’t really seem to be the resolvers “using a protocol that [archive.is]
doesn’t support”; it seems that archive.is responds to queries from
Cloudflare’s systems with an incorrect response. How is Cloudflare meant to
work around that kind of behavior?

~~~
Chlorus
>"it seems that archive.is responds to queries from Cloudflare’s systems with
an incorrect response."

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](https://developers.google.com/speed/public-dns/docs/ecs) )

~~~
akerl_
Sorry, to clarify: when archive.is receives a DNS lookup from Cloudflare’s
resolvers, they reply with an IP in the 127.0.0.0/8 range, so the origin
client is unable to connect (since those IPs aren’t routable over the
internet).

------
miyuru
Cloudflare DNS does not support EDNS Client Subnet[1], so archive.is returns
invalid IP address for Cloudflare IPs[2]

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

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

------
v0v
So much talk about DNS and no one suggested simple workaround for this :-) If
anyone wants to use 1.1.1.1 and still access arhive.is, simply add this line
to your /etc/hosts file.

134.119.220.26 archive.is

------
systemcluster
Previous discussion here:
[https://news.ycombinator.com/item?id=17742457](https://news.ycombinator.com/item?id=17742457)

------
jsizzle
Why doesn’t archive.is return a valid alternate IP for DNS queries that don’t
have the EDNS0 information? They can host an apology page on that IP that
tells the user why they aren’t getting the content they are looking for and
suggest solutions for using a different open DNS service if the user is
willing to use one that provides their client subnet.

------
z3t4
I don't get why people use 1.1.1.1 8.8.8.8 etc, for more then debugging. Why
tell Google et.al about every site you visit !? And get slightly slower, less
accurate and less resilient DNS lookups ...

~~~
sseth
Because what you get is often faster, more accurate and more resilient
compared to the junk DNS run by most ISPs.

And because most site visits start with a Google search anyway.

And finally, because I am comfortable with their privacy statement :
[https://developers.google.com/speed/public-
dns/privacy](https://developers.google.com/speed/public-dns/privacy)

~~~
kiwijamo
I live in New Zealand where all the ISPs and mobile carriers provide fast and
reliable DNS resolvers. I've looked into switching to alterntive DNS providers
but every one of them are slower than my ISP's resolver. I'm aware that the
sitation is quite different in the US and certan other countries, but I wish
more Americans were aware that junk ISP-provided DNS servers seem to be an
issue exclusive to certain countries (such as the US). I think it would be an
intrerestin exercise to figure out why they occur in certain countries and not
in other countries.

~~~
sseth
Sorry - I should have been clear. I am from India - and the ISPs here are
quite bad. I have no idea about the USA ISPs.

------
regnerba
Cloudflare returns a proper response for me.

    
    
      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

~~~
V99
It's possible your ISP is intercepting all traffic for port 53 and sending it
to their own nameservers (which do send client subset) instead of you actually
taking to cloudflare's 1.1.1.1 at all.

~~~
abtinf
Links for documented instances of this practice?

~~~
V99
I don't know of any particular popular concrete instance, but why is it hard
to believe? It's trivial to implement and would be brought to you by the same
people who think serving ads for NXDOMAIN is a good idea.

[https://www.dnsleaktest.com/what-is-transparent-dns-
proxy.ht...](https://www.dnsleaktest.com/what-is-transparent-dns-proxy.html)

~~~
abtinf
That link was useful, thank you. I don't find it hard to believe technically,
but it strikes me as a fundamentally different practice than what I'd head of
before. If I request for traffic to go to a certain IP, I expect it to be sent
to that IP. MITMing and manipulating that traffic is bad, but not delivering
it at all is qualitatively different. I suspect it could be grounds for a
serious civil or criminal action.

~~~
LogicX
I can confirm we run across transparent dns proxying with customers at
DNSFilter all the time. Mobile carriers are the worst for doing this.

A few days ago it was a customers compromised router doing it.

------
darkhorn
[https://developers.cloudflare.com/1.1.1.1/nitty-gritty-
detai...](https://developers.cloudflare.com/1.1.1.1/nitty-gritty-details/)

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

~~~
AndyMcConachie
[https://tools.ietf.org/html/rfc7871](https://tools.ietf.org/html/rfc7871)

------
darkhorn
In Firefox I'm using DNS over HTTPS ( [https://mozilla.cloudflare-dns.com/dns-
query](https://mozilla.cloudflare-dns.com/dns-query) ) and there is no issue
accessing archive.is. Actually I wanted to query archive.is manually but I
don't know how to do it in DoH.

~~~
rmdoss
Firefox is likely falling back to your local resolver (the default) when it
can't find a domain.

------
sverige
archive.org works fine with 1^4. What is the advantage of using archive.is?

~~~
dredmorbius
Archive.org, the Internet Archive, and archive.is, a webpage capture service
that seems to have a primary name of "Archive.today", are wholly separate
concerns, offerring different services.

~~~
jolmg
Interesting, I thought archive.is was an alternate domain of the Internet
Archive, but it seems they are completely different people[1].

[1]
[https://en.wikipedia.org/wiki/Archive.today](https://en.wikipedia.org/wiki/Archive.today)

------
agumonkey
oh I thought my local pdns instance was misconfigured.. interesting

------
Jerry2
I tried Cloudflare's DNS for a week or so and noticed lots of sites that were
blocked. I ended up creating my own DNS server that I run on a VPS.

