Why do Google Cloud Platform static IP addresses list Mountain View, CA in reverse lookup regardless of region assignment?

Question

This issue came up as a result of SEO concerns, but having done some further research, it seems Google feels that IP/hosting location are now a weak signal for ranking, at best. So now I'm just curious, as I'm only familiar with networking on a basic level.

I have several sites hosted in the europe-west-1 region. Each site is on a compute engine instance with an external static IP assigned. I can ping the domains/IPs and then have my colleague in the UK ping the same and based on response time it's clear that the IP is ultimately resolving in Europe (probably Dublin, Ireland where it should be). But a DNS lookup of the same domain/IP lists the IP in Mountain View, CA? It always comes out like this: xxx.xxx.xxx.xxx.bc.googleusercontent.com. Is this Google acting like an ISP, and then the routing to Europe is behind the scenes? Why do none of the IPs show as resolving in the data center where the instances are hosted?

Answer 1

It sounds like you are conflating three concepts:

• The domain registration for the googleusercontent.com reverse DNS
• The SWIP record for the subnet
• The routing decision to reach an IP

All three are independent. All GCE instance IP addresses have a reverse DNS entry that maps to xxx.xxx.xxx.xxx.bc.googleusercontent.com. This domain is under Google's control and therefore registered to the HQ in Mountain View.

The SWIP record / WHOIS entry denotes the administrative ownership of an IP address resp. its subnet. It's therefore also registered to the HQ in Mountain View.

Both of these do not reflect anything about physical location of the machine answering packets to an IP address nor the decisions on how packets are routed to the destination.

Google has a global network. Packets to a GCE instance will cross over to Google's network relatively close to the client. Since Google maintains a lot of peerings with ISPs worldwide, most of the time your packets will end up on Google's network directly from your ISP.

If you run a traceroute to your instance, you might see hops with airport codes in their reverse DNS names, especially when traversing peering points. The hops internal to Google usually do not hint any further at geographical location.

And finally, when the "proximity" or location of an IP address is discussed, most of the time the relevant metric is the latency or network distance to the host - not the geographical distance. (Although geographical distance sets a lower bound for latency as packets cannot go faster than the speed of light)