$ 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
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/
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.
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.
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
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.
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
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.
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
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
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
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
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
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
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
$ 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
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.
% 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
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.
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?
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.
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.
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).
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."
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
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.
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.
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.
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!)
> (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]
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.
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.
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.
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.
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?
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.
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
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
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?
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.
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.
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.
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.
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.
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.
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.
> 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.
>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
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.
> 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.
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.
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 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:
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...
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!
(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.
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.
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.
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.
Then again, a few ms of difference is unlikely to make any noticeable effect in real-world use cases where clients already have local DNS caching and the bulk of the time is data transfer, not DNS lookups.
Are you using BIG ISP or small? Big guys don't peer at QIX and drag your traffic to US. On other side, smaller players peer at QIX https://qix.ca/members
Quad9 is a consortium of 3 founding companies, none of which is the London Police Department. Additionally nowhere in your link is either Quad9, IBM, PCH or GCA mentioned. Please stop spreading and disinformation and FUD. See:
Whether its the City of London's Police Department or the Greater London Police is splitting hairs. Your comment suggests that the Quad9 was funded by a municipal police force. And that's patently untrue.
If you dug a little deeper on one of your own links you would find that the NYC DA and City of London Police Department donated money to establish a 501(c)3 non-profit to combat cyber crime. That 5013C is but one member of a consortium of 3 companies behind Quad9.
"Knowing the potential that an organisation like GCA could have, the DA committed $25 million in criminal asset forfeiture proceeds to fund this critical work over a five-year period. The Center for Internet Security and City of London Police also made significant contributions in providing space, funding, staff, and assistance with building strategic partnerships."[1]
Interesting question: would I rather protect my elderly Mum from known malicious domains potentially trying to scam/phish, or from potential tracking and ad targeting?
(Actually, it's not really a difficult choice at all, is it?)
Out of curiosity, are there any negatives for everyone to funnel their DNS traffic through a single provider? Might be paranoia, and it may in this case just be putting all of your traffic through company_a vs all of your traffic through company_b scenario, but I've been curious since this was announced.
test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 Average
quad9 1 ms 2 ms 1 ms 1 ms 1 ms 1 ms 1 ms 1 ms 1 ms 1 ms 1.10
cloudflare 2 ms 1 ms 1 ms 2 ms 1 ms 1 ms 1 ms 2 ms 1 ms 1 ms 1.30
comodo 1 ms 2 ms 2 ms 3 ms 2 ms 1 ms 2 ms 1 ms 1 ms 2 ms 1.70
adguard 2 ms 2 ms 3 ms 2 ms 2 ms 2 ms 2 ms 2 ms 2 ms 2 ms 2.10
cleanbrowsing 2 ms 4 ms 2 ms 2 ms 2 ms 2 ms 14 ms 16 ms 2 ms 2 ms 4.80
norton 6 ms 7 ms 7 ms 7 ms 8 ms 7 ms 6 ms 7 ms 7 ms 7 ms 6.90
namecheap 7 ms 7 ms 7 ms 7 ms 7 ms 7 ms 7 ms 7 ms 7 ms 7 ms 7.00
neustar 8 ms 7 ms 7 ms 8 ms 9 ms 6 ms 7 ms 7 ms 7 ms 7 ms 7.30
namecheap2nd 8 ms 8 ms 7 ms 9 ms 9 ms 8 ms 10 ms 8 ms 8 ms 8 ms 8.30
opendns 20 ms 1 ms 1 ms 30 ms 2 ms 8 ms 1 ms 16 ms 15 ms 3 ms 9.70
google2nd 16 ms 1 ms 1 ms 17 ms 1 ms 24 ms 1 ms 16 ms 17 ms 14 ms 10.80
google 17 ms 1 ms 1 ms 17 ms 1 ms 41 ms 1 ms 17 ms 18 ms 15 ms 12.90
cloudflare2nd 1 ms 2 ms 1 ms 1 ms 1000 ms 2 ms 2 ms 1 ms 2 ms 2 ms 101.40
yandex 101 ms 102 ms 104 ms 101 ms 115 ms 103 ms 107 ms 100 ms 105 ms 136 ms 107.40
Not so much from my home ISP:
test1 test2 test3 test4 test5 test6 test7 test8 test9 test10 Average
namecheap2nd 45 ms 45 ms 44 ms 45 ms 48 ms 45 ms 45 ms 46 ms 48 ms 45 ms 45.60
cloudflare2nd 45 ms 49 ms 48 ms 47 ms 45 ms 44 ms 45 ms 45 ms 46 ms 46 ms 46.00
namecheap 46 ms 48 ms 48 ms 44 ms 45 ms 45 ms 46 ms 45 ms 45 ms 48 ms 46.00
cleanbrowsing 46 ms 46 ms 44 ms 56 ms 45 ms 44 ms 48 ms 46 ms 44 ms 46 ms 46.50
google2nd 49 ms 47 ms 47 ms 45 ms 51 ms 47 ms 46 ms 44 ms 43 ms 46 ms 46.50
comodo 46 ms 47 ms 48 ms 49 ms 46 ms 47 ms 44 ms 45 ms 47 ms 50 ms 46.90
adguard 49 ms 48 ms 45 ms 46 ms 46 ms 48 ms 49 ms 48 ms 48 ms 48 ms 47.50
google 46 ms 49 ms 47 ms 47 ms 45 ms 47 ms 47 ms 49 ms 44 ms 67 ms 48.80
opendns 47 ms 46 ms 47 ms 64 ms 48 ms 49 ms 46 ms 64 ms 64 ms 48 ms 52.30
cloudflare 44 ms 48 ms 45 ms 50 ms 48 ms 110 ms 45 ms 48 ms 45 ms 47 ms 53.00
quad9 46 ms 49 ms 45 ms 47 ms 49 ms 153 ms 46 ms 45 ms 48 ms 46 ms 57.40
neustar 66 ms 66 ms 66 ms 67 ms 66 ms 66 ms 66 ms 67 ms 66 ms 67 ms 66.30
norton 91 ms 67 ms 67 ms 67 ms 66 ms 66 ms 67 ms 66 ms 67 ms 67 ms 69.10
yandex 176 ms 279 ms 176 ms 174 ms 188 ms 178 ms 179 ms 176 ms 174 ms 179 ms 187.90
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.
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!
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.
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.
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).
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).
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.
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.
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...
Is DNS configuration ever considered as a factor in "DNS performance"? IME as an end user, it makes a significant difference.
For example if it takes seven queries to resolve a name "A" versus two queries to look up a name "B", then in almost all cases, irrespective of the distance to a cache, looking up A is going to be noticeably slower than looking up B. Indirection is only one example. Even worse are configuations that knowingly trigger retries and wait for client timeouts in order to present a client with a particular nameserver.
Indirection and other "DNS tricks" come at a cost. IME, these are not compensated for via the proximity of a cache.
There's a lot more to consider than just performance when deciding whom to share your browsing habits with. Why would you choose Cloudflare or Google?
This isn't an endorsement of Quad9 or OpenDNS; I just don't know enough about them. However, the fact that Cloudflare and Google are privacy-and-security nightmares is well documented.
- One for up to 48 hours which contains IP addresses, which is used for handling abuse.
- One is permanent which doesn't contain any personal identifying information (eg IP addresses), which is used for things like internal performance monitoring, load testing, and tracking frequency of longer term abuse etc.
Google provides Google public DNS because if you see the internet as being slow because of poor DNS performance, then you don't use websearch as much. Google doesn't need to use Google Public DNS to track users, and would rather not have the information (as it makes it available for government requests etc which are a major pain to deal with). But running a large scale recursive DNS server tends to attract a _lot_ of abuse, both intentional, and unintentional as I'm sure 9.9.9.9 and 1.1.1.1 are discovering.
Google provides Google Public DNS because a lot of ISPs provide extremely poor default recursive nameservers (having tiny caches, dropping queries due to overload, not implementing IPv6, DNSSEC validation, EDNS0 payload size, or other important modern DNS features. Some ISPs also hijack domains for their own purposes, or "stretching" DNS TTLs etc) so providing a better alternative to improve overall Internet use is clearly in Google's best interest.
Having other public resolvers, with different trade offs is clearly better for everyone, including Google as long as they are reliable, trustworthy, and provide low latency responses.
Good luck to everyone who's joining in the fun of running a planet scale recursive DNS server.
(Disclaimer: I have previously worked on Google Public DNS, but no longer do)
Do you know if Chrome uses Google Public DNS by default? I've heard it does for performance and avoiding problems with ISPs' crappy DNS. I imagine it would still need to fall back to local DNS to resolve names on enterprise intranets.
My uninformed assumption is that chrome generally uses whatever is configured in the system resolver, otherwise things like captive portals, and split horizon DNS wouldn't work properly, but I don't specifically know.
You've got any proof, indication or even slight hint for this? Aggregate data is indeed used for all kinds of analytics, but individual IP addresses aren't tracked nor kept for more than 48 hours - to combat abuse.
And I wanted to add a similar comment, why on earth would any privacy-oriented person would use Google's 8.8.8.8 when there are other options out there?
Oh, and I definitely don't buy this for Google: "The Privacy option above is based on the providers promise to do not log or share your DNS requests."
Well, the article says so, but they actually measured icmp response. All major domains are in DNS cache anyway. If you look at Yandex result you see it performed very poorly. Why does it resolve popular domains so slow? The reason is it has one server and it is located in Moscow.
So i would say icmp is good proxy to actual performance.
It would be a measure of ping + cache latency. That's still different than just ping.
And is your point that the tested sites aren't popular in Russia?
>for different popular domains (google, facebook, twitter, gmail, etc)
google.com facebook.com and twitter.com are all in the top 50 sites in Russia[1]. And gmail.com is number 6000 globally[2], so it's unpopular everywhere, not just Russia. Popular sites in Russia tend to be popular elsewhere, and vice versa.
https://github.com/cleanbrowsing/dnsperftest