这是一个创建于 3405 天前的主题，其中的信息可能已经有所发展或是发生改变。
递归时如果得到了多个 NS ，会选择哪一个查询？是随机还是会自动挑选延迟最低的？
如果每个 NS 绑定了多个 IP ，恰恰选择的 NS 的 ip 挂了，接下来是向这个 NS 的其他 IP 查询，还是向其它 NS ？
如果每个 NS 绑定了多个 IP ，恰恰选择的 NS 的 ip 挂了，接下来是向这个 NS 的其他 IP 查询，还是向其它 NS ？
 | 1 anjunecha 2016-09-06 00:42:32 +08:00 via iPhone  1 will randomly select one or multiple NS |
 | 2 mytsing520 PRO 随机 |
 | 3 HIT100 2016-09-06 08:20:14 +08:00 随机，不一定分配延时小的解析节点。 |
 | 4 xcodeghost 2016-09-06 08:20:41 +08:00 在进行递归查询时， Local DNS 是如何选择权威 NS 服务器的呢？ BIND ：请求 RTT 时间（从发起查询请求到接收到回应的时间）越小，该权威 NS 被选择的几率越大 和 RTT 值有关。 |
| 5 HIT100 2016-09-06 08:34:56 +08:00 lv3ns1.ffdns.net lv3ns2.ffdns.net lv3ns3.ffdns.net lv3ns4.ffdns.net 就比如 cloudxns 的 4 组 NS 服务器，虽然有海外解析节点，但不一定海外用户解析请求就能分配海外解析节点的。随机的，况且又不是 Anycast |
 | 7 johnjiang85 2016-09-06 10:09:08 +08:00 2 相关协议中有 RTT 延时选择机制及算法，开源的 BIND 和 UNBOUND 也曾经使用过，但是目前这两个开源的更多的是使用随机选择 IP 的方式，而不是根据 RTT 延时机制去较大概率选择质量好的 IP ，较小概率选择质量差的 IP 。质量差的 IP （即使是完全无应答的 IP ）也会去选择是因为网络总是在变化的，有可能之前较差的慢慢变好，根据算法会调整每个 IP 的选择到的概率， BIND 和 UNBOUND 中的 RTT 延时算法是按照 RFC 实现的，但是在实际的使用中， DNS 选优效果并不好。 DNSPod 的 119.29.29.29 的后端递归也使用了 RTT 延时机制，基本思想参照 RFC 的思想，但是算法经过了优化，可以测试不同 IP 的质量，并线性调整各 IP 的权重。 第二个问题差不多，会随机去选择一个或多个 NS 的一个或多个 IP 去重试，根据递归的不同，选择也会有所不同，重试时同样会有第一个问题了选择哪个 IP 的问题。 |
 | 8 txydhr 2016-09-09 20:33:55 +08:00 我觉得不必太纠结这个，因为 dns 查询稍微超时就立刻换下一个 ip |
 | 9 loggerhead 2016-11-05 11:36:54 +08:00 @johnjiang85 正好最近两天在考虑改进 shadowsocks 的客户端，通过一种机制去选择最优的服务器（低延时、低丢包），想到了你说的「根据 RTT 延时机制去较大概率选择质量好的 IP ，较小概率选择质量差的 IP 」。但是你又提到「 BIND 和 UNBOUND 中的 RTT 延时算法是按照 RFC 实现的，但是在实际的使用中， DNS 选优效果并不好。 」。 有点不明白效果不好的原因是什么？如果我按上面说的方法去改进 shadowsocks 会有用吗？ |
| 10 johnjiang85 2016-11-07 20:03:50 +08:00 1 @loggerhead RFC2988/6298 有相关内容， bind 部分版本是极大概率选择 rtt 最短的 IP ， unbound 一搬是在最短 RTT 相差 400ms 以内的都认为是质量较好的 IP ，从而平均选择。这里有篇论文可以参考下，有分析。 |
| 11 johnjiang85 2016-11-07 20:04:19 +08:00 1 |
| 12 loggerhead 2016-11-07 22:41:29 +08:00 @johnjiang85 谢谢！ |
Select Language