DNS over HTTPS in Firefox
DNS over HTTPS in Firefox
Posted Jun 2, 2018 10:55 UTC (Sat) by roc (subscriber, #30627)In reply to: DNS over HTTPS in Firefox by gdt
Parent article: DNS over HTTPS in Firefox
E.g. if your country has two ISPs, ISP X hosts a CDN, and ISP Y hosts a Cloudflare server, the DNS request will appear to come from an IP address under ISP Y, and hopefully the CDN resolver will resolve it to ISP X's CDN.
Posted Jun 3, 2018 17:31 UTC (Sun)
by gdt (subscriber, #6284)
[Link] (3 responses)
The more likely situation is that both ISP X and ISP Y have CDN hosts. If ISP Y hosts a Cloudflare server and ISP X does not, then ISP X pulls from ISP Y's CDN, for all DNS-directed CDN services. The long-run likelihood is that the X-Y path has a charge [1]. Thus Mozilla's choice means that ISP X faces a strong financial motivation to install a Cloudflare CDN server. My view is that free software should promote open network infrastructure rather than promote a proprietary partner.
The other consideration is that ISP X is likely to be a small ISP and ISP Y is likely to be a large ISP (ISP Y is wealthy enough to host a Cloudflare CDN host, which is pretty far down the list of desirable CDN hosts). That is, Mozilla's acceptance of removing the EDNS Client Subnet Option proposed by Cloudflare adds to the market power of larger ISPs. It would be better if Mozilla had retained the EDNS Client Subnet Option, perhaps asking Cloudflare to enhance privacy by rounding the source IP address up to (a large fraction of?) the BGP-visible network rather than to the proposed /24. --
Posted Jun 3, 2018 20:45 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
As it stands the only thing I can divine from a DNS request via Cloudflare's Mozilla DoH offering is that it... came from some particular Cloudflare node. Probably that node is near the originator, although maybe not. There's no way around revealing this unless you're happy sacrificing performance (e.g. TOR will incur a few hundred milliseconds latency, in exchange for which nobody knows where you are in the world)
But if the EDNS "Client Subnet" is back, I get to see part of an IP address which may be more or less incriminating. Among the addresses handled by my ISP are "dynamic" assignments, where even seeing the whole address without access to their logs doesn't tell you much, right through to genuinely portable address space owned by customers, where even seeing /20 potentially gives away the game about who the end user is. I'm in the middle, with a static (but not portable) /28 of my own. So when you snip off the last 8 bits, you narrow things down to maybe a dozen customers like me with "Client Subnet" as it stands today, and maybe you could make that hundreds, but you can't make it thousands without also destroying the utility of the technique, and you'd still identify those with portable space.
Posted Jun 4, 2018 2:19 UTC (Mon)
by gdt (subscriber, #6284)
[Link] (1 responses)
on the other hand you smash some of the routing data That's only the case if the BGP feed to the ISP's CDN providers differs from the BGP offered to globally-visible neighbors. In which case the solution is to provide CloudFlare with the same BGP feed as provided to the ISP's other CDNs providers.
Posted Jun 6, 2018 15:18 UTC (Wed)
by buchanmilne (guest, #42315)
[Link]
Which requires you to deploy CloudFlare everywhere you have any CDN.
Not going to happen.
In a real ISP I used to be involved with:
It was not technically challenging to adjust the route filters appropriately to advertise the client subnets correctly to allow for this, and customers using the ISPs DNS would transparently get the best experience with the least exposure of their DNS requests. It would be technically challenging to get this setup to work with or without Cloudflare in the ISPs DCs.
There is no real privacy improvement available here, because Mozilla's picture doesn't quite hold true. Due to the peering configuration, most DNS requrests to the large CDNs would not traverse the public internet, but would be routed across private peering connections (between the ISP and a root DNS operator, then between the ISP and it's CDN partner).
With DNS over HTTPS, now these requests may traverse the open internet, and be exposed to a 3rd-party (Cloudflare).
IMHO, for some use cases (e.g. public WiFi), this may be an improvement, but for either fixed-line or mobile-operator (e.g. 3G/LTE) internet access, this is a regression in terms of privacy (at least in my country).
In short, this move does make me wonder if Cloudflare recently made some large donation to Mozilla ... which makes me suspicious of both parties.
DNS over HTTPS in Firefox
[1] The argument for the X-Y path being liklely charged in the long run: (1) If X-Y is a transit path then the path is already charged. (2) If X-Y is a peering path then the huge increase in traffic from Y to X will make a large enough change to the X:Y peering ratio such that is no longer in Y's interest to peer.DNS over HTTPS in Firefox
DNS over HTTPS in Firefox
DNS over HTTPS in Firefox
* The country has 3 major public peering locations.
** Cloudflare has presence at 2
** Major CDNs have presence at 3
** Smaller CDNs have presence at 1 or 2
* The ISP had 3 DCs, not co-located with the peering locations
** The ISP had 1 major CDN at 3 DCs, this CDN was actually only present at the largest peering location
** The ISP had 2 major CDNs in 2 DCs that were not at any local peering locations, and didn't want to be advertised to this ISP's peers
** The ISP had 1 major CDN in 2 DCs that were present at local peering locations, and were ok being advertised to this ISP's peers, but wanted to avoid sending any of this ISPs customers to the deployment at the peering location (as it was resource constrained).