共计 1096 个字符，预计需要花费 3 分钟才能阅读完成。
感谢 nnt 大佬的分享
正巧之前有了解过，就尝试来解答一下，纯手打
我们都知道，DNS 的查询过程是个递归的流程
比如说，当你要访问 www.example.com，需要先知道 example.com 的 NS，而这又需要.com 的 NS
整个过程需要几方配合：LDNS、ADNS
LDNS 通常是运营商部署的默认 DNS
当你访问 www.example.com 时，会向 LDNS 查询 www.example.com 对应的 IP 地址，而 LDNS 又会像根 DNS 服务器查询.com 对应的 NS，再通过查询.com 对应的 NS 服务器查询 example.com 的 NS 服务器，最后向 example.com 的 NS 查询 www.example.com 的 IP 地址。在这个过程中，由于 G F W 会抢答最后两步的结果。
而在 查询 example.com 的 NS 服务器 过程中，很神奇的是 G F W 直接返回的是一个 A 记录的 DNS 响应包，并不是 NS 记录的响应包，如此一来，LDNS 便并不会将其缓存起来，如此，每一次发送请求，即使每次都被 G F W 拦截，LDNS 还是回去查询 example.com 的 NS 服务器。与此同时，由于 G F W 的抢答方式的特点，虽然 G F W 通常离 LDNS 更近，处理逻辑也更简单，但有时抢答包可能会比 LDNS 向.com 的 NS 服务器响应的包慢，虽然概率很小很小（<1%），但是通过不断的发 NS 记录的查询包，仍然有概率能够触发，这样一来，我们通过设置较长的 ttl，来让 example.com 正确的 NS 记录能够在 LDNS 中缓存一段时间。
解决了 example.com 的 NS 抢答问题，还需要解决 www.example.com 的抢答问题。首先需要搞清楚，墙部署的位置：出境流量处。因为我们需要向.com 的 NS 服务器查询 example.com 的 NS，而.com 的 NS 服务器在国外，所以会过墙。但通过上一个法子，我们已经将 example.com 正确的 NS 记录缓存到 LDNS 中，如果 example.com 的 NS 服务器在国内的话，那么此查询过程将不会过墙，LDNS 向 example.com 查询其子域 www 的 DNS 包便不会被抢答。
总的来说，此种 DNS 清洗方法的难度特别巨大：由于全国各地的 LDNS 非常多，而且都是不公开的，且有时仅允许同一个运营商的某一篇地区使用，这使得如果你想让全国大部分 LDNS 均能缓存住你的 NS 记录，就只能搜集非常多的 ip，不断地向 LDNS 进行 NS 查询来实现。且缓存是有时间限制的，过期了就会被删除，并不能一劳永逸，想要用多久就要洗多久 …
以上就是我对 DNS 清洗原理的理解。如果不对之处，欢迎指正，以上内容均来源于互联网相关资料搜集整理，非常感谢前人的探索工作。
