有谁搭建过抗干扰DNS

[mu wei]

如题，这个主要是个人用，希望既能把国内网站解析到国内的CDN上，又能正确解析海外的地址

网上有很多类似的文章，比如有很多是通过TCP方式连接openDNS之类的获取正确IP地址，但是对国内网站来说会解析到国外的CDN上，访问速度很慢

有一些看似不错的文章，多条线路，触发条件就切换DNS，但实际测试发现最后都转到了一个DNS上

有谁搭建过类似的服务，可以介绍一下经验么

[Bojie Li]

On 2014年1月3日, at 上午1:29, mu wei <mw2...@gmail.com> wrote:

如题，这个主要是个人用，希望既能把国内网站解析到国内的CDN上，又能正确解析海外的地址

网上有很多类似的文章，比如有很多是通过TCP方式连接openDNS之类的获取正确IP地址，但是对国内网站来说会解析到国外的CDN上，访问速度很慢

国内网站有国外CDN的不多吧。

有一些看似不错的文章，多条线路，触发条件就切换DNS，但实际测试发现最后都转到了一个DNS上

怎么做？

有一个“西厢计划”，我没用过，好像是假设DNS污染出来的IP在一个固定集合里，如果发现国内DNS解析出的IP在这个集合里，就换用TCP连接海外OpenDNS去解析。

有谁搭建过类似的服务，可以介绍一下经验么

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Yifan Gao]

可以解析后ping一下服务器，如果ping不通则换openDNS，如果被墙了估计也不会有国内节点吧。

[Bojie Li]

很多服务器都禁 ping 的。而且 ping 一下就会增加 DNS 解析的延迟。不过如果污染出来的IP没有规律，也算是一种方案。

[Yifan Gao]

不一定要ping，测试80端口之类的也可以替代，不过毕竟有较大的局限。

[mu wei]

比如人人。以8.8.8.8就会解析出国外的地址。

其他一些网站用8.8.8.8解析出来的地址访问比较慢。

西厢计划我看过，原理并不是排除这种法而是TCP连接混淆。曾经管用过，后来某墙升级以后就失效了，现在的各种版本实质上是走代理而不是直接过滤——于是还是会解析出不合适的地址来。

2014/1/3 Bojie Li <boj...@gmail.com>

You received this message because you are subscribed to a topic in the Google Groups "USTC_LUG" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ustc_lug/zm_lCvC0Z7o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ustc_lug+u...@googlegroups.com.

[Min Peng]

目前在国内的话建议直接用114.114.114.114.

有兴趣的也可以自己配置一下bind，不过国内DNS服务器解析国外的域名被劫持是无解的。有自己的专线可以走专线在国外递归，但是和直接用国外的DNS一样对CDN不友好。

PS： edns-client-subnet这类扩展协议即便自己实现了（或者用8.8.8.8）因为不适合大规模推广所以也没有多大的意思。其实解析到海外的地址了很多时候也不同。。肉身翻墙才是硬道理。。

在 2014年1月3日星期五UTC+8上午1时29分33秒，mu wei写道：

[mu wei]

嗯配过，不过用的unbound。

个人倒是不愁网速的事，几乎不看视频所以无压力。

[Bojie Li]

unbound 是什么？

2014-1-3 下午2:15于 "mu wei" <mw2...@gmail.com>写道：

嗯配过，不过用的unbound。

个人倒是不愁网速的事，几乎不看视频所以无压力。

[mu wei]

http://unbound.net/

不是很有名。

另外问题不打算解决了，因为发现即使DNS正确，用https://，对特定的IP仍然有TCP链接重置。

You received this message because you are subscribed to a topic in the Google Groups "USTC_LUG" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ustc_lug/zm_lCvC0Z7o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ustc_lug+u...@googlegroups.com.

[Min Peng]

确实是这样，目前只要你人在墙内。没有单独到国外的专线的话都是无意义的挣扎。。。

连ipsec加密的也是可以被分析的。。

在 2014年1月4日星期六UTC+8下午1时18分54秒，mu wei写道：

[Bojie Li]

2014-1-4 下午1:18于 "mu wei" <mw2...@gmail.com>写道：
>
> http://unbound.net/
> 不是很有名。

这个主要作用是依靠 DNSSEC 检验？貌似 DNSSEC 只覆盖了根域名服务器和顶级域名服务器，也就是只能保证 NS 是不受干扰的。

刚有个想法，在 bind 递归的时候，如果 nameserver 在国内就直接去查，如果 nameserver 在国外就走VPN去查。国内有CDN的网站 nameserver 也多在国内，这样查出来的就是国内IP。被DNS污染的网站 nameserver 肯定在国外(不然就直接拔线了，不用劳驾GFW)，查出来的是未经污染的IP。做起来也很简单，bind 不设 resolver，从 root 开始自己递归，再加个 chnroutes，让国外IP全部走VPN，就能达到上述目的。

> 另外问题不打算解决了，因为发现即使DNS正确，用https://，对特定的IP仍然有TCP链接重置。

可以让特定的IP走VPN。要能正常上网，DNS防污染和VPN都是必须的。

[Bojie Li]

2014-1-4 下午2:40于 "Min Peng" <bett...@gmail.com>写道：
>
> 确实是这样，目前只要你人在墙内。没有单独到国外的专线的话都是无意义的挣扎。。。

专线就是个有 QoS 保证的 VPN 吧，只要自己买的VPN不被墙，跟专线有多少区别？

> 连ipsec加密的也是可以被分析的。。

这种分析是基于流量特征的分析(识别出你是在看视频还是浏览网页)，还是直接能解密出内容或内容的一部分？

[mu wei]

2014/1/4 Min Peng <bett...@gmail.com>

连ipsec加密的也是可以被分析的。。

基于机器学习的加密流量识别，嗯我记得看见过这篇文章。

不过对一般用户来说意义不大，只要你不惹事没人会找你麻烦（不好意思已经离题了）

不过一般「根本不需要分析出加密的内容是什么」，比方说用xp挂vpn上网的时候会有个DNS泄漏的问题，默认VPN的那个比本地连接优先级低，DNS数据包会在毫不知情的情况下从非VPN途径发出去。比如Chrome预解析特性会发出不经过代理的DNS解析包（虽然可能不影响最终结果，也就是说除非抓包根本看不出存在这个问题）等等数都数不完。

再者哈佛那个不也是个例子，挂一万层代理没用，查学校出口网关日志，谁用了Tor，挨个排查就OK了。

有点离题了。

对于我们这些一般用户来说为了这些折腾半天就确实没必要了。我这里也只是讨论技术问题而已。

[mu wei]

2014/1/4 Bojie Li <boj...@gmail.com>

这个主要作用是依靠 DNSSEC 检验？貌似 DNSSEC 只覆盖了根域名服务器和顶级域名服务器，也就是只能保证 NS 是不受干扰的。

DNSSEC要求对方的Authoritative nameserver采用DNSSEC才行，现在这个还不是很普及，所以用处不大。

做起来也很简单，bind 不设 resolver，从 root 开始自己递归，再加个 chnroutes，让国外IP全部走VPN，就能达到上述目的。

嗯这个好像不错。有时间尝试一下

[wzyboy]

2014/1/3 mu wei <mw2...@gmail.com>:

我 2012 年的时候搭过类似的，在本机搭建的，一直用到现在，挺好用的。当时写了篇文章：
https://wzyboy.im/post/874.html 可以凑合看一下。

其实原理还是挺简单的，就是用 dnsmasq 把 DNS 请求分流，带 CDN 的国内网站域名（有人专门维护这种列表）交由当地 ISP 的
DNS，或者 114.114.114.114 之类的解析，而其他的域名则交由国外 DNS 解析。

这样访问国内 CDN 的时候不会被解析到另外一家 ISP 的机房去，造成龟速访问，而解析受到 GFW 污染的国外域名（如
facebook.com, twitter.com ）的时候，又能解析出正确的地址。

但是 GFW 显然也是会干扰这些发往国外 DNS 的查询的，所以要把这些查询保护起来。保护方法挺多的：

* 走 VPN 隧道。这是最通用的方法，配合 chnroutes 一起用挺方便的。我的电脑常年开着 VPN 所以我就直接这样了。
* 再套一层 pdns(?) 之类的，把所有 UDP 查询转成 TCP 查询。目前 GFW 还不污染 TCP 查询。
* 用 dnscrypt-proxy。这是 OpenDNS 领导的一个开源项目，是把 DNS 客户端和 DNS
服务器之间的查询加密。当然，这是需要服务端支持的。OpenDNS 是原生支持这种加密协议的，如果想用别家的，需要自己搭个 wrapper。

这样配置完之后就是如你所说的国内 CDN 能解析出就近的地址，国外受污染的域名也能正确解析了。

--
wzyboy
Link: https://wzyboy.im/
Twitter: @wzyboy

[Qijiang Fan]

我一個小夥伴去爬了alexa上中國Top多少的站，然後這些域名用國內的dns，其他的掛代理到8.8.8.8

然後用dnsmasq來弄。

Github: https://github.com/felixonmars/dnsmasq-china-list

2014/1/5 wzyboy <wzyb...@gmail.com>

--
-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en

---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Qijiang Fan

[wzyboy]

2014/1/8 Qijiang Fan <fqj...@gmail.com>:
> 我一個小夥伴去爬了alexa上中國Top多少的站，然後這些域名用國內的dns，其他的掛代理到8.8.8.8
> 然後用dnsmasq來弄。


我问过 Felix，他说这个列表不是按照 Alexa 统计的，而是他把这套系统实际部署到公司网关上，然后根据员工反映哪些 CDN 慢而慢慢添加和完善的。

[Qijiang Fan]

On Wed, Jan 8, 2014 at 11:05 PM, wzyboy <wzyb...@gmail.com> wrote:
> 我问过 Felix，他说这个列表不是按照 Alexa 统计的，而是他把这套系统实际部署到公司网关上，然后根据员工反映哪些 CDN 慢而慢慢添加和完善的。

原來如此。沒事，反正能用。

--
Qijiang Fan

[Bojie Li]

这个列表有公开吗？求一份。

[Qijiang Fan]

https://github.com/felixonmars/dnsmasq-china-list/blob/master/accelerated-domains.china.conf

--
Qijiang Fan

[wzyboy]

2014/1/9 Bojie Li <boj...@gmail.com>:
> 这个列表有公开吗？求一份。


Qijiang 不是贴了链接么。。。而且我贴的链接里也有这份列表 -_-

[Zhang Cheng]

挖个坟。

最近gfw污染了一些cdn的域名，比如edgecastcdn.net，间接的导致了所有使用这个cdn的域名都被污染了。

原本我做防污染的方法是，维护一个域名列表，让dnsmasq将这些域名的解析请求都穿墙转发给8.8.8.8解析。但是现在这样的域名太多了，手工维护这个列表太累了。

于是我换了一种方法。

首先是dnsmasq的设置(无关部分省略)：

server=114.114.114.114

server=8.8.8.8

all-servers

这里，为dnsmasq指定了两个默认的upstream，默认情况下，dnsmasq会选第一个upstream，将所有的域名都转发过去。当打开"--all-servers"选项后，dnsmasq会同时向所有的upstream转发请求，并取第一个收到的回复。这个参数通常是用来加速解析的（例如你可以设置多个本地的dns上游，谁快用谁）。所以，在这个设置下，理论下114的响应总是比8.8.8.8要快。

由于gfw的dns污染的目标ip很少（已知的有大概43个，见这里），所以可以用iptables来过滤掉含有这些ip的dns响应。

iptables -N AntiDNSPollution

iptables -A INPUT -p udp --sport 53 -i eth0 -j AntiDNSPollution

cat dns-pollution-list.txt | while read ip; do

iptables -A AntiDNSPollution -m string --algo bm --hex-string "|$(printf %.2x $(echo ${ip//./ }))|" -j DROP

done

这样一来，dnsmasq就收不到被污染的结果了。被污染的域名一定会采用来自8.8.8.8的回复（到8.8.8.8的访问是穿墙的）。

这下依赖，世界就清净了。而且本地的平均DNS解析速度也变快了（因为以前维护的污染域名列表里有大量的错杀，这些错杀的域名也都到8.8.8.8解析所以就慢了）。

--

-- 来自USTC LUG
请使用gmail订阅，不要灌水。
更多信息more info：http://groups.google.com/group/ustc_lug?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "USTC_LUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ustc_lug+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Cheng,

Best Regards

[Armnotstrong]

good job

To post to this group, send email to ustc...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

========================================
best regards & a nice day
Zhao Ximing

[Zhuoyun Wei]

2014-11-26 18:25 GMT+08:00 Zhang Cheng <steph...@gmail.com>:
> 首先是dnsmasq的设置(无关部分省略)：
>
> server=114.114.114.114
> server=8.8.8.8
> all-servers
>
> 这里，为dnsmasq指定了两个默认的upstream，默认情况下，dnsmasq会选第一个upstream，将所有的域名都转发过去。当打开"--all-servers"选项后，dnsmasq会同时向所有的upstream转发请求，并取第一个收到的回复。这个参数通常是用来加速解析的（例如你可以设置多个本地的dns上游，谁快用谁）。所以，在这个设置下，理论下114的响应总是比8.8.8.8要快。
>

思路好赞！

> 由于gfw的dns污染的目标ip很少（已知的有大概43个，见这里），所以可以用iptables来过滤掉含有这些ip的dns响应。
>
> iptables -N AntiDNSPollution
> iptables -A INPUT -p udp --sport 53 -i eth0 -j AntiDNSPollution
> cat dns-pollution-list.txt | while read ip; do
> iptables -A AntiDNSPollution -m string --algo bm --hex-string "|$(printf
> %.2x $(echo ${ip//./ }))|" -j DROP
> done
>
> 这样一来，dnsmasq就收不到被污染的结果了。被污染的域名一定会采用来自8.8.8.8的回复（到8.8.8.8的访问是穿墙的）。

除了用 iptables 过滤掉那些伪结果，dnsmasq 也自带一个 --bogus-nxdomain 选项的。这个选项本意是过滤掉一些
ISP DNS 把不存在的域名返回广告页的解析，还原成本来的 NXDOMAIN 结果。不知用这个选项配合 --all-servers
一起使用，是否能达到类似的逻辑呢？



--
Zhuoyun Wei

[Zhang Cheng]

2014-11-26 22:39 GMT+08:00 Zhuoyun Wei <wzyb...@gmail.com>:

除了用 iptables 过滤掉那些伪结果，dnsmasq 也自带一个 --bogus-nxdomain 选项的。这个选项本意是过滤掉一些
ISP DNS 把不存在的域名返回广告页的解析，还原成本来的 NXDOMAIN 结果。不知用这个选项配合 --all-servers
一起使用，是否能达到类似的逻辑呢？

​这个参数我知道，主要用途就是ISP广告（一些ISP会对不存在的域名解析出广告的IP）。我也考虑过结合--bogus-domain

和--all-servers参数，但是并没有实际尝试过，因为没有找到文档说明这种情况下会是什么效果。不过从直觉上理解，这么

用应该达不到所需要的效果。谁感兴趣的话不妨也试一试，跟大家分享一下结果。​

--

Cheng,

Best Regards

[Zhuoyun Wei]

实验了一下，将 GFW 的假冒解析添加到 --bogus-nxdomain 里之后，配合以 --all-servers
得到的结果是……被污染的域名全部变成 NXDOMAIN 了。。。

看来 dnsmasq 在开启 --all-servers 的情况下虽然会给每个上游服务器都发请求，但是即使得到的是应被过滤掉的解析，它也不会再理会后面的解析。

--
Zhuoyun Wei

[Zhang Cheng]

2014-11-26 23:48 GMT+08:00 Zhuoyun Wei <wzyb...@gmail.com>:

实验了一下，将 GFW 的假冒解析添加到 --bogus-nxdomain 里之后，配合以 --all-servers
得到的结果是……被污染的域名全部变成 NXDOMAIN 了。。。

看来 dnsmasq 在开启 --all-servers 的情况下虽然会给每个上游服务器都发请求，但是即使得到的是应被过滤掉的解析，它也不会再理会后面的解析。

​bogus-nxdomain 的意思是，将某些含有特定ip的响应，转化为“无此域名”的响应。“无此域名”也是响应的一种。

all-servers 的意思是，采纳收到的第一个响应。

假如--bogus-nxdomain + --all-servers能达到我们想要的需求的话，那下面这种情形会怎样？我dig一个不存在的域名，dnsmasq所有的upstream都回复“无此域名”，那dnsmasq是所有回复都不采纳么？​

--

Cheng,

Best Regards

[Zhuoyun Wei]

2014-11-26 23:59 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

假如--bogus-nxdomain + --all-servers能达到我们想要的需求的话，那下面这种情形会怎样？我dig一个不存在的域名，dnsmasq所有的upstream都回复“无此域名”，那dnsmasq是所有回复都不采纳么？​

有道理……

我忘记了 NXDOMAIN 也是响应的一种……

--

Zhuoyun Wei

[mu wei]

最新情况，我们这里（联通）建立了8.8.8.8和8.8.4.4的虚假节点，ping值小于5ms，所以直接向8888查询无论是滤包还是用TCP方式都不起作用，如果你们遇到了类似的情况记得试一下。

[Zhang Cheng]

2014-12-09 10:45 GMT+08:00 mu wei <mw2...@gmail.com>:

最新情况，我们这里（联通）建立了8.8.8.8和8.8.4.4的虚假节点，ping值小于5ms，所以直接向8888查询无论是滤包还是用TCP方式都不起作用，如果你们遇到了类似的情况记得试一下。

​我前面的方案里提到的用8.8.8.8，有一个背景没说清楚，到8.8.8.8的流量走隧道，不直接从ISP出去。GFW对所有出国的DNS流量都进行了污染，无论你的ISP是否做了虚假节点。​

--

Cheng,

Best Regards

[Zhuoyun Wei]

我再来挖一下这个坟。

今天看到有人也在折腾 dnsmasq 试图让它过滤 GFW 伪造的 IP 地址，然后发现有这么个项目：
https://github.com/styx-hy/dnsmasq-chinadns

是一个打过补丁的 dnsmasq，可以读取一个列表，然后过滤掉这些 IP 地址。算是除了 iptables 之外另一种解决过滤方式吧。

> To post to this group, send email to ustc...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.



--
Zhuoyun Wei

[Bojie Li]

2014-12-25 15:47 GMT+08:00 Zhuoyun Wei <wzyb...@gmail.com>:

我再来挖一下这个坟。

今天看到有人也在折腾 dnsmasq 试图让它过滤 GFW 伪造的 IP 地址，然后发现有这么个项目：
https://github.com/styx-hy/dnsmasq-chinadns

是一个打过补丁的 dnsmasq，可以读取一个列表，然后过滤掉这些 IP 地址。算是除了 iptables 之外另一种解决过滤方式吧。

现在 LUG 递归 DNS 过滤 GFW 伪造的 IP 地址用的是 iptables：

https://git.ustclug.org/boj/smartproxy/raw/master/anti-poison.sh

LUG DNS 使用国外隧道解析，但为了避免解析出访问较慢的教育网 IP（LUG VPN 没有教育网线路），部分 CDN 的域名（如 akamai）是通过合肥电信 DNS 和 223.5.5.5 public DNS 解析的，这些 CDN 的域名有可能被污染。基于 “宁可解析不出来，也不要被污染的 IP” 的原则，我添加了过滤伪造 IP 的规则。

[Zhang Cheng]

2014-12-25 16:21 GMT+08:00 Bojie Li <boj...@gmail.com>:

现在 LUG 递归 DNS 过滤 GFW 伪造的 IP 地址用的是 iptables：

https://git.ustclug.org/boj/smartproxy/raw/master/anti-poison.sh

​建议建一个CHAIN，仅将53端口的流量传入这个CHAIN，在这个CHAIN里判断是否污染。你的这个写法，所有的包都需要过一下这几十条规则，用CHAIN的话，那么所有的包只需要过一条规则，进了CHAIN的包才会​过这几十条规则。

​另外，这个似乎在filter表里就能做了，不需要在mangle里面。不知道放在mangle里面有什么好处？这两个表的性能有什么区别我不懂，求教。​

LUG DNS 使用国外隧道解析，但为了避免解析出访问较慢的教育网 IP（LUG VPN 没有教育网线路），部分 CDN 的域名（如 akamai）是通过合肥电信 DNS 和 223.5.5.5 public DNS 解析的，这些 CDN 的域名有可能被污染。基于 “宁可解析不出来，也不要被污染的 IP” 的原则，我添加了过滤伪造 IP 的规则。

​既然没有教育网，那么几个有名的公网DNS不妨都加上去​，我在公司网关上是这样配的：

server=114.114.114.114

server=114.114.115.115

server=223.5.5.5

server=223.6.6.6

server=8.8.8.8

server=8.8.4.4

all-servers

​配合all-servers选项，理论上upstream越多，那么请求的响应速度会是这里面最快的一个，不会更慢。​

--

Cheng,

Best Regards

[Zhang Cheng]

2014-12-25 16:35 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

2014-12-25 16:21 GMT+08:00 Bojie Li <boj...@gmail.com>:

现在 LUG 递归 DNS 过滤 GFW 伪造的 IP 地址用的是 iptables：

https://git.ustclug.org/boj/smartproxy/raw/master/anti-poison.sh

​建议建一个CHAIN，仅将53端口的流量传入这个CHAIN，在这个CHAIN里判断是否污染。你的这个写法，所有的包都需要过一下这几十条规则，用CHAIN的话，那么所有的包只需要过一条规则，进了CHAIN的包才会​过这几十条规则。

​另外，这个似乎在filter表里就能做了，不需要在mangle里面。不知道放在mangle里面有什么好处？这两个表的性能有什么区别我不懂，求教。​

​另外，算是git的一个小技巧吧。对于这种行顺序不敏感的文件，我一般在提交到git里之前会先sort一下。这样将来要维护的话，commit diff会比较短，容易查看。尤其是如果这个项目有多方一起维护的话，干净的diff就更重要了。

--

Cheng,

Best Regards

[Bojie Li]

2014-12-25 16:35 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

2014-12-25 16:21 GMT+08:00 Bojie Li <boj...@gmail.com>:

现在 LUG 递归 DNS 过滤 GFW 伪造的 IP 地址用的是 iptables：

https://git.ustclug.org/boj/smartproxy/raw/master/anti-poison.sh

​建议建一个CHAIN，仅将53端口的流量传入这个CHAIN，在这个CHAIN里判断是否污染。你的这个写法，所有的包都需要过一下这几十条规则，用CHAIN的话，那么所有的包只需要过一条规则，进了CHAIN的包才会​过这几十条规则。

多谢建议，已经改到了一个单独的 CHAIN 里。 

​另外，这个似乎在filter表里就能做了，不需要在mangle里面。不知道放在mangle里面有什么好处？这两个表的性能有什么区别我不懂，求教。​

当时就是随手写了个 mangle，mangle 和 filter 没有匹配方式和性能上的区别，对这些过滤 DNS 伪包的规则来说没有区别。 

LUG DNS 使用国外隧道解析，但为了避免解析出访问较慢的教育网 IP（LUG VPN 没有教育网线路），部分 CDN 的域名（如 akamai）是通过合肥电信 DNS 和 223.5.5.5 public DNS 解析的，这些 CDN 的域名有可能被污染。基于 “宁可解析不出来，也不要被污染的 IP” 的原则，我添加了过滤伪造 IP 的规则。

​既然没有教育网，那么几个有名的公网DNS不妨都加上去​，我在公司网关上是这样配的：

server=114.114.114.114

server=114.114.115.115

server=223.5.5.5

server=223.6.6.6

server=8.8.8.8

server=8.8.4.4

all-servers

​配合all-servers选项，理论上upstream越多，那么请求的响应速度会是这里面最快的一个，不会更慢。​

目前递归 DNS 用的是 bind9 的 forwarders。bind9 不像 dnsmasq 的 all-servers 选项那样向多个 upstream 同时发起请求，而是使用了有点复杂的算法，根据请求响应时间动态调整每个 upstream 的 RTT 估计，RTT 估计越小的 upstream 越可能被用来做 forward。当第一个 forwarder 请求超时后，才会向第二个 forwarder 请求，全部超时后才会自己尝试递归。

由于我们的 DNS 有出国隧道，自己递归是一定能得到 IP 的。我们只是把 CDN 的域名（几千个域名的列表）forward 到电信 DNS，其他的仍然是自己递归。如果一个 CDN 的域名被污染了，根据 iptables 规则，电信 DNS 的响应将被丢弃，bind9 就会超时，然后尝试自己递归，得到一个正确的 IP。这里等待超时的时间正比于 forwarder 的个数，因为 bind9 会逐个尝试。我觉得合肥电信 DNS 加一个 223.5.5.5 稳定性已经足够了，延迟方面再增加 public DNS，也降低不了多少了。

[Bojie Li]

2014-12-25 16:35 GMT+08:00 Zhang Cheng <steph...@gmail.com>:

​既然没有教育网，那么几个有名的公网DNS不妨都加上去​，我在公司网关上是这样配的：

server=114.114.114.114

server=114.114.115.115

server=223.5.5.5

server=223.6.6.6

server=8.8.8.8

server=8.8.4.4

all-servers

​配合all-servers选项，理论上upstream越多，那么请求的响应速度会是这里面最快的一个，不会更慢。​

dnsmasq 的 all-servers 确实不错，bind9 没找到类似功能。

LUG 递归 DNS 有一段时间确实用过 dnsmasq，不过跑了几天就挂了（进程悄无声息的自己退出了），过了一天又挂了一次（内存、CPU 占用均无异常），然后就换成了 bind9。

[Zhang Cheng]

2014-12-25 17:38 GMT+08:00 Bojie Li <boj...@gmail.com>:

dnsmasq 的 all-servers 确实不错，bind9 没找到类似功能。

LUG 递归 DNS 有一段时间确实用过 dnsmasq，不过跑了几天就挂了（进程悄无声息的自己退出了），过了一天又挂了一次（内存、CPU 占用均无异常），然后就换成了 bind9。

​这个比较奇怪，我在公司和家里用dnsmasq用了有2年多了，从来没有碰到过挂掉的情况，当然我这边用户的规模没有LUG的大，最大也就100多个人吧。​

感觉在递归这一项功能上，dnsmasq配置起来比bind9灵活很多。

--

Cheng,

Best Regards

[Bojie Li]

100 多个人也算是很大了……因为大家工作时间都在用，流量估计比 LUG DNS 还多。 

我觉得可能是因为 LUG DNS 暴露在公网上，有人利用 dnsmasq 的漏洞发了一些特殊的请求包导致其崩溃。

[Zhang Cheng]

2014-12-25 18:12 GMT+08:00 Bojie Li <boj...@gmail.com>:

LUG 递归 DNS 有一段时间确实用过 dnsmasq，不过跑了几天就挂了（进程悄无声息的自己退出了），过了一天又挂了一次（内存、CPU 占用均无异常），然后就换成了 bind9。

​这个比较奇怪，我在公司和家里用dnsmasq用了有2年多了，从来没有碰到过挂掉的情况，当然我这边用户的规模没有LUG的大，最大也就100多个人吧。​

感觉在递归这一项功能上，dnsmasq配置起来比bind9灵活很多。

100 多个人也算是很大了……因为大家工作时间都在用，流量估计比 LUG DNS 还多。 

我觉得可能是因为 LUG DNS 暴露在公网上，有人利用 dnsmasq 的漏洞发了一些特殊的请求包导致其崩溃。

那是否可以给dnsmasq加一个监控，发现挂了就自动重启。如果持续挂的时间不超过10s，我觉得大多数人都不会有明显觉察。比如在dns服务器上写个脚本，每秒dig一次，设定1秒超时，如果超时了，就看进程是否存在，不存在就重启，存在可能就是有其他问题，再说。

--

Cheng,

Best Regards

[Zhuoyun Wei]

2014-12-25 17:38 GMT+08:00 Bojie Li <boj...@gmail.com>:
> LUG 递归 DNS 有一段时间确实用过 dnsmasq，不过跑了几天就挂了（进程悄无声息的自己退出了），过了一天又挂了一次（内存、CPU
> 占用均无异常），然后就换成了 bind9。

我也遇到过 dnsmasq 悄无声息死掉的情况。在自己笔记本上只供自己用的话，问题不大。后来我把 dnsmasq 试验性作为公司（400+
员工，每人多台上网设备）的出口 DNS，结果两天就挂了。调大 --dns-forward-max 和 --cache-size
的值也不管用，依然两三天一挂。后来我的一个朋友说他也遇到过这样的情况，dnsmasq 作为公司
DNS，也是两三天一挂，错误日志突然就停了，啥也没留下就默默地死了。

后来也换成了 BIND9，再也没挂过。

--
Zhuoyun Wei

[vonjack]

我一直在用dnscrypt-proxy连opendns感觉速度还行啊。d0wn-sg-ns1这个新加坡服务器还有几个岛国服务器都很快的。

在 2014年1月3日星期五UTC+8上午1时29分33秒，mu wei写道：

[www.le...@gmail.com]

除了抗污染，还要“主动”污染一部分域名，类似hosts的作用
比如现在ustc dns解析google.com到216.58.219.14，要在全局代理情况下才有用。

可以考虑用bind9的Response Policy Zone自定义一部分域名的A/AAAA记录
https://www.v2ex.com/t/239562

unbound也可以通过local-zone自定义一部分域名的A/AAAA记录
https://github.com/CNMan/unbound.conf