我有一个查询延迟的差异。 这不是一个问题，这让我很担心。
两者都连接到同一个家庭路由器。 但是，服务器可以parsing非caching查询几乎两倍的速度。 这不是我所期望的！ 服务器是一个1Ghz的ARM（sheevaplug），而客户机是一个2.1Ghz的Intel Core Duo。
两个实例都validation了DNSSEC。 他们返回SERVFAIL为www.dnssec-failed.org。 两者都configuration为使用来自ISP的相同上游DNScaching。
我所能想到的只是NAT的一些问题。 路由器被configuration为服务器“默认DMZ”，即它得到任何其他人没有声称的数据包，这就是我如何运行公共服务，如SSH和bittorrent :)。 或者…也许小版本-19比小版本-17更严格地validation，在某种程度上？
testing方法：parsing.de的10个不存在的子域。 （应该导致ISPcaching未命中）。 .de。 TLD是通过查询雅虎预先加载的。
从客户端
$ for i in 1 2 3 4 5 6 7 8 9; do sudo unbound-control reload; (dig yahoo.de.; dig twitter$i.de.) | grep Query; done Result - mean 120ms, stddev 60ms 从服务器端
$ for i in 1 2 3 4 5 6 7 8 9; do sudo unbound-control reload; (dig yahoo.de.; dig aldi$i.de. ) | grep Query; done Result - mean 70ms, stddev 50ms
我知道，这个testing看起来不太好，而且我的统计数据可能不是绝对的证据。 但是我又试了几次，看起来没有什么不同。
啊! 我只是在两台计算机之间分配unbound.conf。 看来，Fedora开启了下面的选项。 closures它可以消除Fedora机器上的额外延迟。
# Harden the referral path by performing additional queries for # infrastructure data. Validates the replies (if possible). # Default off, because the lookups burden the server. Experimental # implementation of draft-wijngaards-dnsext-resolver-side-mitigation. harden-referral-path: yes
我将不得不看这个，并决定是否要使用它:)。
链接： https ： //datatracker.ietf.org/doc/draft-wijngaards-dnsext-resolver-side-mitigation/