Does Cloudflare’s 1.1.1.1 DNS Block Archive.is? (2019)

https://jarv.is/notes/cloudflare-dns-archive-is-blocked/

by lolinder • 3 years ago

246 172 3 years ago

wkat42423• 3 years ago

Maybe they need it to route the traffic to the right CDN? That kinda would make sense.

While I'm very privacy conscious, I don't really see the benefit to hiding my region in the DNS request. Because the very next step after the DNS is my browser making a request to their webserver, at which time they will have my actual complete IP anyway.

philwelch• 3 years ago

This is actually addressed in the original HN comment the post links to (https://news.ycombinator.com/item?id=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.

eastdakota3• 3 years ago

And today it’s over 250. And the only site I’m aware of that objects to us protecting user privacy by making EDNS more private is this one. ¯\_(ツ)_/¯

wkat42423• 3 years ago

Yeah but if the site standardized on EDNS to get this information, it's rather difficult to do something different just for Cloudflare.

jrockway• 3 years ago

eastdakota's original comment covers this. The DNS request isn't encrypted, so anyone with control over the network (upstream ISPs via warrants) can use this information to figure out who is attempting to visit. ("Someone is resolving example.com" is less information than "someone in LA is resolving example.com") Meanwhile, the actual HTTPS connection leaks less information. If the website is hosted on a CDN or cloud provider, then someone monitoring the IP traffic only knows that you're visiting something hosted by that CDN. ("The target is visiting a Cloudflare-hosted site" is less information than "The target is visiting example.com") So, there is a slight information leak by sending the geolocation information.

On the other hand, it's possible this doesn't matter. The client might not encrypt the host it's trying to visit. Nation states can correlate packet timing. So if someone really wants to know, they'll probably figure it out. (This is always a risk with things like Tor. If the government is monitoring your connection and some target website's connection, and you are sending a lot of packets at the same time they're receiving a lot of packets, you can guess who is talking to who.)

cortesoft2• 3 years ago

If the website is hosted on a CDN or cloud provider, then someone monitoring the IP traffic only knows that you're visiting something hosted by that CDN.

This isn't true, because the request leaks the hostname in the handshake via SNI:

https://en.wikipedia.org/wiki/Server_Name_Indication

jeroenhd3• 3 years ago

I've talked to some people working for the .nl TLD. They collect logs on DNS requests for every .nl domain to mine data about phishing websites and online scams. They're not using the EDNS information as far as I know (that would be very very illegal) and I don't know what the introduction of the GDPR has done to their research, but TLDs not limited by privacy laws such as American companies can do whatever they want.

It's not just the website's DNS server that received your subnet information; it's every single location in the chain of DNS resolvers. That includes TLD servers run by data mining companies. Does Verisign need to know that 2001:2345:6789::abcd is looking for news.ycombinator.com?

With caching in place these methods of data gathering aren't all-encompassing, but if you visit some new or uncommon domains you'll be more likely to become part of the dataset.

Arnavion2• 3 years ago

Does Verisign need to know that 2001:2345:6789::abcd is looking for news.ycombinator.com?

Verizon wouldn't know that even with ECS, because ECS only needs to include the subnet prefix of the length that the client (Cloudflare's recursive resolver in this case) is willing to give out. There is no benefit and only harm to the client if it gives out the whole IP, and indeed it is called out as a bad idea in the ECS RFC.

lol768• 3 years ago

Previous discussions:

Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1) https://news.ycombinator.com/item?id=19828317

- This particular discussion includes a comment from Cloudflare's CEO, referenced in the article: https://news.ycombinator.com/item?id=19828702

Why does 1.1.1.1 not resolve archive.is? https://news.ycombinator.com/item?id=21155056

- StackExchange question, on the subject

Does Cloudflare's 1.1.1.1 DNS Block Archive.is? (2019) https://news.ycombinator.com/item?id=28495204

- Discussion of this blog post

38• 3 years ago

since your formatting is weird, here is the direct link to the stack exchange question:

https://webapps.stackexchange.com/questions/135222

7sovaren• 3 years ago

Hmm, no clue but if i ask 1.1.1.1 for the a record for archive.is i get 89.253.237.217

asking the office DNS the same question i get 51.38.69.52, asking 9.9.9.9 it gives me the same IP as the office DNS. Finaly asking google or 8.8.8.8 i also get 51.38.69.52

So i think their record is borked.

bombcar• 3 years ago

Supposedly Cloudflare uses a feature of DNS archive.* doesn't like, or vice versa.

Nobody cares; the reality is if you use CF DNS, shit don't work.

nuker• 3 years ago

Im using iCloud Private Relay, and it affects me.

jeroenhd3• 3 years ago

It's not just Cloudflare, it's any DNS resolver that doesn't implement EDNS extensions. If you (or the company you work for) run a recursive resolver that doesn't submit such data, you'll run into the same issues.

I've switched to archive.org because archive.* is broken. For stuff that .org doesn't have, there's always the Tor version. The Tor address seems to be more responsive as well, so that's nice.

josephcsible4• 3 years ago

Nobody cares; the reality is if you use CF DNS, shit don't work.

This is super misleading because it ignores the fact that archive.* goes out of their way to make CF DNS not work.

cesarb• 3 years ago

Supposedly Cloudflare uses a feature of DNS archive.* doesn't like, or vice versa.

From what I understand, it's the opposite: Cloudflare doesn't use a relatively new feature of DNS (EDNS Client Subnet), and that site doesn't like the lack of that feature.

obituary_latte3• 3 years ago

I get the same result when I query 1.1.1.1 or 1.0.0.1 for archive.is:

    ┌
    └─(12:32:59)──> 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: 89.253.237.217

    ┌
    └─(12:38:12)──> nslookup archive.is 1.0.0.1
                                            
    Server:  1.0.0.1
    Address: 1.0.0.1#53

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

Wonder why that is happening...

cj• 3 years ago

Comment from Cloudflare CEO from 2019: https://news.ycombinator.com/item?id=19828702

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.

lolinder4• 3 years ago

They still are! I recently switched to Cloudflare DNS and noticed all the archive links people post on HN stopped working.

photonerd• 3 years ago

And the reason they do that is quite reasonable. CF is just being a pain

flutas2• 3 years ago

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.

Or you can try to not imagine everyone as hating everything and read the other comment in here posting the archive.* side of the story.

There have been numerous attacks where people upload illegal content (childporn or isis propaganda) and immediately reported to the authorities near the IP of the archive. It resulted in ceased servers and downtimes. I just have no time to react. So I developed sort of CDN, with the only difference: DNS server returns not the closest IP to the request origin but the closest IP abroad, so any takedown procedure would require bureaucratic procedures so I am getting notified notified and have time to react.
But CloudFlare DNS disrupts the scheme together with all other DNS-based CDNs Cloudflare is competing with and puts the archive existence on risk. I offered them to proxy those CloudFlare DNS's users via their CDN but they rejected. Registering my own autonomous system just to fix the issue with CloudFlare DNS is too expensive for me.

jeroenhd3• 3 years ago

I don't know for sure what's going on with the DNS. I know the archive.* website messes with Cloudflare's DNS results because they don't know how to set up anycast, but when I use some external tool to look up the right address and hardcode that I still get either a TLS error or "hello world".

archiveiya74codqgiixo33q62qlrqtkgmcitqx5u2oeqnmn5bpcbiyd.onion still works fine if you don't want to share your geolocation information with every DNS server in the recursive resolver chain.

freedomben5• 3 years ago

Cloudflare CEO Matthew Prince answered this directly on HN: https://news.ycombinator.com/item?id=19828702

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.

eastdakota3• 3 years ago

In this particular case we truncate EDNS to protect the privacy of users because we believe 1) privacy is a fundamental human right; and 2) the original sin of the Internet is that IP addresses are too closely tied to the identities of individuals and services. Truncating EDNS is trying to honor #1 and overcome #2. So is our work on protocols like Oblivious DNS. This work, frankly, upsets some of our customers or potential customers (like Archive.is). But it’s the right thing to do for the long term health of the Internet.

freedomben5• 3 years ago

More of a meta comment, but thank you for your willingess to upset some customers and potential customers. Having and standing by principles can be damn inconvenient at times, but the world is a much better place because of it.

supriyo-biswas4• 3 years ago

Sure, we’re to believe that, given that you’re trying to lock out Linux users[1] (which still isn't resolved yet) and pushing for device attestation[2] to lock out rooted devices at the same time.

[1] https://news.ycombinator.com/item?id=36197401

[2] https://www.ietf.org/archive/id/draft-private-access-tokens-...

nullindividual4• 3 years ago

I use Quad9 because of this reason. CF will also misdirect Exchange Online connections which can significantly impact client performance.

It would be great if CF offered a choice, like Quad9.

tomp• 3 years ago

This work, frankly, upsets some of our customers or potential customers (like Archive.is).

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!

adql5• 3 years ago

User will navigate to the site and show their own IP anyway. You achieved basically zero increase in privacy while making any competitor have problems with any of their users that use 1.1.1.1

And any malicious client that tries to leak data via DNS can just ask for DNS record like my-ip-is-7.8.9.0.example.com and completely go around that privacy "enhancement".

Sorry but the "privacy" here looks like smokescreen to stifle competition.

ninjagoo4• 3 years ago

So Stavros [1] indicates that archive.is needs that EDNS data to protect themselves against CSAM/ISIS material based attacks, and they suggested solutions but CF refused to cooperate. Is this true?

[1] https://news.ycombinator.com/item?id=36971650

pierat• 3 years ago

In this particular case we truncate EDNS to protect the privacy of users

In other words, you want the data, but prevent others from seeing your advantage?

This is what archive.is is doing, and you stomp your collective feet at.

because we believe 1) privacy is a fundamental human right; and 2) the original sin of the Internet is that IP addresses are too closely tied to the identities of individuals and services.

If you cared about that, you wouldn't either block Tor or send us through captcha-hell just to pull a single webpage.

Truncating EDNS is trying to honor #1 and overcome #2. So is our work on protocols like Oblivious DNS. This work, frankly, upsets some of our customers or potential customers (like Archive.is). But it’s the right thing to do for the long term health of the Internet.

'Upsets'? Wow. Talk about a "Rules for thee but not for me."

btown• 3 years ago

Have you thought about spoofing the EDNS to (a less truncated version of) the nearest Cloudflare edge node's IP? This would be no more of a privacy leak than traffic from your edge to origin servers, while providing generally enough geographic information to keep latency low on the source. This is at the very least compliant with the spirit of the RFC, no?

EDIT: another comment, though somewhat hearsay, suggests that Cloudflare's caching could make this difficult to implement: https://news.ycombinator.com/item?id=36971650

jshier• 3 years ago

This, and Warp's insistence on passing my origin IP to my destinations, are two things I wish I could customize when using Cloudflare. Before going corporate OpenDNS had something similar, and you could even set up custom behaviors per origin IP (for home and work), which I miss. These are good defaults, but I wish to change the defaults while also allowing particular domains to get my full EDNS info, like particular CDNs.

While I'm here, I'd also like to layer Zero Trust and Warp+ so I can toggle my internal network while staying on Warp+.

Also, the separation in Zero Trust and tunnels between routed DNS names and private IPs is very confusing. Why do I need both?

Custom DNS entries for Zero Trust DNS would be nice, so I could point internal domains to the external routing without having to have public DNS, or even have the domains match.

polski-g• 3 years ago

Why don't you just send fraudulent EDNS info?

Zuiii2• 3 years ago

In this particular case we truncate EDNS to protect the privacy of users because we believe 1) privacy is a fundamental human right; and 2) the original sin of the Internet is that IP addresses are too closely tied to the identities of individuals and services.

Your beliefs certainly aren't reflected in how you treat users. It's been a good while since I've been able to visit any cloudflare protected site using Tor. Your broken systems keep presenting me with infinite checkboxes that do absolutely nothing.

If you want to block people who truly believe that privacy is a fundamental human right, at least have the decency to be honest. Tell Tor users that they are permanently blocked so that they don't waste their time clicking on pointless checkboxes.

lopkeny12ko• 3 years ago

This is honestly such a tone-deaf answer. At the end of the day, users don't care about the purity of adherence to some far-down technical principles or details. As a product leader, you should task your team to solve real user problems and not spend literal years arguing about EDNS.

Truly, just imagine the user story:

"I can't access this website."

"No worries! That is by design, because the protocol response returned to CF is illegal, and the server simply propagates the error back to you. It would be impure for CF to modify the response in-flight to fix this for you."

"?? I do not care. I am talking to CF, why can't CF just fix the issue?"

dogleash• 3 years ago

As creators, it’s our job to care about these things for the benefit of users BECAUSE they’re laypeople.

deadalus• 3 years ago

Cloudflare banned 8chan without a legal requirement to do so. They banned it based on moral reasons.

throw0101b• 3 years ago

Cloudflare CEO Matthew Prince answered this directly on HN: https://news.ycombinator.com/item?id=19828702

Archive.is' explanation is quoted in a comment below:

* https://news.ycombinator.com/item?id=36971650

johnklos2• 3 years ago

Cloudflare is in the wrong here. They want to "protect" people from their own ISPs, from nefarious web and DNS servers that'll "sacrifice the privacy of users" by - you guessed it - doing exactly the same thing themselves. They've given very little reason to trust them, while giving plenty of reasons to think they might be evil (like protecting known spammers / scammers / phishers).

If another company did what Cloudflare does and homogenized tons of requests behind them, you can bet Cloudflare's CAPTCHA systems would block them in a second.

I have zero respect for Cloudflare's inability to answer criticisms about what they do, about their constant deflections from simple, straightforward questions, and the fact that they do to others what they would never accept anyone else doing to them. It's hypocrisy in the service of trying to become a monopoly by re-centralizing the Internet.

Don't believe me? Go ahead and look for examples of Matthew Prince addressing concerns that much of the non-western world can't access Cloudflare fronted sites because of Cloudflare's "reasons". When you don't find any that have more than just vague platitudes and handwaving, imagine how you'd feel if you were one of those multiple billion people.

tick_tock_tick2• 3 years ago

EDNS is OPTIONAL. archive.is is objectively in the wrong here.

IggleSniggle• 3 years ago

Your take is so on the money. I'm a staunch CF advocate, but so much rests on the trust they engender. Their power is a consequence in their presence as a trustable company working across the infrastructure of the Internet. There's so many pathways where the enforcers of good behavior eventually end up as the Pharaohs. I genuinely love Cloudflare while being simultaneously extremely wary of Cloudflare.

Zuiii2• 3 years ago

It's the opposite for me. Cloudflare presents me with so many infinite "Are you human" check boxes when using Tor that I decided to never pay a single cent to that company unless we found ourselves in a situation were there was no other choice. Thankfully, there almost always choice, with most vendors now offering very good alternatives. I work in government IT procurement.

hk1337• 3 years ago

Seems like a good reason not to be exclusive with a single DNS service.

wkat42423• 3 years ago

I don't think this will help. It still returns an IP, it's just wrong. Setting a second DNS won't help if the first one returns a response.

diogocp2• 3 years ago

This is obviously not Cloudflare's fault, but I wonder why they don't just mask their identity (e.g. by using a random AWS IP address) when querying archive.is?

AFAICT this wouldn't "violate the integrity of DNS and the privacy and security promises we made to our users" and would solve a big pain point of using 1.1.1.1.

freedomben5• 3 years ago

I'm not affiliated with CF at all, but if I were I would oppose that idea on a couple levels.

Philosophically I think that lacks respect for the site owner and it would be wrong to deceive them and go against their wishes.

Pragmatically that sounds like a giant maintenance pain in the ass to manage, and not worth the time/money to make somebody's site work who actively doesn't want it to work.

eastdakota3• 3 years ago

We’ve tried. The owner of Archive.is actively monitors and then returns bad results. This is true even if we recurse through another recursor. It’s a very odd hill to die on.

dataflow2• 3 years ago

I think I'm missing something, but is there a way you can pass along some some sort of vague location info for caching purposes without revealing too much? From their tweet they mentioned even continent level information isn't available, which I can understand. Is there really no middle ground that works here?

diogocp2• 3 years ago

That's as annoying as it is impressive.

Fabricio20• 3 years ago

Have you guys considered just having the resolver not return anything? Such that my system would fallback to another resolver (such as Google or Quad9) and I wouldn't have issues accessing the site?

I guess that still has the privacy implications.. but at least it would work!

kalleboo3• 3 years ago

Lately I've run into the issue that they're also blocking iCloud Private Relay. Although for some reason the block is only affecting me over IPv6, if I disable v6 it works, which led me to waste a bunch of time debugging. The seemingly anti-privacy blocks by archive and the fact that nobody knows who funds this extremely popular service has led me down conspiratorial thought patterns.

TechBro86152• 3 years ago

Cloudflare is one of the operators of egress nodes for iCloud Private Relay, along with Akamai and Fastly and maybe some others (IIRC). So you probably have issues with Archive.is when you're connected through Cloudflare. Although I'm not sure how DNS resolution works on private relay (since it's the DNS server rather than the egress proxy that causes the issue - but if the egress proxy is making the DNS requests then that would explain it).

kalleboo3• 3 years ago

Ah that would explain it!

electroly3• 3 years ago

Intransigent maintainers are such an irritating problem. Any time a maintainer has some strongly-held beliefs or goals that supersede their desire to serve users, you've got a ticking time bomb. When the two clash, they'll decline to serve users in order to serve their strongly-held belief instead. We see it time and time again.

ninjagoo4• 3 years ago

This case might not be one of an intransigent maintainers. Check out Stavros' note [1]

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

electroly3• 3 years ago

Indeed, they mention that the proper solution is to get their own AS but that it's too expensive (this is what other major websites do). Cloudflare argues that they are protecting user privacy by truncating the EDNS responses, and I believe it's commonly agreed that they're right that this move does so. Archive.is says explicitly that they want this because it's cheaper than an alternative that is available to them. The cost of running an AS is disputed elsewhere in this HN thread. To me it seems clear that Cloudflare has the moral upper hand.

whoopdedo• 3 years ago

Are you talking about Archive.is or Cloudflare?

Answer: "Yes."

electroly3• 3 years ago

I do believe both parties see the other this way.

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] https://news.ycombinator.com/item?id=36971650

[2] https://news.ycombinator.com/item?id=36977654

adithyassekhar• 3 years ago

Cloudflare is also hurting peering and ggc to Google on my ISP.

When I use google dns, opendns or even my isp's own dns, the ip I get for example, googlevideo.com resolves to my isp's cache. But with cloudflare it gives my a google ip and I get no cache benefits.

Also, anecdotal evidence, uploading and downloading large files to Google Drive and some other websites is significantly faster when I use google dns or opendns. I'm not sure how that works, but maybe the server's returning an ip my isp can't route to in a fast way? My isp is notorious for having bad routes.

ChrisArchitect• 3 years ago

(2019)

Did this need to be posted again when it was discussed and answered already?

Goz3rr4• 3 years ago

For me it worked for a while, and has broken again earlier this year.

stavros• 3 years ago

I talked to the maintainer of archive.is years ago, they said this (hopefully they won't mind me posting):

There have been numerous attacks where people upload illegal content (childporn or isis propaganda) and immediately reported to the authorities near the IP of the archive. It resulted in ceased servers and downtimes. I just have no time to react. So I developed sort of CDN, with the only difference: DNS server returns not the closest IP to the request origin but the closest IP abroad, so any takedown procedure would require bureaucratic procedures so I am getting notified notified and have time to react.
But CloudFlare DNS disrupts the scheme together with all other DNS-based CDNs Cloudflare is competing with and puts the archive existence on risk. I offered them to proxy those CloudFlare DNS's users via their CDN but they rejected. Registering my own autonomous system just to fix the issue with CloudFlare DNS is too expensive for me.

When I proposed using the DNS server's IP instead, they said:

It did not work initially because they have global planetwide cache.
1. Someone resolves domain from Brazil.
2. Website's DNS get request from Cloudflare Brazil DC.
3. The result is replicated to other Cloudflare DCs
4. Some from Turkey resolves same domain and get the cached value
It could be worked around by setting tiny TTL, which would slowly end up in consistent results, but... After "I’ve proposed we just fix it on our end .." all requests for 7 archive.* domains are sent from Symantec USA IP

codetrotter• 3 years ago

This makes a lot of sense, and this comment should be higher.

The other comments that only present the Cloudflare side of the situation make it sound like the archive.is owner was being unreasonable, but as we see there is more to it!

I personally tried to use 1.1.1.1 as my resolver a couple of years ago but I use archive.is a lot.

Regardless of who is “at fault”, not being able to access archive.is is a dealbreaker for me so I quickly stopped using 1.1.1.1

But Cloudflare has a lot of other things that work well for me.

flangola7• 3 years ago

Wow. archive.is proposed a perfectly good solution and CF shot it down.

fastball• 3 years ago

I'm using 1.1.1.1 and I can go to archive.is – is this still relevant?

mellosouls• 3 years ago

Tangentially, various network providers (eg. some mobile networks) block access to some archive sites (particularly the Internet Archive as it's the most well known one) on the basis of them containing adult/pirated content.

waithuh• 3 years ago

While archive.is' reaction is questionable (and even then, its their own server and can do whatever they want with it) this blog post is throughout Cloudflare advertising. The CEO used the scenario to their advantage very cleverly, but this blog post could describe all of that without constantly reminding how wonderful CF is.

pessimizer2• 3 years ago

Or, they could do it while constantly reminding people how wonderful Cloudflare is, just because they want to. I'm not sure why supposed to be wrong to honestly advertise.

tiltowait• 3 years ago

Many people think any form of advertising is evil. Though incorrect, it's perhaps a predictable reaction to the pervasive and genuinely morally bankrupt advertising we're inundated with on a regular basis.

rejectfinite• 3 years ago

I switched to https://controld.com/free-dns

Can also do DNS adblock! :)

Goz3rr4• 3 years ago

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.

croes• 3 years ago

And you leak your location, don't you?

therealmarv2• 3 years ago

as does your IP. Where is the win?

ploxiln• 3 years ago

... less than when you connect to the archive.is servers for http requests

adql5• 3 years ago

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.

adql5• 3 years ago

As you do when you connect to any website ?

stock_toaster• 3 years ago

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

ninjagoo4• 3 years ago

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.

Goz3rr4• 3 years ago

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

ishanjain28• 3 years ago

I am in India, using 1.1.1.1 over DoT and it appears to be working okay.

I am served IP addresses with relatively short TTLs (1-5minutes) that are in Moscow and North Holland.

babypuncher• 3 years ago

If Archive.is doesn't want to respond to valid DNS requests then I don't see a reason to use or support them.

therealmarv2• 3 years ago

Any alternatives which support DoH, DoT, DoQ and do not think they need to reinvent (E)DNS ?

Google works but I want to keep a little distance from them. Also no big fan of Quad9. So what else to use and which is distributed World Wide?

silisili• 3 years ago

I use and pay for nextdns, and am a huge fan.

brirec2• 3 years ago

One way you can get around this and still use 1.1.1.1 for most sites would be to use a local recursive resolver that supports domain name-based upstream overrides such as dnsmasq, and setting that as your local resolver.

You can run dnsmasq on anything that can run arbitrary services e.g. on your local workstation, or on your router if it is open enough, or even on something like Termux probably.

obituary_latte3• 3 years ago

Strangely, I get a Russian IP address for an answer when I query 1.1.1.1 for archive.is:

    ┌─(~/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)

Not sure why this would be happening (looks like at least one other person in the thread is seeing same result).

wnevets• 3 years ago

Oh is that why archive.is links on HN will fail for me sometimes?

msravi• 3 years ago

Nextdns: How we made DNS both fast and private with ECS[0]

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

Arnavion2• 3 years ago

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

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

>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

8chanAnon• 3 years ago

Seems like this is no longer relevant. I just tried a DNS lookup via Cloudflare and I got 89.253.237.217.

lolinder4• 3 years ago

I'm seeing that now too. It might have changed in the last 4 hours, or maybe the behavior is cyclical for some reason. I posted this article after running into it repeatedly over the last few weeks since switching to Cloudflare DNS.

I wonder if one party or the other actually made a change in response to this hitting the front page again?

tredre3• 3 years ago

The behaviour is cyclical. It has been for years, really. It starts resolving every now and then, but rarely for long and I doubt this time is any different.

I don't think archive.is blocks CF based on their IPs, so they must have some heuristic in place to defect bogus EDNS. Perhaps sometimes that heuristics fails?

below43• 3 years ago

https://archive.is/hpKIB

News-Dog• 3 years ago

archive.today or archive.is : https://en.wikipedia.org/wiki/Archive.today

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

Launched May 16, 2012; 11 years ago

anuraaga• 3 years ago

Great post! I respect people's decisions regarding the focus on privacy but above all I just need the internet to work and this was always a mysterious issue. Finally fixed by switching to Google DNS, which for me personally is not a problem, escaping their net is better than not but not a requirement.

Does Cloudflare’s 1.1.1.1 DNS Block Archive.is? (2019)

Related Stories