@SCGabriel 目前 V2EX 上的帖子中还没有 DNSPod 官方和内部人员发起的，不过各个帖子的回复中有多个内部人员的回复。

的确 Public DNS 的成本很高，不管是机器成本、 BGP 带宽成本、维护成本等等都很高， DNSPod 在不进行劫持的情况下怎么处理这个问题，其实细心的童鞋可以发现 DNSPod 公共 DNS 的 IP 和为移动互联网解析提供的解决方案 D+是一个 IP ，当然后端架构都是一样的了，而 D+企业版是会进行一定的收费的，从而对 Public DNS 的成本有一定比例的摊平，这个成本一般是使用 D+的企业版客户支付，不会转嫁到使用 Public DNS 和 D+的普通用户上，虽然最终我们肯定还是有亏损，但能解决用户的 DNS 劫持问题也值了。

首先， DNSPod 承诺绝不对 DNS 进行劫持和重定向。
综合情况看，这个应该是浙江电信的 http 劫持（ ping 域名得到的 IP 是对的，但是访问会被跳转），这种情况的应对办法对个人来说一般打电话向运营商投诉，报自己的宽带账号，运营商一般会单独解除对你的劫持。
全网情况一般需要想主管部门投诉，如 cnbeta 留的传送门，或者国家互联网应急中心。

@20140930 现在-vc 都已经支持了

C:\Users\fengbojiang>dig @182.254.116.116 www.qq.com +tcp

; <<>> DiG 9.5.1 <<>> @182.254.116.116 www.qq.com +tcp
; (1 server found )
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1039
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.qq.com. IN A

;; ANSWER SECTION:
www.qq.com. 24 IN A 59.37.96.63
www.qq.com. 24 IN A 14.17.32.211
www.qq.com. 24 IN A 14.17.42.40

;; Query time: 98 msec
;; SERVER: 182.254.116.116#53 (182.254.116.116 )
;; WHEN: Mon Sep 07 13:02:00 2015
;; MSG SIZE rcvd: 76

@20140930 使用的 Intel 的 DPDK 开发，对 TCP 支持的不好，使用 nslookup -vc 或 dig +tcp 时可以使用备用 ip 的 182.254.116.116 ，后期主 ip 119.29.29.29 也会增加支持。
C:\Users\fengbojiang>nslookup -vc www.qq.com 182.254.116.116
服务器: UnKnown
Address: 182.254.116.116

非权威应答:
名称: www.qq.com
Addresses: 240e:ff:f040:28::a
59.37.96.63
14.17.32.211
14.17.42.40


C:\Users\fengbojiang>dig @182.254.116.116 www.qq.com

; <<>> DiG 9.5.1 <<>> @182.254.116.116 www.qq.com
; (1 server found )
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1848
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.qq.com. IN A

;; ANSWER SECTION:
www.qq.com. 119 IN A 220.181.138.29

;; Query time: 60 msec
;; SERVER: 182.254.116.116#53 (182.254.116.116 )
;; WHEN: Mon Sep 07 13:00:57 2015
;; MSG SIZE rcvd: 44

@yexm0 这个目前腾讯网络机构的问题，无法解决，深圳电信只能去广州绕一圈， sorry 。。。。

@HFX3389
@lenovo
公开提供的服务，无法防止“不存在”的网站，无法抗 GFW 的污染。

@xuan880 dig 的时候+noedns 试试,现在是没有去兼容仅带了 edns0 优化 udp 包为 4096 大小的请求包，但是支持带 subnet 访问的请求报，这个会改下进行兼容。

https://www.dnspod.cn/Products/Public.DNS ，虽然页面丑了点，不过好用啊。

欢迎使用 DNSPod 的公共 DNS 119.29.29.29 ，支持 edns-client-subnet 的哦

@xuan880 HttpDNS 和 Public DNS 是共用这一个 IP 的，端口不一样，只是因为某些天灾、人祸的原因还没有正式发布 public DNS ，但是内部已经用了很久了。

可以使用DNSPod的公共DNS 119.29.29.29，是支持edns-client-subnet的，即使对应省份运营商没有部署后端递归节点也是可以正确解析的。

移动互联网下的DNS劫持和失败率比传统互联网的问题要更严重一些，DNSPod目前推了一个D+（HttpDNS）用来解决这个问题，详情可以查看
https://www.dnspod.cn/httpdns
SDK:https://github.com/DNSPod/dplus-c，现在还只有C版的，支持linux64和win32；安卓和IOS的SDK开发也到尾声了，很快就会出来
有D+ HttpDNS的问题需要咨询的话可以申请加HttpDNS的QQ群：307246795

1. 首先裸域是可以设置CNAME的，但是根据RFC，如果设置了CNAME就不能设置其他记录，DNSPod现在可以同时在裸域添加MX和CNAME记录，但是在添加CNAME记录的时候会提示与MX记录有冲突。

2. 很多域名会在裸域设置MX记录，导致CNAME和MX记录冲突问题，原因就是17楼@dant提出的问题，如果递归DNS是根据RFC协议，先查找CNAME，再找CNAME值的MX，如果CNAME记录值上没有设置MX记录，这时候就会导致MX失效。如果递归DNS没有按照RFC协议直接查询MX记录，或者在当前递归上没有缓存CNAME记录，那么这时候MX就不会失效。

3. 如果一定要同时设置MX记录和CNAME记录，DNSPod已经开始部署解决方案，可以部分解决CNAME记录和MX记录冲突的问题。

如果用户的CNAME记录链一直到最后的A记录都在DNSPod上解析，并且所有CNAME指向的域名都开启了CNAME加速功能（如果CNAME完全指向本域名的其他子域名则可以不用开启CNAME加速），那么我们在解析CNAME记录的时候会检查该子域名是否设置了MX记录，如果设置了MX记录则直接返回最终的A记录，不再返回中间的CNAME。这样递归上就不会同时存在CNAME和MX记录，从而避免找不到MX记录。

该功能已经在免费套餐上灰度了一段时间，10个节点灰度了2个节点：113.108.80.138和125.39.208.193，预计2个月时间可以全部灰度完成。

具体可以看下面的测试用例，前面两个是已经灰度的情况，第三个是未灰度的情况。
~$ nslookup loveping.xyz 113.108.80.138
Server: 113.108.80.138
Address: 113.108.80.138#53

Name: loveping.xyz
Address: 1.1.1.1

~$ nslookup loveping.xyz 125.39.208.193
Server: 125.39.208.193
Address: 125.39.208.193#53

Name: loveping.xyz
Address: 1.1.1.1

~$ nslookup loveping.xyz 112.90.82.194
Server: 112.90.82.194
Address: 112.90.82.194#53

loveping.xyz canonical name = cnametest.loveping.xyz.
cnametest.loveping.xyz canonical name = cnametest1.loveping.xyz.
Name: cnametest1.loveping.xyz
Address: 1.1.1.1


4. 当然这个方案存在的缺陷也比较明显，就是所有域名都要在DNSPod解析才能解决，那有没有其他解决方案呢，当然是有的。前面说了从RFC来看，应该先查找CNAME，再找CNAME的MX记录。那么对应的解决方案就是让你的CDN厂商在CNAME域名上增加与裸域相同的MX记录，当然如果CNAME到的是自己的其他域名的话，可以自己增加，同时为了兼容未严格按照RFC协议实现的递归DNS，裸域的MX建议继续保留。

这个方案好像非常好，可以完美的解决CNAME和MX冲突的问题，但也只是看上去完美而已，如果你不是大客户的话，CDN厂商没有可能给你单独支持的，因为支持该功能，CDN厂商需要给你分配完全单独的CNAME域名和调度系统，不能和任何其他域名重复，并且在需要修改调度的时候，需要同时修改该CNAME域名的调度，MX记录有修改时也需要联系CDN厂商给你改。而且是每多一个客户，就需要多维护一套，所以小客户是不可能使用的。

最好的方式还是在自己服务器上设置重定向。
如果要用第三方的话，各有优缺点。
像DNSPod的转发服务器放在香港，优点是不需要备案；缺点是国内使用的时候质量很差，当然如果是科学上网的话就可以正常使用了，另外需要转入一个月以上可以使用，主要是为了防止滥用。
像万网、cloudxns之类的服务器在国内，优点是在国内的服务质量比较好，缺点就是必须要备案才能接入。

统一回复下DNSPod问题。
1. 解析稳定性的问题，DNSPod的免费套餐只有在2013年出现过2次短暂的故障，其他时间和其他收费套餐最近这些年（5.19之后）都没有过出现无法解析的故障，如果遇到问题最好是联系我们的技术支持进行排查。
2. 免费套餐攻击防护的问题，我们的套餐说明说虽然说明了不提供防护服务，有攻击就会封禁，但实际上只有违规域名受攻击会被封禁，正常域名受攻击也不会封禁的，而且在部分节点提供了很高限度的防护，攻击流量在30G以内的攻击，基本上大部分地区网站还是可以访问的（视攻击大小和递归的实现方式可能会有一定延迟）
3. 绑定QQ的问题，使用DNSPod并不是强制必须绑定QQ号的，只有使用腾讯系其他服务（比如风铃的移动建站和之后的云主机、CDN等服务）的时候才必须要绑定QQ号，如果不使用这些服务，是可以不绑定QQ号一直使用原有邮箱登陆的。
4. 新免费套餐的功能限制的问题（主要是国外线路、记录导出功能、SEO线路少、免费攻击防护），其实DNSPod是做出了详细的调研分析才确定的，免费用户其实用到的机会非常少，所以在新免费套餐中去掉了。但是因为用户反馈比较多，我们很快会对免费套餐进行调整，除了会支持这些功能外，还会有更多惊喜。

1. D+(HttpDns)主要是解决移动端的解析问题的，当然PC端如果有客户端也可以用，运营商对DNS的劫持还是很多的，包括直接对53端口的请求全部进行劫持等。
2. http劫持的话D+企业版提供了一个对称加密来防止对域名的广告劫持等，https因为在移动端使用https成本太高，所以在评估后选择了轻量级的对称加密。
3. D+的119.29.29.29使用了BGP Anycast，对各运营商来说都是比较快的，会减少劫持到运营商自己的缓存节点情况。
4. 后端的递归节点分布情况可以看这里https://www.dnspod.cn/httpdns/node，还在继续增加中。
5. ECS的话DNSPod授权很早支持的，也是ECS官方机构afasterinternet的会员单位（看这里），目前Google的PDNS支持ECS，国内还没有支持的PDNS.
6. D+很快就会支持了ECS了，彻底解决线路准确性要依赖递归节点部署的情况。
7.D+的119.29.29.29这个IP现在也是可以直接当作Public DNS来用的，但是正是发布会等到支持ECS之后（下半年）。
8.我们只能保证我们不会去污染解析结果，但是在国内做正规的PDNS，对于“不存在”的网站那就没办法了。