为什么Google Cloud Platform静态IP地址在反向查找中列出了加利福尼亚州的山景城，而与区域分配无关？

Question

这个问题是由SEO引起的，但是经过进一步的研究，似乎Google感觉到IP /托管位置现在最多只是排名的一个微弱信号。所以现在我只是好奇，因为我只基本地了解网络。

我在europe-west-1地区托管了几个站点。每个站点都在分配了外部静态IP的计算引擎实例上。我可以ping域/ IP，然后让我在英国的同事也可以ping通，根据响应时间，很明显，该IP最终将在欧洲解决（应该是爱尔兰的都柏林）。但是，在相同的域/ IP的DNS查找中，列出了加利福尼亚山景城的IP？总是这样显示：xxx.xxx.xxx.xxx.bc.googleusercontent.com。这个Google是否像ISP一样运作，然后到欧洲的路由却在幕后？为什么在托管实例的数据中心中没有IP显示为解析状态？

Answer 1

听起来您正在混淆三个概念：

• googleusercontent.com反向DNS的域注册
• 子网的SWIP记录
• 到达IP的路由决策

这三个都是独立的。所有GCE实例IP地址都有一个反向DNS条目，该条目映射到xxx.xxx.xxx.xxx.bc.googleusercontent.com。该域受Google控制，因此已注册到Mountain View总部。

该SWIP记录 / WHOIS条目表示一个IP地址RESP的行政权。它的子网。因此，它也已注册到Mountain View的总部。

这两个都不反映有关机器将数据包应答到IP地址的物理位置的任何信息，也不反映有关如何将数据包路由到目的地的决定。

Google拥有全球网络。发送到GCE实例的数据包将穿越相对靠近客户端的Google网络。由于Google在全球范围内与ISP保持着许多对等关系，因此大多数情况下，您的数据包将直接从ISP最终到达Google的网络。

如果您对实例运行跟踪路由，则可能会在反向DNS名称中看到带有机场代码的跃点，尤其是在遍历对等点时。Google内部的啤酒花通常不会进一步暗示地理位置。

最后，当讨论IP地址的“邻近性”或位置时，大多数情况下，相关度量是到主机的延迟或网络距离-而不是地理距离。（尽管地理距离为延迟设置了下限，因为数据包的传输速度不能超过光速）