为什么Google云端平台静态IP地址不管区域分配如何，都会反向查询Mountain View，CA？ [英] Why do Google Cloud Platform static IP addresses list Mountain View, CA in reverse lookup regardless of region assignment?
问题描述
这个问题是由于搜索引擎优化问题引起的，但是做了一些进一步的研究，似乎谷歌认为IP /托管位置现在是排名的一个微弱信号，至多。所以现在我只是好奇，因为我只熟悉基本的网络。
我在欧洲西部1区域拥有多个网站。每个站点位于计算引擎实例上，并分配有外部静态IP。我可以ping通域名/ IP，然后让我在英国的同事ping相同，并根据响应时间很清楚知识产权最终在欧洲解决（可能应该是爱尔兰都柏林）。但是，对同一个域/ IP的DNS查找列出了加利福尼亚州山景城的IP？它总是像这样：xxx.xxx.xxx.xxx.bc.googleusercontent.com。这个Google是否像ISP一样行事，然后到欧洲的路由是幕后？为什么没有一个IP显示为在托管实例的数据中心解决？解析方案
这听起来像你在混淆三个概念：
这三者都是独立的。所有GCE实例IP地址都有一个映射到xxx.xxx.xxx.xxx的反向DNS条目 .bc.googleusercontent.com。该域名由Google控制，因此在山景城注册到总部。
SWIP记录 / WHOIS条目表示IP地址的管理所有权。其子网。因此，它也在Mountain View的HQ上进行了注册。
这两个都不反映机器将IP地址回复到IP地址的物理位置，数据包被路由到目的地。
Google有一个全球网络。到GCE实例的数据包将跨越到距离客户端较近的Google网络。由于Google维护了大量与全球ISP的对等，因此大部分时间您的数据包将最终结束在您的ISP的网络上直接访问Google的网络。
如果您为您的实例运行traceroute，您可能会看到在其反向DNS名称中使用机场代码跳转，特别是在遍历对等点。 Google内部的跳跃通常不会在地理位置提供任何进一步的帮助。
最后，当讨论IP地址的接近度或位置时，大部分相关度量的时间是到主机的延迟或网络距离 - 而不是地理距离。 （尽管地理距离为延迟设定了一个下限，因为数据包不能比光速快）
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?
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)
这篇关于为什么Google云端平台静态IP地址不管区域分配如何，都会反向查询Mountain View，CA？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
