一般来说权威 DNS 拿到的都是客户端设置的 DNS 的后端出口 IP，除非你使用的递归 DNS 支持 ECS，然而目前绝大部分递归 DNS 都是不支持（少数支持的有 Google 的 8.8.8.8，OpenDNS、我们的 119.29.29.29 等）。

使用以下命令可以获取 DNS 的后端出口 IP 地址

`for i in {1..20};do dig @119.29.29.29 $i.ip.dnspod.net txt +short;done`

如果结果只有一列，则表示指定 DNS 的后端出口 IP 地址；
如果结果有两列，则第一列表示 DNS 的后端出口 IP 地址，第二列表示递归 DNS 向权威 DNS 请求时携带的 ECS IP.

虽然是友商，不过还是介绍下，搜索引擎线路基本上做不到很准确，原因
1. 可能蜘蛛 ip 并不完全准确，不过这个影响很小，从我们自己的实际数据来看，蜘蛛 ip 准确率还是很高的
2. 最重要的原因是 dns 只有蜘蛛的 ip，而没有蜘蛛使用的 dns 的出口 ip 列表；甚至有时候你明明知道蜘蛛使用的 dns 出口 ip，但是如果这个 dns 是个公用 dns，还有很多普通用户使用，那还是无解的。

@stille 扫描 cname 的 a 记录去添加，可以通过 api 自己实现，但是如果作为商业产品对外提供服务，这么做并不够

@stille
CNAME Flattening 部分支持，满足以下条件会直接生效，直接返回 a 记录
0. mx 记录和 cname 记录同时设置
1. 如果 cname 指向的域名都在 DNSPod 并最终解析出 a 记录
2. cname 指向的域名为同域名的不同子域名，或者指向其他域名并开启了 cname 加速

至于为什么没有完全支持 cname flattening，因为靠那有限的节点扫描 cdn 的节点 ip 是不靠谱的

域名检测是实时检测，控制台提示貌似是一天检测一次，影响是好像不能开启 CNAME 加速，其他没什么影响

@HalloCQ 还在测试中，还需要等等 _-_

试了下，貌似是单点的，另外返回的 v4 和 v6 ecs 参数都有问题，如果作为上游会被下游丢包
算是一个开始的尝试

@vsean 催 IP 库相关同事和阿里沟通谁改了。

@HalloCQ 缓存过期后如果这段 IP 先请求，就会缓存 鹏博士，如果是两边 IP 库都是标记为电信的就正常了。

@loson 还得等等，具体多长时间还不能确定

BGP IP 标记为哪个运营商不算有错，只能算是 IP 库不一致，119 认为是广东电信，alicdn 认为是鹏博士。
当 119 缓存过期后，如果是这部分不一致的 IP 段先请求这个域名，119 会使用这个 ip 作为 ecs ip 去 alicdn.com 的权威请求，返回了长宽的结果，119 把这个结果作为广东电信的缓存（目前绝大部分域名都不会使用 source/scope mask 来缓存），在 ttl 期间内就会出错。

这个 IP 实际是一个 BGP IP，我们没有 gzdic 这种小运营商线路，就是识别为电信的，alicdn 貌似是识别为鹏博士，可以探讨下。

谁能呼叫下 alicdn

这个是最主要原因，还有些其他原因

@HalloCQ
@bclerdx

dig g.alicdn.com.danuoyi.alicdn.com @danuoyinewns1.gds.alicdn.com +subnet=58.67.149.0

; <<>> DiG 9.10.6 <<>> g.alicdn.com.danuoyi.alicdn.com @danuoyinewns1.gds.alicdn.com +subnet=58.67.149.0
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43797
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1410
; CLIENT-SUBNET: 58.67.149.0/32/24
;; QUESTION SECTION:
;g.alicdn.com.danuoyi.alicdn.com. IN A

;; ANSWER SECTION:
g.alicdn.com.danuoyi.alicdn.com. 60 IN A 45.253.17.253
g.alicdn.com.danuoyi.alicdn.com. 60 IN A 45.253.17.219

;; AUTHORITY SECTION:
danuoyi.alicdn.com. 86400 IN NS danuoyinewns1.gds.alicdn.com.
danuoyi.alicdn.com. 86400 IN NS danuoyinewns2.gds.alicdn.com.
danuoyi.alicdn.com. 86400 IN NS danuoyinewns3.gds.alicdn.com.
danuoyi.alicdn.com. 86400 IN NS danuoyinewns4.gds.alicdn.com.

;; Query time: 39 msec
;; SERVER: 101.200.28.65#53(101.200.28.65)
;; WHEN: Wed Jul 31 12:16:06 CST 2019
;; MSG SIZE rcvd: 232

该问题已知，表面原因也已经找到，在修改规避该问题，近期会逐步灰度更新。根因还需要进一步排查。

可以搜索 “关于部分用户路由器被黑客攻击影响用户解析的初步说明”，“关于境内大量家用路由器 DNS 被篡改情况通报”，“家用路由器被劫持的分析与应对”等文章，会对该事件有一定的了解，虽然不是全部了解。

春节时候的事情了，可以关注下 DNSPod 公众号有相关文章推送，cncert、派网等公众号也有推送，感染了国内超过 400 万家用路由器。

@Atomo 现在没有，短期内大概也不会有，不是我负责这块的。
当前 ipv6 的互联质量是非常差的，短期内应该只会跟随腾讯云官网提供 ipv6 的控制台访问。