
DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS - nykolasz
https://medium.com/@nykolas.z/dns-resolvers-performance-compared-cloudflare-x-google-x-quad9-x-opendns-149e803734e5
======
cleanbrowsing
Pushed a shell script to compare all of them from your location:

[https://github.com/cleanbrowsing/dnsperftest](https://github.com/cleanbrowsing/dnsperftest)

    
    
      $ sh ./dnstest.sh |sort -k 22 -n
                   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
      cloudflare     1 ms    1 ms    1 ms    4 ms    1 ms    1 ms    1 ms    1 ms    1 ms    1 ms      1.30
      norton         2 ms    2 ms    2 ms    2 ms    2 ms    2 ms    2 ms    2 ms    2 ms    2 ms      2.00
      neustar        2 ms    2 ms    2 ms    2 ms    1 ms    2 ms    2 ms    2 ms    2 ms    22 ms     3.90
      cleanbrowsing  11 ms   23 ms   11 ms   11 ms   11 ms   11 ms   11 ms   13 ms   12 ms   11 ms     12.50
      google         4 ms    4 ms    3 ms    21 ms   21 ms   61 ms   3 ms    21 ms   21 ms   22 ms     18.10
      opendns        2 ms    2 ms    2 ms    39 ms   2 ms    75 ms   2 ms    21 ms   39 ms   13 ms     19.70
      comodo         22 ms   23 ms   22 ms   22 ms   22 ms   22 ms   22 ms   22 ms   22 ms   23 ms     22.20
      quad9          10 ms   37 ms   10 ms   10 ms   10 ms   145 ms  10 ms   10 ms   10 ms   20 ms     27.20
      yandex         177 ms  216 ms  178 ms  182 ms  186 ms  177 ms  183 ms  174 ms  186 ms  222 ms    188.10
      adguard        199 ms  210 ms  200 ms  201 ms  202 ms  202 ms  199 ms  200 ms  198 ms  201 ms    201.20

~~~
talldan
From Perth, Western Australia:

    
    
                      test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
        cloudflare2nd  94 ms   81 ms   81 ms   79 ms   97 ms   90 ms   85 ms   89 ms   84 ms   78 ms     85.80
        cloudflare     74 ms   316 ms  69 ms   83 ms   77 ms   69 ms   85 ms   69 ms   82 ms   74 ms     99.80
        neustar        98 ms   100 ms  99 ms   102 ms  107 ms  113 ms  113 ms  112 ms  106 ms  100 ms    105.00
        adguard        154 ms  133 ms  133 ms  91 ms   94 ms   133 ms  96 ms   95 ms   98 ms   99 ms     112.60
        norton         132 ms  138 ms  117 ms  118 ms  131 ms  147 ms  133 ms  143 ms  141 ms  141 ms    134.10
        cleanbrowsing  154 ms  142 ms  140 ms  137 ms  155 ms  178 ms  158 ms  115 ms  77 ms   111 ms    136.70
        quad9          187 ms  170 ms  168 ms  154 ms  156 ms  156 ms  165 ms  164 ms  170 ms  174 ms    166.40
        opendns        258 ms  128 ms  121 ms  135 ms  125 ms  317 ms  124 ms  266 ms  131 ms  119 ms    172.40
        google         148 ms  264 ms  153 ms  137 ms  225 ms  274 ms  74 ms   258 ms  136 ms  279 ms    194.80
        google2nd      149 ms  284 ms  159 ms  223 ms  257 ms  412 ms  125 ms  254 ms  134 ms  268 ms    226.50
        comodo         273 ms  290 ms  303 ms  286 ms  308 ms  280 ms  314 ms  302 ms  263 ms  299 ms    291.80
        yandex         511 ms  567 ms  482 ms  442 ms  516 ms  443 ms  477 ms  471 ms  449 ms  454 ms    481.20

~~~
kyledrake
Are you using Telstra by chance? They have the worst routing I've ever seen.
I've had huge problems getting good routes for their customers. I've had
better luck with "IInet" customers.

I would be curious to see what the ping ms is for status.neocities.org,
ideally it's coming from Sydney and not the states.

~~~
talldan
Not sure, actually! I'm just staying with someone at the moment. They're
coincidentally changing broadband provider to this tomorrow -
[https://node1.com.au/](https://node1.com.au/)

------
lucb1e
Which ISPs are so bad that you want to use external services, which are
further in distance than your ISP, for speed? When I test with my ISP, they
beat all of these services (both IPv4 and IPv6). They're simply closer to me
in terms of hops.

My router is another story though. The Fritzbox (>200eur router) adds 6ms of
latency, and that's what is advertised over DHCP. (Might still be fine, since
cached queries are faster than the ping time to the ISP.) Note that my tests
were all with uncached queries (random subdomains of a domain), so it always
had to go out and ask an external server (though it could cache the NS record
for the domain).

~~~
coaxial
My isp got the brilliant idea of rolling their own YouTube cache servers. It's
great in theory but in or active they're under powered and so at peak hours I
can't even stream 240p on my 500mbits connection. I've had to block their
cache servers in my firewall for YouTube to be butter smooth at 1080p
consistently.

Another example is bell Canada who used to mine your DNS queries to profile
you for ads, or ISPs that high jack the nxdomain result to send you sponsored
results of vaguely similar sounding websites.

~~~
takeda
The YouTube cache is probably there not to increase performance for you, but
to reduce ISP cost (ISP pays for all data received from outside of their
network)

~~~
oasisbob
That's a strange way of looking at it. ISPs take all sorts of actions to both
increase performance to customers, and to reduce their costs.

A competent ISP operating in good faith will execute and expand peering
agreements when it makes economic sense to do so.

~~~
takeda
An ISPs #1 goal is to generate money.

When there's a competition this often equates with making customers happy so
they will stick with the ISP and perhaps more will switch from competitors.

When there's no competition and customers have no choice who to use it's
purely all about squeezing as much money as they can. This means raising
prices for the service and reducing cost by paying less to others services
even if it would reduce quality of service. The goal is to have service that's
good enough to keep people still use them (I mean there is price point and/or
quality that people would just not to have service at all).

If a specific action that ISP with monopoly does and it improves quality for
customer that's just a coincidence.

------
yread
It would be more interesting to see how are they doing for some websites in
the long tail, try the 900th, 9000th, and 90000th most popular sites instead
of the top. And try some locations which are not actual datacenters?

~~~
iforgotpassword
And test consistency. Stddev, and get the worst results from 1000 runs.

~~~
jobigoud
Worst result can be an outlier, maybe better to use the 95th percentile or
something.

------
cagenut
Mentally you need to add a big asterisk to tests of CDNs, and by extension
"dns done like a cdn" from VPS provider networks (content networks). That's
not where users come from (eyeball networks), and therefore not where they
focus their efforts in peering and route-optimizing.

------
anilgulecha
I think we'll start seeing the standard configuration of 1.1.1.1,8.8.8.8
everywhere.

Google/Cloudflare tackled the UX of free DNS spectacularly with these gold IP
addresses. It's the primary reason I use them instead of OpenDNS, which was an
earlier player in this space.

~~~
keeperofdakeys
Be careful with that, Google DNS (as an example) will start ignoring your DNS
requests if you go over the rate-limit. Not an issue for home users, but an
issue for any sizeable business.

~~~
voltagex_
How big a business do you have to be to use "free" DNS servers, but not big
enough to run your own resolver?

~~~
stubish
Probably the same way they use Lets Encrypt instead of purchasing
certificates. Lots of free things actually are free, despite the negative
training otherwise we get from some companies.

------
enz
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

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

~~~
bjslade
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](https://www.quad9.net/faq)

~~~
sajal83
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.

~~~
bscphil
>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.

~~~
mjevans
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).

------
nvarsj
Just run your own DNS resolver if you value your privacy. With prefetching and
caching there will be little difference in performance.

~~~
jamra
But your DNS will have to query other DNS providers so if you’re the only one
using it, it won’t be private.

~~~
Daviey
There is 2 main different ways, one which does what you say - the other i'd
say is pretty much OK.

If your local DNS server is merely querying an upstream resolver (like 1.1.1.1
/ 8.8.8.8) on your behalf, then yes - it is no different.

If however, you query the root nameservers for the glue record for a domain
and query the domain's own nameservers directly, then it is pretty good... As
you are neither querying your ISP or TheMan.. which means that logically only
the domain nameserver owner knows what queries you made (and you are probably
hitting that domain in a moment anyway!). (The caveat is that some ISP's do
transparent DNS proxying.. in which case, you have much larger trust issues
with your ISP and need to take greater measures!)

That said.. I cba with that.

~~~
jeremejevs
> only the domain nameserver owner knows what queries you made (and you are
> probably hitting that domain in a moment anyway!)

But these are different people, with different incentives. The NS owner may be
logging everything, without the domain owner's knowledge, and the NS owner
won't even be in the wrong, because they likely made no promise to not log.

With a single resolver, I can verify that they're trustworthy enough [for me],
just once, and direct all my traffic to it. Cloudflare's "We committed to
never writing the querying IP addresses to disk and wiping all logs within 24
hours" is something, I imagine, they very much wouldn't want to be caught
violating or changing their mind about later.

In the meanwhile, with the root NS method, I can only hope that my queries
will get lost in the "noise". And I'm putting noise in quotation marks because
there isn't much diversity in the name server ownership: 75% of Alexa top 1M
domains are hosted at Cloudflare, GoDaddy and Amazon. [0]

[0] [https://www.datanyze.com/market-
share/dns/Alexa%20top%201M/](https://www.datanyze.com/market-
share/dns/Alexa%20top%201M/)

~~~
Isomer
With QNAME minimalisation, RFC7129 (Authenticated denial of existence) and
RFC8020 (NXDOMAIN: There really is nothing underneath), you should be sending
almost nothing to the root servers of use.

QNAME minimalisation will only send <randomstring>.com to the root for them to
give you the referral.

and RFC7129/RFC8020 mean that when you get a NXDOMAIN back from the root,
you'll cache it and never try again for a large swath of possible names.

~~~
vavrusa
QNAME minimization just minimizes the name to one label under a delegation,
there's no randomization. So root zone would only get 'com.' (and type NS).
It's unfortunately easy for authoritative servers (below TLD level) to bypass
it by returning NXDOMAIN. Resolver has to fall back on using a full name. The
main reason is that a lot of authoritative DNS servers (notably Akamai) return
NXDOMAIN when there's nothing under the minimized name, but there is something
below it (aka empty non-terminal). So without workarounds the resolver would
return NXDOMAIN early instead of retrying with the full name.

------
swinglock
You can run a benchmark of your own using namebench. I recommend you uncheck
the options for the included nameservers or it will take a very long time to
run and enter only the DNS servers you want to test manually. It can use your
Firefox browsing history as a source for domains to resolve.

Ignore the "incorrect" and "hijacked" warnings, I think the program has
hardcoded, outdated IP ranges for popular services which causes those.

[https://code.google.com/archive/p/namebench/](https://code.google.com/archive/p/namebench/)

~~~
agumonkey
for the curious arch user, it's on AUR

ps: namebench is quite extensive. thousands of queries and a nice and long
report. enjoy it

------
jimaek
If you want to see the performance from even more locations here is a more
detailed benchmark [https://www.cdnperf.com/tools/cdn-latency-
benchmark/0d8b484e...](https://www.cdnperf.com/tools/cdn-latency-
benchmark/0d8b484e2b77537487e5170c4c38647e)

Or you can even use a CLI [https://perfops.net/cli](https://perfops.net/cli)
to run custom tests from any location

------
tambre
Unfortunately no tests for IPv6 connections. Disappointing considering that
all DNS traffic I generate will be over IPv6.

------
bjslade
Besides response time, the next level of comparison is how well geo-DNS-based
services (global load balancing, etc.) support these resolvers. AFAIK 8.8.8.8
gives decent results in most places, though I've seen suboptimal US-centric
results from Quad9 in Asia. Support for RFC 7871 (Client Subnet in DNS
Queries) comes into play here too.

~~~
dbg31415
I always used 8.8.8.8, since I couldn't remember OpenDNS's IPs.

But just found out today that, from Sydney, OpenDNS and Cloudflare are kicking
Google's ass for speed. 8.8.8.8 is on par with my ISP-default DNS.

~~~
jg2leet
Ever since The Great Comcast DNS Outage of 2010, I've had the OpenDNS IPs
burned into my memory from telling so many people.

I like the fact that you can sign up for OpenDNS and customize some of the
filtering (ads, spam/malware, etc.) They used to have crappy handling of
nxdomains (by default) redirecting you to a website with ads, but I believe
that's no longer the case?

~~~
coaxial
As250 is running a free DNS server with adblocking enabled FWIW:
[https://twitter.com/as250/status/790593201832857601?s=20](https://twitter.com/as250/status/790593201832857601?s=20)

Pihole is also a great alternative if you have a spare raspi lying around.

~~~
mynameisvlad
> if you have a spare raspi lying around.

Really, if you have a spare computer of any type. I run it on a VM and it
works just fine. It was made for Raspberry Pis but it'll work on any system.

------
Klasiaster
The OpenNIC project has a database of community/private DNS servers with
certain standards.

[https://www.opennic.org/](https://www.opennic.org/)

------
djsumdog
I feel like people forgot about how CloudFlare, Google, et. al. can new
effectively censor content they don't agree with:

[https://fightthefuture.org/article/the-new-era-of-
corporate-...](https://fightthefuture.org/article/the-new-era-of-corporate-
censorship/)

..and even though CloudFlare back pedaled on that particular decision
somewhat, it still happened.

If you really want something fast and secure, run your own caching DNS that
uses root DNS servers.

~~~
plg
> If you really want something fast and secure, run your own caching DNS that
> uses root DNS servers.

is there a good tutorial for this somewhere?

~~~
oelmekki
If you want to do it on your local linux system, it's pretty easy: you just
need to install bind9 and use `nameserver 127.0.0.1` in your /etc/resolv.conf

Bind9 has a poor reputation because of how difficult it is to use it to define
zones (manage a domain name), but if you want to use it as a resolver, it's
basically plug'n'play.

Huge bonus included : if you want to flush the cache, you just need to run
`sudo rndc flush`, so you don't have to wait for TTL timeout to test your
newly configured domain name when you setup a website (you still have to
restart your browser, because most of them do their own dns caching).

~~~
vertex-four
Honestly, isn’t Unbound a better shout if you’re not going to be fiddling with
it? Just install, run, and edit /etc/resolv.conf to point at 127.0.0.1.

~~~
oelmekki
Well, you're describing exactly how to do it with bind9 :) What make you say
Unbound is better?

~~~
swinglock
Unbound is more lightweight. All it does is recursive lookups, it has no
option for being authoritative. If that's all you need then that's better.

There are other options too, I don't know what makes Unbound better than
PowerDNS Recursor or Knot Resolver.

------
qwerty456127
Is there a tutorial on setting up your own? I've got a huge hosts file and
would like it to affect all the devices at my home but setting up a DNS server
always seemed high-level black magic to me.

~~~
AntonyGarand
[https://pi-hole.net](https://pi-hole.net)

------
v0id24

      Moscow, Russia
                     test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
      adguard        6 ms    8 ms    4 ms    8 ms    11 ms   5 ms    7 ms    4 ms    4 ms    22 ms     7.90
      google2nd      4 ms    4 ms    5 ms    22 ms   30 ms   18 ms   3 ms    27 ms   3 ms    3 ms      11.90
      yandex         5 ms    9 ms    5 ms    9 ms    87 ms   50 ms   9 ms    9 ms    5 ms    60 ms     24.80
      google         3 ms    18 ms   3 ms    20 ms   29 ms   165 ms  3 ms    18 ms   3 ms    19 ms     28.10
      cloudflare2nd  45 ms   44 ms   46 ms   44 ms   46 ms   44 ms   44 ms   45 ms   65 ms   48 ms     47.10
      quad9          47 ms   48 ms   47 ms   48 ms   46 ms   57 ms   46 ms   44 ms   46 ms   45 ms     47.40
      opendns        45 ms   47 ms   46 ms   59 ms   47 ms   45 ms   47 ms   49 ms   51 ms   44 ms     48.00
      norton         52 ms   49 ms   53 ms   52 ms   58 ms   56 ms   51 ms   48 ms   54 ms   52 ms     52.50
      cleanbrowsing  96 ms   48 ms   60 ms   46 ms   49 ms   46 ms   45 ms   49 ms   44 ms   46 ms     52.90
      neustar        54 ms   56 ms   52 ms   59 ms   50 ms   57 ms   55 ms   57 ms   59 ms   54 ms     55.30
      comodo         80 ms   88 ms   73 ms   113 ms  79 ms   75 ms   75 ms   74 ms   74 ms   90 ms     82.10
      cloudflare     1000 ms 1000 ms 1000 ms 1000 ms 1000 ms 1000 ms 1000 ms 1000 ms 1000 ms 1000 ms   1000.00

------
delhanty
From Waimanalo, Hawaii cloudflare times out:

    
    
                      test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
      192.168.50.1      154 ms  157 ms  154 ms  154 ms  154 ms  154 ms  156 ms  158 ms  155 ms  184 ms    158.00
      cloudflare        1000 ms 1000 ms 1000 ms 1000 ms 1000 ms 1000 ms 1000 ms 1000 ms 1000 ms 1000 ms   1000.00
      google            106 ms  82 ms   80 ms   158 ms  113 ms  148 ms  82 ms   107 ms  106 ms  81 ms     106.30
      quad9             91 ms   99 ms   111 ms  106 ms  90 ms   97 ms   89 ms   91 ms   89 ms   88 ms     95.10
      opendns           105 ms  81 ms   96 ms   120 ms  82 ms   110 ms  81 ms   115 ms  105 ms  83 ms     97.80
      norton            82 ms   80 ms   82 ms   94 ms   84 ms   91 ms   82 ms   80 ms   82 ms   83 ms     84.00
      cleanbrowsing     135 ms  158 ms  245 ms  136 ms  132 ms  132 ms  133 ms  138 ms  133 ms  145 ms    148.70
      yandex            287 ms  389 ms  256 ms  256 ms  258 ms  256 ms  258 ms  257 ms  258 ms  255 ms    273.00
      adguard           290 ms  270 ms  319 ms  295 ms  433 ms  340 ms  261 ms  351 ms  290 ms  264 ms    311.30
      neustar           86 ms   82 ms   83 ms   84 ms   80 ms   90 ms   80 ms   81 ms   84 ms   83 ms     83.30
      comodo            149 ms  148 ms  152 ms  152 ms  153 ms  148 ms  150 ms  147 ms  148 ms  151 ms    149.80

------
leowinterde
Quad9 has several IPs and different services, see
([https://www.heise.de/imgs/18/2/3/1/7/9/4/7/quad9-feature-
mat...](https://www.heise.de/imgs/18/2/3/1/7/9/4/7/quad9-feature-
matrix-72311e6ae96e13b1.png)). For some reason this is hidden on the quad9
website.

~~~
mynameisvlad
It's in their FAQ:
[https://www.quad9.net/faq/#Is_there_a_service_that_Quad9_off...](https://www.quad9.net/faq/#Is_there_a_service_that_Quad9_offers_that_does_not_have_the_blocklist_or_other_security)

Seems they've sunset .11 and .12, but .10 is still up.

------
halayli
This tests the performance / distance between vps data centers and the dns
server's data centers. imho it's better to have a test web page that consumers
visit and establishes a tcp connection to those dns services and estimate the
rtt of a single packet from the time it took to establish the connection, or
test via the https interface for services that support it.

~~~
jsjohnst
While I whole-heartedly agree with your objection, I question the solution.
How do you get high accuracy timing of DNS resolution in JavaScript inside the
browser?

~~~
falcolas
Not a JavaScript developer, but if they can do timings fine enough to run
Meltdown attacks in JS, I think they can safely and accurately measure network
timings.

~~~
jsjohnst
Timing in general isn’t the issue here, there isn’t a way to my knowledge to
get just the DNS portion (specifically across an arbitrary set of DNS
providers) of the network timing in JS. Just like there isn’t a way to test
the timing of a single packet really either.

~~~
falcolas
You can get the DNS-over-HTTP(s) though. Not as ideal as a perfect DNS
request/response over UDP, of course.

~~~
jsjohnst
See original context, it is clearly about evaluating DNS providers with real
end users via a web app. Considering a majority of providers don’t support it,
seems it’ll be a very limited evaluation if it followed your proposal.

------
justicezyx
Anecdotally, I know a guy who runs a local Cloud provider in the greater-
Beijing area (part of Hebei proveince). He told me Cloudflare has struck a
deal with the government to have integration with them, presumably with higher
standard than normal tech providers.

That might explain why CloudFlare has good performance across the globe, which
in a large part related to China.

------
sajal83
[https://pulse.turbobytes.com/results/5ac1f967ecbe4078c200ee4...](https://pulse.turbobytes.com/results/5ac1f967ecbe4078c200ee4a/)

Cloudflare consistently times out from these networks.

Netherlands - AS13127 Philippines - AS135132 Thailand - AS17552 (One of the
largest consumer internet providers) US - AS7018 (AT&T)

~~~
therealmarv
I'm sure this is because 1.1.1.1 does not work everywhere well. Maybe with
1.0.0.1 it will work more reliable.

~~~
sajal83
Yep you are right right.

    
    
        ~# mtr --report --address 192.168.2.2 1.1.1.1
        Start: Mon Apr  2 16:53:31 2018
        HOST: apu                         Loss%   Snt   Last   Avg  Best  Wrst StDev
          1.|-- 192.168.2.1                0.0%    10    0.9   1.1   0.9   1.2   0.0
          2.|-- 10.137.128.1               0.0%    10   11.3  12.8  10.7  17.1   1.8
          3.|-- 10.246.253.133             0.0%    10    7.7   8.2   7.5   9.1   0.0
          4.|-- 10.185.94.203              0.0%    10    9.1   8.4   6.9   9.4   0.6
          5.|-- 10.185.94.25               0.0%    10    9.5   8.7   7.7  10.0   0.5
          6.|-- 61-91-220-101.static.asia  0.0%    10   11.7  11.7   8.6  25.7   5.2
          7.|-- 58-97-82-116.static.asian  0.0%    10   10.7  10.2   8.6  15.4   1.9
          8.|-- ppp-171-102-254-81.revip1  0.0%    10    9.2   9.2   7.1  10.8   0.9
          9.|-- ppp-171-102-250-134.revip  0.0%    10    8.4  10.0   8.4  11.3   0.7
         10.|-- ppp-171-102-250-149.revip  0.0%    10    9.0   9.7   9.0  10.9   0.3
         11.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
        ~# mtr --report --address 192.168.2.2 1.0.0.1
        Start: Mon Apr  2 16:54:05 2018
        HOST: apu                         Loss%   Snt   Last   Avg  Best  Wrst StDev
          1.|-- 192.168.2.1                0.0%    10    1.2   1.1   0.8   1.3   0.0
          2.|-- 10.137.128.1               0.0%    10   12.1  12.8   9.2  18.2   2.4
          3.|-- 10.246.253.133             0.0%    10    9.8   9.0   7.5  14.7   2.0
          4.|-- 10.185.94.203              0.0%    10    4.4   7.9   4.4   8.8   1.2
          5.|-- 10.185.94.17               0.0%    10    9.2   9.1   7.2  10.3   0.9
          6.|-- 61-91-220-55.static.asian  0.0%    10    9.7  10.6   8.0  17.2   2.6
          7.|-- 58-97-82-120.static.asian  0.0%    10   10.5   9.7   8.2  11.2   0.7
          8.|-- ppp-171-102-254-65.revip1  0.0%    10   10.5   9.7   8.8  10.7   0.0
          9.|-- ppp-171-102-254-227.revip  0.0%    10    8.9  13.1   8.8  44.0  10.8
         10.|-- 61-91-213-130.static.asia  0.0%    10   10.9   9.8   8.3  10.9   0.6
         11.|-- TIG-Net242-40.trueinterga  0.0%    10   15.0  14.1  10.9  16.1   1.8
         12.|-- TIG-Net245-243.trueinterg  0.0%    10   38.1  38.0  36.4  40.6   0.9
         13.|-- 13335.sgw.equinix.com      0.0%    10   37.4  38.6  36.4  48.5   3.5
         14.|-- 1dot1dot1dot1.cloudflare-  0.0%    10   36.9  36.3  35.0  36.9   0.5
    

Edit: Formating

------
eikenberry
What about services which use anycast/geolocation to decide where to serve you
data from? They will get bad location data as they will get the location of
the resolver. This can have a direct impact on services.

An example of my own is from about 10 years ago when Netflix started
streaming. We got a Roku and signed up but the service terrible due to the
stream stopping to buffer every few minutes. After researching and trying
several things I eventually came across the fact that the stream was coming
from servers in over a thousand miles away with pretty bad latency between.
Long story short, I eventually figured out it was due to my using the level3
resolvers for DNS. As soon as I changed to our ISP's DNS servers it worked
great and the data was streaming from very close.

~~~
unethical_ban
I wonder if location data would/could/should be an optional flag in DNS
requests, instead of relying on physical location of the resolver.

------
timdavila
What is the benefit to Google/CloudFlare of providing free DNS resolution? Why
do they offer it?

~~~
sseth
Long back when this started, OpenDNS was the largest public DNS provider. And
I know at one point they started "hijacking" google requests - you can read
this here : [http://www.dslreports.com/forum/r21284386-Google-Com-
Hijacke...](http://www.dslreports.com/forum/r21284386-Google-Com-Hijacked-by-
OpenDNS). This was in 2008. They used to also hijack DNS requests to show
their own ads. And i am pretty sure many ISPs always played around with DNS in
this way.

In 2009, Google launched its own Public DNS - the reasons given were to make
the web faster and safer, and i think there is some sense in which they have
delivered. But I think another reason was defensive - provide an alternative
to OpenDNS and to crappy ISP DNSs.

In 2014 - OpenDNS stopped using DNS to show ads :
[https://umbrella.cisco.com/blog/2014/05/29/no-more-
ads/](https://umbrella.cisco.com/blog/2014/05/29/no-more-ads/).

------
ryanlol
Why is google DNS listed as "private"? They permanently log all of your DNS
queries.

[https://developers.google.com/speed/public-
dns/privacy](https://developers.google.com/speed/public-dns/privacy)

~~~
oasisbob
That page specifically says that they don't:

> Google Public DNS stores two sets of logs: temporary and permanent. The
> temporary logs store the full IP address of the machine you're using. [...]
> We delete these temporary logs within 24 to 48 hours.

> In the permanent logs, we don't keep personally identifiable information or
> IP information. We do keep some location information (at the city/metro
> level) so that we can conduct debugging, analyze abuse phenomena. After
> keeping this data for two weeks, we randomly sample a small subset for
> permanent storage.

~~~
ryanlol
Read the page.

>Finally, if you're interested in knowing what else we log when you use Google
Public DNS, here is the full list of items that are included in our permanent
logs:

>Request domain name, e.g. www.google.com

>Client's AS (autonomous system or ISP), e.g. AS15169

>User's geolocation information: i.e. geocode, region ID, city ID, and metro
code

>Absolute arrival time in seconds

Not tracking individual IPs doesn't mean shit.

------
reaperducer
What I don't understand is how these services are offered at apparently no
cost.

Sure, I expect Google is slurping all of my connections to help build an ad
profile on me. But what about the other companies? They've got to keep the
lights on somehow.

~~~
drivebycomment
> I expect Google is slurping all of my connections to help build an ad
> profile on me.

Google says they don't - from [https://developers.google.com/speed/public-
dns/privacy](https://developers.google.com/speed/public-dns/privacy):

> We don't correlate or combine information from our temporary or permanent
> logs with any personal information that you have provided Google for other
> services.

Honestly, Google DNS policy seems largely similar to Cloudflare, with the
exception of 3rd party audit.

Cloudfare apparently doesn't do GeoIP mapping, so, till they implement that,
it's not going to be useful for me.

------
nextlevelwizard
GRC's DNS Benchmark[0]

For anyone who wants to test their DNS servers. It is Windows binary, but
works fine on Wine.

[0]
[https://www.grc.com/dns/benchmark.htm](https://www.grc.com/dns/benchmark.htm)

~~~
manigandham
This is the only proper way to test nameservers as a consumer. Everything else
using any virtual servers in data centers will be skewed.

------
Isomer
Things to look for in comparing recursive DNS servers performance:

The 95%ile DNS response time for cached/uncached names. The 95%ile DNS
response when one/some of the authoritative nameservers is "lame" or not
responding. (better yet, 99%ile, but that requires even more queries...)

The average packet loss to the nameserver. (As many resolvers use the default
of a 5s timeout, better resolvers use a 1s timeout, the best stub resolvers
would use a dynamic timeout, but afaik, none do...).

Do they implement DNSSEC validation? What is their story for domains that
break DNSSEC (eg:
[https://www.internetsociety.org/resources/deploy360/2014/cas...](https://www.internetsociety.org/resources/deploy360/2014/case-
study-comcasts-dnssec-implementation/))?

Do they implement RFC7129 (authenticated denial of existence)? This can be
used to prevent your service being used to attack an authoritative nameserver,
prevents leaks of useless domains (eg machines looking up untitled.pdf as a
domain), and allows you to return NXDOMAIN with much lower latency, making DNS
search paths faster. RFC8020 (NXDOMAIN: There is really nothing underneath)
would be another example where you can prevent leaking names, and return
faster responses from a smaller cache (although I admit I've never seen anyone
implement RFC8020 yet).

Will they accept (signed) responses into their cache in the additional
section? Again, this can significantly reduce the time for uncached responses.

[hint: These are good reasons you should sign your domain, it can make things
faster and reduce load on your authoritative nameserver!]

What is their story for domains that need a cache flush?

Do they (correctly) implement IPv6 from the recursive to the authoritative
nameservers? Do they (correctly) implement IPv6 from the stub to the recursive
nameserver?

How big is their cache? How long do things stay in their cache? There's no
point being close to a nameserver with an empty cache. Querying www.google.com
isn't really going to tell you much about their cache depth, nor is the Alexa
1M. You need a very very wide variety of names.

Do they provide good GeoIP responses? There's no point in getting an answer
for the middle of the US in <1ms if you happen to be 300ms away in Asia
somewhere. The DNS response was fast, but the webserver it sent you to is
going to give you abysmal performance. This is often done with EDNS0-Client-
Subnet, but it can also be fudged by making the outbound IPs for the iterative
requests being diverse enough for different localities.

Do they "lie" about names? In what circumstances do they lie? Do they NXDOMAIN
malicious domains? adult websites? ad domains? random websites? Do they
redirect ad websites to their own ad farm? How do their lies handle DNSSEC?

Do they perform QNAME minimalisation to help protect your queries from servers
that don't need it?

What other features do they implement to make sure their cache is never
poisoned?

What is their abuse plan? If I send them a vast number of queries what
happens? Do they send back TrunCated responses and force me over TCP? Will
they respond with SERVFAIL? Or will they drop the queries? Or will they pass
them all through to the authoritative nameservers? Do I need to do anything
(other than stop sending abusive amounts of load) to be unblocked? What if the
reason I'm sending a large number of queries is because I'm a carrier grade
NAT IP pool and I have one broken/bad user?

What is their reliability story? Is it expected that they will go down for 10
minutes every now and again?

What do they do about general Internet Hygiene? Do they have protects against
being used for reflection attacks?

Do they do preemptive lookups to keep their cache warm or is someone always
guaranteed to have to wait for the full resolution? How do they make sure they
don't accidentally DoS authoritative nameservers with preemptive resolutions?

Things not to look for:

ICMP/mtr times are essentially meaningless, except as providing general
information about routing decisions.

The mean response time, as it tends to be washed out by cached response times,
and what you don't care about is if it takes 15ms or 17ms on average, as you
can't perceive the difference. What you _do_ care about is if one nameserver
has 1/5000 queries which take >1s as that will become a frequent noticeable
problem when your surfing.

Just looking at a few common names that are likely to be in the cache. Yes,
those are important, but as with anything at scale, it's the long tail that's
actually interesting and will dominate your perception of performance. You can
set up your own domain, and search for random strings and force the full end-
to-end query flow. (Beware about wildcard domains for this, if your domain is
signed, in theory the nameserver could synthesize responses without going back
to your nameserver).

Where are your vantage points for measurements? Many people appear to measure
from places like AWS zones, and then report spectacular performance for DNS
servers also hosted in the same AWS zones – despite most of their users not
being hosted there.

Hmm, I'm sure there's more, but that's off the top of my head.

(Disclaimer: Once upon a time, I was one of the engineers oncall for Google
Public DNS, so I have Opinions)

~~~
vavrusa
This is a great comment. The ping time is so much less meaningful for
recursive service than for authoritative. The latency difference between
cached answer and uncached answer is in several orders of magnitude. The cache
hit ratio also plummets without some sort of cache sharing, which many
recursive services don't implement. So you may end up with great ping time,
but something like:

``` ;; Query time: 12 msec ;; Query time: 149 msec ;; Query time: 14 msec ;;
Query time: 238 msec ;; Query time: 112 msec ;; Query time: 27 msec ```

For less popular names.

------
retirw
Hi, could someone explain to me what this DNS stuff is about like I'm 5? How
is it related to private browsing?

~~~
ohiovr
DNS is a service that converts easy to remember names like google.com or
youtube.com to hard to remember ip addresses so you don't have to. We find it
easier to remember names than strings of numbers. So usually your isp assigns
their own dns server for you to use automatically and most people don't think
about it. Sometimes a DNS server can go bad or become slow and people use
services like google's dns services to speed up access to the sites they use.
Google could use dns look up information from your computer to know what sites
you visit even when you don't search google.com for it. I don't know if they
do or not but I was thinking, if I was google I would probably do that. Its
not that google needs your browsing habits to find web sites but it can use
the querys it recieves to measure the popularity of web sites or web pages. As
to why the current interest in DNS I'm not sure.

A lot of trust is in DNS and a lot of people don't realize that an evil dns
server can make your browser think you are going to good sites but could
actually be an imposter.

Other annoyances are NXDOMAIN (non existant domain) querys that are hyjacked
to serve you ads.

Controling DNS servers is a great way for a nation state to censor
communication. They could take any site they wish and forward your browser to
an automatic service that logs you with other "wrong thinkers". Or just
resolve the domain name to null reference.

Speed, security, privacy are things to consider for DNS. But like a lot of
things on the internet, it all about trust...

------
Jaruzel
Hmmm. Off the bat, CloudFlare ICMP for me is worse than Google:

[http://www.jaruzel.com/files/ICMP-CloudFlareDNS-vs-Google-
te...](http://www.jaruzel.com/files/ICMP-CloudFlareDNS-vs-Google-tetx.png)

I'll stick with Google I think. UK/London btw.

------
scrumper
Safari barfs on visiting [https://1.1.1.1](https://1.1.1.1) as linked in the
article. Certificate invalid (though it looks fine). Rather unfortunate
regarding perception; it's an interesting service!

~~~
sjwright
Works for me; Safari 11.0.3 on High Sierra.

(I'm surprised it works at all though... I wouldn't have thought you could
have an HTTPS certificate for an IP address? You learn something new every
day.)

~~~
Kalium
The actual domain name is [https://cloudflare-dns.com/](https://cloudflare-
dns.com/) (found by inspecting the cert)

Before SNI, every cert had to go to a static public IP address. Everything
between you and the TLS terminator had to handle this. As a side-effect, you
didn't actually need to know the domain name to get the tunnel, because
everything handling the packets was running on the destination IP.

tl;dr: Trickery based on dated TLS quirks.

~~~
scrumper
That works fine (the URL directly). The certificate is valid. Entering
[https://1.1.1.1](https://1.1.1.1) doesn't, but shows the same certificate.

Don't really understand what's happening here. Anyway thanks for the info
there.

~~~
Kalium
How odd. What browser are you using? It appears to be deviating from spec.

~~~
scrumper
Safari 11.1 (13605.33.1.2). Mac OSX 10.13.4.

~~~
Kalium
You are using a slightly more recent version than me, but not significantly.
There's no obvious reason there, unless Apple decided to kill support for ip
addresses entirely. Is it possible that your machine has been configured in an
unconventional fashion?

------
beaconfield
I let it (the story) sit a day after 4/1 just to make sure it wasn't really an
April Fools' joke. But today I made it my primary DNS server and it's
performing very well. Glad there's another player in the private DNS space.

------
userbinator
I wonder how well 4.2.2.x compares...

Then again, a few ms of difference is unlikely to make any noticeable effect
in real-world use cases where clients already have local DNS caching and the
bulk of the time is data transfer, not DNS lookups.

~~~
jsjohnst
> the bulk of the time is data transfer, not DNS lookups

You’d be surprised.

------
christogreeff
No tests for Africa?

------
rdtsc
I've been using Quad9, if anything just because I feel Google already knows
too much about me anyway. So far no complaints about it.

------
ralfm
Why is Montreal reporting abnormally high response times across the board?

For example:

# Cloudflare Toronto 3.42ms vs. Montreal 17ms;

# Google Toronto 9.42ms vs. Montreal 16.71ms.

~~~
concatime
I live in Montréal, and I saw the same tendency. Cloudflare has a datacenter
here. Waiting for a tangible explanation…

~~~
betaby
Are you using BIG ISP or small? Big guys don't peer at QIX and drag your
traffic to US. On other side, smaller players peer at QIX
[https://qix.ca/members](https://qix.ca/members)

------
pouetpouet
How do other services compare? Like [https://blog.uncensoreddns.org/dns-
servers/](https://blog.uncensoreddns.org/dns-servers/)
[https://dns.watch/](https://dns.watch/)
[https://ipredator.se/page/services#service_dns](https://ipredator.se/page/services#service_dns)

------
cbg0
I wasn't aware of Quad9, it seems like a pretty great option for those that
are easy targets of scams/phishing.

~~~
akerro
Quad9 is supported/funded by City Of London Police, the same police that
cooperates with ad companies to track people online.
[https://www.theguardian.com/media-network/media-network-
blog...](https://www.theguardian.com/media-network/media-network-
blog/2014/apr/17/police-advertising-industry-copyright-infringement)

Keep away from this.

~~~
mft_
Interesting question: would I rather protect my elderly Mum from known
malicious domains potentially trying to scam/phish, or from potential tracking
and ad targeting?

(Actually, it's not really a difficult choice at all, is it?)

~~~
hollander
Why not both? You're smart enough I guess to find a good solution.

------
paulcarroty
I switched all my devices to CloudFlare 'cause it 2x faster than Google DNS in
my location - Europe.

~~~
patrickaljord
I'm in Europe too which is in Paris and Google DNS is way faster at 4ms vs
15ms for cloudflare.

------
ManishKrishna
Will website name in certificate shared by server during handshake kill the
DNS over https purpose?

------
jsgo
Out of curiosity, are there any negatives for everyone to funnel their DNS
traffic through a single provider? Might be paranoia, and it may in this case
just be putting all of your traffic through company_a vs all of your traffic
through company_b scenario, but I've been curious since this was announced.

------
ralfm
Why is Montreal abnormally high for all services?

~~~
Thaxll
It goes to NYC ...

------
sabujp
google is faster for me in the bay area from comcast network. Using both ping
and dig for testing

------
darkhorn
It is blocked in Turkey.

------
unixhero
Cloudflare it is then!

------
jradd
Thanks, great response times from my NYC droplet.

    
    
    				   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
    	quad9          1 ms    2 ms    1 ms    1 ms    1 ms    1 ms    1 ms    1 ms    1 ms    1 ms      1.10
    	cloudflare     2 ms    1 ms    1 ms    2 ms    1 ms    1 ms    1 ms    2 ms    1 ms    1 ms      1.30
    	comodo         1 ms    2 ms    2 ms    3 ms    2 ms    1 ms    2 ms    1 ms    1 ms    2 ms      1.70
    	adguard        2 ms    2 ms    3 ms    2 ms    2 ms    2 ms    2 ms    2 ms    2 ms    2 ms      2.10
    	cleanbrowsing  2 ms    4 ms    2 ms    2 ms    2 ms    2 ms    14 ms   16 ms   2 ms    2 ms      4.80
    	norton         6 ms    7 ms    7 ms    7 ms    8 ms    7 ms    6 ms    7 ms    7 ms    7 ms      6.90
    	namecheap      7 ms    7 ms    7 ms    7 ms    7 ms    7 ms    7 ms    7 ms    7 ms    7 ms      7.00
    	neustar        8 ms    7 ms    7 ms    8 ms    9 ms    6 ms    7 ms    7 ms    7 ms    7 ms      7.30
    	namecheap2nd   8 ms    8 ms    7 ms    9 ms    9 ms    8 ms    10 ms   8 ms    8 ms    8 ms      8.30
    	opendns        20 ms   1 ms    1 ms    30 ms   2 ms    8 ms    1 ms    16 ms   15 ms   3 ms      9.70
    	google2nd      16 ms   1 ms    1 ms    17 ms   1 ms    24 ms   1 ms    16 ms   17 ms   14 ms     10.80
    	google         17 ms   1 ms    1 ms    17 ms   1 ms    41 ms   1 ms    17 ms   18 ms   15 ms     12.90
    	cloudflare2nd  1 ms    2 ms    1 ms    1 ms    1000 ms 2 ms    2 ms    1 ms    2 ms    2 ms      101.40
    	yandex         101 ms  102 ms  104 ms  101 ms  115 ms  103 ms  107 ms  100 ms  105 ms  136 ms    107.40
    

Not so much from my home ISP:

    
    
    				   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
    	namecheap2nd   45 ms   45 ms   44 ms   45 ms   48 ms   45 ms   45 ms   46 ms   48 ms   45 ms     45.60
    	cloudflare2nd  45 ms   49 ms   48 ms   47 ms   45 ms   44 ms   45 ms   45 ms   46 ms   46 ms     46.00
    	namecheap      46 ms   48 ms   48 ms   44 ms   45 ms   45 ms   46 ms   45 ms   45 ms   48 ms     46.00
    	cleanbrowsing  46 ms   46 ms   44 ms   56 ms   45 ms   44 ms   48 ms   46 ms   44 ms   46 ms     46.50
    	google2nd      49 ms   47 ms   47 ms   45 ms   51 ms   47 ms   46 ms   44 ms   43 ms   46 ms     46.50
    	comodo         46 ms   47 ms   48 ms   49 ms   46 ms   47 ms   44 ms   45 ms   47 ms   50 ms     46.90
    	adguard        49 ms   48 ms   45 ms   46 ms   46 ms   48 ms   49 ms   48 ms   48 ms   48 ms     47.50
    	google         46 ms   49 ms   47 ms   47 ms   45 ms   47 ms   47 ms   49 ms   44 ms   67 ms     48.80
    	opendns        47 ms   46 ms   47 ms   64 ms   48 ms   49 ms   46 ms   64 ms   64 ms   48 ms     52.30
    	cloudflare     44 ms   48 ms   45 ms   50 ms   48 ms   110 ms  45 ms   48 ms   45 ms   47 ms     53.00
    	quad9          46 ms   49 ms   45 ms   47 ms   49 ms   153 ms  46 ms   45 ms   48 ms   46 ms     57.40
    	neustar        66 ms   66 ms   66 ms   67 ms   66 ms   66 ms   66 ms   67 ms   66 ms   67 ms     66.30
    	norton         91 ms   67 ms   67 ms   67 ms   66 ms   66 ms   67 ms   66 ms   67 ms   67 ms     69.10
    	yandex         176 ms  279 ms  176 ms  174 ms  188 ms  178 ms  179 ms  176 ms  174 ms  179 ms    187.90

------
monochromatic
Does anyone actually believe that google isn’t hoovering up personal data with
its DNS service?

~~~
jeremy7600
All this tasty data:

Request domain name, e.g. www.google.com

Request type, e.g. A (which stands for IPv4 record), AAAA (IPv6 record), NS,
MX, TXT, etc.

Transport protocol on which the request arrived, i.e. TCP, UDP, or HTTPS

Client's AS (autonomous system or ISP), e.g. AS15169 User's geolocation
information: i.e. geocode, region ID, city ID, and metro code

Response code sent, e.g. SUCCESS, SERVFAIL, NXDOMAIN, etc.

Whether the request hit our frontend cache

Whether the request hit a cache elsewhere in the system (but not in the
frontend)

Absolute arrival time in seconds

Total time taken to process the request end-to-end, in seconds

Name of the Google machine that processed this request, e.g. machine101

Google target IP to which this request was addressed, e.g. one of our anycast
IP addresses (no relation to the user's IP)

~~~
monochromatic
And my IP address, linking my browsing to my google account and my identity.

------
feelin_googley
Is DNS _configuration_ ever considered as a factor in "DNS performance"? IME
as an end user, it makes a significant difference.

For example if it takes seven queries to resolve a name "A" versus two queries
to look up a name "B", then in almost all cases, irrespective of the distance
to a cache, looking up A is going to be noticeably slower than looking up B.
Indirection is only one example. Even worse are configuations that knowingly
trigger retries and wait for client timeouts in order to present a client with
a particular nameserver.

Indirection and other "DNS tricks" come at a cost. IME, these are not
compensated for via the proximity of a cache.

------
Hyva
There's a lot more to consider than just performance when deciding whom to
share your browsing habits with. Why would you choose Cloudflare or Google?

This isn't an endorsement of Quad9 or OpenDNS; I just don't know enough about
them. However, the fact that Cloudflare and Google are privacy-and-security
nightmares is well documented.

------
mtgx
OpenNIC offers DNSCrypt.

[https://www.opennic.org/](https://www.opennic.org/)

------
vermaden
Google and Privacy=Yes ... sure.

------
MikeGale
I presume that Google uses this as part of it's surveillance operation.

~~~
Isomer
Google has a separate, stricter, privacy policy for Google Public DNS:
[https://developers.google.com/speed/public-
dns/privacy](https://developers.google.com/speed/public-dns/privacy)

Basically there are two log files kept:

\- One for up to 48 hours which contains IP addresses, which is used for
handling abuse.

\- One is permanent which doesn't contain any personal identifying information
(eg IP addresses), which is used for things like internal performance
monitoring, load testing, and tracking frequency of longer term abuse etc.

Google provides Google public DNS because if you see the internet as being
slow because of poor DNS performance, then you don't use websearch as much.
Google doesn't need to use Google Public DNS to track users, and would rather
not have the information (as it makes it available for government requests etc
which are a major pain to deal with). But running a large scale recursive DNS
server tends to attract a _lot_ of abuse, both intentional, and unintentional
as I'm sure 9.9.9.9 and 1.1.1.1 are discovering.

Google provides Google Public DNS because a lot of ISPs provide extremely poor
default recursive nameservers (having tiny caches, dropping queries due to
overload, not implementing IPv6, DNSSEC validation, EDNS0 payload size, or
other important modern DNS features. Some ISPs also hijack domains for their
own purposes, or "stretching" DNS TTLs etc) so providing a better alternative
to improve overall Internet use is clearly in Google's best interest.

Having other public resolvers, with different trade offs is clearly better for
everyone, including Google as long as they are reliable, trustworthy, and
provide low latency responses.

Good luck to everyone who's joining in the fun of running a planet scale
recursive DNS server.

(Disclaimer: I have previously worked on Google Public DNS, but no longer do)

~~~
cpeterso
Do you know if Chrome uses Google Public DNS by default? I've heard it does
for performance and avoiding problems with ISPs' crappy DNS. I imagine it
would still need to fall back to local DNS to resolve names on enterprise
intranets.

~~~
Isomer
This is outside my area of expertise.

My uninformed assumption is that chrome generally uses whatever is configured
in the system resolver, otherwise things like captive portals, and split
horizon DNS wouldn't work properly, but I don't specifically know.

------
dbg31415
dig +noall +stats @1.0.0.1 news.ycombinator.com; dig +noall +stats @1.1.1.1
news.ycombinator.com; dig +noall +stats @208.67.220.220 news.ycombinator.com;
dig +noall +stats @208.67.222.222 news.ycombinator.com; dig +noall +stats
@8.8.4.4 news.ycombinator.com; dig +noall +stats @8.8.8.8 news.ycombinator.com

Fixed? =P

I removed some of the records form the article after reading some of the
comments here. Cloudflare, Google, and OpenDNS only.

Kind of cool, I switched it up and ran it against 10 sites I frequent... was
pretty impressed to see how well OpenDNS was doing.

~~~
akerro
You should be doing `dig @1.1.1.1 news.ycombinator.com`

~~~
swinglock
That resolves "news.ycombinator.com" and "1.1.1.1" with your system resolver.

You're looking for "dig @1.1.1.1 news.ycombinator.com" which will resolve
"news.ycombinator.com" using "1.1.1.1".

~~~
akerro
Thanks, I wrote that from memory. I'll update my comment.

