Hacker News new | past | comments | ask | show | jobs | submit login
DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS (medium.com)
860 points by nykolasz on Apr 2, 2018 | hide | past | web | favorite | 311 comments



Pushed a shell script to compare all of them from your location:

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


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


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.


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/


Thanks.

Paris, France (OVH ADSL link FWIW):

    test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
    cloudflare2nd  9 ms    9 ms    10 ms   9 ms    9 ms    9 ms    9 ms    9 ms    9 ms    9 ms      9.10
    cloudflare     9 ms    9 ms    9 ms    10 ms   9 ms    10 ms   10 ms   9 ms    9 ms    9 ms      9.30
    google2nd      16 ms   14 ms   8 ms    17 ms   21 ms   9 ms    9 ms    23 ms   14 ms   14 ms     14.50
    google         32 ms   10 ms   9 ms    16 ms   14 ms   22 ms   9 ms    22 ms   15 ms   14 ms     16.30
    quad9          17 ms   18 ms   18 ms   19 ms   17 ms   18 ms   18 ms   17 ms   18 ms   19 ms     17.90
    cleanbrowsing  19 ms   18 ms   18 ms   18 ms   18 ms   18 ms   18 ms   18 ms   18 ms   19 ms     18.20
    opendns        8 ms    9 ms    9 ms    9 ms    24 ms   109 ms  9 ms    9 ms    8 ms    8 ms      20.20
    comodo         23 ms   22 ms   22 ms   22 ms   23 ms   22 ms   22 ms   23 ms   22 ms   23 ms     22.40
    neustar        25 ms   25 ms   25 ms   26 ms   24 ms   25 ms   25 ms   27 ms   25 ms   25 ms     25.20
    norton         25 ms   26 ms   25 ms   35 ms   25 ms   25 ms   25 ms   26 ms   25 ms   26 ms     26.30
    yandex         101 ms  91 ms   54 ms   46 ms   54 ms   72 ms   54 ms   45 ms   47 ms   55 ms     61.90
    adguard        63 ms   239 ms  71 ms   65 ms   73 ms   63 ms   66 ms   60 ms   58 ms   58 ms     81.60
Results for Yandex and AdGuard do vary a lot between runs, but are consistently worse than all the others.


Singapore, work:

                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
  neustar        2 ms    2 ms    3 ms    3 ms    3 ms    2 ms    2 ms    2 ms    3 ms    3 ms      2.50
  norton         2 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    2 ms    3 ms      2.80
  quad9          3 ms    3 ms    3 ms    3 ms    3 ms    2 ms    3 ms    2 ms    3 ms    3 ms      2.80
  cloudflare     2 ms    3 ms    3 ms    4 ms    3 ms    4 ms    3 ms    2 ms    3 ms    2 ms      2.90
  cloudflare2nd  3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    4 ms    3 ms      3.10
  google2nd      2 ms    2 ms    2 ms    5 ms    14 ms   3 ms    2 ms    6 ms    3 ms    2 ms      4.10
  google         2 ms    2 ms    2 ms    5 ms    6 ms    200 ms  3 ms    5 ms    2 ms    2 ms      22.90
  opendns        3 ms    2 ms    2 ms    191 ms  3 ms    272 ms  2 ms    3 ms    2 ms    3 ms      48.30
  cleanbrowsing  177 ms  177 ms  178 ms  178 ms  178 ms  177 ms  177 ms  177 ms  176 ms  177 ms    177.20
  adguard        185 ms  186 ms  185 ms  185 ms  194 ms  185 ms  186 ms  185 ms  185 ms  185 ms    186.10
  yandex         255 ms  248 ms  282 ms  281 ms  224 ms  201 ms  213 ms  285 ms  213 ms  215 ms    241.70
  comodo         262 ms  262 ms  263 ms  263 ms  272 ms  261 ms  262 ms  262 ms  261 ms  262 ms    263.00


Made a couple of changes to add median value and local DNS (via ViewQuest).

  ./dnstest.sh| column -s\, -t
  DNS            test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average    Median
  cloudflare     3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    4 ms    3 ms    3 ms    3.10 ms    3 ms
  cloudflare2nd  3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3.00 ms    3 ms
  google         4 ms    3 ms    2 ms    3 ms    4 ms    3 ms    2 ms    6 ms    2 ms    4 ms    3.30 ms    3 ms
  google2nd      2 ms    2 ms    2 ms    2 ms    6 ms    201 ms  2 ms    4 ms    2 ms    2 ms    22.50 ms   2 ms
  quad9          5 ms    4 ms    4 ms    3 ms    3 ms    3 ms    3 ms    2 ms    2 ms    4 ms    3.30 ms    3 ms
  opendns        2 ms    2 ms    2 ms    5 ms    3 ms    236 ms  2 ms    54 ms   2 ms    2 ms    31.00 ms   2 ms
  norton         3 ms    3 ms    3 ms    4 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3 ms    3.10 ms    3 ms
  cleanbrowsing  178 ms  179 ms  178 ms  182 ms  176 ms  178 ms  177 ms  177 ms  177 ms  177 ms  177.90 ms  178 ms
  yandex         200 ms  319 ms  281 ms  213 ms  293 ms  215 ms  281 ms  287 ms  281 ms  215 ms  258.50 ms  281 ms
  adguard        185 ms  189 ms  185 ms  186 ms  186 ms  185 ms  186 ms  186 ms  186 ms  186 ms  186.00 ms  186 ms
  neustar        3 ms    3 ms    3 ms    3 ms    2 ms    2 ms    3 ms    3 ms    3 ms    3 ms    2.80 ms    3 ms
  comodo         271 ms  262 ms  263 ms  265 ms  290 ms  264 ms  262 ms  266 ms  263 ms  262 ms  266.80 ms  264 ms
  local          0 ms    6 ms    3 ms    1 ms    0 ms    0 ms    0 ms    0 ms    0 ms    0 ms    1.00 ms    0 ms


For DNS performance the average is probably not the correct measurement stick. It's vulnerable to sudden spikes or timeouts which happen a lot in UDP traffic.

I recommend measuring the median and p0.5, p99.5 and maybe p99.99 values with a lot of data points. That eliminates any packet issues and laves you with the performance you can expect for 50%, 0.5%, 99.5% and 99.99% of your DNS traffic.


Buenos Aires [City], Argentina

                      test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
    10.2.129.10       21 ms   1000 ms 1000 ms 25 ms   1000 ms 1000 ms 27 ms   1000 ms 28 ms   1000 ms   610.10
    10.2.129.11       28 ms   26 ms   25 ms   25 ms   82 ms   31 ms   24 ms   28 ms   24 ms   26 ms     31.90
    cloudflare        26 ms   25 ms   26 ms   24 ms   26 ms   25 ms   24 ms   24 ms   25 ms   25 ms     25.00
    google            25 ms   25 ms   25 ms   27 ms   81 ms   25 ms   24 ms   26 ms   24 ms   24 ms     30.60
    quad9             158 ms  160 ms  156 ms  158 ms  157 ms  158 ms  163 ms  159 ms  159 ms  160 ms    158.80
    opendns           149 ms  32 ms   32 ms   269 ms  34 ms   232 ms  32 ms   152 ms  87 ms   34 ms     105.30
    norton            156 ms  152 ms  163 ms  156 ms  174 ms  158 ms  157 ms  163 ms  161 ms  163 ms    160.30
    cleanbrowsing     32 ms   36 ms   34 ms   35 ms   33 ms   31 ms   33 ms   156 ms  33 ms   37 ms     46.00
    yandex            271 ms  283 ms  297 ms  288 ms  287 ms  302 ms  277 ms  295 ms  294 ms  296 ms    289.00
    adguard           291 ms  290 ms  290 ms  294 ms  285 ms  288 ms  287 ms  297 ms  284 ms  294 ms    290.00
    neustar           160 ms  150 ms  164 ms  161 ms  159 ms  156 ms  159 ms  159 ms  156 ms  159 ms    158.30
    comodo            169 ms  170 ms  171 ms  162 ms  166 ms  161 ms  169 ms  162 ms  165 ms  166 ms    166.10


thanks for the script, I added my isp (spectrum) and my own server (localbind)

Central Ohio

                    test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
  localbind         1 ms    1 ms    1 ms    1 ms    1 ms    1 ms    1 ms    1 ms    1 ms    1 ms      1.00
  norton            34 ms   34 ms   33 ms   34 ms   33 ms   34 ms   34 ms   34 ms   34 ms   34 ms     33.80
  cloudflare        35 ms   33 ms   34 ms   33 ms   34 ms   34 ms   36 ms   33 ms   34 ms   33 ms     33.90
  neustar           36 ms   34 ms   35 ms   33 ms   34 ms   34 ms   34 ms   34 ms   35 ms   33 ms     34.20
  spectrum          37 ms   37 ms   36 ms   36 ms   36 ms   36 ms   35 ms   36 ms   35 ms   47 ms     37.10
  opendns           33 ms   33 ms   33 ms   54 ms   33 ms   33 ms   33 ms   45 ms   41 ms   34 ms     37.20
  127.0.1.1         2 ms    36 ms   77 ms   3 ms    118 ms  2 ms    2 ms    80 ms   2 ms    71 ms     39.30
  google            34 ms   33 ms   35 ms   44 ms   51 ms   51 ms   33 ms   44 ms   33 ms   44 ms     40.20
  comodo            43 ms   41 ms   42 ms   42 ms   41 ms   41 ms   41 ms   41 ms   41 ms   41 ms     41.40
  cleanbrowsing     48 ms   48 ms   133 ms  48 ms   45 ms   46 ms   45 ms   48 ms   48 ms   61 ms     57.00
  quad9             88 ms   87 ms   90 ms   89 ms   89 ms   88 ms   90 ms   90 ms   88 ms   93 ms     89.20
  yandex            149 ms  176 ms  152 ms  148 ms  149 ms  155 ms  149 ms  161 ms  155 ms  201 ms    159.50
  adguard           158 ms  202 ms  157 ms  165 ms  161 ms  156 ms  155 ms  158 ms  155 ms  155 ms    162.20


Welp glad to know I was trying to dig www.pornhub.com on my work network.


Worse than that, you were running scripts without knowing what they do


To be fair, every single time I install an emacs or vim plugin, npm lib, ruby gem, pip package, or anything close, so do I.

Really the only code I audit is a 2 page script on HN because I feel someone might judge me if I don't. But even then, I sort of gave up after the first page.

Computer security is so fubar, it's not even funny.


I used to teach people not to pipe curl to bash. Now I just add sudo -n tests to my scripts and see if they have passwordless sudo. It turns out, a lot of people have passwordless sudo.


Good point. Removed it from the default tested domains.


Glad I pulled after it was removed. In some countries (incl. Singapore) this domain is banned & blocked. Plus off-course I ran it from work...


I'm seeing much closer results:

    cloudflare     32 ms   33 ms   34 ms   39 ms   36 ms   35 ms   29 ms   57 ms   48 ms   33 ms     37.60
    google         43 ms   38 ms   37 ms   60 ms   34 ms   30 ms   30 ms   50 ms   32 ms   67 ms     42.10
    quad9          30 ms   139 ms  25 ms   35 ms   49 ms   36 ms   34 ms   32 ms   27 ms   47 ms     45.40
    opendns        32 ms   33 ms   28 ms   69 ms   32 ms   91 ms   37 ms   75 ms   67 ms   39 ms     50.30
    norton         35 ms   33 ms   33 ms   31 ms   39 ms   34 ms   22 ms   25 ms   24 ms   33 ms     30.90
    cleanbrowsing  36 ms   48 ms   40 ms   49 ms   56 ms   35 ms   36 ms   49 ms   49 ms   46 ms     44.40
    yandex         217 ms  233 ms  203 ms  199 ms  215 ms  380 ms  210 ms  204 ms  258 ms  205 ms    232.40
    adguard        98 ms   95 ms   101 ms  97 ms   104 ms  129 ms  103 ms  110 ms  95 ms   111 ms    104.30
    neustar        32 ms   30 ms   32 ms   35 ms   31 ms   34 ms   29 ms   28 ms   138 ms  34 ms     42.30
    comodo         55 ms   52 ms   51 ms   52 ms   47 ms   48 ms   58 ms   59 ms   48 ms   48 ms     51.80


Run it with "sort -k 22 -n" to to get it listed in order of performance:

*norton is faster for you:

    norton         35 ms   33 ms   33 ms   31 ms   39 ms   34 ms   22 ms   25 ms   24 ms   33 ms     30.90
    cloudflare     32 ms   33 ms   34 ms   39 ms   36 ms   35 ms   29 ms   57 ms   48 ms   33 ms     37.60
    google         43 ms   38 ms   37 ms   60 ms   34 ms   30 ms   30 ms   50 ms   32 ms   67 ms     42.10
    neustar        32 ms   30 ms   32 ms   35 ms   31 ms   34 ms   29 ms   28 ms   138 ms  34 ms     42.30
    cleanbrowsing  36 ms   48 ms   40 ms   49 ms   56 ms   35 ms   36 ms   49 ms   49 ms   46 ms     44.40
    quad9          30 ms   139 ms  25 ms   35 ms   49 ms   36 ms   34 ms   32 ms   27 ms   47 ms     45.40
    opendns        32 ms   33 ms   28 ms   69 ms   32 ms   91 ms   37 ms   75 ms   67 ms   39 ms     50.30
    comodo         55 ms   52 ms   51 ms   52 ms   47 ms   48 ms   58 ms   59 ms   48 ms   48 ms     51.80
    adguard        98 ms   95 ms   101 ms  97 ms   104 ms  129 ms  103 ms  110 ms  95 ms   111 ms    104.30
    yandex         217 ms  233 ms  203 ms  199 ms  215 ms  380 ms  210 ms  204 ms  258 ms  205 ms    232.40


I had my own script. CloudFlare and CleanBrowsing are great, but my ISP (Telekom) still wins.

  Tested 20 domains 5 times each
                Median    MAD
  NortonDNS      38 ms   + 3 ms
  CleanBrowsing  25 ms   +22 ms
  CloudFlare     24 ms   + 2 ms
  AdGuard        36 ms   + 6 ms
  Yandex         60 ms   +53 ms
  Comodo         46 ms   +11 ms
  Google         39 ms   +12 ms
  Quad9          39 ms   +26 ms
  OpenDNS        35 ms   +11 ms
  NeuStar        37 ms   + 2 ms
  Telekom        20 ms   +10 ms
  (system)        5 ms   + 9 ms


Berlin, Vodafone Kabel Deutschland (Cable):

                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
  cloudflare2nd  13 ms   13 ms   11 ms   12 ms   16 ms   12 ms   11 ms   12 ms   11 ms   12 ms     12.30
  cloudflare     14 ms   11 ms   18 ms   12 ms   47 ms   16 ms   12 ms   12 ms   11 ms   11 ms     16.40
  opendns        11 ms   29 ms   10 ms   29 ms   30 ms   12 ms   11 ms   30 ms   29 ms   11 ms     20.20
  norton         20 ms   21 ms   20 ms   21 ms   23 ms   20 ms   22 ms   19 ms   20 ms   21 ms     20.70
  neustar        22 ms   23 ms   21 ms   22 ms   23 ms   19 ms   22 ms   22 ms   22 ms   21 ms     21.70
  cleanbrowsing  23 ms   23 ms   22 ms   25 ms   23 ms   24 ms   27 ms   26 ms   22 ms   24 ms     23.90
  quad9          21 ms   26 ms   25 ms   27 ms   28 ms   26 ms   31 ms   23 ms   22 ms   26 ms     25.50
  google2nd      23 ms   37 ms   22 ms   26 ms   36 ms   25 ms   26 ms   29 ms   24 ms   27 ms     27.50
  google         32 ms   31 ms   31 ms   26 ms   32 ms   36 ms   26 ms   28 ms   22 ms   29 ms     29.30
  comodo         36 ms   36 ms   35 ms   38 ms   37 ms   36 ms   37 ms   36 ms   36 ms   35 ms     36.20
  yandex         37 ms   79 ms   36 ms   37 ms   47 ms   35 ms   41 ms   40 ms   35 ms   71 ms     45.80
  adguard        41 ms   53 ms   54 ms   42 ms   142 ms  56 ms   47 ms   72 ms   49 ms   66 ms     62.20


I added Charter (71.10.216.1) to the list, and in Mid-michigan via Charter, they consistently come out ahead by a clear margin for me:

  charter        15 ms   15 ms   15 ms   16 ms   15 ms   15 ms   15 ms   15 ms   15 ms   30 ms     16.60
  norton         22 ms   23 ms   30 ms   28 ms   23 ms   23 ms   22 ms   21 ms   22 ms   31 ms     24.50
  neustar        24 ms   26 ms   23 ms   25 ms   25 ms   23 ms   28 ms   23 ms   23 ms   39 ms     25.90
  cloudflare     25 ms   27 ms   33 ms   62 ms   26 ms   26 ms   27 ms   27 ms   27 ms   26 ms     30.60
  comodo         37 ms   37 ms   36 ms   38 ms   38 ms   36 ms   38 ms   38 ms   38 ms   37 ms     37.30
  quad9          33 ms   33 ms   45 ms   46 ms   51 ms   40 ms   33 ms   34 ms   35 ms   34 ms     38.40
  opendns        44 ms   40 ms   41 ms   59 ms   30 ms   32 ms   30 ms   38 ms   40 ms   33 ms     38.70
  google         36 ms   40 ms   22 ms   31 ms   18 ms   138 ms  21 ms   32 ms   30 ms   30 ms     39.80
  cleanbrowsing  62 ms   77 ms   65 ms   64 ms   67 ms   74 ms   63 ms   63 ms   63 ms   63 ms     66.10
  adguard        128 ms  131 ms  125 ms  124 ms  124 ms  134 ms  127 ms  134 ms  124 ms  132 ms    128.30
  yandex         160 ms  154 ms  160 ms  154 ms  165 ms  163 ms  153 ms  152 ms  159 ms  157 ms    157.70
Norton, Neustar, and Cloudflare consistently vie for the top spots next to Charter on all of the runs I've done. Occasionally Google mixes it up for the #2 spot as well, but Neustar, Norton, and Cloudflare just edge them out most of the time.


From New Delhi(Airtel), India

                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
  cloudflare     35 ms   58 ms   89 ms   14 ms   14 ms   42 ms   44 ms   35 ms   13 ms   29 ms     37.30
  cloudflare2nd  17 ms   16 ms   39 ms   57 ms   26 ms   42 ms   42 ms   64 ms   41 ms   64 ms     40.80
  google         93 ms   98 ms   184 ms  246 ms  277 ms  122 ms  97 ms   91 ms   241 ms  82 ms     153.10
  google2nd      60 ms   44 ms   43 ms   363 ms  90 ms   103 ms  110 ms  210 ms  10 ms   28 ms     106.10
  quad9          284 ms  255 ms  204 ms  479 ms  292 ms  270 ms  282 ms  298 ms  279 ms  283 ms    292.60
  opendns        35 ms   50 ms   34 ms   207 ms  42 ms   221 ms  34 ms   94 ms   36 ms   35 ms     78.80
  norton         70 ms   80 ms   80 ms   90 ms   73 ms   38 ms   38 ms   43 ms   42 ms   44 ms     59.80
  cleanbrowsing  271 ms  275 ms  283 ms  455 ms  333 ms  389 ms  406 ms  273 ms  235 ms  238 ms    315.80
  yandex         263 ms  285 ms  304 ms  262 ms  403 ms  172 ms  298 ms  562 ms  222 ms  340 ms    311.10
  adguard        346 ms  388 ms  317 ms  457 ms  243 ms  325 ms  396 ms  386 ms  394 ms  328 ms    358.00
  neustar        130 ms  213 ms  196 ms  140 ms  281 ms  205 ms  73 ms   114 ms  104 ms  169 ms    162.50
  comodo         277 ms  332 ms  252 ms  275 ms  298 ms  267 ms  302 ms  293 ms  277 ms  193 ms    276.60


From Mumbai, India:

                   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
    cloudflare     3 ms    3 ms    2 ms    3 ms    3 ms    123 ms  3 ms    2 ms    3 ms    6 ms      15.10
    cloudflare2nd  3 ms    3 ms    2 ms    3 ms    3 ms    2 ms    3 ms    2 ms    2 ms    3 ms      2.60
    google         61 ms   61 ms   61 ms   61 ms   64 ms   273 ms  61 ms   64 ms   61 ms   62 ms     82.90
    google2nd      1 ms    1 ms    1 ms    1 ms    66 ms   62 ms   2 ms    64 ms   1 ms    1 ms      20.00
    quad9          124 ms  126 ms  124 ms  124 ms  124 ms  118 ms  127 ms  121 ms  125 ms  179 ms    129.20
    opendns        2 ms    2 ms    2 ms    57 ms   5 ms    261 ms  2 ms    245 ms  2 ms    2 ms      58.00
    norton         4 ms    4 ms    4 ms    5 ms    4 ms    4 ms    4 ms    4 ms    3 ms    4 ms      4.00
    cleanbrowsing  225 ms  232 ms  235 ms  214 ms  232 ms  225 ms  219 ms  245 ms  233 ms  218 ms    227.80
    yandex         136 ms  139 ms  142 ms  138 ms  140 ms  141 ms  136 ms  142 ms  142 ms  142 ms    139.80
    adguard        205 ms  205 ms  196 ms  196 ms  217 ms  211 ms  212 ms  197 ms  205 ms  211 ms    205.50
    neustar        233 ms  232 ms  236 ms  235 ms  233 ms  243 ms  246 ms  242 ms  232 ms  227 ms    235.90
    comodo         132 ms  134 ms  133 ms  133 ms  133 ms  130 ms  130 ms  130 ms  131 ms  145 ms    133.10


Fredericton, Canada:

               test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
  cloudflare     38 ms   38 ms   38 ms   37 ms   37 ms   37 ms   37 ms   37 ms   38 ms   37 ms     37.40
  cloudflare2nd  38 ms   37 ms   37 ms   38 ms   37 ms   38 ms   38 ms   38 ms   37 ms   37 ms     37.50
  cleanbrowsing  37 ms   37 ms   37 ms   37 ms   37 ms   37 ms   45 ms   38 ms   37 ms   37 ms     37.90
  neustar        37 ms   38 ms   38 ms   38 ms   38 ms   39 ms   37 ms   40 ms   38 ms   38 ms     38.10
  google2nd      39 ms   37 ms   37 ms   37 ms   45 ms   43 ms   38 ms   40 ms   38 ms   38 ms     39.20
  google         38 ms   37 ms   75 ms   37 ms   46 ms   38 ms   37 ms   40 ms   37 ms   37 ms     42.20
  comodo         38 ms   41 ms   100 ms  42 ms   38 ms   38 ms   40 ms   43 ms   39 ms   39 ms     45.80
  quad9          59 ms   62 ms   57 ms   58 ms   65 ms   67 ms   70 ms   71 ms   133 ms  206 ms    84.80
  norton         147 ms  280 ms  154 ms  38 ms   39 ms   38 ms   40 ms   37 ms   40 ms   38 ms     85.10
  adguard        119 ms  118 ms  128 ms  112 ms  118 ms  114 ms  119 ms  119 ms  116 ms  122 ms    118.50
  yandex         145 ms  147 ms  142 ms  144 ms  148 ms  174 ms  136 ms  141 ms  143 ms  141 ms    146.10
  opendns        172 ms  63 ms   245 ms  158 ms  146 ms  159 ms  279 ms  140 ms  163 ms  150 ms    167.50


London, with BT fibre

                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
  cloudflare2nd  4 ms    4 ms    4 ms    4 ms    3 ms    3 ms    3 ms    4 ms    4 ms    4 ms      3.70
  cloudflare     4 ms    3 ms    4 ms    4 ms    4 ms    4 ms    4 ms    4 ms    4 ms    4 ms      3.90
  quad9          4 ms    4 ms    4 ms    4 ms    4 ms    4 ms    4 ms    4 ms    4 ms    4 ms      4.00
  norton         5 ms    5 ms    5 ms    6 ms    5 ms    5 ms    5 ms    5 ms    5 ms    5 ms      5.10
  neustar        5 ms    11 ms   5 ms    6 ms    5 ms    5 ms    6 ms    5 ms    6 ms    5 ms      5.90
  google2nd      3 ms    4 ms    4 ms    5 ms    13 ms   3 ms    11 ms   15 ms   4 ms    5 ms      6.70
  google         4 ms    5 ms    4 ms    14 ms   5 ms    9 ms    4 ms    16 ms   4 ms    4 ms      6.90
  opendns        5 ms    4 ms    4 ms    17 ms   6 ms    13 ms   5 ms    16 ms   5 ms    6 ms      8.10
  comodo         10 ms   11 ms   13 ms   10 ms   12 ms   11 ms   11 ms   11 ms   10 ms   19 ms     11.80
  yandex         41 ms   34 ms   38 ms   39 ms   42 ms   147 ms  40 ms   52 ms   43 ms   37 ms     51.30
  adguard        51 ms   102 ms  70 ms   66 ms   49 ms   51 ms   60 ms   50 ms   52 ms   82 ms     63.30
  cleanbrowsing  71 ms   72 ms   72 ms   72 ms   72 ms   72 ms   70 ms   73 ms   71 ms   72 ms     71.70


Italy, TIM:

                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
  cloudflare     23 ms   19 ms   20 ms   20 ms   21 ms   21 ms   23 ms   22 ms   22 ms   20 ms     21.10
  cloudflare2nd  23 ms   23 ms   20 ms   20 ms   24 ms   20 ms   23 ms   23 ms   24 ms   23 ms     22.30
  google         20 ms   22 ms   22 ms   41 ms   20 ms   43 ms   21 ms   45 ms   20 ms   36 ms     29.00
  neustar        41 ms   34 ms   33 ms   43 ms   35 ms   47 ms   45 ms   35 ms   41 ms   33 ms     38.70
  quad9          38 ms   47 ms   33 ms   32 ms   39 ms   51 ms   35 ms   50 ms   44 ms   39 ms     40.80
  google2nd      23 ms   20 ms   20 ms   20 ms   20 ms   214 ms  21 ms   38 ms   23 ms   23 ms     42.20
  norton         47 ms   44 ms   42 ms   45 ms   46 ms   42 ms   44 ms   47 ms   46 ms   44 ms     44.70
  cleanbrowsing  48 ms   50 ms   47 ms   46 ms   48 ms   48 ms   46 ms   49 ms   46 ms   49 ms     47.70
  opendns        39 ms   41 ms   41 ms   47 ms   40 ms   197 ms  33 ms   50 ms   42 ms   34 ms     56.40
  comodo         58 ms   56 ms   58 ms   59 ms   56 ms   58 ms   55 ms   56 ms   55 ms   65 ms     57.60
  yandex         69 ms   67 ms   63 ms   62 ms   71 ms   65 ms   71 ms   65 ms   75 ms   125 ms    73.30
  adguard        90 ms   88 ms   80 ms   93 ms   76 ms   78 ms   79 ms   161 ms  86 ms   79 ms     91.00


Amsterdam:

  test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
  cloudflare     28 ms   37 ms   25 ms   28 ms   28 ms   24 ms   25 ms   24 ms   26 ms   26 ms     27.10
  cloudflare2nd  24 ms   25 ms   29 ms   28 ms   34 ms   31 ms   21 ms   27 ms   33 ms   34 ms     28.60
  google         29 ms   35 ms   37 ms   33 ms   18 ms   34 ms   39 ms   50 ms   84 ms   15 ms     37.40
  google2nd      15 ms   27 ms   25 ms   30 ms   42 ms   28 ms   22 ms   28 ms   27 ms   28 ms     27.20
  quad9          61 ms   55 ms   32 ms   37 ms   28 ms   30 ms   24 ms   20 ms   20 ms   21 ms     32.80
  opendns        48 ms   50 ms   46 ms   68 ms   61 ms   186 ms  43 ms   56 ms   50 ms   43 ms     65.10
  norton         35 ms   167 ms  32 ms   36 ms   32 ms   36 ms   33 ms   48 ms   47 ms   38 ms     50.40
  cleanbrowsing  31 ms   34 ms   35 ms   33 ms   34 ms   30 ms   24 ms   23 ms   24 ms   27 ms     29.50
  yandex         48 ms   53 ms   54 ms   47 ms   59 ms   67 ms   47 ms   52 ms   52 ms   91 ms     57.00
  adguard        17 ms   20 ms   23 ms   17 ms   19 ms   25 ms   139 ms  22 ms   25 ms   21 ms     32.80
  neustar        26 ms   34 ms   31 ms   28 ms   26 ms   29 ms   33 ms   24 ms   25 ms   34 ms     29.00
  comodo         38 ms   38 ms   46 ms   41 ms   37 ms   34 ms   28 ms   33 ms   37 ms   38 ms     37.00


Oddly, I also got the best performance from Norton. An MTR shows Norton at 5 hops, Google at 8 hops and Cloudflare at 7. I might even accept slower speeds for added privacy, luckily I don't have to.

               test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
  norton         5 ms    6 ms    5 ms    6 ms    5 ms    5 ms    6 ms    6 ms    5 ms    6 ms      5.50
  neustar        6 ms    6 ms    6 ms    6 ms    6 ms    5 ms    6 ms    5 ms    6 ms    6 ms      5.80
  cloudflare     7 ms    7 ms    7 ms    7 ms    7 ms    7 ms    7 ms    7 ms    7 ms    7 ms      7.00
  cleanbrowsing  16 ms   31 ms   16 ms   16 ms   16 ms   16 ms   16 ms   16 ms   16 ms   16 ms     17.50
  google         14 ms   5 ms    5 ms    13 ms   5 ms    121 ms  5 ms    14 ms   12 ms   12 ms     20.60
  opendns        11 ms   5 ms    5 ms    18 ms   5 ms    131 ms  5 ms    12 ms   12 ms   5 ms      20.90
  comodo         34 ms   34 ms   34 ms   34 ms   33 ms   34 ms   34 ms   33 ms   33 ms   34 ms     33.70
  quad9          45 ms   46 ms   49 ms   44 ms   44 ms   44 ms   44 ms   56 ms   45 ms   45 ms     46.20
  yandex         144 ms  148 ms  148 ms  146 ms  153 ms  143 ms  148 ms  180 ms  148 ms  148 ms    150.60
  adguard        156 ms  167 ms  150 ms  149 ms  151 ms  146 ms  147 ms  148 ms  189 ms  147 ms    155.00


What ISP/city you tested it from?


Thanks, this is a very useful script. I added my pi-hole (using neustar as upstream) to the script and found it adds about 2ms to the initial queries. After I ran the script a second time, the pi-hole average was half of neustar, so pi-hole must do some amount of caching.

                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
  pihole(cached) 14 ms   20 ms   1 ms    4 ms    15 ms   16 ms   1 ms    15 ms   1 ms    2 ms      8.90
  neustar        12 ms   16 ms   15 ms   11 ms   15 ms   11 ms   13 ms   15 ms   12 ms   13 ms     13.30
  norton         11 ms   16 ms   11 ms   13 ms   14 ms   15 ms   15 ms   10 ms   13 ms   16 ms     13.40
  pihole         17 ms   14 ms   14 ms   20 ms   18 ms   15 ms   19 ms   15 ms   1 ms    18 ms     15.10
  cleanbrowsing  14 ms   17 ms   14 ms   16 ms   16 ms   13 ms   16 ms   26 ms   13 ms   14 ms     15.90
  opendns        11 ms   11 ms   12 ms   23 ms   12 ms   11 ms   11 ms   28 ms   27 ms   15 ms     16.10
  google         12 ms   15 ms   11 ms   27 ms   12 ms   26 ms   15 ms   30 ms   12 ms   28 ms     18.80
  cloudflare     43 ms   40 ms   42 ms   42 ms   44 ms   41 ms   41 ms   42 ms   43 ms   43 ms     42.10
  comodo         45 ms   46 ms   43 ms   43 ms   47 ms   44 ms   47 ms   45 ms   43 ms   45 ms     44.80
  quad9          82 ms   91 ms   79 ms   117 ms  160 ms  111 ms  82 ms   82 ms   80 ms   91 ms     97.50
  adguard        153 ms  161 ms  161 ms  155 ms  164 ms  154 ms  154 ms  156 ms  177 ms  158 ms    159.30
  yandex         159 ms  158 ms  163 ms  160 ms  170 ms  268 ms  159 ms  159 ms  160 ms  192 ms    174.80


From Oakland on Comcast:

  $ sh ./dnstest.sh | sort -k 22 -n
                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
  cloudflare     27 ms   40 ms   45 ms   41 ms   42 ms   41 ms   41 ms   47 ms   41 ms   41 ms     40.60
  norton         41 ms   42 ms   47 ms   48 ms   45 ms   42 ms   46 ms   42 ms   44 ms   13 ms     41.00
  google         42 ms   41 ms   40 ms   42 ms   41 ms   69 ms   42 ms   13 ms   45 ms   41 ms     41.60
  cleanbrowsing  43 ms   44 ms   41 ms   41 ms   41 ms   41 ms   40 ms   45 ms   41 ms   41 ms     41.80
  neustar        44 ms   41 ms   42 ms   42 ms   42 ms   41 ms   40 ms   43 ms   42 ms   44 ms     42.10
  comodo         41 ms   41 ms   46 ms   41 ms   42 ms   45 ms   42 ms   42 ms   43 ms   42 ms     42.50
  quad9          41 ms   40 ms   41 ms   42 ms   41 ms   44 ms   45 ms   45 ms   44 ms   46 ms     42.90
  opendns        45 ms   46 ms   45 ms   44 ms   43 ms   235 ms  46 ms   49 ms   48 ms   47 ms     64.80
  adguard        81 ms   81 ms   80 ms   80 ms   81 ms   81 ms   80 ms   85 ms   89 ms   81 ms     81.90
  yandex         198 ms  292 ms  294 ms  292 ms  293 ms  292 ms  186 ms  399 ms  291 ms  293 ms    283.00


Comcast in Mountain View, CA.

                   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
    quad9          39 ms   39 ms   38 ms   39 ms   39 ms   39 ms   39 ms   40 ms   41 ms   38 ms     39.10
    cloudflare     41 ms   41 ms   39 ms   40 ms   39 ms   41 ms   39 ms   39 ms   39 ms   39 ms     39.70
    norton         41 ms   40 ms   40 ms   41 ms   41 ms   39 ms   44 ms   39 ms   40 ms   40 ms     40.50
    comodo         39 ms   40 ms   39 ms   39 ms   54 ms   38 ms   40 ms   40 ms   42 ms   40 ms     41.10
    neustar        49 ms   44 ms   42 ms   42 ms   43 ms   40 ms   40 ms   38 ms   38 ms   38 ms     41.40
    opendns        41 ms   39 ms   39 ms   49 ms   39 ms   85 ms   39 ms   39 ms   12 ms   41 ms     42.30
    google         39 ms   39 ms   41 ms   39 ms   39 ms   70 ms   13 ms   65 ms   40 ms   39 ms     42.40
    cleanbrowsing  59 ms   46 ms   44 ms   46 ms   40 ms   79 ms   40 ms   47 ms   48 ms   51 ms     50.00
    adguard        80 ms   80 ms   80 ms   81 ms   84 ms   80 ms   79 ms   81 ms   80 ms   80 ms     80.50
    yandex         183 ms  229 ms  185 ms  186 ms  234 ms  186 ms  187 ms  189 ms  185 ms  189 ms    195.30


Something isn't right with those results. Since the lowest average is above 20ms, can you share the results of a traceroute to 1.1.1.1 or 8.8.8.8 or any of the DNS servers in the list?

It looks like your results are skewed due to your local network. (On laggy WiFi perhaps?)


I see great differences in the top 5 fastest dns-servers on my Macbook, when running the script a couple of times with like a few minutes in between; Sometimes cloudflare is fastest, sometimes cloudflare is very slow, etc.

So the results everyone posts here are pretty useless i believe (since it's just a single test.)


When using WPT to benchmark network latency from a given location, a rule of thumb I adopted during my years as a webperf engineer was to repeat the test 9x. Using an odd number ensured the median run was an actual test, and 9 seemed sufficient to iron out the inevitable temporal inconsistencies, while allowing the overall test suite to finish in a reasonable time. The fastest value was sometimes more interesting / useful than the median though.


from interior BC:

  % bash ./dnstest.sh
               test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
  cloudflare     32 ms   28 ms   29 ms   25 ms   35 ms   26 ms   26 ms   36 ms   26 ms   27 ms     29.00
  cloudflare2nd  29 ms   26 ms   25 ms   32 ms   30 ms   29 ms   26 ms   27 ms   167 ms  84 ms     47.50
  google         31 ms   29 ms   29 ms   30 ms   30 ms   97 ms   31 ms   76 ms   29 ms   38 ms     42.00
  google2nd      29 ms   39 ms   34 ms   38 ms   29 ms   97 ms   31 ms   41 ms   29 ms   37 ms     40.40
  quad9          31 ms   31 ms   30 ms   39 ms   30 ms   36 ms   33 ms   68 ms   29 ms   36 ms     36.30
  opendns        34 ms   30 ms   28 ms   113 ms  70 ms   105 ms  27 ms   80 ms   78 ms   49 ms     61.40
  norton         73 ms   88 ms   71 ms   78 ms   70 ms   78 ms   80 ms   83 ms   85 ms   79 ms     78.50
  cleanbrowsing  73 ms   82 ms   80 ms   75 ms   73 ms   197 ms  73 ms   71 ms   75 ms   75 ms     87.40
  yandex         211 ms  250 ms  209 ms  213 ms  215 ms  469 ms  202 ms  218 ms  206 ms  237 ms    243.00
  adguard        75 ms   73 ms   75 ms   73 ms   73 ms   75 ms   71 ms   71 ms   72 ms   233 ms    89.10
  neustar        73 ms   69 ms   78 ms   80 ms   77 ms   81 ms   72 ms   82 ms   87 ms   84 ms     78.30
  comodo         32 ms   31 ms   1536 ms 36 ms   1538 ms 1686 ms 46 ms   35 ms   1532 ms 1531 ms   800.30


Warsaw, Poland

               test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
cloudflare 21 ms 14 ms 14 ms 14 ms 15 ms 18 ms 15 ms 14 ms 16 ms 13 ms 15.40 cloudflare2nd 23 ms 16 ms 14 ms 14 ms 18 ms 12 ms 13 ms 12 ms 16 ms 15 ms 15.30 google 16 ms 16 ms 13 ms 40 ms 47 ms 35 ms 12 ms 35 ms 35 ms 59 ms 30.80 google2nd 23 ms 57 ms 11 ms 34 ms 43 ms 14 ms 15 ms 39 ms 14 ms 31 ms 28.10 quad9 14 ms 199 ms 22 ms 14 ms 551 ms 190 ms 15 ms 14 ms 14 ms 198 ms 123.10 opendns 48 ms 14 ms 19 ms 51 ms 35 ms 162 ms 13 ms 36 ms 48 ms 12 ms 43.80 norton 48 ms 38 ms 38 ms 42 ms 43 ms 42 ms 38 ms 43 ms 38 ms 46 ms 41.60 cleanbrowsing 37 ms 33 ms 37 ms 38 ms 38 ms 36 ms 33 ms 38 ms 36 ms 35 ms 36.10 yandex 62 ms 91 ms 57 ms 59 ms 66 ms 343 ms 53 ms 53 ms 61 ms 64 ms 90.90 adguard 42 ms 34 ms 34 ms 32 ms 46 ms 34 ms 59 ms 114 ms 100 ms 50 ms 54.50 neustar 42 ms 42 ms 37 ms 43 ms 38 ms 42 ms 39 ms 48 ms 42 ms 42 ms 41.50 comodo 54 ms 53 ms 55 ms 51 ms 50 ms 51 ms 59 ms 51 ms 54 ms 50 ms 52.80


The performance is depending on how many concurrent user are using their service.


This is cool; thanks for the script.


Results for Reno, NV on AT&T:

Round One:

                   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
    cloudflare     0 ms    7 ms    7 ms    7 ms    11 ms   0 ms    0 ms    8 ms    0 ms    0 ms      4.00
    cloudflare2nd  8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms      8.00
    neustar        8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms      8.00
    norton         8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms      8.00
    quad9          9 ms    8 ms    9 ms    8 ms    9 ms    8 ms    8 ms    9 ms    8 ms    10 ms     8.60
    opendns        8 ms    8 ms    8 ms    45 ms   9 ms    8 ms    8 ms    45 ms   27 ms   10 ms     17.60
    google2nd      8 ms    8 ms    8 ms    26 ms   8 ms    67 ms   8 ms    27 ms   8 ms    26 ms     19.40
    cleanbrowsing  14 ms   16 ms   15 ms   15 ms   15 ms   14 ms   15 ms   52 ms   15 ms   26 ms     19.70
    comodo         27 ms   28 ms   27 ms   27 ms   28 ms   27 ms   27 ms   27 ms   29 ms   27 ms     27.40
    google         8 ms    8 ms    8 ms    8 ms    8 ms    166 ms  8 ms    27 ms   8 ms    27 ms     27.60
    adguard        159 ms  154 ms  160 ms  155 ms  153 ms  156 ms  158 ms  156 ms  156 ms  152 ms    155.90
    yandex         189 ms  191 ms  188 ms  184 ms  189 ms  208 ms  188 ms  179 ms  182 ms  225 ms    192.30
Round 2:

                   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
    norton         8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms      8.00
    neustar        8 ms    8 ms    8 ms    9 ms    8 ms    8 ms    8 ms    8 ms    8 ms    8 ms      8.10
    cloudflare2nd  8 ms    10 ms   8 ms    8 ms    8 ms    14 ms   8 ms    8 ms    8 ms    8 ms      8.80
    cloudflare     8 ms    7 ms    7 ms    7 ms    7 ms    51 ms   7 ms    7 ms    0 ms    12 ms     11.30
    google         8 ms    9 ms    8 ms    28 ms   8 ms    26 ms   8 ms    8 ms    8 ms    8 ms      11.90
    google2nd      8 ms    8 ms    8 ms    26 ms   8 ms    27 ms   8 ms    27 ms   8 ms    8 ms      13.60
    cleanbrowsing  14 ms   27 ms   15 ms   15 ms   15 ms   14 ms   14 ms   15 ms   15 ms   15 ms     15.90
    opendns        8 ms    8 ms    8 ms    45 ms   9 ms    48 ms   8 ms    45 ms   8 ms    8 ms      19.50
    quad9          9 ms    27 ms   10 ms   17 ms   10 ms   32 ms   18 ms   27 ms   21 ms   26 ms     19.70
    comodo         27 ms   28 ms   27 ms   28 ms   27 ms   27 ms   28 ms   27 ms   27 ms   28 ms     27.40
    adguard        155 ms  149 ms  162 ms  157 ms  154 ms  157 ms  155 ms  152 ms  166 ms  163 ms    157.00
    yandex         180 ms  179 ms  191 ms  185 ms  189 ms  183 ms  185 ms  184 ms  189 ms  222 ms    188.70
Weird how much the results seem to fluctuate between rounds. Either way, Norton, Neustar, and Cloudflare seem to be consistently fast (~ 8ms averages), while Google and Quad9 are inconsistently fast. Comodo, Clean Browsing, and OpenDNS are consistently decent, while AdGuard and Yandex are consistently slow.

Unrelated note: Clean Browsing looks pretty neat, though I'm curious about how it manages to enforce any kind of "safe search" setting through DNS alone.


From Guadalajara via Totalplay:

                   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
    cloudflare     24 ms   22 ms   23 ms   22 ms   22 ms   22 ms   22 ms   22 ms   30 ms   33 ms     24.20
    norton         72 ms   34 ms   33 ms   35 ms   34 ms   45 ms   33 ms   32 ms   32 ms   32 ms     38.20
    cloudflare2nd  25 ms   24 ms   22 ms   28 ms   24 ms   22 ms   24 ms   27 ms   25 ms   172 ms    39.30
    cleanbrowsing  33 ms   58 ms   34 ms   35 ms   33 ms   33 ms   33 ms   51 ms   55 ms   34 ms     39.90
    opendns        31 ms   30 ms   31 ms   67 ms   31 ms   68 ms   32 ms   57 ms   32 ms   32 ms     41.10
    neustar        105 ms  33 ms   33 ms   33 ms   33 ms   56 ms   33 ms   32 ms   33 ms   37 ms     42.80
    google2nd      46 ms   53 ms   57 ms   46 ms   53 ms   55 ms   48 ms   55 ms   48 ms   66 ms     52.70
    google         68 ms   53 ms   46 ms   64 ms   79 ms   56 ms   47 ms   54 ms   46 ms   82 ms     59.50
    comodo         71 ms   73 ms   71 ms   72 ms   97 ms   73 ms   88 ms   74 ms   73 ms   75 ms     76.70
    quad9          73 ms   144 ms  72 ms   92 ms   72 ms   111 ms  71 ms   73 ms   71 ms   75 ms     85.40
    yandex         213 ms  273 ms  333 ms  386 ms  244 ms  304 ms  184 ms  277 ms  294 ms  287 ms    279.50
    adguard        304 ms  243 ms  1190 ms 288 ms  388 ms  294 ms  399 ms  286 ms  289 ms  234 ms    391.50


Nice script, but 10 runs aren't enough to give reliable results. Not even close.


from Bhimavaram, India

  sh ./dnstest.sh |sort -k 22 -n
               test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
  yandex         56 ms   56 ms   56 ms   57 ms   5 ms    57 ms   58 ms   5 ms    58 ms   58 ms     46.60
  comodo         58 ms   6 ms    56 ms   57 ms   53 ms   56 ms   56 ms   56 ms   56 ms   56 ms     51.00
  google2nd      55 ms   54 ms   56 ms   57 ms   55 ms   57 ms   55 ms   60 ms   55 ms   59 ms     56.30
  opendns        54 ms   55 ms   56 ms   56 ms   56 ms   57 ms   59 ms   57 ms   57 ms   56 ms     56.30
  google         58 ms   58 ms   56 ms   56 ms   55 ms   56 ms   55 ms   56 ms   57 ms   57 ms     56.40
  norton         55 ms   56 ms   59 ms   56 ms   57 ms   56 ms   56 ms   57 ms   55 ms   57 ms     56.40
  cleanbrowsing  59 ms   56 ms   57 ms   57 ms   56 ms   61 ms   57 ms   59 ms   55 ms   54 ms     57.10
  quad9          62 ms   55 ms   56 ms   60 ms   56 ms   57 ms   55 ms   57 ms   56 ms   57 ms     57.10
  cloudflare2nd  59 ms   57 ms   60 ms   56 ms   57 ms   58 ms   58 ms   59 ms   54 ms   56 ms     57.40
  adguard        57 ms   59 ms   60 ms   58 ms   57 ms   59 ms   60 ms   61 ms   60 ms   61 ms     59.20
  neustar        62 ms   59 ms   56 ms   58 ms   61 ms   61 ms   64 ms   61 ms   59 ms   57 ms     59.80
  cloudflare     257 ms  241 ms  55 ms   139 ms  168 ms  163 ms  123 ms  157 ms  58 ms   58 ms     141.90


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


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.


It is common for ISP to host instances of the Google Global Cache (GGC, see https://peering.google.com/) which are used for many Google services, most importantly YouTube.

In fact, in many cases Google itself "suggests" to ISP that they host a few GGC servers.

They are directly monitored by Google, and the ISP has basically no say in how they are run. Capacity is managed by Google directly.


Yep, Virgin Media did this in the UK and messed it up badly. Every day at 6pm YouTube would stop working until the following morning.

It appeared to work by inspecting DNS packets and replying with overrides if necessary. I didn’t like it but I could understand that.

What I did not agree with was the fact that this also happened for other DNS services. Google DNS and OpenDNS both experienced the same issue, as did a few other “famous” DNS providers. Random little ones wouldn’t return the caching servers, and also enabling encrypted DNS for Google/OpenDNS would stop it happening too. I’m fairly sure it was some badly thought out deep packet inspection.


Again, it's probably _not_ Virgin's fault or responsibility. Capacity planning is handled by Google directly.

Also, I think that virtually every ISP with more than a few tens of thousands users is hosting a GGC instance nowadays (and a Netflix OpenCache, etc. etc.).

Nowadays, the vast majority of the transit&peering of ISPs is not going to the Internet, but to a few racks of local caching servers managed by OTT operators.

Bandwidth-wise, at least in prime time, the Internet is much less connected/realtime than people think :)


I would suggest that the deep packet inspection is Virgin's fault. Perhaps it was Google under provisioning the CDN inside VM's network, but I would suggest that's also probably Virgin's fault in part, as they will likely have more network information available to them that may have suggested network congestion, but that was not acted upon.


As someone else suggested, this is likely part of our GGC program. If you can give me info on which ISP + Geographic region you're in, I can take a look and see if there's anything in our logs to indicate a problems; you can email me details at myusernamehere at google dot com with details, since I don't routinely check Hacker News.

If you can reproduce a bad experience, and right click on the player, click "Get Debug Info", and share that result, it's the most helpful thing for us to dig into problems.


FYI, something that makes my Hacker News experience much nicer is email notifications when my comments are replied to.

Get your own at http://hnreplies.com/ - built by Dan Grossman


>My isp got the brilliant idea of rolling their own YouTube cache servers

Are YouTube videos not served using https? Sounds like it's google/YouTube servers but they're underprovsioned


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)


Even for data not delivered via their cache they'll get free peering with Google. But having cache servers at several locations reduces the capacity they need to peering points. E.g. in the UK, most traffic gets peered in London so having cache servers in Northern England reduces the bandwidth they need for their internal network within the country.

I don't think ISPs pay much for peering in Europe.


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.


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.


> A competent ISP operating in good faith

That's probably the funniest thing I've read all year


My own tiny neighborhood ISP thinks they are smart and have their own CDN for caching everything under the sun. Of course it doesn't work well, not only it caches DNS and HTTP requests like kids collecting candy in Halloween but it also breaks HTTPS sometimes.

As an anecdote of how bad ISP caching can hurt you, I am a web developer and I was debugging an issue in a legacy system. I had fixed the stuff and deployed a new version. Erased all the caches in my machine, refreshed the page, broken. I thought that maybe I fixed the wrong thing and started fixing more... now rinse and repeat over five hours before you realize that the cache is happening at ISP level and that things are fine in the live version on the real internet. This ISP is called PredialNet, web developers from the city call it PredialCache...

I know this is about DNS and not HTTP but their cache servers will also cache DNS requests, so moving some domain to a new machine and IP is also a quest under their network. For a while I paid PIA so that I could side-step their cache servers.


Sometimes it's not even at the ISP level. I experienced a similar adventure a few months ago. I turns out that my cellular hotspot caches PDFs. It's not even at the ISP level, it's in the little box in my pocket.

Naturally, it can't be disabled.


Holy shit!!!!!!! That is evil! I just imagine the tortuous debugging process that led you to discover this. Wow.


Which hotspot is that? It'd be fun to poke at.


All ISPs in Denmark are required to implement a filtering list of somewhat arbitrarily chosen websites, including a number of torrent sites, illegal pornography and probably others. There is a very reasonably fear that this could be used for political purposes.

This filter list is implemented through DNS, making third-party DNS services the most practical workaround.


The same thing happens here in Portugal since 2015. The fact that the block orders don't even go through a court first makes it even worst.


One of the issues is that many ISPs don't actually run their own recursive DNS servers... They outsource to companies which provide a "monetized solution," operating the recursive resolvers and paying the ISP in exchange for the customers' data, which they sell. This will become an illicit activity shortly in Europe, as the GDPR comes into effect, but there are many ISPs that have become very used to receiving those payments. And most of them already don't admit to selling their customers' privacy.

So privacy is why many of the people who use a different recursive nameserver are doing so... In order for that to work, you need to use one of the ones which support link-level encryption, like Quad9 (DNS-over-TLS) or OpenDNS (DNScrypt). Other reasons are performance (which at least in Quad9's case should be no worse than your ISP for real-world queries, since it's back-to-back with many of the authoritative servers already, and all of them will give you a large pool of other users sharing the same cache, which helps performance immensely), and security... Going back-to-back with the authoritative servers also collapses the attack surface between them, minimizing the possibility for MITM attacks between the recursive and authoritative servers.


The ones that cooperate with state-sanctioned censorship? Malaysia blocks anti-government news sites via ISP DNS entries; using a 3rd party DNS bypasses the block easily.

Accusing government officials of mismanagement or outright theft of public funds is an easy way to get your domain black holed over here. That, piracy, and porn. Though I wouldn't be surprised if the latter two were thrown in solely to make the program look more legit.

https://cilisos.my/8-sites-the-malaysian-gomen-blocked-in-20...

Perhaps most ridiculously, Medium.com is blocked for simply hosting an article posted by a censored website. Yes, you read that right; they banned an entire domain, the vast majority of which covers nothing even remotely related to Malaysia, over a single article.

I try to be grateful they are as inept at censorship as they are oversensitive to criticism.


It’s best to just pretend those DNS things are a good way for bureaucrats to achieve whatever it is because they’re so easy to circumvent and the alternative is far worse.


We have only ourselves to blame for allowing the socialists and fundamentalists a foot in.


NXDOMAIN hijacking is enough for me to switch, and most ISPs are doing it nowadays.


Brighthouse did it before they became Spectrum. They did allow me to turn it off though. I've heard that this is still the case with Spectrum, but I haven't tested.


Spectrum is still doing it (N Pinellas Co FL). Not sure if it can be turned off.


That’s quite a bold claim. Got any data to back it up?

Source: I've yet to see this on any ISP I've used anywhere, sans free airport wifis. Travelled pretty much every continent on earth.


Cox does. And I think Kabletown does, too.

> I've yet to see this on any ISP I've used anywhere, sans free airport wifis. Travelled pretty much every continent on earth.

I guess you've never been to Turkey.


CenturyLink, major telecom in 37 US states. DNS requests for all nonexistent domains go to a server that delivers a dumb "search" page to web requests. They're currently the sole fiber-to-the-home provider in my neighborhood, and Comcast is the only broadband alternative.


So one or two ISPs in one country out of 300+ worldwide.

Hardly “most” ISPs as claimed in the post I replied to. Not even a fraction.



T-Mobile does it and that is an enormous ISP.


AT&T does it on their home Internet service. Annoys me to no end.

EDIT: lots of ISPs do it, in fact: https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...


Time Warner (Now Spectrum) in Texas does this on residential as well as "business class"


So this is a US problem and therefore “most” ISPs worldwide does this?

That’s hardly evidence if any.


> numerous examples of huge ISPs with more users than some European countries have residents

> "That's hardly evidence if any"

I'm sorry what?


Comcast has been on-and-off about doing it. They've switched between proper NXDOMAIN and hijacking it a few times.

I don't have Comcast anymore (not even available in my area), I can't tell you if it's current practice.


Time Warner/Spectrum, the largest provider in NYC (and the only one that services my apt building) does this. They let you turn it off in your account settings, but it doesn't actually turn it off.


I live near Toronto Canada and Rogers my ISP hijack's DNS requests for non existent domains. The data to back up my bold statement is a simple Google search which reveals that they have been doing this at the very least from my Google search was from 2008.

It is possible to turn off this feature, But it is set by a cookie and once that cookie is deleted you have to do it all over again.


Verizon Fios


That's quite the aggressive reaction. ;)


Windstream in Ohio does it.

I'm pretty sure I had a previous ISP that did it too, but I can't remember which one now.


TalkTalk in the UK. last chance I got to test it was about a year ago.


I know you're asking in jest, but here's an honest answer: Google Fiber. Google's DNS servers are ~15ms further away than a local ISP who runs public DNS servers as well (xmission). Part of this is because google fiber has a peering connection at SLIX (slix.net), and so does xmission, whereas Google's DNS servers appear to be in the bay area.

Whether or not it's noticeably faster, I'm not sure, but I've always used xmission's dns servers without fault for the past 10 years.

--- 8.8.8.8 ping statistics ---

4 packets transmitted, 4 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 17.763/18.264/18.803/0.425 ms

--- 198.60.22.2 ping statistics ---

4 packets transmitted, 4 packets received, 0.0% packet loss

round-trip min/avg/max/stddev = 2.906/3.457/3.871/0.408 ms


I've had several ISPs in different countries that do horrible things. Not using NXDomain is one, but I've had some that return NXdomain when they shouldn't, then cache that result!

8.8.8.8 is consistent and easy to remember, and now so is 1.1.1.1


Queries to my local Spectrum DNS service are 4 times slower than 1.1.1.1, and they redirect you to stupid search pages instead of `NXDOMAIN`. I switched the whole network over this morning.


Assuming Spectrum is your ISP, wow. Just wow, that's impressive. On Spectrum's part I mean.


In the U.S., many of them are mining and selling our data. Getting off of their DNS service is one step in mitigating this.

Also, as others mention, they can and do monkey with the results.

In other words, here, your ISP is in part a hostile entity. At least, in my perception -- and I'm not alone.

P.S. Of course, there's the argument against giving Google all your DNS usage, as well... I use a different DNS service from a company with a good reputation that says it's not collecting usage data. Even then, and with the state of our State, who knows...


They can (do) mine it even if you use Google or Cloudflare or whatever since DNS is trivial to intercept.


Mine's over a VPN. And if you use a VPN, make sure your DNS traffic is using it (along with some other types of traffic that can bypass it, if you're not careful).


> Which ISPs are so bad that you want to use external services, which are further in distance than your ISP, for speed?

When I upgraded my WiFi equipment at home a month ago I thought it was defective. Multiple times every day I'd seem to lose connectivity to the internet. After two weeks it occurred to me that my previous router was configured to do a couple things for me, one of which was overriding what DNS servers were assigned with DHCP. I reconfigured my new equipment to use those DNS servers and suddenly everything works normally.

To answer the question asked: Spectrum.


To answer the question asked: Spectrum.

I have Spectrum and have been fighting this exact problem for months. Trying out your steps now and hoping for success.


So did it work?


Not really :( I'm looking to replace my router entirely soon anyhow, and hoping this does the trick. My hardwired devices don't seem to have this problem.


Does no one bother to run their own DNS server? It's not hard---in fact, it's easier than running an authoritative DNS server, since you are only using it for local resolving.

I ran the provided script, added my own local resolver, and after the first run, got incredibly fast results.

                   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 
    cloudflare     35 ms   38 ms   39 ms   33 ms   34 ms   39 ms   28 ms   33 ms   28 ms   39 ms     34.60
    cloudflare2nd  34 ms   27 ms   34 ms   34 ms   34 ms   27 ms   34 ms   28 ms   28 ms   28 ms     30.80
    google         42 ms   27 ms   27 ms   40 ms   28 ms   40 ms   28 ms   40 ms   40 ms   28 ms     34.00
    google2nd      42 ms   27 ms   28 ms   43 ms   41 ms   39 ms   28 ms   41 ms   41 ms   28 ms     35.80
    quad9          65 ms   64 ms   54 ms   65 ms   63 ms   53 ms   59 ms   52 ms   60 ms   53 ms     58.80
    opendns        45 ms   32 ms   56 ms   51 ms   29 ms   74 ms   32 ms   48 ms   45 ms   32 ms     44.40
    norton         92 ms   73 ms   56 ms   152 ms  48 ms   144 ms  68 ms   40 ms   77 ms   83 ms     83.30
    cleanbrowsing  33 ms   28 ms   33 ms   28 ms   33 ms   35 ms   28 ms   32 ms   33 ms   29 ms     31.20
    yandex         174 ms  174 ms  185 ms  178 ms  184 ms  179 ms  179 ms  199 ms  176 ms  186 ms    181.40
    adguard        143 ms  147 ms  146 ms  142 ms  148 ms  143 ms  130 ms  130 ms  138 ms  137 ms    140.40
    neustar        62 ms   63 ms   70 ms   80 ms   40 ms   74 ms   73 ms   151 ms  58 ms   65 ms     73.60
    comodo         60 ms   137 ms  59 ms   60 ms   59 ms   59 ms   64 ms   62 ms   60 ms   59 ms     67.90
    localhost      0 ms    0 ms    0 ms    0 ms    0 ms    0 ms    0 ms    0 ms    0 ms    0 ms      0


Most people are not very interested in testing how fast their local machine can talk to itself; regardless of how fast your local cache is, it will have to talk outside pretty often (for expiring TTL if nothing else).


People are praising CloudFlare for not bothering to log requests. Yes, well ... you get the same results by using your own DNS resolver, and you don't have to be shocked when five years later a different governing team running CloudFlare decide to reverse their stance and log everything ...

But what do I know? Apparently I'm in the minority for running my own infrastructure (DNS, web, mail).


Where do you think your DNS resolver gets the answers it gives you? You're just introducing a caching layer between you and whatever external resolver you're using. The first time a machine requests a domain (and every time a TTL expires; look at CDN TTLs sometime) you are effectively talking to the internet just like everyone else.


Do you ever wonder if such activity (basically trying to be invisible) will put you under far more scrutiny than if you were to just 'be normal'? Thinking from the other side of it you would be a high value target to monitor as closely as possible if I were law enforcement. I know it sounds ridiculous but you may actually have more privacy (unless you're actually breaking the law) by hiding in plain sight with the rest of us.


If you talk to an upstream resolver through an encrypted link (both CloudFlare and Google support DNSoverTLS and DNSoverHTTPS, at least) then you at least limit the potential privacy threats.


If you live close to a peering point, both CF and Google will have mean ping times <10ms, often even <5ms. I doubt there's any real world difference between using localhost and either of them. As they cache results, using them could actually be faster than your own server.


Comcast... before changing DNS on my network, I tested a variety of DNS providers including Comcast. While Comcast had the best individual test minimum and average times, Comcast repeated testing showed lost packets and the occasional worst max times.

I don't know why they faired as poorly as they did, but once I realized some network issues could be pinned against DNS packet loss / terrible performance spikes, I changed over to 9.9.9.9 and 8.8.8.8 as the fall back. Home network has been a bit more stable since the change over.


Indonesian ISPs are required to filter certain domains, but go further than the Denmark case - they also block access to third-party DNS servers. Using DNScrypt or a VPN (or hosting your own DNS on a port they're not blocking like 80) is the only workaround.

Prior to third-party DNS servers being blocked a lot of tech-savvy people were using either Google's DNS or OpenDNS anyway since they tend to be more reliable than the local ISP's (even before they started filtering).

I'm no longer in Indonesia, but I could imagine the results people are posting here would be useful to folks back home so they can adjust their DNScrypt config.


My ISP is Comcast, a company I can trust about as much as I can throw it, so I use DNSCrypt when I'm not otherwise on a VPN, and have a number of fallback DNS providers for when DNSCrypt doesn't work.

Reasonably speaking I don't need very much from a DNS provider: <15ms latency, basic DNS security features and the ability to display an error rather than redirect me to a sponsored results page. I can do without the extra filters, but as long as I can get those three things, then I would rather use a different service than my ISP.


Do you use Netflix? If so, how do you get access if you use a third party DNS service?


Netflix doesn't care who your DNS resolver is. They might care if you access it through a VPN, which I don't.


It does. It’s how most Aussies were bypassing their geoblock about a year ago.


VirginMedia UK nameservers are notoriously poor, they just stop responding or disappear for hours. At least with Google I’m more or less guaranteed a response, as slow as it might be. I’m in an area where VM is the only cable operator, so I couldn’t switch without either losing on speed or spending a ton of money for someone else to cable me up.

I do try to use VM dns, but I periodically have to reverse to Google and often forget to switch back post-outage.


I run a local caching server on my network 192.168.1.22, from there I now forward to cloudflare, then to opendns on misses. This makes DNS resolution blazing fast for things we frequent.

I use my ASUS router's DHCP to teach all my dynamically configured network devices how to find the bind9 DNS caching server.

All the statically configured ones just have 192.168.1.22 hard coded with 1.1.1.1 as backup.


"Which ISPs are so bad that you want to use external services"

Any ISP that tries to redirect me to an ad-filled half-baked web search whenever I run into an inactive domain would definitely fall into my "so bad that I want to use external services" bucket.


Verizon's DNS seems to have improved, but a few years ago I ran into consistent problems resolving even the biggest / most common domains. My brief never-to-be-repeated dalliance with Comcast in 2016 was even worse.


BT in the UK. Their DNS is so unreliable that using it isn't really an option, so it's not even in the running.


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?


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


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


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.


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.


OpenDNS still has a lot of value beyond just free DNS service though. When I was very active in dealing with phishing, we found that OpenDNS flagged phishing sites about 4 times faster than any other DNS provider, which I assume is because of PhishTank. It's the primary reason I recommend it to my parents.

Between that and some of the content filtering options you can get with the paid plan, I find that it's a very full-featured option for homes with young kids. I'm pretty sure you get to control the logs on the paid plan too. Need to double check.


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.


Doesn't this just mean that you should be running your own caching resolver so that requests for common things don't constantly hit the upstream server? For those same common sites it should also be better performance anyway.


I have run into this in the wild.

Presented as a weird, intermittent, "hey the internet is out" at the office around the same time each afternoon.


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


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.


Yep, don't configure your servers with Google's public DNS servers but use the ones your public cloud provides.


Google DNS also has issues resolving DNSSEC-enabled Cloudflare domains.


Interesting! Do you have any examples?


Hmm, it seems like they may have fixed it, I can't seem to reproduce the problem I had (it would randomly fail to resolve CAA records for DNSSEC enabled domains).


Do we know yet if CloudFlare has similar rate limits?


I'd be surprised if they didn't have some form of rate limiting. Here are some reasons Google DNS does it https://developers.google.com/speed/public-dns/docs/security....


I wonder how much Cloudflare paid/pays for the 1.1.1.1


Read the announcement: https://blog.cloudflare.com/announcing-1111/ "APNIC's research group held the IP addresses 1.1.1.1 and 1.0.0.1. While the addresses were valid, so many people had entered them into various random systems that they were continuously overwhelmed by a flood of garbage traffic. APNIC wanted to study this garbage traffic but any time they'd tried to announce the IPs, the flood would overwhelm any conventional network.

We talked to the APNIC team about how we wanted to create a privacy-first, extremely fast DNS system. They thought it was a laudable goal. We offered Cloudflare's network to receive and study the garbage traffic in exchange for being able to offer a DNS resolver on the memorable IPs. And, with that, 1.1.1.1 was born."


Have they discussed what this means in terms of the privacy promises? What "garbage traffic" does APNIC have access to in order to study?


HA failover pings that get routed rather than being sent to their peer, captive portal requests that no longer exist. Things of that nature.

There is a lot of documentation, Cisco being one of the primary at-fault companies, that uses 1.1.1.1 for all kinds of various internal configuration.

Given hundreds of thousands of devices configured with 1.1.1.1, even a simple misconfiguration on just 10% of those is a lot of garbage traffic.


I think that's part of the point of all this - to find out what all that garbage traffic is.


No cash outlay. Read the blog, but tl;dr is that it's quid pro quo as the owners can't afford to stand it up due to the volume of junk traffic (but want to, to study the junk) -- cloudflare can and will let the owner study the junk.

What cloudflare don't say in any of their materials that I've seen is the agreement is for an initial 5 years, so YMMV after that.


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


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.


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


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


You can query DNS root server. https://www.iana.org/domains/root/servers

And use long TTL time with large cache size.

Other than some small edge cases, this is pretty much the most secure and fastest DNS performance you will have, in most instances getting about 1 or <1ms speed. Depending on DNS server you can even have both root servers and resolver configured.

I have been using unbound for at least 4 years. Simple and fast.


It is also very easy to do this with dnsmasq or powerdns, djbdns, etc.

I'm increasingly beginning to think that every node should be it's own dns so it's cache blacklist can be verified (checksums?) per node instead of per request to the dns provider.


Ok I'm going to try and set up Cloudflare's DNS setup in Go to point to those root servers and see what I get.

Is there a different DNS server you would recommend? I don't think my usage requires anything special.


BIND is the industry standard - but insanely overkill for your use case. Unbound is very easy and lightweight. Dnsmasq is another option, but I don't think you can setup root server with it.


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.


> (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!)

I once had an ISP which did transparent http proxying. You could theoretically query an external DNS server and get back the correct result, but it would intercept your http connection, discard the ip address you were trying to connect to then do a new DNS lookup to the ISP's DNS server on the HOST header.

Took me ages to work out what was going on with the various issues it was causing.

I dumped that ISP like a rock after they refused to disable that caching proxy, which they claimed was only there to improve customer experience.


Virgin Media in the UK appear to do this for sites they are ordered to block. Even if you get the right DNS response, you get forwarded to http://assets.virginmedia.com/site-blocked.html (HTTPS requests get a connection reset).


They don't need to be doing DNS proxying, they can just inspect port 53 traffic -- unless the site you're visiting supports DNS over TLS, then you're not hiding anything from your ISP, since they'll see the DNS query packet hitting the www.porn-site.com nameserver.

However, if have a local TLS nameserver, you can set it up to query 1.1.1.1 over TLS, then your ISP can't see any of your DNS queries.

So you need to decide who you trust more -- your ISP or a DNS provider (or a VPN provider).


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


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.


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.


> With a single resolver, I can verify that they're trustworthy enough [for me], just once, and direct all my traffic to it.

Apply this deceptively simple principle to every need you have on our wonderfully decentralized Internet and see where that gets us.

Oh snap. Not so decentralized anymore.


I'm talking about DNS and nothing else.

Okay, say, 1 year from now, somehow, 95% of internet users are sending their DNS queries to Cloudflare. What can go wrong? Malicious or not. Not rhetorical, actually curious.


Internet-wide censorship is now 1 US court order way. Compared to ... say 200,000 court orders away.

Centralizing things, makes it easy for law-makers to enforce bad policy which technology otherwise would have side-stepped.


But you also leak more things to TLAs right?


Yeah, there is that.


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/


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


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


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)


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



we don't keep personally identifiable information

We all know what that means. "Anonymous" user IDs that can trivially be traced when combined with another database.


Except that if you click the link, that's not what this means.


I read the policy before quoting it...

How can I verify that's not what it means? It's all about subtlety in language. It's just a fact that centralized DNS servers are a bad idea and cannot be trusted, regardless of what it very carefully says on a policy page or whatever speed gains you could get. It's a broken system and I have no reason to trust Google with even more data.


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

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


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


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

https://www.opennic.org/


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.


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.


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?


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

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


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


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

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


This is some pretty sage advice. I think it's great that Cloudflare is offering the service, but it's relatively simple (and fun!) to setup up our own. There's guide in the link below for using unbound server to do this. Example#1 fits many people. And, if we choose to censor any domains we can always do so on our own service... take a look at Example#2!

https://calomel.org/unbound_dns.html


Since a discussion about this topic has been present in every thread about Cloudflare's DNS service, I can quite confidently say "people" didn't forget.


They also allow for websites to look HTTPs-enabled, but the transfer happens in clear text, e.g.:

    Client -(HTTPS)> CloudFlare -(HTTP)> Server.
For a company that allegedly is privacy first, this is a huge violation of trust.

I also know about some people that run websites that can't get Stripe because they can't figure out how to configure SSL for their website, they just plug in CloudFlare in front, and now they can communicate with Stripe, and everything is received in cleartext following the diagram i posted.

Cloudflare calls this "Flexible SSL", and it is described here: https://support.cloudflare.com/hc/en-us/articles/200170416-W...

I have flagged this for both Cloudflare and Stripe, but none seems to care.


The threat model of MiTM attacks leans heavily towards the client side than the Cloudflare -> origin connection. It's not perfect and it would be fantastic if everyone could setup SSL on their origin servers, but in the end there's are more script kiddies in coffeeshops than there are tier1 isps trying to steal your data


Flexiable SSL by Cloudflare should itself be considered a MiTM Attack and should be opposed by all security standards, organizations, and anyone that values privacy or security, this highlights the inherent problem with SSL in the first place.


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


I ran a full recursor on my laptop for about two years. It's not a great choice, especially if you're not stationary. A lot as a lot of environments intercept DNS and poison your cache, the answers for lb'd names also change depending on your geolocation (so you have to flush it every time you move). Your queries are also not really private as you the resolver has to talk to multiple authoritatives to get you your name in a plain text. The performance is also not as great even with prefetching, as you don't benefit from a shared cache.

Probably the best thing you can do is to run something like https://github.com/jedisct1/dnscrypt-proxy which at least retains privacy between you and the resolver, and use public resolvers you trust.

If you don't trust any of them, you could start a resolver on a VM somewhere, but then again that can be traced back to you, so it depends on your threat model.

Both of these options are better than running a full resolver on localhost (unless you expect the recursive DNS infrastructure to fail, while authoritative remains operational).


What you want is DNSSEC-trigger, which installs Unbound on 127.0.0.1: https://www.nlnetlabs.nl/projects/dnssec-trigger/


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


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.


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


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.


I prefer Unbound as it lets me set a min-ttl. This of course is taboo and comes with caveats, so you have to know what you are doing and the implications. Unbound has better support for DNSSEC as well.


Unbound is a bit less likely to come with distro-specific oddities in the default config, I think, mostly. It's a matter of preference.


> Bind9 has a poor reputation because of how difficult it is to use it to define zones

YMMV, but bind’s poor reputation in my circles has completely to do with this:

https://www.cvedetails.com/product/144/ISC-Bind.html?vendor_...


This is the most alarming thing about this trend that has been happening for the last few years

The Internet should be DECENTRALIZED yet it seems we are attempting to do everything in our power to ensure only a handful of companies control access to all information. For what to save 3 ms off a ping time?

Facebook is in hot water over privacy issues, but that is just the tip of the ice berg

Google, AWS, Cloudflare are IMO are larger threat then facebook ever could be.


You're barking up the wrong tree here. DNS is already an inherently centralized service -- using one company's resolvers instead of another doesn't change that.


Yes and No

the problem with Cloudflare is not simply the fact that DNS is centralized, it is a combination of all their services that is concerning for Cloudflare,

between the DDOS Proxy, the CDN, the Other Services, and now DNS that is a lot of services in a single basket, so while it is true that dns is some what centralized, having all traffic and all services dependent upon a single company seems to be a bad idea to me

But clearly everyone sees not issue with it provided they "claim" to providing a "privacy first" service for free (ya riiiiiggghhhhttttt and Facebook cares about their users privacy as well) and they have better performance, who cares what the long term effects are...

We should be working to make DNS less centralized, or replace it with something less centralized, not moving to DNS over HTTP to a few "cloud" providers who also control all of the content...


  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


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


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.




On Linux, the easiest thing to do is to install busybox; it has a DNS server, dnsd. It will accept your hosts file directly.


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


It's in their FAQ: https://www.quad9.net/faq/#Is_there_a_service_that_Quad9_off...

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


  dig @9.9.9.11 +short
  ;; connection timed out; no servers could be reached
  dig @9.9.9.12 +short
  ;; connection timed out; no servers could be reached


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.


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?


It's an estimate of rtt + dns resolution.

The challenge in providing a good dns service is more about having nodes closer to the user than the dns resolution step itself because that in theory is almost constant for cached responses (it's usually in the microseconds) and when it's not cached the response time is really dependent on recursive querying of other dns servers. So the dns resolution can me estimated by measuring it from a data center manually and subtracting the rtt and use that as a constant.

To estimate the rtt, you can do an xhr request and grab the connectStart and connectEnd using window.performance API keeping in mind it takes 3 rtt to do the handshake. Note that the request will fail for services that don't provide https support but that's ok because we just want to measure connect.

The reason cloudflare has a better performance is most likely because they have better coverage and not because their servers are faster. Faster servers are a small factor in the final response time.

For services that provide https support you can accurately measure the connect and response time of the XHR request using window.performance interface and subtract the dns resolution of the request. Also if you do the request twice, the second time is likely to have a dns and connect time = 0.


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.


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.


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


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.


Using the Resource Timing API: https://www.w3.org/TR/resource-timing/#dom-performanceresour...

This allows you to get accurate timings for every resource the page loaded, including the timeline of DNS request/response for that resource.


Yes, but how do you test different DNS providers? ;)

(Please read the thread for context)


You'd have to change your nameserver manually unfortunately.

But you could build a good webpage that actually measures how well your current nameserver performs over a wide variety of different types of lookups, both warm and cold caches etc.


> You'd have to change your nameserver manually unfortunately.

Which negates the purpose intended in this thread.

I get it you could sorta hack together a one-off test, but please refer to the context of this thread as mentioned previously.


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.


https://pulse.turbobytes.com/results/5ac1f967ecbe4078c200ee4...

Cloudflare consistently times out from these networks.

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


Probably some smart people working there using 1.1.1.1 for internal stuff instead of one of the reserved subnets (private or "for documentation").


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.


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


I just got bite by this. If your ISP is AT&T (I have AT&T fiber) don't use 1.1.1.1, only use the CloudFlare secondary 1.0.0.1.

1.1.1.1 does not resolve.


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.


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


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


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.... 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/.


See my reply here: https://news.ycombinator.com/item?id=16733619

tl;dr: Google succeeds when people use websearch. Cloudfare succeeds when people use the Internet in general. People use websearch more when the Internet is fast and reliable. ISPs resolvers are frequently not fast nor reliable. Thus if you can improve peoples Internet experience with a better resolver, you improve your core business.

No need to track anyone via DNS for this to be successful.


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

https://developers.google.com/speed/public-dns/privacy


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.


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.


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.


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

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


See my other reply here: https://news.ycombinator.com/item?id=16733619

tl;dr: These companies are successful when more people use the Internet. DNS is a major contributor to poor perceived internet performance. Thus providing better DNS services encourages people to use the Internet more.


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


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


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...)?

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)


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.


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


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


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

http://www.jaruzel.com/files/ICMP-CloudFlareDNS-vs-Google-te...

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


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.


Safari barfs on visiting 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!


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


Yes, the browser checks the certificate presented includes a name which exactly matches the name in the URL it is trying to fetch.

The relevant RFC specifies two types of name suitable for servers, dnsName (a Fully Qualified DNS name written as text, except that there is no final dot, and optionally an asterisk may be used to make "wildcards") and ipAddress (an IPv4 or IPv6 address stored as a numeric value). Because this RFC is only about 20 years old, some software (but not e.g. Chrome, Firefox) also checks the X.500 series Common Name on a certificate to see if that seems to be textually equivalent to the name in the URL, which is how Netscape originally did this in like 1995 or whenever they invented SSL.

Unlike for DNS names we haven't substantially cleaned up the validation mechanisms Certificate Authorities may use for IP addresses, so they're a bit... lax, but the basic structure is you need to show you really have control over the address which was easy in this case.


The actual domain name is 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.


That works fine (the URL directly). The certificate is valid. Entering 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.


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


Safari 11.1 (13605.33.1.2). Mac OSX 10.13.4.


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?


Works fine in Safari here. Wondering if your request is being intercepted by one of the many network devices out there which hijacks 1.1.1.1 for its own use.


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: