A few days ago I was doing a little bit of a research into our new potential client. Something got me confused for a second. The client is based in Switzerland and they only serve Swiss market, therefore seeing this was a surprise:
DNS servers in United States for a company that operates only in Switzerland? I mean, it will work just fine, but surely it's not optimal and therefore I wanted to put this (moving DNS servers to Switzerland or at least somewhere in Europe) as a recommendation for the client. To back my recommendation I wanted to provide some example of a latency difference between a server in US and server in CH. So the first thing I did was to execute ping to one of the above IP addresses and here's where the mystery/confusion started:
~60ms round trip from Switzerland to US? I don't think that's physically possible. You see, network packets travel with the speed of light. Now, the speed of light as we all know it is ~300k m/s but that's in vacuum. In copper wires it's more or less 2/3 of that and in fiber-optic cables it varies between 2/3 (yes! there are some poor optic wires that give you roughly the same speed as copper) to 4/5 for high quality fibers. Therefore we can only achieve about 200k m/s.
So, let's calculate the distance and check if that 60ms ping is physically possible. Unlike Switzerland, United State is a huge country therefore we need to narrow down where our server is because 4000km (distance between east and west coast of US) is already quite something. For checking physical location of any given IP address I usually use www.iplocation.net because they show data from multiple sources. So, let's check the results for 22.214.171.124:
All data sources give exactly the same location so we can be quite confident to use that in our calculation. So, now, using distancecalculator.net (could as well just use google maps for that) we can see that there is ~9500km between me and Mountain View:
Time for a simple math then. We can get the minimal THEORETICAL latency by simply dividing distance by speed so in our case that would be 9500km/200000km/s which gives us 0.0475s which is 47.2ms. Now, this is ONE WAY latency which also assumes that there is a direct optic fiber connection between my PC and our mysterious DNS server. Of course, that is not the case and moreover, unfortunately I only have 5G internet at home which means my latency to anything is a little bit higher than a typical home internet. Needles to say, 60ms ping (which is the round trip time) is physically not possible.
So, what is going on? Are 5 different data sources lie about the physical location of our server? Highly unlikely. Let's investigate a bit more. We know that the server in question belongs to Google and we know that it servers as a DNS server. Let's check GCP Cloud DNS documentation...
Most of the information of course focuses on how Google Cloud DNS works (it works just like any other DNS server so nothing interesting here), but already on the bottom of the Overview page we can find "Performance" section which quickly solves the mystery:
ANYCAST! HA! Quite smart and if you thing about it not surprising, really. If you never heard of anycast, it's a routing mechanism (just like standard unicast and more common multicast) that allows for single IP address to be shared by multiple devices (servers) in multiple locations. And yes, you guessed it right, the main point of anycast is simply performance. If you ever heard of CDNs it's a similar concept but on a network level (L3). So, basically, multiple servers can advertise the same IP address, and routers will direct packets addressed to that IP to the nearest instance (according to the metrics used by the routing protocol in use, usually hop count or latency).
So, there you have it. Turns out that our server is actually not in Mountain View but somewhere closer :)