NXDOMAIN-Query技术

　　梁锦津等人利用NXDOMAIN-Query方法来测量从解析器到不同域名层级的延迟问题。NXDOMAIN-Query法的主要想法是通过利用不存在的域名控制递归解析器停留在特定域级上。此外，NXDOMAIN-Query利用新的、不存在的域名作为每个请求，以避免缓存的负响应。例如，要测量从一个解析器到根域名的延迟，通过在客户端的一个包含着新的、不存在的TLD作为DNS查询发送到解析器。当解析器收到这个查询要求，解析器会对根服务器提出请求，然后解析器接收NXDOMAIN响应并利用NXDOMAIN应答对客户做出回应。假设Tc-root是从客户处观察到的整个查询延迟时间，Tc-root是解析器和根服务器之间的延迟时间，Tc-r是在客户机和解析器之间的延迟时间，Tc-r可以通过解析器发出的非递归查询请求来测量。随之，可以通过Tc-root=Tc-root-Tc-r公式来估算Tr-root。同样，也可以测量从解析器到TLD的的DNS查询延迟时间。

　　NXDOMAIN-Query方法具有一定局限性，这种方法只允许测量从选定的解析器到一组服务于特定的DNS域名的DNS服务器的的整体延迟时间，而不是测量一个特定的DNS服务器的整体延迟时间。原因在于不同的解析器执行不同的服务器选择策略，这些选择策略无法间接控制。

　　King技术

　　作为NXDOMAIN-Query方法之上的补充技术，通过选定的解析器对一个特定的DNS服务器，利用king技术来间接测量DNS查询延迟。King技术的基本思想方法是通过指明一个可控域命名服务器的IP地址来欺骗递归解析器去查询任意指定的IP，然后估计在解析器和被观测的RTT内的特定IP地址之间的延迟时间。

　　测量方法和结果

　　利用前面介绍的方法，通过测定在根服务器和TLD水平上的整体查询延迟，以及在不同地区的每一个13个根服务器的查询延迟，来调查地理分布对于顶级域名服务器的影响。还分析比较了在不同洲际之间临近F根和L根服务器的anycast的差异。

　　在根服务器和TLD层次结构的查询延迟

　　利用NXDOMAIN-Query方法评估了根服务器和通用的TLD的整体查询延迟。对于收集的每个开放解析器，各自测量了它对于根服务器、.com/.net，.org的查询延迟。为降低测量噪声，在两天时间内对于每个解析器连续进行超过500次的查询延迟测量并使用中间值作为一个解析器的最终延迟时间数据。

　　梁锦津等人研究结果发现：1.一般顶级DNS服务器为互联网用户服务高效，根服务器具有一个约20.26ms的中度延迟，对于.com或.net延迟时间约为42.64ms，对于.org有39.07ms的延迟时间。2.服务质量不均，欧洲和北美服务质量最好，而在非洲和南美洲的服务质量却比欧洲和北美糟糕3~6倍。3.与其他地区比较而言，大多欧洲和北美的根服务器表现良好，只有F根、J根、L根服务器显示出具有较低的延迟问题。4.对于F，L根，只有60%的查询被路由到最近的根服务器，表明F根、L根服务器存在延迟问题。

　　导致长时查询延迟的原因

　　梁锦津等人观察到一群开放解析器(共664，占全部解析器的3.2%)在访问根服务器和TLD时持续显示长时的查询延迟(超过2秒)。这些开放解析器对于根服务器，查询延迟在6~18秒之间；而对TLD，查询延迟在4~6秒之间；.com/.net和.org的查询延迟在6~12秒之间。

　　对于这些存在查询延迟问题的解析器探测后，可发现两个原因导致这种长时查询延迟：一种是与IPv4/IPv6双栈主机相关的存在漏洞的特定的解析器所致，另外是在与过滤大DNSSEC或分片DNSSEC应答被路径上的中间设备过滤所致。

　　与IPv4/IPv6双栈相关的设备缺陷

　　首先，重点关注解析器到达根服务器经常消耗18秒的延迟问题。利用fpdns工具来收集这些解析器的信息，发现几乎所有解析器都在BIND9.2上运行。为了观察这些解析器的解析过程，梁锦津等人建立一个具有3个域名服务器的测试域，并驱使存在查询延迟问题的解析器通过查询它们在测试域的子域来访问这些由我们控制的服务器。

　　发现每次输入一个新的IPv6地址到glue记录，便会产生额外增加2s的查询延迟。可推断这种长时的延迟与域名服务器的IPv6地址有关。在13个根服务器中的9个根服务器均配置了IPv6地址，这导致解析器需要大约18s才能贯穿到根服务器。同样，2个.com/.net和6个.orgTLD服务器也使用IPv6地址，这导致分别产生4~12s的延迟。进一步调查源代码后证明在BIND9.2x运行IPv4/IPv6双栈主机总偏好授权给IPv6地址，即便无法查找服务器名称。新版本的BIND（≥9.3）已经修正这个问题

　　过滤DNSSEC应答

　　除了上述已说明的长时延迟外，其余大多是6s左右的查询延迟。再次利用fpdns工具，发现其余大部分有问题的解析器是在BIND9.3x上运行。研究者也让这些解析器去查询他们自行命名的那些服务器并观察其行为。

　　梁锦津等人注意到，利用DNSSEC配置的测试域名服务器，便会产生6s的查询延迟的结果。通过观察自行命名的域名服务器后，发现解析器首先通过EDNS0连续发送3个查询请求，每个查询请求间隔2s；随后发送一个无EDNS0的查询请求收尾。由于DNSSEC可用，对于最初发送的前3个EDNS0查询请求的响应包含了DNSSEC记录，这些DNSSEC记录超过512字节。文章作者推断大的DNSSEC响应包被路径上的中间设备过滤，最终导致产生6s的查询延迟结果。