DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS

DNS Performance compared: CloudFlare 1.1.1.1 x Google 8.8.8.8 x Quad9 x OpenDNS | Hacker News Reader

test1 test2 test3 test4 test5 namecheap2nd 45 ms 45 ms 44 ms 45 ms 48 ms 45 ms 45 ms 46 ms 48 ms 45 ms cloudflare2nd 45 ms 49 ms 48 ms 47 ms 45 ms 44 ms 45 ms 45 ms 46 ms 46 ms namecheap 46 ms 48 ms 48 ms 44 ms 45 ms 45 ms 46 ms 45 ms 45 ms 48 ms cleanbrowsing 46 ms 46 ms 44 ms 56 ms 45 ms 44 ms 48 ms 46 ms 44 ms 46 ms google2nd 49 ms 47 ms 47 ms 45 ms 51 ms 47 ms 46 ms 44 ms 43 ms 46 ms comodo 46 ms 47 ms 48 ms 49 ms 46 ms 47 ms 44 ms 45 ms 47 ms 50 ms adguard 49 ms 48 ms 45 ms 46 ms 46 ms 48 ms 49 ms 48 ms 48 ms 48 ms google 46 ms 49 ms 47 ms 47 ms 45 ms 47 ms 47 ms 49 ms 44 ms 67 ms opendns 47 ms 46 ms 47 ms 64 ms 48 ms 49 ms 46 ms 64 ms 64 ms 48 ms cloudflare 44 ms 48 ms 45 ms 50 ms 48 ms 110 ms 45 ms 48 ms 45 ms 47 ms quad9 46 ms 49 ms 45 ms 47 ms 49 ms 153 ms 46 ms 45 ms 48 ms 46 ms neustar 66 ms 66 ms 66 ms 67 ms 66 ms 66 ms 66 ms 67 ms 66 ms 67 ms norton 91 ms 67 ms 67 ms 67 ms 66 ms 66 ms 67 ms 66 ms 67 ms 67 ms yandex 176 ms 279 ms 176 ms 174 ms 188 ms 178 ms 179 ms 176 ms 174 ms 179 ms User's geolocation information: i.e. geocode, region ID, city ID, and metro code

Response

For a company that allegedly is privacy first, this is a huge violation of trust.

I noopener noreferrer">https://github.com/cleanbrowsing/dnsperftest

  $ sh ./dnstest.sh |sort -k 22 -n test10  Average 1.30 2.00 3.90 12.50 18.10 19.70 22.20 27.20 188.10 201.20

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 42.10 45.40 50.30 30.90 44.40 232.40 104.30 42.30 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 37.60 42.10 42.30 44.40 45.40 50.30 51.80 104.30 232.40

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

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

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.

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 5.50 5.80 7.00 17.50 20.60 20.90 33.70 46.20 150.60 155.00

What ISP/city you tested it from?

This is cool; thanks for the script.

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 8.90 13.30 13.40 15.10 15.90 16.10 18.80 42.10 44.80 97.50 159.30 174.80

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 24.50 25.90 30.60 37.30 38.40 38.70 39.80 66.10 128.30 157.70 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.

I had my own script. CloudFlare and CleanBrowsing are great, but my ISP (Telekom) still wins.
  Tested 20 domains 5 times each border-l-2 pl-3 border-orange-400">From Oakland on Comcast:
  $ sh ./dnstest.sh | sort -k 22 -n test10  Average 40.60 41.00 41.60 41.80 42.10 42.50 42.90 64.80 81.90 283.00
Comcast in Mountain View, CA.
                   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 39.10 39.70 40.50 41.10 41.40 42.30 42.40 50.00 80.50 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?)
Results for Reno, NV on AT&T:Round One:
                   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 4.00 8.00 8.00 8.00 8.60 17.60 19.40 19.70 27.40 27.60 155.90 192.30 test7   test8   test9   test10  Average 8.00 8.10 8.80 11.30 11.90 13.60 15.90 19.50 19.70 27.40 157.00 188.70 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 24.20 38.20 39.30 39.90 41.10 42.80 52.70 59.50 76.70 85.40 279.50 391.50
Thanks.Paris, France (OVH ADSL link FWIW):
    test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 9.10 9.30 14.50 16.30 17.90 18.20 20.20 22.40 25.20 26.30 61.90 81.60 than all the others.
from Bhimavaram, India
  sh ./dnstest.sh |sort -k 22 -n test10  Average 46.60 51.00 56.30 56.30 56.40 56.40 57.10 57.10 57.40 59.20 59.80 141.90
Berlin, Vodafone Kabel Deutschland (Cable):
                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 12.30 16.40 20.20 20.70 21.70 23.90 25.50 27.50 29.30 36.20 45.80 62.20
From Perth, Western Australia:
                  test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 85.80 99.80 105.00 112.60 134.10 136.70 166.40 172.40 194.80 226.50 291.80 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/
from interior BC:
  % bash ./dnstest.sh test10  Average 29.00 47.50 42.00 40.40 36.30 61.40 78.50 87.40 243.00 89.10 78.30 800.30
From New Delhi(Airtel), India
                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 37.30 40.80 153.10 106.10 292.60 78.80 59.80 315.80 311.10 358.00 162.50 276.60
From Mumbai, India:
                   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 15.10 2.60 82.90 20.00 129.20 58.00 4.00 227.80 139.80 205.50 235.90 133.10
Singapore, work:
                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 2.50 2.80 2.80 2.90 3.10 4.10 22.90 48.30 177.20 186.10 241.70 263.00
Made a couple of changes to add median value and local DNS (via ViewQuest).
  ./dnstest.sh| column -s\, -t Median 3 ms    3.10 ms    3 ms 3 ms    3.00 ms    3 ms 4 ms    3.30 ms    3 ms 2 ms    22.50 ms   2 ms 4 ms    3.30 ms    3 ms 2 ms    31.00 ms   2 ms 3 ms    3.10 ms    3 ms 177 ms  177.90 ms  178 ms 215 ms  258.50 ms  281 ms 186 ms  186.00 ms  186 ms 3 ms    2.80 ms    3 ms 262 ms  266.80 ms  264 ms 0 ms    1.00 ms    0 ms
London, with BT fibre
                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 3.70 3.90 4.00 5.10 5.90 6.70 6.90 8.10 11.80 51.30 63.30 71.70
Amsterdam:
  test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 27.10 28.60 37.40 27.20 32.80 65.10 50.40 29.50 57.00 32.80 29.00 37.00
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; 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.
Warsaw, Poland
               test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average
 15.40 15.30 30.80 28.10 123.10 43.80 41.60 36.10 90.90 54.50 41.50 52.80
Nice script, but 10 runs aren't enough to give reliable results. Not even close.
The performance is depending on how many concurrent user are using their service.
Italy, TIM:
                 test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 21.10 22.30 29.00 38.70 40.80 42.20 44.70 47.70 56.40 57.60 73.30 91.00
Fredericton, Canada:
               test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 37.40 37.50 37.90 38.10 39.20 42.20 45.80 84.80 85.10 118.50 146.10 167.50
Buenos Aires [City], Argentina
                      test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 1000 ms   610.10 31.90 25.00 30.60 158.80 105.30 160.30 46.00 289.00 290.00 158.30 166.10
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.
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 1.00 33.80 33.90 34.20 37.10 37.20 39.30 40.20 41.40 57.00 89.20 159.50 162.20

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

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

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.

>My isp got the brilliant idea of rolling their own YouTube cache serversAre YouTube videos not served using https? Sounds like it's google/YouTube servers but they're underprovsioned

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.

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)

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.

> A competent ISP operating in good faithThat's probably the funniest thing I've read all year

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

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.

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

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

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.

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.

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

Verizon Fios

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?

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.

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.

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.

Here's an incomplete list with dozens.https://en.m.wikipedia.org/wiki/DNS_hijacking#Manipulation_b...

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.

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.

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

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

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.

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.

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

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.

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

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

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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 34.60 30.80 34.00 35.80 58.80 44.40 83.30 31.20 181.40 140.40 73.60 67.90 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).

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.

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.

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.

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.

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

I wonder how much Cloudflare paid/pays for the 1.1.1.1

Read the announcement:  https://blog.cloudflare.com/announcing-1111/ 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?

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

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.

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.

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.

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.

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

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.

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

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.

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.

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 class="scroll-mt-28 border-l-2 pl-3 border-orange-400">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.
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 id="c16733427" class="scroll-mt-28 ">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.
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).
But you also leak more things to TLAs right?
Yeah, there is that.
> 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.
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).
You can query DNS root server. noreferrer">https://www.iana.org/domains/root/serversAnd 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.
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.
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.
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 AURps: namebench is quite extensive. thousands of queries and a nice and long report. enjoy it
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.
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=20Pihole 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.
The OpenNIC project has a database of community/private DNS servers with certain standards.https://www.opennic.org/
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.
https://pi-hole.net
On Linux, the easiest thing to do is to install busybox; it has a DNS server, dnsd. It will accept your hosts file directly.
https://github.com/jedisct1/dnscrypt-proxy
  Moscow, Russia test10  Average 7.90 11.90 24.80 28.10 47.10 47.40 48.00 52.50 52.90 55.30 82.10 1000.00
From Waimanalo, Hawaii cloudflare times out:
                  test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 158.00 1000.00 106.30 95.10 97.80 84.00 148.70 273.00 311.30 83.30 149.80
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.
  dig @9.9.9.11 +short id="c16735326" class="scroll-mt-28 border-l-2 pl-3 border-orange-400">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.
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: target="_blank" rel="nofollow noopener noreferrer">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 border-l-2 pl-3 border-orange-400">
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 border-l-2 pl-3 border-orange-400">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?
See my reply here: https://news.ycombinator.com/item?id=16733619tl;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.
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/.
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.
See my other reply here: https://news.ycombinator.com/item?id=16733619tl;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.
> 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.
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:``` ">
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.
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.)
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). border-l-2 pl-3 border-amber-400">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?
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.
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.
I wonder how well 4.2.2.x compares...Then again, a few ms of difference is unlikely to make any noticeable effect in real-world use cases where clients already have local DNS caching and the bulk of the time is data transfer, not DNS lookups.
> the bulk of the time is data transfer, not DNS lookupsYou’d be surprised.
In my tests 4.2.2.1 performs 50% faster than 1.1.1.1 and is twice as fast as 8.8.8.8.
4.2.2.x (Level3) is one of those resolvers hijacking negative answers and redirecting your to their "search pages".
No tests for Africa?
I've been using Quad9, if anything just because I feel Google already knows too much about me anyway. So far no complaints about it.
Why is Montreal reporting abnormally high response times across the board?For example:
# Cloudflare Toronto 3.42ms vs. Montreal 17ms;
# Google Toronto 9.42ms vs. Montreal 16.71ms.
I live in Montréal, and I saw the same tendency. Cloudflare has a datacenter here. Waiting for a tangible explanation…
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
Perhaps that particular test setup doesn't go to QIX where both of them are present. Cloidflare much faster from QIX peering nonetheless.
How do other services compare? noreferrer">https://blog.uncensoreddns.org/dns-servers/ x2F;dns.watch/ noopener noreferrer">https://ipredator.se/page/services#service_dns
I wasn't aware of Quad9, it seems like a pretty great option for those that are easy targets of scams/phishing.
Quad9 is supported/funded by City Of London Police, the same police that cooperates with ad companies to track people online. tising-industry-copyright-infringement" target="_blank" rel="nofollow noopener noreferrer">https://www.theguardian.com/media-network/media-network-blog...Keep away from this.
Actually Quad9 seems to be a non-profit, founded by IBM, PCH and GCA (of which the City of London Police is a founder).The simple fact that it's supported by the CoLP doesn't seem sufficient to point out that Quad9 should be avoided since it will track people online.
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?)
Why not install an ad blocker with a malware blocking list in her browser?
Why not both? You're smart enough I guess to find a good solution.
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:https://www.quad9.net/about/
I never said it's London PD, it's City of London, these are two different things, have different mayors and budget etc.https://www.youtube.com/watch?v=LrObZ_HZZUc
http://news.cityoflondon.police.uk/r/945/ibm__packet_clearin...
https://www.cityoflondon.police.uk/advice-and-support/cyberc...
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]
[1] https://www.globalcyberalliance.org/about.html#history
Quad9 doesn’t seem to work at some universities in Australia, not sure why. DNS fails to resolve from the WiFi.
I switched all my devices to CloudFlare 'cause it 2x faster than Google DNS in my location - Europe.
I'm in Europe too which is in Paris and  Google DNS is way faster at 4ms vs 15ms for cloudflare.
Will website name in certificate shared by server during handshake kill the DNS over https purpose?
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.
Why is Montreal abnormally high for all services?
It goes to NYC ...
google is faster for me in the bay area from comcast network. Using both ping and dig for testing
It is blocked in Turkey.
Cloudflare it is then!
Thanks, great response times from my NYC droplet.
				   test1   test2   test3   test4   test5   test6   test7   test8   test9   test10  Average 1.10 1.30 1.70 2.10 4.80 6.90 7.00 7.30 8.30 9.70 10.80 12.90 101.40 107.40 test6   test7   test8   test9   test10  Average 45.60 46.00 46.00 46.50 46.50 46.90 47.50 48.80 52.30 53.00 57.40 66.30 69.10 187.90
Does anyone actually believe that google isn’t hoovering up personal data with its DNS service?
https://developers.google.com/speed/public-dns/privacy
we don't keep personally identifiable informationWe 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.
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 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.
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 the most alarming thing about this trend that has been happening for the last few yearsThe 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 Nothe 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...
> 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?
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.confBind9 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 zonesYMMV, but bind’s poor reputation in my circles has completely to do with this:
https://www.cvedetails.com/product/144/ISC-Bind.html?vendor_...
What you want is DNSSEC-trigger, which installs Unbound on 127.0.0.1: https://www.nlnetlabs.nl/projects/dnssec-trigger/
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).
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. 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.
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.
OpenNIC offers DNSCrypt.https://www.opennic.org/
Google and Privacy=Yes ... sure.
I presume that Google uses this as part of it's surveillance operation.
Yes, they aren’t providing 8.8.8.8 out of the goodness of their black hearts
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."
Google has a separate, stricter, privacy policy for Google Public DNS: https://developers.google.com/speed/public-dns/privacyBasically there are two log files kept:
- One for up to 48 hours which contains IP addresses, which is used for handling abuse.
- One is permanent which doesn't contain any personal identifying information (eg IP addresses), which is used for things like internal performance monitoring, load testing, and tracking frequency of longer term abuse etc.
Google provides Google public DNS because if you see the internet as being slow because of poor DNS performance, then you don't use websearch as much.  Google doesn't need to use Google Public DNS to track users, and would rather not have the information (as it makes it available for government requests etc which are a major pain to deal with).  But running a large scale recursive DNS server tends to attract a _lot_ of abuse, both intentional, and unintentional as I'm sure 9.9.9.9 and 1.1.1.1 are discovering.
Google provides Google Public DNS because a lot of ISPs provide extremely poor default recursive nameservers (having tiny caches, dropping queries due to overload, not implementing IPv6, DNSSEC validation, EDNS0 payload size, or other important modern DNS features.  Some ISPs also hijack domains for their own purposes, or "stretching" DNS TTLs etc) so providing a better alternative to improve overall Internet use is clearly in Google's best interest.
Having other public resolvers, with different trade offs is clearly better for everyone, including Google as long as they are reliable, trustworthy, and provide low latency responses.
Good luck to everyone who's joining in the fun of running a planet scale recursive DNS server.
(Disclaimer: I have previously worked on Google Public DNS, but no longer do)
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.
This is outside my area of expertise.My uninformed assumption is that chrome generally uses whatever is configured in the system resolver, otherwise things like captive portals, and split horizon DNS wouldn't work properly, but I don't specifically know.
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.(Disclaimer: I'm a Google corporate shill)
dig +noall +stats @1.0.0.1 news.ycombinator.com; dig +noall +stats @1.1.1.1 news.ycombinator.com; dig +noall +stats @208.67.220.220 news.ycombinator.com; dig +noall +stats @208.67.222.222 news.ycombinator.com; dig +noall +stats @8.8.4.4 news.ycombinator.com; dig +noall +stats @8.8.8.8 news.ycombinator.comFixed? =P
I removed some of the records form the article after reading some of the comments here.  Cloudflare, Google, and OpenDNS only.
Kind of cool, I switched it up and ran it against 10 sites I frequent... was pretty impressed to see how well OpenDNS was doing.
That tests ICMP echo requests not name resolution.
That is what original test was testing.
What? It says>Our test was very simple and we performed 70 DNS lookups
That's not ICMP.
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.
[1] https://www.similarweb.com/top-websites/russian-federation
[2] https://www.alexa.com/siteinfo/gmail.com
all these sites are popular in Russia, so we can presume cache latency is a constant on all tested servers. What left is a ping, packet response time.
You should be doing `dig @1.1.1.1 news.ycombinator.com`
That resolves "news.ycombinator.com" and "1.1.1.1" with your system resolver.You're looking for "dig @1.1.1.1 news.ycombinator.com" which will resolve "news.ycombinator.com" using "1.1.1.1".
Thanks, I wrote that from memory. I'll update my comment.
Sorry, I've downvoted you (even though you're not being offensive in any way) because your incorrect command will confuse a bunch of people.EDIT: fixed, so I've undowned
This whole subtree of comments is really messy with all the editing several of you people did.It would be better to just delete this whole subtree.
Reply on news.ycombinator.com