Google Fiber DNS: Cloudflare vs Google

My home has recently been connected to Google Fiber. I’d been looking forward to this for awhile. Finally, faster upload speeds!

Google Fiber pitches itself as the “Fastest internet provider in the country.”. They are offering 5 and 8 Gigabit fiber connections in some places, which is not the highest capacity out there, but still very good. Also, it will always be Internet to me.

Quick aside, all of this kinda blows my mind. I don’t think I would have believed you if you had told me in the 1990s that this is how things would have turned out. Back when I was still dreaming about the idea of somehow having a T1 line( 1.5 Mbps ) at home. Now we’ve since sailed past even a T3 line ( 44 Mbps ).

This being a Google service, it was no surprise to see that DNS pointed to their public 8.8.8.8 DNS service by default. My naive assumption was that the Google 8.8.8.8 DNS service was going to be the fastest option with a Google Fiber connection. Google Fiber + Google DNS, how could that not be the fastest combination?

A funny thing about obvious conclusions, some times they are wrong.

Testing

A big pipe, with low latency, is the foundation of having a “fast” Internet connection. My new 5 Gbps fiber certainly takes care of that.

A major service for actually using the Internet is DNS. For most people DNS is being used constantly, generally invisible, in the background. Before you can connect to another host on the Internet your system uses DNS to translate a host name ( like wordpress.com ) to an IP address ( like 192.0.78.9 ). A slow DNS service means those lookups take longer, and they happen while trying to connect to another machine.

There is plenty more to understanding how DNS works, but for the sake of simplicity, all other things being equal: a faster DNS service is better than a slower one. A slow ( or even worse, broken ) DNS service can make it look like your network connection is slow or broken. Google DNS documentation has a section on why DNS latency is important to performance.

To test the latency between my home and 8.8.8.8 I ran ping test from a wired connection.

$ ping -4 -n -c 10 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=19.5 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=19.3 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=57 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=57 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=57 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=57 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=57 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=57 time=19.4 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=57 time=19.4 ms

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 18ms
rtt min/avg/max/mdev = 19.332/19.406/19.525/0.183 ms

$ traceroute -4 -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1  0.493 ms  0.533 ms  0.513 ms
 2  * * *
 3  * * *
 4  192.119.18.214  2.748 ms  2.173 ms  2.713 ms
 5  149.112.13.42  20.278 ms  20.260 ms  20.240 ms
 6  * * *
 7  8.8.8.8  19.751 ms  19.452 ms  19.467 ms

It did well in terms of consistency, but was 19 ms really a good result for the network latency to the DNS server? That was higher than I expected.

Next I tried another very popular public DNS service, Cloudflare’s 1.1.1.1.

$ ping -4 -n -c 10 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=2.00 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=1.83 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=2.06 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=2.05 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=2.03 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=2.55 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=59 time=2.07 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=59 time=1.93 ms
64 bytes from 1.1.1.1: icmp_seq=9 ttl=59 time=1.92 ms
64 bytes from 1.1.1.1: icmp_seq=10 ttl=59 time=2.08 ms

--- 1.1.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 18ms
rtt min/avg/max/mdev = 1.832/2.052/2.552/0.191 ms

$ traceroute -4 -n 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  192.168.1.1  0.324 ms  0.355 ms  0.338 ms
 2  * * *
 3  * * *
 4  192.119.18.214  2.418 ms  2.493 ms  2.475 ms
 5  149.112.13.27  2.909 ms  3.426 ms  3.311 ms
 6  1.1.1.1  2.392 ms  2.302 ms  2.246 ms

What?!

I did not expect to see a 17 ms difference here. To make it even more extreme, the Google DNS latency is 9X slower than the Cloudflare DNS latency. This is of course only from my house, and this might be a unique situation.

Ping only tries to measure what is happening at the network level. I ran a few DNS queries using dig against 8.8.8.8 and 1.1.1.1, to see if there was any additional overhead for the actual DNS work.

I didn’t notice any change in the Google times, even though I was using made up host names, that were very unlikely to ever have been requested. Google DNS seems to hover around 35 ms for each DNS request, cached or not. There was some varying in cached times for both, the times listed above were by far the most common values.

It seems clear that 8.8.8.8 is being backhauled from Utah to another state. While the 1.1.1.1 responding server was in Salt Lake City, Utah. Google Cloud has a Salt Lake City location, so I had a sliver of hope that this would have turned out better.

Given these differences I’ve switched to using 1.1.1.1 instead of the default 8.8.8.8 as my upstream DNS resolver.

Other Discoveries

While digging around I found a few other things that were new to me.

slix.net - which appears to be the main IX in SLC. Both Google and Microsoft have 200 Gbps connections there.

dns.google - a public site for doing DNS queries with Google 8.8.8.8. Also supports cache flushing, which is interesting to see ( wonder how much abuse that gets ). This has been around since at least mid-2019. I’m surprised I have’t come across it before