Urle Sistiana

fast_forward 本意就是不用bootstrap，让用户手动指定 dial_addr IP。按作者的意思是如果一个DNS服务器IP会变则它不适合作为DNS服务器。 DNS服务器的IP不应该随意变。所以大的DNS服务商自服务正式上线起，没有谁的IP变过。所以不停解析一个不变的域名没意义。 > dial_addr 可临时解决这个问题但是不能解决IP变动问题 即使服务器自身的IP变了，AdGuardHome 本身bootstrap也没有自动更新的能力，会直接不可用，除非手动重启。boot strap，只管 boot，不管更新。

DNS.PUB 确实变过 IP，应该是内测的时候。现在 1.12.12.12 / 120.53.53.53 IP 应该已经定死了。 > 循环解析，resolver 还有双栈多 IP 问题。 以前和作者讨论过。 1. 如果让系统取解析域名，系统自身就带有很完善的resolver 。双栈自带选择，多 IP，实时更新，这些问题都能帮你处理，如果让 mosdns 去实现这些功能，很麻烦，是造轮子，而且最后肯定没系统自带的好。比如 AdGuardHome 虽然看起来支持多 IP，给人一种会自动选择最优 ip的感觉。但其实就是简单的一个IP连不上后继续试下一个IP。如果第一个IP永远也连不上，比如失效了，则接下来每次连接都要hang一段时间。所以 fast_forward 选择用系统去解析。 2. 即使网关本身也要使用mosdns解析，避免循环解析也不难。可以用 docker，给容器指定一个 dns...

> 调研了一下，golang设计导致想要每个客户端custom一个dnsresolver还是很麻烦的，后续都得维护，估计作者也不会接受这样的PR, 目前看 bwrap 还是最经济的方案，但是需要主机支持fs namespace 是，golang runtime 这部分很抽象不好自定义。linux 好处理，win跟mac不容易。作者之前似乎动过手，有代码但还没完成... 他最近很忙.... https://github.com/IrineSistiana/mosdns/blob/main/pkg/upstream/bootstrap/bootstrap.go 我觉得可以先实现 linux 上的 bootstrap，因为是用的go runtime，实现很容易，而且网关基本上都是 linux，有刚需。其他平台可以以后再说。

我有空开个 PR。

v5 已实现。

v5 支持外部数据导入记录。

无计划。 “自动使用延时最低的IP”这个功能看上去很美好。但实际上没作用。大 CDN 已经帮你把网络优化到极限了。烂的 CDN 即使你自动选择了延时低的接入点，线路差，该多慢还是多慢。延时不能说明速度。 四舍五入真的没什么用。

新版本已实现。

RFC7871 https://www.rfc-editor.org/rfc/rfc7871#section-7.1.1 的意思应该是“附加的 ECS 的请求如果收到 REFUSE ，用无 ECS 的请求重试”