Using Cloudflare's 18.104.22.168 might lead to slower CDN performanceSat, Apr 21, 2018 Tweet Vote on HN
Disclaimer: All views expressed here are personal
Recently Cloudflare launched their 22.214.171.124 public resolver in partnership with APNIC to great fan-fare boasting performance improvements and increased privacy.
While their claims are true, I would like to talk about them not forwarding EDNS client subnet(ECS). Quad9 does something similar, but provide an ECS capable IP hidden in the docs for users who really care about performance.
In 2010 I wrote a post outlining how using public DNS resolvers leads to degraded performance when accessing non-anycast CDNs. We have come a long way since then, with EDNS Client Subnet being supported by most public resolvers, and a wider pop footprint, that blogpost is very outdated.
According to Cloudflare
126.96.36.199 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
If I do a DNS lookup for
cdn.example.com, it is with the intent of connecting to that website(over HTTP/HTTPS/TCP/whatever). The concern appears to be the CDN’s authoritative DNS service provider being able to see the subnet of the end user. Sure that is one way some information about the user could leak. But /24 is not a strong indicator to identify specific user.
When I do make the final connection, I am sending my whole /32 IP address. The /24 (or /28) that would have been sent is hardly any privacy concern compared to the exact IP that’s needed to be exposed while making a TCP connection.
While visiting a typical website, A user exposes their full IP to potentially following parties
- The website’s server
- The website’s loadbalancer (if any - Like AWS ELB, digital ocean, etc)
- The website’s hosting provider (AWS, DO, Google, etc etc…)
- 1 - 3 for all 3rd party objects on the webpage (including their CDNs).
- All network devices sitting in between 1 - 4
Authoritative DNS service provider is just another piece of a website’s hosting infrastructure, which with ECS only gets partial IP. Sending partial IP, IMHO, is a very trivial privacy concern in comparison to the potential benefits.
For a non-anycast CDN, to get accurate DNS-based routing from user of 188.8.131.52, the following must work flawlessly.
- Internal POP IP of Cloudflare must be very accurate in geoip databases like MaxMind and friends.
- The user must always be routed to closest Cloudflare POP. If for some reason the path is wrong, then along with slower Cloudflare, users will experience slower all-CDNs.
But… Doesn’t Cloudflare have POPs almost everywhere?
Yes. But that only gives somewhat geographical granularity. What about ISP-level optimizations. I would like to only send users on Verizon from San Francisco to my Verizon POP. If that user uses 184.108.40.206, they don’t benefit from all the money I spent in setting up that POP. If another CDN has more locations than Cloudflare, then for a 220.127.116.11 user the CDN has to limit their service based on Cloudflare’s network map. CDNs who host closer to the Edge are impacted more than ones who host at hubs.
Choosing Akamai as the target of this test was an intentional selection bias on my end to highlight the issue at hand.
From Thailand/AIS Fiber (first hop adds ~20ms latency!)
$ dnsperfbench -resolver 18.104.22.168 -httptest https://turbobytes.akamaized.net/static/rum/100kb-image.jpg 2018/04/21 20:09:47 Resolving 2018/04/21 20:10:00 Issuing HTTP(s) tests
The fastest responding IP
49.231.112.x is hosted inside my ISP, next best is in another ISP in Thailand. If I were to use
22.214.171.124 my access to things hosted with Akamai would get about 2x slower, in exchange for Akamai not getting to see my (partial) IP during DNS resolution.
Sure, Cloudflare’s DNS service (which appears to be serving locally within this ISP) is new, perhaps Akamai has not updated their geoip databases with Cloudflare’s backend IPs, perhaps Cloudflare has not yet published them, but even with that fix, the best Akamai could do is send me to a generic Thailand POP, instead of the one sitting at my ISP.
Similarly for Thailand/True
In this case only Google, OpenDNS and ISP resolvers send me to an ISP-local POP. Quad9 came #2 because of their fast DNS time (this test does not use locally cached DNS).
Cloudflare sends me to Singapore, and others further out.
Cloudflare sending me Singapore IP might be due to the fact that for me
126.96.36.199 is being routed to Cloudflare Singapore, probably True’s fault.
~# mtr --report-wide 188.8.131.52 Start: Sat Apr 21 21:05:43 2018 HOST: apu Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.2.1 0.0% 10 1.2 1.1 0.9 1.2 0.0 2.|-- 10.137.128.1 0.0% 10 18.0 13.4 10.5 18.8 2.8 3.|-- 10.246.253.133 0.0% 10 8.8 8.3 6.3 9.7 0.9 4.|-- 10.185.94.203 0.0% 10 8.2 9.3 7.8 11.7 1.3 5.|-- 10.185.94.25 0.0% 10 9.2 9.4 7.5 15.1 2.1 6.|-- 61-91-220-101.static.asianet.co.th 0.0% 10 8.3 9.2 7.8 10.2 0.5 7.|-- 58-97-82-116.static.asianet.co.th 0.0% 10 8.6 10.2 8.5 13.4 1.4 8.|-- ppp-171-102-254-65.revip18.asianet.co.th 0.0% 10 9.2 9.7 8.3 11.4 0.7 9.|-- ppp-171-102-254-227.revip18.asianet.co.th 0.0% 10 11.5 10.6 8.9 15.9 2.0 10.|-- 210-86-143-74.static.asianet.co.th 0.0% 10 9.8 9.3 8.0 10.8 0.7 11.|-- TIG-Net242-108.trueintergateway.com 0.0% 10 10.6 11.8 9.8 16.5 1.9 12.|-- TIG-Net245-241.trueintergateway.com 0.0% 10 39.7 40.5 38.5 47.6 2.5 13.|-- 13335.sgw.equinix.com 0.0% 10 41.8 38.2 36.5 44.5 2.6 14.|-- 1dot1dot1dot1.cloudflare-dns.com 0.0% 10 35.3 37.4 35.3 40.0 1.2
Dear Cloudflare, please turn on ECS by default.
PS: Check out ismydnsfast.com to check your performance to major authoritative DNS providers.