I did the same research because I too found it hard to believe and it's still not clear to me how the problem is not on cloudflare. They claim the upstream is misconfigured, but how then does every single other DNS provider manage to handle it correctly?
Or are they claiming archive.is is explicitly blacklisting the cloudflare IP range? If that is the case it seems odd they are claiming the upstream is misconfigured as opposed to explicitly blocking them. Something does not add up correctly.
> how then does every single other DNS provider manage to handle it correctly?
They do not handle it at all. Remember that the responses are tailored to the IP address of the client, i.e. Cloudflare's back end. It is not Cloudflare that is doing that tailoring. So the question that you should be asking is how come archive.is did that tailoring for (as you claim at any rate, although I suspect that no-one has exhaustively tested this before claiming it) every single other DNS provider and not Cloudflare.
Indeed, if you read what you replied to, you'll find that it's the inverse of that situation. archive.is answers are explicitly tailored by archive.is for whenever it is, specifically, Cloudflare asking. So the question that you should be asking is how come archive.is is saying that it is on a Cloudflare-hosted CDN ("cdn-wo-ecs.archive.is", mapped to Cloudflare hosting IP addresses), but only saying that when it is Cloudflare asking.
Once you ask that latter question, you'll get to the meat of the issue, which is that archive.is demands that Cloudflare et al. pass on (most of) your IP address to them, and returns fake name-to-address mappings for Cloudflare and indeed anyone else who says that (for privacy or otherwise) they are not going to pass on that kind of ultimate client identifying information to archive.is nor to anyone else.
(It's archive.is tailoring its response where there is no EDNS0 client subnet, a.k.a. ECS, information, for the technical. That's what the "wo-ecs" means.)
Sometimes 1.1.1.1 is used as a testing value, and can get blocked for reasons. CloudFlare is getting a huge amount of spam IP traffic to 1.1.1.1 from misconfigured equipment, it wouldn't be too surprising if some upstreams have firewalled valid IPs.
When cloudflare resolves addresses, the DNS request is not coming from 1.1.1.1, it's coming from the IP address of the server actually making the request. You can confirm this by looking at the results of a VPN DNS leak test [0] and seeing the IPs being used to resolve the addresses do come from cloudflare, but are not 1.1.1.1
Or are they claiming archive.is is explicitly blacklisting the cloudflare IP range? If that is the case it seems odd they are claiming the upstream is misconfigured as opposed to explicitly blocking them. Something does not add up correctly.