@yetsky 深圳的接入服务器确实返回了错误的结果，上海和天津的正常，我们看下。

@d8 有黑产专门做这个的，建议自己在 DNSPod 添加域名并管理。

@yetsky
使用江苏联通的 IP 向 119.29.29.29 进行 httpdns 和 dig 测试结果都是正确的，能测试下你那里的出口 IP 吗

http://119.29.29.29/d?dn=t.cn&ip=221.6.246.1
dig @119.29.29.29 t.cn +client=221.6.246.1

; <<>> DiG 9.9.3-P2 <<>> @119.29.29.29 t.cn +client=221.6.246.1
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41322
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; CLIENT-SUBNET: 221.6.246.1/32/24
;; QUESTION SECTION:
;t.cn. IN A

;; ANSWER SECTION:
t.cn. 5 IN A 123.125.106.196

;; Query time: 32 msec
;; SERVER: 119.29.29.29#53(119.29.29.29)
;; WHEN: Mon Nov 09 14:03:56 CST 2015
;; MSG SIZE rcvd: 61

@woocean
@MOxFIVE
从描述来看无法确定具体问题，建议联系 DNSPod 客服进行排查，我个人也有 xyz 域名， DNSPod 免费版，未发现过此类问题。
另外加不加路径 /cart.php ， about/等与 DNS 没有关系， DNS 只负责解析域名本身，路径由 web 服务器进行处理。

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

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 的逻辑着手修改，修改验证完成后会灰度上线。