使用 8.8.8.8 在 SG 机器上 部分 google 域名解析会到国内

[infinityv]

在某台位于 SG 机器上使用的 DNS 服务器是 8.8.8.8 1.1.1.1

最近发现一些域名，比如：（域名前面代表次数 可以忽略）

• 11276 safebrowsing.googleapis.com
• 1199 www.gstatic.com
• 1112 ssl.gstatic.com
• 465 update.googleapis.com
• 409 fonts.googleapis.com
• 377 fonts.gstatic.com
• 232 clientservices.googleapis.com
• 109 googleads.g.doubleclick-cn.net
• 87 www.googletagmanager.com
• 73 www.google-analytics.com
• 66 connectivitycheck.gstatic.com
• 38 www.googleadservices.com
• 37 redirector.googlevideo.com

通过 8.8.8.8 解析，拿到的结果是 CN 的； 通过 1.1.1.1 解析，拿到的就都是 US 的；

我的一些分析和猜测：

• fonts.googleapis.com 这些域名本身确实在北京有节点（大概率是事实）
• 1.1.1.1 并不支持 ECS ，所以并不会就近解析；
• 8.8.8.8 支持 ECS ，这台 SG 机器和某些 CN 碰巧在一个自治域内。国内用户（通过国内 DNS ）查询后，cdn 返回了国内的 ip ，同时这个请求被当前自治域的公共 dns 缓存。所以当国外用户查询（即使通过 8.8.8.8 ）的时候，公共 dns 就直接返回了缓存的国内 ip ，从而导致这个问题。

目前感觉除了替换 DNS 8.8.8.8 没有别的方案，话说有没有适合 SG 的本地的 DNS 服务器啊。 （ smartdns 里面配置用，SG 节点供应商未提供自己的 DNS 服务器）

[by]

你的新加坡 IP 可能是被 Google 送中了

试试
129.250.35.250
129.250.35.251

[infinityv]

@by 差不多就是第三点 被放在一个 AS 下了么。

这俩我试了下 和 1.1.1.1 差不多 都直接解析到 US 了。

因为 smartdns 会缓存最快的解析记录，所以感觉除非把 8.8.8.8 移掉 不然感觉一直有这个问题。好难顶

我的 SG 机器应该是套路云 SG 的节点 确实可能 AS 不干净

[gentrydeng]

既然你都在用 SmartDNS 了，也知道 ECS 。那为什么不直接指定一个地理位置能被正确识别 ECS ？

https://pymumu.github.io/smartdns/config/edns-client-subnet/

发帖之前建议先自行查看程序文档来解决问题，而不是靠凭空想象。

而 1.1.1.1 不支持 ECS 不代表它就不是“就近解析”，只是依赖任播。
如果你的服务器访问 1.1.1.1 是被分配到 Cloudflare 新加坡节点。那么自然是通过 Cloudflare 新加坡节点进行 DNS 请求，这也是就近解析。

相反，支持 ECS 也不代表就是“就近解析”，因为 ECS 是可以被设置（伪装）的。

[yyzh]

g 家 dns 会送中很正常
4 条 1 如果解析到的是真位于美国的 ip 那就很不正常

[dream0689]

@yyzh 我遇到过 op 说的这种 4 个 1 解析到其他地区的情况。一般是商家没有把 cf 任播类地址路由调到当地的 ix 或者运营商出口跟 cf 直接 peer ，我当时是 sg 的机器走 singtel 到了 hkix ，延时 200ms+，这种情况使用 4 个 1 很多时候解析不仅慢还会返回 hk 解析结果，后来发工单找技术支持调路由到他们的 EQX SG 路由解决问题了。不过如果 op 所说 us 解析结果是在 SG 的广播地址，那是没有问题的。

[dream0689]

楼主可以参考一下这个网站 https://publicdnsserver.com/singapore/
根据你的机器出口选择适合你的 subnet 。网站上的 dns 地址也可以试试。我平时用来测试内地到海外运营商的路由。

[yyysuo]

ecs 给 vps ip 就行了。

[infinityv]

@dream0689 @gentrydeng 分开说哈。8.8.8.8 这个解析到国内 意思是即使我的公网地址即使物理位置在 SG ，但是 google 认为这个地址的 subnet 就是 CN 的么。

另外 1.1.1.1 Anycast 我明白，我说的意思有一些偏差，因为我对 ECS 是有一些误解。 现在看来 这个 SG 的机器被拿到的 1.1.1.1 广播地址看来也不对，这种应该是只能找厂家调路由出口吗

[mytsing520]

/t/1081627

这里有答复

[infinityv]

综合看目前应该是没被送 中

[dream0689]

@yyysuo 谷歌把 SG 的机器 ip 识别为 CN ip ，这个只能向谷歌提交反馈，谷歌说是一个月会调整，但也未必，基本无解，也就是这位朋友 @yyzh 说的被送中了。所有谷歌系都会被指向 CN 区域。这种情况尽量不要使用 4 个 8 进行解析。我的 SG 机器 ip 被识别成了 HK ip ，所以 gemini 之类的都用不了。油管的广告也是 HK 的。

你要先 trace 一下到 4 个 1 看走哪出的，如果不是从 sg 出的，再联系技术看不能调。但就算调了，也只是意味着 4 个 1 能就近解析了，谷歌系的解析 ip 结果也会是最近的，但服务区域仍将是 CN 区域的。


@mytsing520 基本上遇到的都是类似的情况。

问题的根源其实是机器 ip 不是原生 ip ，ip 注册地、注册公司、实际使用地(或是 gps 定位)三者不一致。

[infinityv]

@dream0689 我现在其实油管啥的都能正常被识别为 SG 区。只是四个八的解析不对劲。 是不是可以说我的谷歌系服务没被送中，但是谷歌 dns 四个八 给我松中了

[dream0689]

@infinityv 服务区域还在 SG ，就表示目前还没被送中。那应该改下机器的 dns 地址或者 smartdns 改一下 subnet 值就行了。如果要用 4 个 1 就在机器上 trace 一下，如果绕了就尝试寻求技术调一下路由。

[infinityv]

@dream0689

[NextTrace API] preferred API IP - 172.67.155.192 - 149.19ms - Misaka.HKG
IP Geo Data Provider: LeoMoeAPI
traceroute to 1.1.1.1, 30 hops max, 52 bytes payload
1 *
2 *
3 10.54.243.133 * RFC1918
3.11 ms / 6.34 ms / 3.14 ms
4 *
5 116.251.66.230 AS45102 [Taobao] 中国 浙江 杭州 alibabagroup.com
3.90 ms / 3.05 ms / 2.96 ms
6 162.158.160.192 AS13335 [CLOUDFLARENET] 新加坡 cloudflare.com
3.05 ms / 2.86 ms / 3.05 ms
7 162.158.160.171 AS13335 [CLOUDFLARENET] 新加坡 cloudflare.com
7.98 ms / 45.92 ms / 47.26 ms
8 1.1.1.1 AS13335 CLOUDFLARE.COM cloudflare.com
one.one.one.one 2.51 ms / 2.54 ms / 2.53 ms
MapTrace URL: https://assets.nxtrace.org/tracemap/3ebd426d-3e79-5004-9ee5-eb400e67409d.html



[NextTrace API] preferred API IP - 104.21.40.176 - 564.56ms - Misaka.LAX
IP Geo Data Provider: LeoMoeAPI
traceroute to 8.8.8.8, 30 hops max, 52 bytes payload
1 *
2 11.73.1.57 * DOD
53.09 ms / * ms / * ms
3 10.54.243.189 * RFC1918
2.72 ms / 2.65 ms / 2.85 ms
4 10.102.31.193 * RFC1918
2.54 ms / 2.48 ms / 2.47 ms
5 47.246.115.222 * 美国 加利福尼亚 San Mateo
* ms / 52.95 ms / 58.91 ms
6 116.251.72.54 AS45102 [Taobao] 新加坡 alibabagroup.com
2.40 ms / 2.46 ms / 2.55 ms
7 142.251.254.17 AS15169 [GOOGLE] 新加坡 about.google
3.60 ms / 6.21 ms / 3.59 ms
8 72.14.232.107 AS15169 新加坡 about.google
3.19 ms / 3.18 ms / 3.21 ms
9 8.8.8.8 AS15169 GOOGLE.COM about.google
dns.google 2.69 ms / 2.72 ms / 2.71 ms
MapTrace URL: https://assets.nxtrace.org/tracemap/c4589c98-8c04-573a-a98b-7ec08292e333.html


感觉虽然都绕路了一下 但是最终跳都在 SG 很奇怪为啥 DNS 解析就是完全不对劲

[mytsing520]

路由上的绕路与否，与他们数据库里认定你的 IP 送中，没有必然关联

[dream0689]

@infinityv 从延迟看，两个地址都没绕，4 个 8 应该只是对机器 ip 识别的问题，会有给其他区域解析结果的可能。4 个 1 是递归解析，应该没问题，你看到的 us ip 解析结果，不等于服务器在 us ，得看延迟。sg 到 us 延迟 180ms 左右，或许你看到的解析 us ip 结果 ping 只有几 ms ，那就只不过是 us ip 在 sg 使用而已。

[infinityv]

@dream0689 确实，理解了你的意思。目前看 1.1.1.1 的解析没有任何问题，虽然拿到的解析 ip 归属美国（好像不少谷歌 ip 都注册在他的 LA 总部） 但是其实应该是在新加坡用 时延都非常低。 四个 8 我制定了一个 DigitalOceal 家的 SG DNS Subnet 之后看着也没问题了。

[Pig930]

借楼问一下最近发现的一个奇怪现象，访问同样的 Google 搜索，Chrome 就会认为我的 IP 在香港，Safari 会认为我的 IP 在美国。Clash 分流是把 Google 分流到美国的 IEPL 节点了，Tun 模式也是开着的，看 log 在用 Chrome 的时候也没有被分流到香港节点的请求，非常百思不得其解

[Tianao]

我们客户有两条新加坡线路，一条去另一条绕比利时……