zlacker

[return to "Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)"]
1. ikeboy+I1[view] [source] 2019-05-04 18:52:03
>>ikeboy+(OP)
Looks like it's a known issue https://community.cloudflare.com/t/archive-is-error-1001/182..., yet not been fixed for at least a year
◧◩
2. floati+d2[view] [source] 2019-05-04 18:56:00
>>ikeboy+I1
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...

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

◧◩◪
3. ikeboy+Z2[view] [source] 2019-05-04 19:03:31
>>floati+d2
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.

◧◩◪◨
4. akerl_+A3[view] [source] 2019-05-04 19:08:18
>>ikeboy+Z2
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?
◧◩◪◨⬒
5. ikeboy+14[view] [source] 2019-05-04 19:13:02
>>akerl_+A3
https://twitter.com/archiveis/status/999788186904576002 claims that cloudflare isn't supporting a protocol that would enable it to work with their servers.
◧◩◪◨⬒⬓
6. floati+Z4[view] [source] 2019-05-04 19:22:01
>>ikeboy+14
Archive.is does not appear to specify in detail what operational issues result from the missing client subnet EDNS data. We can speculate, though. Is it for data harvesting purposes, or for global load balancing concerns? Are users complaining due to some unknown side effect? Are localized in-country-firewall servers receiving traffic from out-country clients?
[go to top]