这是一个创建于 3400 天前的主题，其中的信息可能已经有所发展或是发生改变。
在家无聊的时候做了些实验，想到些关于Google自己IPv6 CDN原理的问题。。。
首先，家里IPv6网络是隧道，不是原生的。一条去HE的VA路由，另一条去NetAssist的Ukrine路由器。家里的DNS Server是台Relay服务器，不是递归DNS，上级DNS是2001:4860:4860::8888。IP和ASN的whois里面地址都是INDIANA的地址。
我先去家里路由器里把NetAssist那边的Announce和Input都prepend我自己AS 5次，劣化线路。然后“nslookup -query=AAAA google.com”，拿到的地址是Google在Chicago的地址，这样CDN没有任何问题。
然后我反过来，把HE那边的Announce和Input都prepend我自己AS 5次，确保走Ukrine的线路。然后，我“nslookup -query=AAAA google.com”，拿到的竟然还是Chicago的地址。。。我同时也“nslookup -query=AAAA google.com 2001:4860:4860::8888”这样来确保不是缓存问题。。。
之后我也想过，会不会是edns-client-subnet的问题，但是我在Fremont, CA那边Announce的地址就被正确引流到了附近的节点。
所以Google CDN引流背后的逻辑到底是什么呢？Google具体怎么知道用户真正的GeoLocation，如果我使用隧道的话。
第 1 条附言 · 2015-07-24 15:30:04 +08:00
Ukrine线路：
HE线路：
Fremont MTR：
HE线路：
Fremont MTR：
3 条回复 • 2015-07-24 15:29:26 +08:00
 |
1
jasontse 2015-07-24 06:38:35 +08:00 via Android
是不是你的 DNS 先请求了 IPv4 的 8.8.8.8。找台 Route Server 看看确定路由生效后分别 +trace 试试。
|
 |
2
lty1993 OP @jasontse
DNS我确定是请求了IPv6的8888。我的Relay Server上根本没有配置IPv4的8888。 理论上来说Google DNS是根据我连接到的不同地理位置的Anycast的服务器，然后用服务器所在地IP做递归查询的。以上的测试我都是mtr过+level 3 looking glass确保正反向也都生效了的。 Ukrine线路： |
|
3
lty1993 OP Ukrine线路：
 HE线路：  Fremont MTR：  |
Select Language