zlacker

[return to "Tell HN: Archive.is inaccessible via Cloudflare DNS (1.1.1.1)"]
1. eastda+d6[view] [source] 2019-05-04 19:31:43
>>ikeboy+(OP)
We 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 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. This is especially problematic as we work to encrypt more DNS traffic since the request from Resolver to Authoritative DNS is typically unencrypted. We’re aware of real world examples where nationstate actors have monitored EDNS subnet information to track individuals, which was part of the motivation for the privacy and security policies of 1.1.1.1.

EDNS IP subsets can be used to better geolocate responses for services that use DNS-based load balancing. However, 1.1.1.1 is delivered across Cloudflare’s entire network that today spans 180 cities. We publish the geolocation information of the IPs that we query from. That allows any network with less density than we have to properly return DNS-targeted results. For a relatively small operator like archive.is, there would be no loss in geo load balancing fidelity relying on the location of the Cloudflare PoP in lieu of EDNS IP subnets.

We are working with the small number of networks with a higher network/ISP density than Cloudflare (e.g., Netflix, Facebook, Google/YouTube) to come up with an EDNS IP Subnet alternative that gets them the information they need for geolocation targeting without risking user privacy and security. Those conversations have been productive and are ongoing. If archive.is has suggestions along these lines, we’d be happy to consider them.

◧◩
2. CodeWr+x9[view] [source] 2019-05-04 19:57:15
>>eastda+d6
@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 the next time I’m messing with my network settings.

◧◩◪
3. eastda+yb[view] [source] 2019-05-04 20:13:33
>>CodeWr+x9
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.

◧◩◪◨
4. CodeWr+EE[view] [source] 2019-05-05 02:58:45
>>eastda+yb
My take on the Emerson quote you mention is to be mindful instead of mindless when it comes to consistency. I respect the commitment to consistency you convey (and I do think it is mindful).
[go to top]