铁通无差别劫持的问题，以腾讯的关系和资源去推动铁通不劫持腾讯自有业务域名，都推不动，仅在寥寥的几个省解除了劫持。

ip.dnspod.cn 这个 DNSPod 的在线监测，是检测的出口 IP 地址以及 DNS 的后端出口 IP 地址，并不是检测的 DNS 的入口地址。
原理很简单，就是设置多个子域名， ns 指向一个抓包服务器，在网页上检测的时候会对这些子域名进行解析，抓包服务器就抓到了 dns 的后端出口 IP 地址。

@crazyfengs 我们最近在和一些运营商沟通劫持的问题，主要是部分地区移动和铁通，但是即使以腾讯的关系依然收效甚微，囧。

@crazyfengs 能测试下 http://119.29.29.29/d?dn=www.jd.com 的返回结果吗，目前 DNSPod 公共 DNS 对外提供服务的有 53 和 80 （ D+）端口，如果 80 未被劫持的话，我们看看提供的转换程序搭配 dnsmasq 使用。
另外我们正在考虑非 53 端口的支持。
还有楼主能反馈下哪个地区的移动运营商吗，我们通过线下关系找运营商沟通下，看能否解决。

@openbaby 已于 10 月 8 号封网解除后更新了 IP 库，包括 106.0.4.0/22 从福建电信到北京电信的更改。

@loson 能发下域名和出口 IP 吗

@lastczj
@vpnyihao
江西联通和广东电信的递归都已经升级完成，看下现在解析 360 的域名 OK 吗？
今晚到明天可以全网升级完成。

@lastczj 好的，我们把广东电信也提前，预计最晚明天。

@lastczj 江西联通的两台节点已经灰度了一台，目前可以解析了，如果没有问题，下午会灰度另一台。

@johnjiang85 修复版本内部测试截图，在受到 format error 后进行重试会改为不带 ecs 信息。
http://ww2.sinaimg.cn/large/55700cb1gw1ewun67hutsj215o0j7nag.jpg

@lastczj
目前还是有问题的，代码问题已经修复，但涉及的服务器太多，会逐步进行灰度修复，江西联通会在今天优先进行灰度。
http://ww2.sinaimg.cn/mw690/55700cb1gw1ewun67hutsj215o0j7nag.jpg

@d8 经过测试， 119.29.29.29 在所有节点解析 www.banwangong.com 、 banwagong.com 都是正常的，能发下你那里的测试信息吗，如 ping ， dig/nslookup ， mtr/winmtr,traceroute/tracert 等

@lastczj 看 82 楼回复

@vpnyihao 经过联合排查，部分地区无法解析 360 域名的原因已经定位，之后会进行修复。具体原因如下：
1. www.so.com 的解析记录是这样的
www.so.com CNAME so.qh-lb.com
so.qh-lb.com A 140.207.202.254
2. www.so.com 的授权 NS 地址是 ns3/4/5/7/8.360safe.com ，该授权 NS 支持 google ecs 协议，可以对我们后端递归发出的带有 ecs 的查询包正常响应。
3. so.qh-lb.com 的授权 NS 地址是 ns2/3/5/6.qh-lb.com ，该授权 NS 不支持 google ecs 协议，对我们后端递归发出的带有 ecs 的查询包返回格式错误（符合 RFC 协议）
4. 我们自研的后端递归对 2,3 单独出现时都可以兼容，可以正常解析。但是当 2 和 3 同时混合出现时，我们的后端递归逻辑有点问题，再收到 format error 后再次重试还是带着用户的 IP 去向 360 的第二级授权请求，结果总是返回 format error ，最终解析超时。
5. 江西联通的递归节点失败后，路由回退到联通默认递归节点 /全网默认递归节点，我们所有的默认节点都是支持 ecs 的递归，同样有该 ecs 的问题，最终还是超时。
6. 部分地区可以解析的原因是我们的后端递归节点并非全部部署的支持 ecs 的自研递归，有部分与其他业务复用的节点使用的是不支持 ecs 的递归程序，可以正常解析。不支持 ecs 的递归只会处理该省份运营商的解析请求，没有递归节点的省份运营商的解析都是调度到邻近省份相同运营商且支持 ecs 的自研递归进行解析的。这里我们在江西联通，联通默认，全网默认的递归节点部署的都是支持 ecs 的递归，最终造成该问题。
7. 其他类似这样的域名也会遇到该问题。

解决方案：
1. 先在三大运营商默认线路各增加两台不支持 ecs 的递归节点，先解决部分地区部分域名无法解析的问题。
2. 我们已经对递归代码中自动探测授权 DNS 是否支持 ecs 的逻辑着手修改，修改验证完成后会灰度上线。

@lastczj 能发下 dig/nslookup 和 ping 的测试结果吗，我们测试都是正常的。

收到，已确认， 105.0.4.0/22 已经切到北京电信，多谢。
我们的 IP 源里也收集到了该改变，会在下次 IP 库更新中进行更新，目前处于封网期间，会在 10.1 假期之后进行。

@lastczj 刚看到，这个问题当时有其他用户投诉 360 搜索解析很慢甚至有时候无法解析的时候，排查了该问题。具体原因如下。
1. 360 授权 DNS 的其中一个节点宕机
2. 360 授权 DNS 的一个 ns 地址只有一个 IP ，没有其他 IP ，目前 DNSPod 后端递归节点的重试机制是优先向同 NS 地址的其他 IP 进行同时发送查询请求重试。
3. DNSPod 公共 DNS 部分后端递归节点未同时向其他 NS 地址的 IP 发送 DNS 查询请求，当该 ns 地址的 IP 失败后才会向其他 NS 的 IP 进行重试。
4. DNSPod 公共 DNS 用户较少，且使用 360 的用户更少，导致后端递归节点在自我学习并排除异常授权 DNS 节点的速度较慢，时间较长。
5. DNSPod 公共 DNS 的缓存是按照用户 IP 缓存的，不会复用其他地区用户解析出的结果。
以上原因综合导致了部分地区解析 360 的域名有问题，在接到用户反馈后，经过人口多次请求该域名重复测试后，加速了后端递归节点通过自我学习排除掉了有问题的授权 DNS 节点，之后恢复正常。

@xiaoc19 貌似我记混了，重新过了一遍，确实说不会联动。 DNSPod 公共 DNS 不会也无法收集除了用户发过来的 DNS 查询以及应答信息以外的其他任何信息，也就是说获取不到用户的 qq 号或者微信号等相关个人数据。
google 提到和广告相关的就是不存在的域名不会重定向到广告页面(这个 DNSPod 也不会做)，其他没有提到广告等相关内容。
当然如果通过 qq/微信的日志与 Public DNS 的日志进行关联分析，还是可能得到 qq 号 /微信号这些信息的， DNSPod 短期内不会做这些数据挖掘的工作，但是我这里暂时无法承诺以后会不会进行联动。