Hacker News new | past | comments | ask | show | jobs | submit
I absolutely will not support archive.is/archive.today given the shenanigans they’ve pulled with cloudflare dns [1].

> Archive.is’s authoritative DNS servers return bad results to 1.1.1.1 when we query them. I’ve proposed we just fix it on our end but our team, quite rightly, said that too would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service.

> The archive.is owner has explained that he returns bad results to us because we don’t pass along the EDNS subnet information. This information leaks information about a requester’s IP and, in turn, sacrifices the privacy of users.

[1] https://community.cloudflare.com/t/archive-today-is-failing-...

That does sort of sound like Cloudflare is pulling the shenanigans. It's awfully convenient for a CDN company (the same company that MITMs half the web) to cite privacy concerns to not pass through data to enable better request routing. In almost all cases the DNS lookup precedes a connection from the client anyway.
EDNS subnet/ECS is an optional DNS extension. DNS requests have no obligation to provide it. archive.is's behavior is in violation of RFC 7871 [1]:

> Note again that a query MUST NOT be refused solely because it provides 0 address bits.

The shenanigans are absolutely on archive.is's side here.

[1] https://www.rfc-editor.org/rfc/rfc7871#section-7.5

When the RFC refers to a query being refused, it's talking about a response with rcode=REFUSED. Archive.is is responding with rcode=NOERROR and bogus RR data. Shenanigans? Yes. RFC violation? No.
Perhaps technically not a violation but clearly against the spirit of the RFC.