In Firefox I'm using DNS over HTTPS ( https://mozilla.cloudflare-dns.com/dns-query ) and there is no issue accessing archive.is. Actually I wanted to query archive.is manually but I don't know how to do it in DoH.
Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)
61–70 of 210 posts
Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)
#62Earlier quoted context omitted.
It's possible your ISP is intercepting all traffic for port 53 and sending it to their own nameservers (which do send client subset) instead of you actually taking to cloudflare's 1.1.1.1 at all.
Links for documented instances of this practice?
I don't know of any particular popular concrete instance, but why is it hard to believe? It's trivial to implement and would be brought to you by the same people who think serving ads for NXDOMAIN is a good idea.
https://www.dnsleaktest.com/what-is-transparent-dns-proxy.ht...
Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)
#63We don’t block archive.is or any other domain via 1.1.1.1. Doing so, we believe, would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service. 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…
@eastdakota what about just failing without response on archive.is calls so the second resolver address configured in the client will be used? I understand this is also a DNS integrity violation, however the result for the end user would be either the same if they don’t have a second resolver configured or enhanced if they do. The current effect is I stop using 1.1.1.1 when I need archive.is (often) and set it back t…
DNS either has integrity or it doesn’t. We get a response from an Authoritative server and, as a Resolver, we believe our responsibility is to return it. If we start making exceptions because of bad PR, how can you trust us to do the right thing when the stakes are even higher (e.g., nationstate pressure)?
As an aside, I used to think that when Emerson said that “a foolish consistency is the hobgoblin of little minds” he meant that we were foolish to try and be consistent. Increasingly I wonder if instead he meant that when you’re trying to reason with people who may not have the same detailed knowledge of a problem as you, there’s an enhanced importance to being consistent. Unfortunately, most policy makers globally don’t have a detailed understanding of how technical systems like DNS work, so we think it’s especially important we be consistent.
Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)
#64Earlier quoted context omitted.
This diverges pretty hard from your earlier comparison, between this scenario and the Linux kernel breaking userspace. If a dev updates their code so it won’t run unless an kernel flag is enabled, the kernel hasn’t broken userspace, and kernel devs are unlikely to add a “fake-enabled-flag” to trick the userspace program, even if it’s popular. Likewise, I don’t expect my DNS resolver to add in custom behavior if upstr…
Besides, my reading is: Every other resolver supports EDNS Archive.is only works with resolvers that support EDNS Cloudflare decided not to support EDNS That itself is a defendable decision but I do feel for a popular site they could implement some sort of fix.
dig @carl.archive.is archive.is A +noedns
curl http://134.119.220.26 -H 'Host: archive.is' -v
I'm not a dig expert, but I believe this means it works without EDNS. I think that means archive.is is specifically blocking Cloudflare's servers, not blocking all non-EDNS requests.
Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)
#65Earlier quoted context omitted.
Links for documented instances of this practice?
I don't know of any particular popular concrete instance, but why is it hard to believe? It's trivial to implement and would be brought to you by the same people who think serving ads for NXDOMAIN is a good idea. https://www.dnsleaktest.com/what-is-transparent-dns-proxy.ht...
That link was useful, thank you. I don't find it hard to believe technically, but it strikes me as a fundamentally different practice than what I'd head of before. If I request for traffic to go to a certain IP, I expect it to be sent to that IP. MITMing and manipulating that traffic is bad, but not delivering it at all is qualitatively different. I suspect it could be grounds for a serious civil or criminal action.
Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)
#66https://developers.cloudflare.com/1.1.1.1/nitty-gritty-detai... >EDNS Client Subnet >1.1.1.1 is a privacy centric resolver so it does not send any client IP information and does not send the EDNS Client Subnet Header to authoritative servers. What does this mean?
Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)
#67We don’t block archive.is or any other domain via 1.1.1.1. Doing so, we believe, would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service. 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…
Thank you for your comment.
Since HTTPS traffic already reveals communicating IPs to nation-state actors, could you clarify what attack vector removing user IP info from authoritative DNS queries protects against?
In what way does Cloudflare publish its PoP geolocation? Is it a Cloudflare-specific API? Why not fake EDNS subnet info by providing the PoP’s?
I notice of course that Google, Facebook, and Netflix still work on 1.1.1.1. Does this mean they’re currently using Cloudflare PoP geolocation in lieu of EDNS subnet information?
Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)
#68Earlier quoted context omitted.
The full IP of the Cloudflare resolver doing the recursive resolution is already provided to the authoritative server, as the source IP for the DNS query traffic.
I think the parent is saying, why not spoof the EDNS client subnet information?
[deleted]
Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)
#69Earlier quoted context omitted.
It's possible your ISP is intercepting all traffic for port 53 and sending it to their own nameservers (which do send client subset) instead of you actually taking to cloudflare's 1.1.1.1 at all.
Links for documented instances of this practice?
Re: Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)
#70We don’t block archive.is or any other domain via 1.1.1.1. Doing so, we believe, would violate the integrity of DNS and the privacy and security promises we made to our users when we launched the service. 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…
Say you remove/don't proxy the ECS information, and I get some generic, non-geo-location aware response back. In the majority of cases, wouldn't my next step be to open a TCP connection to the IP in the response, and immediately leak my full IP address to the other end? While I get (and appreciate!) the concern for the user's privacy, I'm having a hard time seeing what practical effect not proxying the subnet the user is on has?
(This is not meant to suggest that archive.is's DNS response is appropriate, or that CF's setup is inappropriate.)
(Just to check my understanding of ECS: it's an extension to DNS that sends the user's subnet in the request, and gets relayed with the request, s.t. an authoritative server can respond with a geo-location appropriate response/IP.)