@openbaby 谢谢提醒，经确认，该网段确实为腾讯广东 BGP IP 段，在 DNSPod 标记为广东电信

@openbaby 能具体点吗， 203.196.130.x-203.196.255.x ，经验证这些网段标记为印度，实际 traceroute 跟踪也是印度。腾讯内部系统上也查不到这些 IP 的记录。

天津联通劫持的 8.8.8.8 到自己的递归 DNS 的，早就这样了。

不同家的策略不太一样。但从第二次重试开始，一般是并发的。

127.0.0.1 最近在国内问题很严重，被攻击打的要不能自理了。

@quericy
目前 DNSPod 免费套餐灰度更新了部分服务器，已经可以验证通过 letsencrypt 的证书了。
之前一些其他国内 NS 可以验证通过，但是现在无法验证通过了，主要是 letsencrypt 修改了规则，重新兼容新规则，并申请开通安全防护策略耽误了一些时间。

测试感觉现在 letsencrypt 的验证规则一直在变， 12.09 的最新规则 DNSPod 、 ali 、 XNS 等都无法验证通过了，都报 timed out 错误， DNSPod 这边修改后的解析程序，测试已经可以验证通过，本周将从免费版逐步灰度更新。
主要修改内容有:1. 支持 0x20 encode （ letsencrypt 貌似已经修改了该规则，不再需要了，但是还是会进行支持）. 2.对 CAA 请求进行应答

@lution 现在国内 letsencrypt 解析 timed out 非常多，包括 DNSPod 、阿里等的 DNS 基本都是 timed out ，无法验证通过。 0x20 问题我们是使用国外节点进行测试的。

@xhat
@clanned
关于 letsencrypt 无法验证使用 DNSPod 解析的域名的情况，我们经过排查主要为两个原因造成：
1. 超时错误。
DNSPod 免费服务器最近几天一直持续受到大流量攻击，且中国电信骨干网络出现拥塞，从国外访问 DNSPod 免费 DNS 服务器丢包严重，导致国外 DNS （如 8.8.8.8 ）解析 DNSPod 免费域名异常，该问题目前已基本恢复正常。
2. DNS 验证失败错误.
letsencrypt 在最终验证时使用了随机大小写（ 0x20 encode ）方式进行 DNS 解析请求，以及请求 CAA 记录（可以不支持）。 DNSPod 为了提高解析服务器的性能，以及应对随机大小写方式的 DNS FLOOD 攻击，是没有对该验证方式进行支持的，一律返回小写。我们正在对该问题进行验证，验证 OK 后将尽快更新支持 letsencrypt 。

目前受到的攻击流量相比昨天低很多，虽然从国外访问 DNSPod 免费服务器失败率还是比较高，但相比昨天已经有大幅度缓解。国外的 DNS ，如 8.8.8.8 等解析 DNSPod 免费版已基本恢复正常。
从电信得到的答复“经集团核实骨干网有拥塞，请贵方知悉。”，我们还在进一步与电信确认是否只是骨干网拥塞+我们的 DNS 受攻击导致国外丢包严重，还是因为攻击同时触发了电信的某些防护策略，以防止之后再次出现国外无法解析的情况。
另外最近几天电信骨干网一直有拥塞，可能导致部分域名（不仅限于托管在 DNSPod 的域名）在电信的解析异常。

目前从国外网络访问 DNSPod 免费版解析服务器丢包严重，导致使用国外 DNS 的用户解析免费版域名失败率非常高。
目前排查进度，从国内访问一切正常。从国外直接访问免费 DNS 服务器，联通服务器正常，电信服务器 ping 正常， dns 解析丢包严重。
具体原因待确定，目前怀疑是因为免费版套餐长时间受攻击，电信在国际出口可能加了相关防护规则（如 DNS 限速等），导致国外解析失败率高，目前正在联系电信一起进行问题排查。
在国外网络恢复前，建议用户先使用 119.29.29.29 等国内公共 DNS 。

@gamexg 可以试试 DNSPod 的 119.29.29.29 ，也可以解析 whether.dnspod.cn 来测试看看是否被运营商劫持，如果返回 127.0.0.1 说明被劫持。 119.29.29.29 的用户因为比较少，所以被劫持的情况相对较少，除了部分小运营商将所有 dns 都劫持了。

@20140930 谢谢支持
DNSPod 的授权解析很之前是使用的开源解析程序的二次开发版，并对 DNSSEC 进行了支持，但是因为该功能基本无任何意义（递归都不支持），且大量消耗服务器资源，所以在之后的自研解析程序中以及官网升级中，并未对 DNSSEC 进行直接支持，目前 DNSPod 官网中也都去掉了支持 DNSSEC 的描述。
但是随着这几年的发展， DNSSEC 有了一定程度（虽然很小）的增长，我们也在讨论重新支持 DNSSEC 的可行性和必要性（主要是我们自己也推出了公共 DNS ），目前来看时机尚未完全成熟，主要的原因除了 5 楼说的大部分客户端不支持外，还有一个很重要的原因是目前国内针对 DNS 的攻击非常严重，而如果要支持 DNSSEC ，势必造成解析服务器消耗资源过多，严重影响解析服务器的性能，应答包太大容易被用于反射放大攻击等等问题。
现在 DNSPod 对于支持 DNSSEC 并没有具体的安排，但是不排除在 2016 年进行支持的可能，如果决定要进行支持的话，我们会在授权 DNS 和公共 DNS 进行同时支持，解决我们能决绝的这一部分问题。
由于支持 DNSSEC 来解决 DNS 劫持问题，需要非常多的依赖，并存在很多问题，一直未进行支持。但是我们 15 年推出了 D+(HttpDNS ）的解决方案，虽然大多数时候只能解决 app(客户端）的 DNS 劫持问题，但是相比于 DNSSEC 的可行性还是高不少，而且今后移动互联网毕竟是大势所趋，并且移动互联网的 DNS 劫持问题比 PC 时代更严重一些。

@yetsky
经过测试， t.cn 的授权 NS 是 ns1/2/3/4.sina.com.cn ，这里面比较乱,大概整理如下。
1. 新浪授权 DNS 不支持 ecs ，当请求带了 ECS IP 时，返回结果会在香港 /联通或北京间乱跳，且返回包格式是有问题的（有警告错误）。
2. 当请求包不带 ecs 时，返回结果固定，此处新浪是识别错了我们的江苏联通的递归 DNS 出口 IP （ 153.3.167.13 ），返回了香港结果。
现在两个问题都会导致解析结果可能出错，第一个问题我们会想办法通过修改递归代码兼容新浪的错误格式，认为其不支持 ECS ，之后总是不带 ECS IP 进行请求。
第二个问题，我们只能想办法联系新浪，更新 IP 库，从我们的从新浪过来的同事反馈，他们的 IP 库应该是购买的翼南地址度，且可能很久没更新了，导致识别错误（最新版翼南 IP 库可以正确识别）。

@johnjiang85 经过测试， t.cn 的授权 NS 是 ns1/2/3/4.sina.com.cn ，这里面比较乱。

@yetsky 与接入点无关，并不是总是解析到香港，有时候是解析到新浪北京联通土城机房的，看上去是哪一步缓存的原因。

@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