论最好的 DNS 地址

[janecc]

我这，网络，不同 DNS，分别存在一批打不开的网站，屌的不行

[jasontse]

如果网络奇葩的话就不要有什么念想

[wwc]

我只想说在大陆，没有最好的 DNS，只有合适的 DNS ……

[janecc]

@jasontse 电信光钎 100M

[janecc]

@wwc 有理

[hzw]

用国内的解析，打不开的网站用梯子。
靠解析来解决打不开网站的问题太折腾了，费时费力又不能一劳永逸。

[pifu]

广州移动好像是劫持了 114.114...

[eoxy]

DNS 这个问题不是找一个好 dns 就能解决的，都不是本机一方能彻底解决的
排除墙的干扰,你用 8.8.8.8 就没有 cdn 加速，你用 isp 分配的就有投毒污染
还有各种各样奇奇怪怪的问题
比如二三级小 isp 的 cdn 加速 ip 分配错误
dns 缓存 ip 错误
解析到的 ip 服务器上内容错误
等等等等...

多年来综合遇到的各种情况，我思考的结果是
应该这么来终极解决 DNS 问题：
就是任何网址都解析出所有的 ip 来，包括所有的 cdn 加速 ip，然后在里面根据网速和内容正确性优选最好的来使用
所有的 ip 靠本机自己一端是不可能的获取到的
这就需要用网上一些多点 ip 解析的服务来协助获取
即使这样很多网址也不可能所有的 ip 都获取到比如 www.google.com，只能尽可能多的获取
至少比单一 dns 要多得多，在其中优选出最好的 ip 的概率就高很多了
上面的步骤可能要耗时很长，如果每次解析都这么来一次那是不可接受的
所以还要有各种加速机制，缓存，快速返回结果，后台预解析等等

[asuhe]

感觉 dnspod 的好一点 119.29.29.29
alidns 很多网站都解析失败

[ksmter]

@KCheshireCat 能不能问下，有哪些公共 DNS 支持 EDNS Client Subnet ？

[KCheshireCat]

@imn1 #16 这样抬杠式的安利看了真是只会徒增反感.
@Jesse #12 提出疑问,一般来说不是介绍自己软件的优点吗.贬低对方软件,抬杠,真是没见过的"安利"手段

你提出的 2,3 点 dnsmaq 可以简单的控制,并不是做不到.

那么对比另一个选手 unbound,dnsforwarder 有何优势呢?

所谓的 "多 ip 域名择优" 到底是怎么工作的也没有说明.

是对每个解析结果都发 TCP syn 测一下延时? 还是根据 IP 归属地或者运营商来择优?

看 dnsforwarder 的配置文件,都没有提到,并且也不支持 EDNS Client Subnet.

如果是手动指定某个域名查询哪个上游 DNS 的规则池叫择优的话,那 dnsmasq 也能做到.

最后 "dnsmasq 能 DHCP,你安利的 dnsforwarder 能吗?"

[KCheshireCat]

@ksmter #28

dnspod 的 httpdns 明确支持,udp 查询不是不是支持我没测过
google 的 httpsdns 支持,udp/tcp 查询没有测试过

[KCheshireCat]

@pifu #25

浙江移动现在应该是 53 端口无差别回源了,只要是请求的域名在规则表里,统一全部抢答解析结果.

用 udp port53 解析,你不管换什么 dns 都没用

不知道广州那边是不是这样了

[KCheshireCat]

@eoxy #26

这个是一种解决方法,但是太难实现.

我根据 dnsmasq 的先到先回的特性做了一个简单的优选. /t/350162

以 dnsmasq 作为本地缓存和并发器.

同时向 dnspod httpdns 和远端 google httpsdns 发起查询.

EDNS Client Subnet 分别填 本地 DNS 和 台湾 DNS .

这样,如果有本地 CDN 优化的,dnspod 会比 google 先返回结果.如果没有则会等待 google 查询台湾地区的 CDN 优化结果.

以此绕开移动解析到电信,联通的窘境.

并且绕开了 dns 污染.

[mytsing520]

@KCheshireCat 这个叫域名强解，是由指定网站向移动申请的业务，在全省 UDP53 上面强制下达，要取消这个，得网站单位向移动下达授权书取消业务

[janecc]

@KCheshireCat 你这个轮子，我表示不会用，哈哈

[kiah]

一直用 360 自动选择最优 dns 地址的路过

[KCheshireCat]

@mytsing520 #33

之前我是在微博的图床地址上发现这个情况的,被强解析之后图床用 https 访问会出现协议错误.

用 dnspod httpdns 解析结果则正常,所以我还是不接受这种"优化"了

[mytsing520]

@KCheshireCat 换宽带 233333333

[eoxy]

@KCheshireCat
这样做有的被墙网址仍然无法避免 dns 缓存污染
dns 投毒和 dns 缓存污染是两个概念
投毒是指墙抢先返回假 ip，污染是指国内 dns 在递归查询时被墙投毒，自己已经缓存上了假 ip

如果你 dnspod 已经缓存了 facebook.com 的假 ip，那么查询时先返回的还是它，一样被污染

感觉这个先到先回的特性没有什么意义，还是得判断 ip 的正确性和速度才能最终确定

[KCheshireCat]

@eoxy #38 查询脸书返回的假 IP 在移动的 ip 段里么?不在移动 IP 段里就不会返回,等待远端解析结果,这是我目前想到的最好方法了