专家专栏 | 递归侧DNSSEC错误配置检测能力建设

域名系统（DNS, Domain Name System）作为互联网的核心服务之一，旨在将人类易于识别的域名转换为机器可读的IP地址。DNS采用分层结构，主要包括根域、顶级域（如.com、.org、.cn）以及二级域（如cnnic.cn、北龙中网.网址）等。DNS查询过程涉及多个关键组件：首先是位于域名层次结构顶端的根域名服务器，其负责指向顶级域名服务器。其次是顶级域名服务器，它们管理顶级域名的信息，并指向权威域名服务器。再次是权威域名服务器，提供特定域名对应的IP地址。最后是递归服务器，其接收用户的DNS查询请求，并通过递归查询找到相应的IP地址。

域名系统安全扩展（DNSSEC, Domain Name System Security Extensions）是对传统DNS的安全增强，旨在解决其固有的安全问题，如缓存投毒和数据篡改。DNSSEC通过数字签名和公钥加密技术，确保DNS数据的真实性和完整性。以下是DNSSEC的主要工作原理：首先，域名持有者生成一对公钥和私钥。私钥用于对DNS数据进行签名，而公钥用于验证签名。域名持有者使用私钥对其DNS记录（如A记录、MX记录）进行数字签名。这些签名与DNS记录一起存储在DNS服务器上。域名持有者的公钥作为DNSKEY记录发布在DNS中，以供查询者使用。当用户发出DNS查询请求时，递归解析器不仅获取DNS记录，还获取相应的数字签名和公钥。递归解析器使用已发布的公钥来验证DNS记录的数字签名。如果签名验证通过，则表明DNS数据未被篡改且来自权威服务器。通过这种方式，DNSSEC显著提高了DNS的安全性，确保用户获取到的DNS信息是可信的和未被修改的。

DNSSEC确保DNS数据在传输过程中未被篡改，且确实来自权威服务器，这可以有效防止中间人攻击和数据篡改。通过提供数据完整性和真实性验证，DNSSEC增加了用户对互联网服务的信任，用户可以更安全地访问网站和在线服务。此外，DNSSEC还为其他安全协议提供了基础。例如，DANE利用DNSSEC来存储和验证X.509证书信息，从而增强TLS/SSL的安全性。总的来说，DNSSEC通过增强DNS的安全性，保护用户免受多种攻击，提高了整个互联网的安全和稳定性。

自2010年互联网根区成功签署DNSSEC以来，全球顶级域名的签署进展显著。多数通用顶级域名（如.com、.net、.org）以及众多国家顶级域名（如.cn、.uk、.jp）已部署了DNSSEC。递归解析器的DNSSEC验证支持也取得了显著进展，主要的公共DNS服务提供商如Google Public DNS和Cloudflare DNS已全面支持DNSSEC验证。

DNSSEC体系具有较复杂的结构，仅当从根到叶子的每个签署人以及验证签名的解析器都履行其职责时，DNSSEC才能正常工作。任何环节的错误配置都可能对DNSSEC的安全性及性能产生影响。由于DNSSEC错误配置导致服务不可达的情况时有发生，这不仅影响用户体验，还可能给运营商带来严重的经济损失。因此，当DNSSEC配置错误发生时，递归服务器能否检测并正确判断出错误配置的类型至关重要。

递归侧DNSSEC错误配置检测能力的建设，不仅能够提升互联网的安全性和稳定性，还能促进DNSSEC的普及和正确部署，从而为整个互联网生态系统带来长远的积极影响。这将为提升全球互联网服务的安全性与可靠性提供坚实基础，并推动网络环境的进一步优化。

本研究基于RFC 8914等标准，对DNSSEC的错误配置情况进行了系统分类和梳理。在一个权威域名下搭建了多个启用DNSSEC的子域，并分别为这些子域设置了不同的DNSSEC错误配置。进一步地，本研究对一系列广泛使用且支持DNSSEC的递归解析服务器进行了深入的探测和分析。

通过评估这些递归服务器在探测配置错误的权威子域时所提供的错误提示信息，本研究旨在探测支持DNSSEC的递归服务器对DNSSEC配置错误的检测与响应情况，并根据探测结果提出递归服务器安全能力建设的建议。研究结果将有助于理解当前递归解析器在处理DNSSEC错误配置方面的表现，并为提升其检测和响应能力提供依据。通过这一过程，本研究希望推动递归解析服务器在DNSSEC错误配置检测能力上的改进，从而提升互联网的整体安全性和稳定性。

本研究方案的整体实验思路为搭建支持DNSSEC的权威服务器并划分子域，在其子域分别设置不同的错误配置，再使用支持DNSSEC的递归服务器来验证搭建的子域上的DNSSEC配置，从而探究递归服务器是否有发现DNSSEC错误配置的能力。本文基于RFC8914标准，全面梳理了DNSSEC错误配置的类型，再结合实际可部署情况，最终选择了包括“unsupported DNSKEY Algorithm”在内的八种错误类型。然后，在二级域“iwbtfy.top”搭建了八个三级子域，并在子域上配置不同的错误，同时还设置了一个正确配置的子域作为对照。在数据集的选择上，本文收集了全球范围内的DNS服务器地址，筛选出了3607个支持DNSSEC的递归服务器，并向筛选出来的递归服务器发送对所搭建子域的请求，对返回的日志进行了全面的研究分析，以验证两个问题：一是递归服务器是否能验证错误；二是如果能验证错误，是否可以返回相应的错误。

本研究从（https://public-dns.info）网站下载了一个开源的DNS数据集，该数据集汇集了全球的DNS服务器。然而，由于该数据集并非实时更新，可能存在某些服务器已不再使用但仍包含在数据表中的情况，因此需要对该数据集进行进一步筛选。筛选的标准包括：1. 该DNS服务器是否仍在提供DNS解析服务；2. 该DNS服务器是否为递归服务器；3. 该DNS服务器是否支持DNSSEC。根据这些筛选条件，本文利用DIG工具，编写了Python脚本进行筛选。在最初的13382个DNS服务器中，筛选出递归服务器4869个，最终得到其中仍在提供服务且支持DNSSEC的递归服务器3607个。

在获得上述筛选后的服务器数据后，本文搭建了域名环境。我们注册了域名iwbtfy.top，并在云服务器上搭建了DNS服务器，将该域名的DNS服务器地址指向此云服务器。在云服务器上使用BIND搭建DNS服务器，配置域环境，并为域配置DNSSEC，以提供DNS解析服务。为了方便后续配置及分析更加清晰，我们在此域名下搭建了八个三级子域，分别对应八种错误配置类型，具体配置见表1所示。

本研究编写了批量化检测的Python脚本，向这些递归服务器发送请求，获取返回日志，并将探测结果保存起来。随后，利用Python脚本对数据进行分析并进行可视化展示。在进行检测实验的过程中，由于实验中涉及的DNS服务器遍布全球，网络环境复杂，导致检测日志中出现了丢失数据包的情况。为了降低丢失数据包对实验结果的影响，提高实验的鲁棒性，本研究采用了重复发送探测包的策略。如果出现丢失数据包的情况，会对该服务器重新发送DNS请求。为保证检测效率，我们设定了最大连接请求重发次数为5次。

本次实验首先针对递归服务器是否能够验证DNSSEC配置错误进行了统计分析。如果服务器判断出域名的DNSSEC配置存在错误，就不会解析该域名，即不会返回A记录。相反，如果返回A记录，则表明服务器没有检测到域名存在DNSSEC错误配置情况。我们统计了每个错误类型子域对应的日志中返回A记录的服务器数量。具体统计结果如下表2所示：

对于Unsupported DS Digest Type、Signature Expired、Signature Not Yet Valid、DNSKEY Missing、RRSIGs Missing、No Zone Key Bit Set和NSEC Missing这七种错误，有2%的服务器由于未正确配置DNSSEC检测，仍然返回了A记录。这七种错误在正常解析数量上大致相同。通过对日志信息的分析，我们验证了这些服务器基本上是同一批，它们在每种错误情况下均不具备检错能力。除去这些服务器后，剩余的98%的服务器能够正确检测域名的DNSSEC配置错误，并且不解析域名。值得注意的是，有2%的递归服务器尽管在前期筛选中表明支持DNSSEC，但在实际测试中发现其并不具备验证DNSSEC错误配置的能力。对于Unsupported DNSKEY Algorithm这一特定错误，91%的服务器未能检测出该错误，本文将在后续部分单独分析这一结果。根据以上探测实验结果可以看出，大多数递归服务器能够检测出域名的DNSSEC是否存在配置错误。

通过对八种错误类型的探测结果分析，我们将其划分为三类：

第一类为多数服务器能够检测出的DNSSEC配置错误类型，包括四种错误：Signature Expired、Signature Not Yet Valid、DNSKEY Missing、RRSIGs Missing。例如，RRSIGs Missing错误的检测结果显示，1949台服务器（占全部服务器的54%）返回了该错误，其余服务器则连接失败或返回其他错误。

第二类为服务器能够检测出错误，但无法准确识别具体DNSSEC配置错误类型的错误，包括三种错误：No Zone Key Bit Set、NSEC Missing和Unsupported DS Digest Type。以No Zone Key Bit Set为例，有2096台服务器（占58%）判断出存在错误，但无法返回具体的错误类型（No error code），其返回的其他错误类型也非预期错误。

第三类为一种特殊情况，即Unsupported DNSKEY Algorithm错误。本实验探测该错误时，820台服务器（约25%）返回了error_code，即这些服务器在判断存在配置错误的情况下，仍然返回了A记录，成功解析域名。这种情况源于不同服务器的判错标准差异，有些服务器严格，而有些则较为宽松。对于Unsupported DNSKEY Algorithm配置错误，本实验使用SHA-1算法生成512位长度的DNSKEY，这种较不安全的算法被一些服务器认为是不支持的，从而导致报错。然而，除该报错外，其余验证过程均成功，这些服务器也因此返回了A记录，导致尽管返回错误但仍成功解析域名的情况。多数服务器由于其内部校验机制不严格，认为密钥长度短在可接受范围内，因此并不返回错误。这反映了当前递归服务器对DNSSEC配置分析的规范性不足。

DNS递归服务器能否及时检测域名存在的DNSSEC错误配置并提供提示，对保障DNS安全具有重大意义。本研究通过对八个三级子域配置不同的DNSSEC错误，并使用筛选后的DNS递归服务器向这些子域发送DIG请求，以评估服务器检测DNSSEC错误配置及其具体类型的能力。实验结果表明，除去部分递归服务器可能不支持DIG版本（即出现no_error_code）的情况外，其余绝大多数支持DNSSEC的递归服务器均能验证出DNSSEC配置错误。然而，对于具体错误类型，相当比例的递归服务器无法提供准确的错误配置类型。基于递归侧DNSSEC错误配置检测能力建设的需求，作者提出以下建议：

通过上述措施，能够有效提高DNS递归服务器对DNSSEC错误配置的检测能力，进而增强DNS系统的整体安全性。