Hacker News Reader

Comment by enz | Hacker News Reader

9.9.9.9 does not seem to be geographically-aware. Here are the resolutions for the same domain name (CNAME referring to the hopefully closest edge server), from France.

   % dig [domain] @8.8.8.8 +short  
   [id].kxcdn.com.  
   p-frpa00.kxcdn.com. # France

   % dig [domain] @9.9.9.9 +short  
   [id].kxcdn.com.  
   s-us-ca00.kvcdn.com. # America  
   p-ussj00.kxcdn.com.

   % dig [domain] @1.1.1.1 +short  
   [id].kxcdn.com.  
   p-frpa00.kxcdn.com. # France

   % dig [domain] @ns0.fdn.fr +short # My ISP resolver  
   [id].kxcdn.com.  
   p-frpa00.kxcdn.com. # France

View on HN

9.9.9.9 does not pass along EDNS client subnet resulting in wrong geo-located responses. It is their "feature".

According to the FAQ[1], they also offer 9.9.9.10, which passes client subnet at the cost of other features.

[1] https://www.quad9.net/faq

Fair enough, but most users won't care enough look it up and use 9.9.9.10 instead of 9.9.9.9 if they want better performance in exchange for allegedly lower privacy.

It appears 1.1.1.1 also does not pass client-subnet, atleast not by default. Queries to my authoritative from Google always includes client subnet, OpenDNS required request for whitelist. For Cloudflare its unclear.

>It appears 1.1.1.1 also does not pass client-subnet, atleast not by default.

Wow, this is actually a huge issue. Just as a simple test, I tried nslookup google.com for both 1.1.1.1 and 8.8.8.8, and Cloudflare's responses ping at about 200ms, whereas Google's responses ping at ~10ms.

That also explains the abnormally low response time of CloudFlare's solution compared to the 2nd and 3rd place solutions; the geo-location lookups require more time to reach and resolve a decision and thus represent an increase in response time from the resolver (in exchange for improved latency in all future communications to the target server).

If you have a CF PoP close to you, the absent of it shouldn't really matter. Will only have an effect for those with a Google peering much closer than CF peering.

Should, but does not.

  dig @8.8.8.8 o-o.myaddr.test.l.google.com txt +short 
  "74.125.46.11"
  "edns0-client-subnet 94.181.44.185/32"
  dig @9.9.9.10 o-o.myaddr.test.l.google.com txt +short
  "2620:171:57::240"

A more comprehensive benchmark would also measure a ping or HTTP request to each resolved IP take to this into account. Actual browser performance is very skewed now without it.

And throughput to the content as well - RTT (even time to first byte) by itself does not a benchmark make.

Reply on news.ycombinator.com