DNS 污染的一个讨论。

同求 解决方法

@Toools 哈哈 送礼

大陆是有根服务器的啊。

你这个问题是能正确解析 MX 而不能解析 A 记录？
那你直接向你的权威服务器请求能返回正确的 A 记录数据吗？

要看递归服务器有没有缓存 NS 用 dig 执行一次迭代解析就行了

dig youdomain.com @114.114.114.114 +norecurse

上面 @ 后面的 IP 换成递归服务器的 IP 就好了。

对，我也在想为什么所有的污染的域名全都不会返回 NS 记录。

如果可以返回 NS 记录的话，那么可以采取 NS 国内一台国外一台，NS 所用 DOMAIN 分区解析的方式躲过 DNS 污染。

关键就是不向 NS 查啊。

@Devmingwang 要污染整个域最快的方式当然就是屏蔽 NS 啊
不过我刚刚查了一下，是可以正常查询到 google.com 的域 NS 的，说明你们的域名的污染方式和污染 Google 的方式还是有些不同的啊 (￣▽￣)"

@matsuz Google 没被完全污染，不然这事情后果严重

@mytsing520 嗯，对 Google 的处理方式可能主要还是 IP 黑名单吧。
我刚才试了一下，Google 权威服务器还可以直接查询呢，而且好像也没被劫持

。。我错了，DNS 报文进入大陆的网络的时候应该确实是被劫持了，不过 google\.com 域里面不是每个域名都会被劫持的

楼主的 cdn 系统啥时候上线开卖

@matsuz 可以返回 NS 记录，如果你域名有 MX 记录的情况下

@matsuz 大陆的根服务器仅限 CN 域名。
而且就算 CN 域名同样要过 root-servers.net ，root-servers.net 中国没有。

@eben 卖这个？

@Devmingwang

如果像根查询的时候不返回 NS，伪造根服务器直接返回 A 记录 IP，这样不就彻底封死。直接跳过 NS 查询那个步骤。

@matsuz 直接伪装根服务器返回了假的 udp 包，能直接返回 A 记录，根本不需要向 NS 查询

@holinhot

#12 我在 http://www.root-servers.org 上看到的是中国大陆有 5 台根，这个应该并不是指 CN 顶级域的权威服务器

#11 #14 那你这个可能是只针对了 A 记录进行了污染，可能是通过劫持 DNS 响应包实现的。如果是这样的话，这个估计不好解决了

@holinhot 试试换个子域名看看

向海外任何一个 IP 请求（或者从海外向境内 ip 请求）都会被 gfw 抢答，不管是请求的是 a 记录，ns 记录，还是 mx 记录。。防火墙没有污染 google.com ，污染的是 www.google.com 这个子域名。。正常向根服务器查询 www.google.com 的 a 记录，根服务器会返回 google.com 的 ns 记录。。然而防火墙直接伪装抢答了一个错误的 a 记录，isp 的 dns 直接将这个错误的 a 记录缓存下来返回给用户。。。我测试请求 www.google.com 的 mx 记录也会被污染的。。。

@txydhr 是的，入境的 DNS 数据包都会被检测一遍。但是是发现请求了特定的一些域名才会抢答（或劫持？）

@matsuz 是的 估计为了提高性能，防火墙不区分源 IP 是境外还是境内（入境还是出境），也不管目标 ip 是否有效。。只要发往 53 端口的 udp 包通过 gfw 时。。匹配上特定域名直接抢答。。毕竟抢答你得速度快。。比如你在境外向国内任何一个 ip 地址查询那些域名，都可以收到被污染的解析结果。。

@matsuz 大陆的 2010 年后早就停了，你没听说？

@holinhot #21

听说?自己不会试一试?

@KCheshireCat 反正我路由过去是到日本

@KCheshireCat

看来像撤销宣告了。

@geekzu 你用阿里云节点去测？

@geekzu 中国这啥垃圾根哦，名义上放中国，实际绕到国外再回国？
我测试了 10 几个点都是出国的，用 ping.chinaz.com 一看那值 100 多都去日本美国了

@holinhot 国内的根是镜像服务器

对 192.5.5.241 的 MTR 结果：
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.16.1 - 0 | 6 | 6 | 0 | 0 | 1 | 1 |
| 183.157.x.x - 0 | 6 | 6 | 1 | 1 | 2 | 1 |
| 61.164.12.30 - 0 | 6 | 6 | 2 | 2 | 2 | 2 |
| No response from host - 100 | 1 | 0 | 0 | 0 | 0 | 0 |
| 202.97.68.161 - 0 | 4 | 4 | 24 | 275 | 1031 | 24 |
| No response from host - 100 | 1 | 0 | 0 | 0 | 0 | 0 |
| 18.254.120.106.static.bjtelecom.net - 0 | 1 | 1 | 31 | 31 | 31 | 31 |
| 18.254.120.106.static.bjtelecom.net - 0 | 1 | 1 | 31 | 31 | 31 | 31 |
| 218.241.107.94 - 0 | 6 | 6 | 24 | 24 | 24 | 24 |
| 218.241.107.94 - 0 | 6 | 6 | 24 | 24 | 25 | 24 |
| f.root-servers.net - 0 | 6 | 6 | 29 | 29 | 30 | 29 |
|________________________________________________|______|______|______|______|______|______|

测试环境：杭州电信