Today, I enabled quad9 dns for my home network, and archive.today now requires a captcha, which results in an infinite loop.
A similar problem was reported some months ago for Cloudflare’s 1.1.1.1
Posting here to see whether it’s just me or everyone. Is this a know problem?
Yes it’s been like that forever. Before it used to outright block the entire domain.
Who’s blocking what?
Last time, IIRC someone blamed Cloudflare and they said they did not do anything, just relaying from upstream.
The gist is, archive.today configured their DNS server to use edns client subnet to determine the visitor’s general location to direct them to servers closest to their area for load balancing purpose. Cloudflare DNS however doesn’t pass that information for privacy reason. I guess this piss archive.today’s dev off because their dns-based load balancing is no longer work effectively for cloudflare DNS users, so they outright block it.
Weird, I change from dns11.quad9.net (with ECS / EDNS client subnet enabled) to dns.quad9.net. Now archive.today works.
And then it broke again. And then it worked again.
Totally random. How does one debug this?
Maybe just hard code the DNS value for archive.is in your host file or your pihole (if you use pihole)?
Sounds like a simple solution.
Although I’m not really sure what happens here. I do get an IP address via quad9 and I do get other IP adresses using other resolvers, but how do I know which one works.
Both should work, archive.today is using a dns-based load balancer where it answer DNS query with an IP address for a server that supposedly closer to you. Just pick one with the shortest ping and see if it’ll work.
But, then, why does it not work when using quad9? The result from quad9 may not be the closest server, but they can serve the captcha, so I’m reaching one of their servers.
deleted