为什么无论区域分配如何，Google Cloud Platform 静态 IP 地址都会在反向查找中列出加利福尼亚州山景城? [英] Why do Google Cloud Platform static IP addresses list Mountain View, CA in reverse lookup regardless of region assignment?

问题描述

这个问题是由于 SEO 问题而出现的，但经过进一步研究后，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.

我在 europe-west-1 区域托管了多个站点.每个站点都位于分配有外部静态 IP 的计算引擎实例上.我可以 ping 域/IP，然后让我在英国的同事 ping 相同，并且根据响应时间，很明显 IP 最终会在欧洲解析(可能应该在爱尔兰都柏林).但是相同域/IP 的 DNS 查找会列出加利福尼亚州山景城的 IP?它总是这样出现:xxx.xxx.xxx.xxx.bc.googleusercontent.com.难道这谷歌像一个ISP，然后到欧洲的路由在幕后?为什么在托管实例的数据中心中没有任何 IP 显示为已解析?

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:

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

这三个都是独立的.所有 GCE 实例 IP 地址都有一个 反向 DNS 条目，映射到 xxx.xxx.xxx.xxx.bc.googleusercontent.com.此域在 Google 的控制之下，因此已注册到山景城的总部.

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.

SWIP 记录/WHOIS 条目表示 IP 地址的管理所有权.它的子网.因此，它也注册到了山景城的总部.

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.

这两者都没有反映任何有关将数据包回复到 IP 地址的机器的物理位置，也没有反映数据包如何路由到目的地的决定.

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 拥有一个全球网络.发送到 GCE 实例的数据包将跨越到相对靠近客户端的 Google 网络.由于 Google 维护了大量与全球 ISP 的对等互连，因此大多数情况下，您的数据包最终会在直接来自您的 ISP 的 Google 网络.

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.

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

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.

最后，当讨论 IP 地址的邻近性"或位置时，大多数时候相关指标是延迟或到主机的网络距离 - 而不是地理距离.(虽然地理距离设定了延迟的下限，因为数据包的速度不能超过光速)

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 Cloud Platform 静态 IP 地址都会在反向查找中列出加利福尼亚州山景城?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！