Archive.* sabotages their DNS records when Cloudflare queries for them. They don't like that Cloudflare doesn't do EDNS forwarding so they broke their service for people using 1.1.1.1.
That said, I have the same problem. Even hard coding the IP address I resolved through Google doesn't seem to work. I'm guessing their sabotage may have backfired and is causing issues beyond their intentional scope?
This just helped me realize why I couldn't get to archive.today anymore -- however, for me, both Google DNS (8.8.8.8) and CloudFlare DNS (1.1.1.1) resulted in either infinite captcha loop or timeout.
I had to switch back to my ISP DNS to have connection successful.
I did not realize that choice of DNS resolver could effect access to a website like this. I thought DNS was boring stable technology. The error conditions weren't even DNS failure (which I would also find surprising from Google or Cloudflare), but that server timeout, or weirder infinite captcha loop.
if you can't trust your isp than either find someone that you can trust (by verification) or run your own resolver.
there was a recent move from the eu to have an eu-centric public resolver which brought up the question if/how the big players address country specific filtering requirements which in turn might have shed some light on the fact that gog/cf didn't care; until now.
Are you suggesting the cert problem is DNS related or the new captcha issue?
DNS was ISP, not 1.1.1.1, and I get the same behaviour after switching to 8.8.8.8.
Archive.* sabotages their DNS records when Cloudflare queries for them. They don't like that Cloudflare doesn't do EDNS forwarding so they broke their service for people using 1.1.1.1.
That said, I have the same problem. Even hard coding the IP address I resolved through Google doesn't seem to work. I'm guessing their sabotage may have backfired and is causing issues beyond their intentional scope?
This just helped me realize why I couldn't get to archive.today anymore -- however, for me, both Google DNS (8.8.8.8) and CloudFlare DNS (1.1.1.1) resulted in either infinite captcha loop or timeout.
I had to switch back to my ISP DNS to have connection successful.
I did not realize that choice of DNS resolver could effect access to a website like this. I thought DNS was boring stable technology. The error conditions weren't even DNS failure (which I would also find surprising from Google or Cloudflare), but that server timeout, or weirder infinite captcha loop.
If you use an Apple device and have iCloud Private Relay turned on, one of their providers is Cloudflare and that will cause the same issue.
>I've had infrequently occurring arcane cert/SSL issues <> Same error page as https://news.ycombinator.com/item?id=37009598
Edit of formatting for readability.
Who is your ISP's DNS provider?
Do they run their own resolver, or rely on an extant service?
I do Not use my ISP's DNS!
I'm reticent to disclose my current DNS provider,
given that I am able to access archive.is and many are not at this point of time.
2 replies →
I'm using Quad 9 and getting the same results. Who is the right DNS provider?
if you can't trust your isp than either find someone that you can trust (by verification) or run your own resolver.
there was a recent move from the eu to have an eu-centric public resolver which brought up the question if/how the big players address country specific filtering requirements which in turn might have shed some light on the fact that gog/cf didn't care; until now.
I run Pi-hole with Unbound - set up is easy and rewards are uncensored DNS, ad-blocking etc..
Oh and - given the right adlists - may also prevent infecting your machine/network/... with malware...
Not to speak of clients which may not equipped with on-device adblockers, such as TVs etc...