Anyone else having problems lately with archive.is taking you to a captcha, you solve it and then it just keeps redirecting you back to the captcha over and over. Happens to me in chromium, a friend just tried in firefox and had same problem.
Why and/or how is Archive Today managing to send Cloudflare different responses than other DNS providers?
I'd suggest you kick your "integrity of DNS" principle in the interest of "rough consensus, working code". And yes, you can do that without passing on user-specific EDNS to AT, who're quite likely to obtain just that information through the subsequent HTTP GET request in any event.
In case anyone comes back to this. I noticed I get redirected to the archive.is domain and that's when I wind up in a captcha loop.
When I get captcha'd, the archive.is resolves to 198.23.187.186
I cleared my DNS server cache and got new IPs for archive.today and archive.ph but the same address for archive.is. I tried the OPs link, got redirected to .is and got captchas.
I cleared DNS server cache again and got 89.253.237.217 for .is (along with more new IPs for .ph and .today). No captchas.
Yep, reCAPTCHA is satisfied but then archive.{is,ph,today} still just loops 429 Too Many Requests. Not sure how they arrived at that conclusion; reading HN I probably hit the service about once per day.
Today is happening to me on a link from another thread which was to https://archive.is/gwuFp
Yup. Me too. On Firefox.
Confirming Firefox issue here too
I have the issue on Firefox, but not on Chrome.
Currently no luck on android using both brave and chrome.
Yes, seems broken.
Check your DNS, there are issues using Cloudflare to reach archive.{is | li | today | etc }
Google DNS and others work where Cloudflare does not.
Interesting ...
Using Cloudflare (1.1.1.1) vs. Google (8.8.8.8) I get different IP resolution:
Results:
Cloudflare: Fix your shit.
Nothing to fix. We are responding with what archive.* sends to us. They choose to send us incorrect data.
See: https://news.ycombinator.com/item?id=19828702
Why and/or how is Archive Today managing to send Cloudflare different responses than other DNS providers?
I'd suggest you kick your "integrity of DNS" principle in the interest of "rough consensus, working code". And yes, you can do that without passing on user-specific EDNS to AT, who're quite likely to obtain just that information through the subsequent HTTP GET request in any event.
And while we're at it: <https://news.ycombinator.com/item?id=37149094>
You can always email me (jgc@) with details.
Email sent, to jgc.org and cloudflare.com, hopefully one of those works.
In case anyone comes back to this. I noticed I get redirected to the archive.is domain and that's when I wind up in a captcha loop.
When I get captcha'd, the archive.is resolves to 198.23.187.186
I cleared my DNS server cache and got new IPs for archive.today and archive.ph but the same address for archive.is. I tried the OPs link, got redirected to .is and got captchas.
I cleared DNS server cache again and got 89.253.237.217 for .is (along with more new IPs for .ph and .today). No captchas.
Captcha loop here as well. Both from FF and an ungoogled Chromium with no add ons that I keep just for these situations.
DNS is the unsecured quad9 9.9.9.10
Secure DNS is likewise https://dns10.quad9.net/dns-query
Console shows error 429
And sure enough, if I disable secure DNS and change the DNS server to my ISP's, it works.
Assholes.
not a technical person, how can I fix this? turned off secure DNS, didn't work, changed IP to Google's, that disabled my WiFi...
i don't use cloudfare..i think..don't know what that is..just my wifi
strangely sometimes it randomly works once.
Yep, reCAPTCHA is satisfied but then archive.{is,ph,today} still just loops 429 Too Many Requests. Not sure how they arrived at that conclusion; reading HN I probably hit the service about once per day.
Firefox ETP strict, CenturyLink residential
Been having this issue for months. In addition, Safari can't connect to the server at all using iCloud Private Relay.
Seems like an OTT security config.