←back to thread

1.1.1.1: Fast, privacy-first consumer DNS service

(blog.cloudflare.com)
1895 points _l4jh | 6 comments | 01 Apr 18 12:14 UTC | HN request time: 0s | source | bottom
Show context
cleanbrowsing ◴[01 Apr 18 17:09 UTC] No.16729310[source]▶
And look at these ping times:

                                   CloudFlare       Google DNS       Quad9            OpenDNS          
  NewYork                            2 msec           1 msec           2 msec           19 msec          
  Toronto                            2 msec           28 msec          17 msec          27 msec          
  Atlanta                            1 msec           2 msec           1 msec           19 msec          
  Dallas                             1 msec           9 msec           1 msec           7 msec           
  San Francisco                      3 msec           21 msec          15 msec          20 msec          
  London                             1 msec           12 msec          1 msec           14 msec          
  Amsterdam                          2 msec           6 msec           1 msec           6 msec           
  Frankfurt                          1 msec           9 msec           2 msec           9 msec           
  Tokyo                              2 msec           2 msec           81 msec          77 msec          
  Singapore                          2 msec           2 msec           1 msec           189 msec         
  Sydney                             1 msec           130 msec         1 msec           165 msec
Very impressive CloudFlare.
replies(20): >>16729423 #>>16729467 #>>16729545 #>>16729560 #>>16729939 #>>16729952 #>>16730034 #>>16730110 #>>16730198 #>>16730229 #>>16730567 #>>16730893 #>>16731389 #>>16732068 #>>16732273 #>>16732936 #>>16733149 #>>16733462 #>>16733833 #>>16761330 #
1. kentonv ◴[01 Apr 18 17:56 UTC] No.16729545[source]▶
Keep in mind that ping time isn't the only factor in DNS lookup speed. For me (sonic.net in Palo Alto):

ping 1.1.1.1: ~22ms

ping 8.8.8.8: ~19ms

dig @1.1.1.1: ~45ms

dig @8.8.8.8: ~70ms

Disclaimer: Eyeballed averages over a few samples. A more rigorous test of DNS lookup times would be cool to see.

Disclosure: I work for Cloudflare, but not on DNS.

replies(3): >>16729749 #>>16729765 #>>16730238 #
2. joemag ◴[01 Apr 18 18:37 UTC] No.16729749[source]▶
So logging accounts for 25ms ;)
3. mgkimsal ◴[01 Apr 18 18:40 UTC] No.16729765[source]▶
how are you pinging 8.8.8.8?

EDIT: nevermind - mistake on my end!

4. yborg ◴[01 Apr 18 20:22 UTC] No.16730238[source]▶
I'm guessing Google's resolvers are a little busier than Cloudflare's right now, because pretty much nobody not on HN right now is hitting them. Will be a more interesting comparison in 6 months.
replies(1): >>16730474 #
5. kentonv ◴[01 Apr 18 21:15 UTC] No.16730474[source]▶
I'd be surprised if increased load has a negative effect on 1.1.1.1's performance.

We run a homogeneous architecture -- that is, every machine in our fleet is capable of handling every type of request. The same machines that currently handle 10% of all HTTP requests on the internet, and handle authoritative DNS for our customers, and serve the DNS F root server, are now handling recursive DNS at 1.1.1.1. These machines are not sitting idle. Moreover, this means that all of these services are drawing from the same pool of resources, which is, obviously, enormous. This service will scale easily to any plausible level of demand.

In fact, in this kind of architecture, a little-used service is actually likely to be penalized in terms of performance because it's spread so thin that it loses cache efficiency (for all kinds of caches -- CPU cache, DNS cache, etc.). More load should actually make it faster, as long as there is capacity, and there is a lot of capacity.

Meanwhile, Cloudflare is rapidly adding new locations -- 31 new locations in March alone, bringing the current total to 151. This not only adds capacity for running the service, but reduces the distance to the closest service location.

In the past I worked at Google. I don't know specifically how their DNS resolver works, but my guess is that it is backed by a small set of dedicated containers scheduled via Borg, since that's how Google does things. To be fair, they have way too many services to run them all on every machine. That said, they're pretty good at scheduling more instances as needed to cover load, so they should be fine too.

In all likelihood, what really makes the difference is the design of the storage layer. But I don't know the storage layer details for either Google's or Cloudflare's resolvers so I won't speculate on that.

replies(1): >>16732501 #
6. lugg ◴[02 Apr 18 05:20 UTC] No.16732501{3}[source]▶
> In fact, in this kind of architecture, a little-used service is actually likely to be penalized in terms of performance because it's spread so thin that it loses cache efficiency

This is exactly what I'm seeing with the small amount of testing I'm doing against google to compare vs cloudflare.

Sometimes google will respond in 30ms (cache hit), more often than not it has to do at least a partial lookup (160ms), and sometimes even go further to (400ms.)

The worst I'm encountering on 1.1.1.1 is around 200ms for a cache miss.

Basically, what it looks like is that google is load balancing my queries and I'm getting poor performance because of it - I'm guessing they simply need to kill some of their capacity to see increased cache hits.

Anecdotally I'm at least seeing better performance out of 1.1.1.1 than my ISP's (internode) which has consistently done better than 8.8.8.8 in the past.

Also anecdotally, my short 1-2 month trial of using systemd-resolved is now coming to a failed conclusion, I suspect I'll be going back to my pdnsd setup because it just works better.