一秒解决 DNS 污染问题，给用 windows 的最省事最懒的方法

好东西，感谢楼主分享

cdn 肯定有问题啊

@GPU
@fcicq

我也是看了 10 楼的方法才知道方法……原来竟然是这样玩的。简单来说，就是在 n.yiz.me 这个域名配置了一个 NS 服务器，所以它和它的子域名都将向那个 NS 服务器发起查询请求，也就实现了这个我们看着莫名其妙的东西。

重点在于 n.yiz.me 配置了单独的 ns 服务器
重点在于 n.yiz.me 的子域名全部靠那个 NS 服务器来解析
重点在于 增加了 n.yiz.me 后缀（在电脑里做好设置后，所有域名查询请求就自动加了 n.yiz.me 后缀），墙的域名匹配规则就匹配不到了 就不存在劫持了 所以可以正常解析了

但是我仍然没搞懂，虽然没改变 DNS 服务器（电脑端），怎么就能查询到最近的服务器了，难道请求不是全部发往 n.yiz.me 来做查询吗？全部由 n.yiz.me 解析？那它怎样知道每个电脑端最近的服务器是哪个呢（因为需要楼主的服务器代为查询吧？）？表示不解。

探半个身子到墙外没什么意义啊，直接 SS 出去 DNS 远程解析啊。

@yeyeye 所以我说 cdn 肯定有问题啊，说没问题那真的成了黑科技

@yeyeye 因为对于无污染的域名，仅返回 cname 而不是递归查询，接收到 cname 之后，运营商的 dns 会自己查询 cname 的 ip 。这是标准的 dns 协议行为，所以能够正确返回 cdn 的地址。

@21grams 你说有问题你就试试看嘛 反正我觉得理论上是很正确 你说的 CDN 问题确实不可能存在

@pagxir 对了， DNSPOD 一直说 cname 记录和 mx 记录有冲突，只能二选一，所以这里其实是有坑的对吧。

@yeyeye 那你从理论上解释一下不存在的理由是？ 你自己都说没搞懂，但又这么肯定不存在？

@pagxir 恩。。。 lz 这个的确是个新思路，我比较好奇 lz 怎么配置的，能分享下么。
n.yiz.me 独立一个 ns 记录， ns 到自己的服务器是么_(:з」∠)_
然后自己的服务器用的应该是标准的递归 dns ，关于搜索域这块怎么配置呢~
@21grams 这个真不存在, 真的黑科技。

解析过程如下

root@web1 [~]# dig +trace qq.com.n.yiz.me

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> +trace qq.com.n.yiz.me
;; global options: +cmd
. 361365 IN NS h.root-servers.net.
. 361365 IN NS k.root-servers.net.
. 361365 IN NS e.root-servers.net.
. 361365 IN NS j.root-servers.net.
. 361365 IN NS m.root-servers.net.
. 361365 IN NS b.root-servers.net.
. 361365 IN NS l.root-servers.net.
. 361365 IN NS f.root-servers.net.
. 361365 IN NS a.root-servers.net.
. 361365 IN NS c.root-servers.net.
. 361365 IN NS d.root-servers.net.
. 361365 IN NS i.root-servers.net.
. 361365 IN NS g.root-servers.net.
;; Received 228 bytes from 114.114.114.114#53(114.114.114.114) in 186 ms

me. 172800 IN NS a2.me.afilias-nst.info.
me. 172800 IN NS ns.nic.me.
me. 172800 IN NS d0.cctld.afilias-nst.org.
me. 172800 IN NS b2.me.afilias-nst.org.
me. 172800 IN NS a0.cctld.afilias-nst.info.
me. 172800 IN NS ns2.nic.me.
me. 172800 IN NS b0.cctld.afilias-nst.org.
me. 172800 IN NS c0.cctld.afilias-nst.info.
;; Received 503 bytes from 192.5.5.241#53(192.5.5.241) in 112 ms

yiz.me. 86400 IN NS dns9.hichina.com.
yiz.me. 86400 IN NS dns10.hichina.com.
;; Received 83 bytes from 199.254.62.1#53(199.254.62.1) in 172 ms

n.yiz.me. 43200 IN NS ns1.keziwo.com.
;; Received 61 bytes from 140.205.228.13#53(140.205.228.13) in 25 ms

qq.com.n.yiz.me. 50 IN CNAME qq.com.
qq.com. 50 IN A 125.39.240.113
qq.com.n.yiz.me. 50 IN A 61.135.157.156
;; Received 121 bytes from 167.160.166.177#53(167.160.166.177) in 217 ms

root@web1 [~]#


可以很明显的看到， lz 的 qq.com.n.yiz.me 返回的是一个 cname 值， cname 为真实的域名 qq.com ，根据 dns 协议，如果是 cname 别名，递归 dns 会再次深度递归，直到返回 a 记录，也就是只要保证原本的 cdn 没问题，并且调度正确或者支持 edns ， lz 这个也基本不受影响。

对于被劫持的 ip ， lz 的做法则是采用直接劫持返回值，解析过程如下
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>> +trace youtube.com.n.yiz.me
;; global options: +cmd
. 361218 IN NS h.root-servers.net.
. 361218 IN NS k.root-servers.net.
. 361218 IN NS e.root-servers.net.
. 361218 IN NS j.root-servers.net.
. 361218 IN NS m.root-servers.net.
. 361218 IN NS b.root-servers.net.
. 361218 IN NS l.root-servers.net.
. 361218 IN NS f.root-servers.net.
. 361218 IN NS a.root-servers.net.
. 361218 IN NS c.root-servers.net.
. 361218 IN NS d.root-servers.net.
. 361218 IN NS i.root-servers.net.
. 361218 IN NS g.root-servers.net.
;; Received 228 bytes from 114.114.114.114#53(114.114.114.114) in 169 ms

me. 172800 IN NS ns.nic.me.
me. 172800 IN NS d0.cctld.afilias-nst.org.
me. 172800 IN NS a0.cctld.afilias-nst.info.
me. 172800 IN NS a2.me.afilias-nst.info.
me. 172800 IN NS b0.cctld.afilias-nst.org.
me. 172800 IN NS b2.me.afilias-nst.org.
me. 172800 IN NS c0.cctld.afilias-nst.info.
me. 172800 IN NS ns2.nic.me.
;; Received 496 bytes from 192.228.79.201#53(192.228.79.201) in 399 ms

yiz.me. 86400 IN NS dns9.hichina.com.
yiz.me. 86400 IN NS dns10.hichina.com.
;; Received 88 bytes from 89.188.44.88#53(89.188.44.88) in 365 ms

n.yiz.me. 43200 IN NS ns1.keziwo.com.
;; Received 66 bytes from 42.120.221.13#53(42.120.221.13) in 36 ms

youtube.com.n.yiz.me. 299 IN A 216.58.216.46
;; Received 74 bytes from 167.160.166.177#53(167.160.166.177) in 226 ms

也就是直接劫持到正确的 ip 上，在这个情况下是会影响 cdn 的调度的。

@yeyeye 是有冲突的，两者都配置会导致 DNS 解析出现不可预期的行为， CNAME 会覆盖 MX 记录，得到的是 CNAME 的 MX 记录，而原来的 MX 记录像没有配置过一样。

https://www.cloudxns.net/Support/detail/id/6.html

@21grams 他解释之后我就明白了，简单说就是所有域名查询都加上了一个域名后缀，相当于全部发到他的服务器去解析了，如果被墙域名（他做个列表检测一下），就转发域名（去掉后缀）请求到 8.8.8.8 ，返回的记录又转发给用户，实现解析被墙域名。

那么不被墙的域名又要如何解析呢？它不转发，直接返回一个 cname 记录，记录所指的就是你请求的域名本身（没有后缀），然后你的 DNS 服务器会去查询这个 cname 记录的值，然后返回给客户端。
dig tanronggui.xyz.n.yiz.me
n.yiz.me NS 服务器返回
tanronggui.xyz.n.yiz.me. 1308 IN CNAME tanronggui.xyz.
v2ex.com NS 服务器返回
tanronggui.xyz. 642 IN CNAME v2ex.global.zgslb.net.
zgslb.net NS 服务器返回
v2ex.global.zgslb.net. 1799 IN CNAME v2ex.edge.zgslb.net.
zgslb.net NS 服务器再返回
v2ex.edge.zgslb.net. 9 IN A 23.251.124.132
v2ex.edge.zgslb.net. 9 IN A 23.251.96.131
v2ex.edge.zgslb.net. 9 IN A 23.251.124.131
v2ex.edge.zgslb.net. 9 IN A 23.251.126.133
v2ex.edge.zgslb.net. 9 IN A 23.251.100.132

解析完毕
从 tanronggui.xyz 开始 都是交给回给你本地的 DNS 服务器去代为查询了，使用的域名记录也是该域名本身，所以 CDN 不会出问题啊 并不是 n.yiz.me 的服务器在代为查询，最后返回 IP 给程序，搞定。

唯一我觉得有异常的地方就是说了很多年的 cname 和 mx 记录有冲突，所以可能导致点毛病，不知道它这个会不会有影响

神奇。。

@ovear 曾经写的一个 C++小程序，之前公布过，不过那时不是很稳定，也没什么人关注。这两天，刚好有空，发现有这么有趣的玩法，所以修改了实现方式增加对 CDN 的支持。

@pagxir 哈哈 原来是自己写的，不是标准递归 dns 呀。膜拜_(:з」∠)_，我之前也写了个，然后还有很多问题，也没公布。
总之谢谢 lz 显啦~

@pagxir

nslookup -q=mx v2ex.com.n.yiz.me
没有返回 mx 记录

nslookup -q=mx v2ex.com
返回了 mx 记录

这就是传说中的坑。没猜错的话， cname 只会转发 a 记录，其他记录不管。

@21grams 这种东西没公布的时候是黑科技，但是一公布了，会这方面编程的都能随手写一个程序来做，简直是……我咋就刚好不会呢……

36 楼 补充

应该是只返回 a 记录和 aaaa 记录

@yeyeye 我不是说他整个这个是黑科技，这个东西 N 年前就有人做了，原理一望便知。 我唯一疑惑的是按我的理解这肯定有 cdn 问题，但如果按上面说的，其实只是返回一个 CNAME 的话，倒也解释的通了。

@ovear 看 dig 的输出， qq.com.n.yiz.me 除了返回 cname 是 qq.com 外， qq.com 的 ip 也返回了呀，这种情况还要再次递归查询 qq.com 吗？