抗量子域名系统：全面的系统级研究

域名系统 （DNS） 在互联网基础设施中发挥着基础性作用，但其核心协议仍然容易受到量子对手的入侵。随着与加密相关的量子计算机成为现实威胁，在后量子时代确保 DNS 的机密性、真实性和完整性势在必行。在本文中，我们提出了一项全面的系统级研究，研究了三种广泛部署的机制中的后量子 DNS 安全：DNSSEC、DNS-over-TLS （DoT） 和 DNS-over-HTTPS （DoH）。我们提出了后量子加密 （PQC）-DNS，这是一个统一的框架，用于在传统、后量子和混合加密配置下对 DNS 安全进行基准测试。我们的实现利用开放量子安全 （OQS） 库，并将基于格和哈希的基元集成到 BIND9 和 TLS 1.3 堆栈中。我们正式确定了性能和威胁模型，并分析了后量子密钥封装和数字签名对端到端 DNS 解析的影响。在容器化测试平台上的实验结果表明，基于格的基元（如基于模块格的密钥封装机制 （MLKEM） 和 Falcon）提供了实用的延迟和资源配置文件，而基于哈希的方案（如 SPHINCS+）则显著增加了消息大小和处理开销。我们还研究了安全影响，包括降级风险、碎片漏洞和拒绝服务放大的敏感性。我们的研究结果为部署量子弹性 DNS 提供了实用指南，并为保护后量子未来核心互联网协议的更广泛努力做出了贡献。

域名系统 （DNS） 是互联网的基本基础，它将人类可读的域名转换为互联网协议 （IP） 地址，并促进所有现代网络通信。但是，最初的 DNS 协议在设计时并未考虑安全性，因此容易受到多种攻击。常见威胁包括 DNS 欺骗（或缓存中毒），攻击者将虚假的 DNS 记录注入解析器的缓存中，DNS 放大攻击，一种分布式拒绝服务 （DDoS） 形式，利用 DNS 服务器向目标发送流量，以及 DNS 劫持，查询被重定向到恶意服务器（胡代布和胡代布，2014).在过去的二十年中，已经开发了许多 DNS 安全扩展和增强功能，即域名系统安全扩展 （DNSSEC）、基于 TLS 的 DNS （DoT） 和基于 HTTPS 的 DNS （DoH），以减轻欺骗、篡改和监控等威胁（Abirami 和 Naresh，2024) （Sengupta 等人，2024).DNSSEC 通过数字签名提供数据完整性和源身份验证，从而防止缓存中毒和类似攻击。DoT 和 DoH 提供加密的传输机制，以保护 DNS 请求和响应在传输过程中免受窃听和数据纵。这些协议共同构成了当前 Internet 生态系统中安全 DNS 解析的支柱。

但是，所有三种协议的安全性都取决于经典的公钥加密原语，最常见的是 RSA、ECDSA 和 X25519，众所周知，它们容易受到量子攻击。一旦量子计算机可以大规模部署，像 Shor 这样的算法将使这些密码系统过时，并使 DNS 容易受到隐私和完整性问题的影响（Aydeger 等人，2024).

为了应对这种新威胁，人们对后量子密码学 （PQC） 的兴趣日益浓厚，这种加密算法旨在抵御来自量子计算机的攻击。尽管标准化工作正在进行中，尤其是美国国家标准与技术研究院 （NIST） 的标准化工作，但使这些新原语适应 DNS 基础设施是一项重大挑战。DNS 是一个性能关键型系统，对消息大小、延迟和兼容性有严格的限制。MLDSA、Falcon 和 SPHINCS+ 等后量子签名方案虽然可以抵御量子对手，但可能会引入更大的密钥和签名或增加计算开销，这可能会影响 DNSSEC 保持效率和互作性的能力。同样，必须在 DoT 和 DoH 的背景下评估后量子密钥交换机制，其中低延迟 TLS 握手对于实际使用至关重要。

虽然在将后量子加密原语整合到 DNS 安全的特定组件（例如具有 PQ 签名的 DNSSEC）方面已经取得了进展（McGowan 等人，2025)或具有 PQ 密钥交换的 TLS（Bozhko 等人，2023)，目前的大多数研究工作都只集中在这些协议上。这种脱节的画面导致对整个 DNS 安全堆栈中后量子措施的性能理解不足，尤其是在实际作约束下组合部署时。特别是，与 DNSSEC 相比，DoT 和 DoH 等加密 DNS 协议构成了当前 DNS 解析的隐私增强基础，在后量子话语中很少受到关注。此外，当将所有三种协议放在一起分析时，引入后量子密码学对 DNS 系统的互作性、延迟和可扩展性的影响几乎没有得到全面调查。这种狭隘的关注点在文献中造成了一个明显的空白：在后量子密码学框架中缺乏对 DNSSEC、DoT 和 DoH 的彻底、比较和系统级检查。否则，就很难评估将 DNS 基础设施过渡到后量子弹性架构的实际可行性和权衡取舍。

为了解决这一差距，我们的研究对三种主要 DNS 保护机制（DNSSEC、DoT 和 DoH）的后量子安全性进行了全面分析。我们特别介绍以下主要贡献：

• 后量子 DNS 实施和评估框架：我们提出了 DNSSEC、DoT 和 DoH 协议的统一实现，这些协议由 NIST 推荐的后量子加密基元保护。我们的框架支持跨经典、混合和仅 PQC 模式的协议级基准测试，并包括不同加密配置下 DNS 解析性能的正式模型。实验结果量化了延迟、带宽和资源权衡，为 DNS 迁移的可行性提供了实用见解。
• 安全威胁分类和缓解策略：我们识别了 PQC 采用引入的关键漏洞（例如降级攻击、计时泄漏和碎片漏洞），并提出了按严重性排序的缓解策略。我们的分析为将 PQC 安全设计集成到 DNS 系统中提供了信息。
• 部署挑战和设计建议：我们揭示了限制即时部署的实际限制因素，包括兼容性差距、边缘资源消耗和混合模式脆弱性。根据我们的调查结果，我们为将 DNS 基础设施过渡到量子弹性提供了可行的指导。

本文的其余部分结构如下。第 2 节调查了网络协议中 DNS 安全扩展和后量子密码学的相关工作。第 3 节介绍了系统架构，并正式化了 PQC-DNS 的性能模型、协议序列和相关成本方程式。第 3 节还分析了 PQC 采用引入的新安全威胁，并提出了相应的缓解策略。第 4 节报告了经典、混合和后量子加密配置下 DNSSEC、DoT 和 DoH 的实证发现。第 5 节讨论了部署挑战、可持续性和未来工作的方向。最后，第 6 节对本文进行了总结。

DNS 是互联网的基础组件，长期以来一直被认为是隐私和完整性攻击的目标。作为回应，DoT 等多项隐私增强功能（胡 et al.，2016)、DoH（霍夫曼和麦克马纳斯，2018)和 DNSSEC（Austein 等人，2005)已标准化以启用加密和身份验证。但是，这些协议基于经典的加密基元，容易受到未来量子对手的攻击。随着 PQC 标准化的进行（美国国家标准与技术研究院，2022)，最近的研究已经开始探索如何适应 DNS 安全协议以适应后量子弹性。PQ-TLS 的早期工作，例如 Stebila 等人。（Stebila 等人，2016)和 Hülsing 等人。（Hülsing 等人，2021)演示了在 TLS 1.3 框架内结合经典和后量子算法（例如 X25519+MLKEM）的混合密钥交换技术。这些混合方法已在实际部署中进行了试点，包括 Google Chrome（团队，2023)和 Cloudflare（Cloudflare、2022)，并显示可接受的延迟和带宽开销。但是，这些评估主要侧重于性能指标，而不是更广泛地集成到 DNS 基础设施中。

为 DNS 整合后量子密码学的工作相对有限。Ali 和 Chen 的 Titan-DoH（Ali 和 Chen，[n. d.])为 PQC 安全 DoH 引入信任感知型自适应架构。他们的解决方案集成了信任代数、图形信号处理、贝叶斯上下文推理和基于 FrodoKEM 的 TLS 握手，并由可验证的延迟函数支持，以识别加密的恶意请求。该系统在模拟对抗负载下表现出高精度和低延迟，突破了安全 PQC 就绪型 DoH 基础设施的界限。

其他现有工作主要集中在 DNSSEC 上。IETF DNSOP 工作组探讨了将后量子签名集成到 DNSSEC 中的注意事项，以解决密钥大小、算法敏捷性和协议兼容性等问题（组，2023).Zhang 等人。（Zhang 等人，2022)在 DNSSEC 设置中评估了 SPHINCS+，指出其适用于量子弹性身份验证，但也强调了由于其较大的签名大小和 IP 层碎片化风险而面临的挑战。这些问题凸显了在实际 DNS 服务器和解析器实施中实验验证 PQ 签名的重要性。Pan 等人。（Pan 等人，2024)提出了一种双签名 DNSSEC 方法，该方法集成了经典和后量子技术，以提供针对量子和经典攻击的过渡安全性。通过使用应用层分段，他们的双签名记录在 UDP 上提供解析，同时遵守数据包大小限制。Raavi 等人。（Raavi 等人，2024)使用基于区块链的公钥卸载策略的提交和显示方法应对基于碎片化的攻击。他们的方法可以保证片段的真实性并减小 DNSSEC 数据包的大小，尤其是对于 Falcon-512 等大量签名。该解决方案虽然独特，但解决了 DNSSEC 内部的碎片错误关联问题，并且不与 DoT 和 DoH 等更广泛的 DNS 安全协议集成。

Goertzen 和 Stebila（Goertzen 和 Stebila，2023)提出 ARRF（Application-layer Request-based Resource Fragmentation），将碎片逻辑移动到应用程序层。与以前的分段方法不同，ARRF 发送初始截断响应，并要求客户端显式请求其他分段，从而提高可靠性和向后兼容性。他们的实验表明，在使用 Falcon-512、Dilithium2（又名 MLDSA44）和 SPHINCS+ 等 PQC 算法时，与具有 TCP 回退的传统 DNS-over-UDP 相比，ARRF 显著减少了解析时间和数据开销。在 ARRF 的基础上进行扩展，McGowan 等人。（McGowan 等人，2025)识别可被更改的 RRSIZE 字段利用的内存耗尽漏洞。他们使用动态内存分配方法来解决这个问题，该方法在保持 ARRF 效率的同时防止放大威胁。 Rawat 和 Jhanwar 贡献了几个互补协议，旨在最大限度地减少 PQC 集成的开销。他们提出了基于 QNAME 的碎片 （QBF）（Rawat 和 Jhanwar，2023 年)，这是一种 DNS 层分段方案，可完全避免 IP 分段和 TCP 回退。QBF 使用标准 DNS 记录对 DNSSEC 响应进行分段，从而能够在不更改 DNS 协议堆栈的情况下在一次往返中进行重建。他们的实验结果表明了显著的性能提升：在后量子分辨率场景中，QBF 的性能优于标准 DNS 和并行 ARRF，尤其是在 Falcon-512、Dilithium2（又名 MLDSA44）和 SPHINCS+ 的情况下。通过保持完全向后兼容并避免更改区域文件或 DNS 堆栈，QBF 代表了立即部署 PQC 的有前途的中间地带。Rawat 和 Jhanwar 通过 SL-DNSSEC 协议进一步扩展了这一工作范围（Rawat 和 Jhanwar，2024b)，它用后量子密钥封装机制 （KEM） 和 MAC 替换数字签名，从而显著降低消息大小和解析延迟。TurboDNS 域名解析（Rawat 和 Jhanwar，2024 年)通过将身份验证数据包含在第一个 UDP 查询中，使用加密 Cookie 提供单往返解析，从而增强 TCP 上的 PQC DNSSEC。虽然这些协议提供了显著的性能提升，但它们背离了传统的基于签名的验证链，对普遍采用构成了挑战。与此同时，Schutijser 等人。（Schutijser 等人，2024)推出 PATAD，这是一个用于 PQC 和 DNSSEC 实验的容器化平台。PATAD 使用 PowerDNS 和模块化拓扑来评估现实区域层次结构中的 Falcon 和其他签名方法。虽然 PATAD 支持对 Falcon 和其他候选协议进行实证基准测试，但它仍然专注于 DNSSEC，并没有扩展到加密的 DNS 协议，例如 DNS-over-TLS （DoT） 或 DNS-over-HTTPS （DoH）。

几篇论文提供了基础实证研究，支持将后量子特征整合到 DNSSEC 中。贾法利（贾法利，2022)提出了一个基于 Merkle Tree 的框架，该框架使用 XMSS 对分组记录进行签名。此框架通过根据记录更新频率调整树大小来优化有效负载维度和签名效率，但代价是内存消耗增加和更新复杂性。 贝尔宁克（贝尔宁克，2022)使用实际 DNS 流量和签名者日志评估许多后量子加密算法的可行性。他的研究表明，Falcon-512 符合当前的 DNS 数据包限制，同时计算负担很小。Beernink 进一步提出了一种带外密钥交换架构，以绕过更重要的后量子密码学系统（如 Rainbow）的签名大小限制。 PQDNS 之类的项目 （项目、2022)以及来自 NLnet Labs 的行业建议（实验室，2023)和 NIST（Chen 等人，2016)强调了在实际作条件下对后量子安全 DNS 进行原型设计和测试的重要性。然而，大多数现有工作都集中在孤立的组件（例如 PQ-TLS 或 PQ-DNSSEC）上，而不是对所有主要 DNS 安全渠道进行整体评估。

在本节中，我们首先简要介绍 DNS 基础设施以及 DNS 协议的工作原理。稍后，我们将描述我们旨在解决的问题。然后，我们定义我们提议的 PQC-DNS 序列，最后我们讨论安全威胁和潜在的缓解技术。

无花果。1 提出了一个安全 DNS 解析的垂直分层架构，该架构将 DoH、DoT 和 DNSSEC 集成到一个连贯的工作流程中。它分为四个关键层：网络、缓存、索引和数据，每个层代表解析和安全管道中的一个不同阶段。在网络层，用户发起 DNS 查询，该查询使用加密传输协议（DoH 或 DoT）安全地传输到 DNS 解析器，从而确保机密性并防止中间人攻击。解析器将查询转发到缓存层中的验证解析器，该解析器检查结果是否已缓存，并通过根据可信密钥（DNSKEY 和 DS）验证数字签名 （RRSIG） 来执行 DNSSEC 验证。如果答案在本地不可用，解析器将查询索引层，其中查询的域（例如 example.com）经过哈希处理并映射到查找相关 DNS 记录的指针。最后，数据层包含从外部权威 DNS 服务器（例如根、TLD （.com）和特定于域的权威名称服务器）检索的实际签名 DNS 记录。这些服务器返回所需的资源记录（A、AAAA、DNSKEY、RRSIG），然后使用 DNSSEC 以递归方式验证这些记录，直到 DNS 根。验证的结果将通过层向上传递，并最终返回给用户。这个分层模型演示了如何在现代 DNS 基础设施中同时实施隐私（通过 DoH/DoT）和完整性（通过 DNSSEC）。

虽然 PQC 算法的安全特性已经单独进行了严格的分析，但它们与 DNS 协议的系统集成仍未得到充分探索，尤其是对于 DoT 和 DoH 等加密传输机制。现代过渡框架（例如 NIST 和 IETF 提出的框架）包括仅 PQC 和混合经典 + PQC 配置，以适应向后兼容性。但是，它们对延迟、资源消耗和协议兼容性的实际影响需要统一的系统级评估。为了解决这个问题，我们提出了一个统一的后量子 DNS 安全架构 （PQC-DNS），用于评估三个部署类：

1. (1) 

   仅限旧版：使用经典 KEM 和签名算法的 DNS 配置。

2. (2) 

   仅限 PQC：使用后量子 KEM 和签名的 DNS 配置。

3. (3) 

   混合：在 KEM 或数字签名中结合经典方案和 PQC 方案的混合部署。

我们定义了一个 DNS 解析性能配置文件𝒫DNS 解析(k,s)作为加密配置的函数，如公式 1 所示。表 1 列出了整篇论文中使用的符号。

每𝒮我⁢(k,s)定义为：

此公式允许跨加密配置进行系统比较，并量化延迟、计算工作量、带宽和内存的权衡。

安全模型：我们认为是对手一个具有量子计算能力，能够执行 Shor 和 Grover 的算法。攻击者可以 （i） 窃听 TLS 握手并执行 MITM 攻击。（ii） 执行 DNS 欺骗和缓存中毒。（iii） 试图通过量子手段破解数字签名或密钥交换。我们假设 PQC 原语满足以下条件：（i） KEM 在量子对手下是安全的 IND-CCA2（选择密文攻击下密文的不可区分性）（Chevalier 等人，2022).（ii） 签名在量子随机预言机模型中是 EUF-CMA（选定消息攻击下的存在不可伪造性）安全的（Xagawa，2024).该系统旨在为针对此类攻击者的 DNS 查询和响应提供后量子机密性、真实性和完整性。

无花果。图 2 说明了 PQC-DNS 的架构。该协议包括两个阶段：与 PQC 基元的 TLS 1.3 握手和随后的 DNS 解析。

第 1 阶段：建立 PQC 安全 TLS 1.3 会话

让T第一阶段是建立后量子安全 TLS 会话的总时间。我们定义：

这种握手可确保 DNS 交换之前的后量子机密性和相互身份验证。

第 2 阶段：加密递归 DNS 解析

建立 TLS 后，DNS 查询将在加密下遍历传统的递归路径。DNS 查询解析的总时间为：

这些方程中出现的变量在表 1 中定义。

PQC-DNS 由于使用了 NIST 标准化算法，因此可以抵抗量子攻击。但是，还需要考虑以下进一步的威胁：（i） 定时攻击：后量子 KEM 和签名算法的常数时间实现对于防止 TLS 握手期间的侧信道泄漏至关重要。最近的研究表明，如果没有严格的时序控制实现，即使是像 Kyber 和 Dilithium 这样的基于 lattice 的方案也可能容易受到影响（Hochstätter 等人，2023).（ii） DDoS 攻击：PQC作增加的带宽和 CPU 开销，尤其是在握手和验证阶段，可以被用于拒绝服务攻击。缓解策略包括客户端谜题和为 PQC 引起的延迟量身定制的速率限制机制（舒尔曼和韦德纳，2023).（iii） 降级攻击：结合经典和后量子算法的混合配置必须严格执行密码套件协商策略，以防止回退到仅经典模式。不正确的协商可能会使会话遭受降级攻击，从而抵消预期的量子抵抗（Stebila 等人，2023).（iv） 碎片漏洞：大型 PQC 签名（例如 SPHINCS+）可能会触发 IP 层碎片化，尤其是在 DNSSEC 响应中。应用层基于请求的资源碎片 （ARRF） 等技术 （Goertzen 和 Stebila，2022)通过将碎片逻辑移动到应用程序层来缓解这种情况。基于 QNAME 的碎片 （QBF） （Rawat 和 Jhanwar，2023 年一)通过使用标准 DNS 记录字段完全避免 IP 层碎片。虽然 TurboDNS 等协议 （Rawat 和 Jhanwar，2023年)和 SL-DNSSEC （Rawat 和 Jhanwar，2023b)提高后量子 DNSSEC 性能，但它们不会直接解决碎片化问题，并且可能会带来兼容性权衡。（v） 密钥/签名重用：在 PQC 方案（例如 Dilithium、Falcon）中重用随机数或临时密钥可导致通过代数攻击恢复私钥。这种风险在具有共享随机性的多线程解析器环境中会被放大。缓解措施包括使用强化库（例如 liboqs），这些库强制执行一次性密钥使用和线程安全随机性（Dukhovni 和 Schwabe，2023).（vi） 互作性故障：PQC 部署可能会在不支持混合或仅 PQC 密码套件的客户端、解析器或中间设备之间失败。配置错误的回退行为可能会导致静默降级或连接断开。作员应使用混合感知配置测试兼容性并监控故障模式（Wood 等人，2023).最后，表 2 列出了这些威胁和潜在缓解策略的摘要。

在本节中，我们将介绍我们的实验设置、指标、数值结果，并提供我们对结果的分析。

实验测试平台由两个在 Ubuntu 22.04 上运行的 Docker 容器组成，部署在适用于 Linux 2 的 Windows 子系统 （WSL2） 中，如图 2 所示。3 将资源使用情况与主机系统活动隔离开来，并获得准确的性能基准。一个容器作为支持 PQC 的本地 DNS 解析器运行，而另一个容器则作为发出 DNS 查询的客户端运行。解析程序是使用 BIND9 的分叉版本 （OQS-BIND） 构建的（戈尔岑，2023)，使用与 Open Quantum Safe （OQS） 库和 oqsprovider 集成的 OpenSSL 进行编译。此配置支持后量子密钥交换和数字签名算法。解析器充当本地 DNS 服务器，能够处理 DNS-over-TLS （DoT）、DNS-over-HTTPS （DoH） 和 DNSSEC 查询。客户端容器分别使用带有 +tls 和 +https 选项的 dig 工具生成了基于 DoT 和 DoH 协议的 DNS 查询。每次测试运行向解析程序上托管的测试域发出 100 个查询。

基准测试是在运行 Windows 11 Home 的系统上进行的，该系统配备了运行频率为 2.90 GHz 的 Intel（R） Core（TM） i7-10700 CPU。该处理器由 8 个物理内核和 16 个线程组成。该机器安装了 16.0 GB 的 RAM，其中 15.7 GB 可用。实验环境是使用适用于 Linux 2 的 Windows 子系统 （WSL2） 设置的，Ubuntu 22.04 作为来宾作系统运行。WSL2 为来宾系统动态分配了大约 7.6 GiB 的 RAM，并提供对所有 16 个逻辑 CPU（8 个内核，每个内核 2 个线程）的访问。软件堆栈包括作为容器引擎的 Docker 版本 26.1.3、集成了对后量子加密的支持 OpenSSL 3.4.0 和 liboqs 版本 0.12.0。使用的 OQS OpenSSL 提供程序是 oqsprovider 版本 0.8.0。实验中使用的 DNS 解析器是 BIND 的定制版本，基于 BIND 9.19.17 的分叉版本（称为 OQS-BIND），经过编译以支持带有 liboqs 和 oqsprovider 的 PQC-DNS。

为了评估不同加密配置对 DNS 性能的影响，我们分析了性能向量的组成部分𝒮我⁢(k,s)，之前在 Section 3.2 中介绍过。此向量表示系统在每个 KEM 特征对下的经验行为(k,s). 我们开发了基于 Python 的基准测试脚本，可自动执行 DNS 查询、监控系统资源、捕获网络流量，并汇总重复试验的性能数据。它使用 psutil、/usr/bin/time 和 tshark 等工具来收集可重现的系统级测量结果。GitHub 上提供了完整的基准测试套件和一些示例数据包捕获11https://github.com/ljy4499/pqc-dns.评估框架的逐步执行在算法 1 中正式定义，图 1 中给出了高级摘要。4. 的各个组件𝒮我⁢(k,s)定义如下：

• • 

  延迟 (T延迟)：此值是根据从客户端发出的 DNS 请求的第一个数据包到收到该请求的最后一个数据包之间所花费的时间（以毫秒为单位）计算得出的。此指标衡量协议的响应能力和易用性。

• • 

  带宽使用情况 (B带宽)每个 DNS 查询生成的总网络流量，以千字节为单位，同时考虑传输和接收的数据。这反映了协议效率和加密开销。

• • 

  CPU 使用率 ：DNS 查询期间消耗的 CPU 时间百分比是独立测量的，供客户端和服务器评估两端的加密工作负载：

  （i） 客户端 CPU 使用率 (C客户)：此指标反映启动 DNS 查询的 dig 进程的 CPU 利用率。/usr/bin/time -v 实用程序用于运行 dig 并提供详细的统计信息。字段“Percent of CPU this job got”是使用正则表达式提取的。此原始百分比表示 CPU 时间与实际 （挂钟） 时间的比率，并在内部计算如下：

  

  “用户时间”是指执行用户级指令（例如加密作），而“系统时间”包括内核级作（如 I/O）所花费的时间。“经过时间”是指从作开始到结束的总实际（挂钟）持续时间。为了以标准化的 0-100% 比例表示这一点，将原始值除以分配给容器的虚拟 CPU 数量（16 个 vCPU）：

  

  此规范化可确保值 100% 表示所有已分配内核的完全利用率。

  （ii） 服务器 CPU 使用率 (C服务器)：此指标是使用 docker stats 的定期快照得出的，它为容器提供实时 CPU 利用率。终止所有其他后台进程以确保测量的准确性。

  监控脚本持续对容器的 CPU 使用率进行采样，在整个客户端请求持续时间内观察到的最高百分比被记录为服务器的 CPU 使用率。 在内部，docker stats 计算 CPU 使用率为：

  – Δ⁢容器 CPU 使用率：容器在测量周期内消耗的 CPU 总时间。

  – Δ⁢系统 CPU 使用率：同一时间段内系统的总 CPU 时间。

  – vCPU：分配给容器的虚拟 CPU 数量。在本例中，为容器分配了 16 个 vCPU。

  此公式计算容器消耗的 CPU 时间相对于主机系统总 CPU 时间的比例，按分配给容器的虚拟 CPU 数量进行缩放。 为了以标准化的 0-100% 比例表示这一点，将原始值除以分配给容器的虚拟 CPU 数量（16 个 vCPU）：

  

  此调整可确保与标准化客户端 CPU 使用率的可比性，并将容器 CPU 消耗表示为其完整计算容量的比例。

• • 

  内存使用情况 (M客户)：dig 进程使用的峰值物理内存，相对于容器中的总可用内存。 最大驻留集大小 （RSS） （以 KB 为单位）是从 /usr/bin/time -v 获取的。 它被转换为 兆字节 （MiB）：

  

  RAM 使用量按总内存的百分比计算（即 7810.3 MiB）：

  

1: function RunSession（ session_id)

2:     B开始← GetTotalNetworkBytes

3:     T开始← GetCurrentTime （获取当前时间）

4:使用 100 个 worker 初始化线程池

5:      适用于所有工人∈线程池  do

6:提交 RunDNSQuery

7:      end  为

8:等待所有查询完成

9:     T结束← GetCurrentTime （获取当前时间）

10:     B结束← GetTotalNetworkBytes

11:     Δ⁢T←(T结束−T开始)×1000▷延迟（毫秒）

12:     Δ⁢B←(B结束−B开始)/1024▷带宽 （KB）

13:     写入 CSV(s⁢e⁢s⁢s⁢我⁢o⁢n⁢_⁢我⁢d,Δ⁢T,Δ⁢B)

14: end  函数

为了评估 PQC 的可扩展性和对具有并发 DNS 工作负载的资源的影响，使用了多线程测试配置。与上述单线程测试相比，此基准测试包括 100 个并行工作程序（即 DNS 客户端），每个工作程序每个会话发送一个查询，因此 100 个会话中的查询总数为 10000 个。Docker 内置实用程序 docker stats 用于捕获 CPU 和内存使用指标。在测试期间，通过定期拍摄快照并从客户端和服务器提取峰值来记录资源利用率。所有报告的 CPU 使用率值都按照 0 到 100% 的等级进行标准化，这与单线程评估中使用的标准化方法相对应。这确保了不同加密方法和系统配置之间的公平比较。 与传统加密方法相比，该基准测试专门旨在评估 PQC 算法在负载下的行为，重点关注高查询量下的吞吐量扩展和系统资源演变。网络使用情况和延迟的测量方式如算法 2 所示。

本节介绍了在不同 NIST 安全级别使用经典和后量子 KEM 和数字签名 （DS） 的各种组合的 DNS 基准测试结果（美国国家标准与技术研究院 （2015），美国国家标准局 （NIST).对于每个评估的加密配置(k,s)，我们计算相应的性能向量𝒮我⁢(k,s)如第 3.2 节中所定义。性能数据按协议类别进行组织，DoT、DoH、启用 DNSSEC 的配置和安全级别有单独的表格。所有表都显示了三个加密配置文件的结果：（i） 仅旧版、（ii） 仅 PQC 和 （iii） 混合。 每个表都包含延迟、带宽使用情况、客户端/服务器的 CPU 利用率和内存消耗的测量值，其表示法和定义在前面的表示法摘要（表 1）和第 4.2 节中介绍。我们在提供的每个表中为每个指标的每个子类别中的最低数值加粗。每个组合(k,s)根据用于促进混合和完全后量子配置之间比较的加密基元进行分类。

在表 3 中，基准测试使用一系列 PQC 和传统算法评估了 NIST 安全级别 1（对应于传统 128 位安全级别）的 DoT 性能。尽管最初预计 PQC 算法相对于传统算法会带来显著的性能损失，但某些组合（尤其是MLKEM512与 MLDSA44 或 Falcon512 配对的组合）证明的延迟指标与传统配置非常匹配，甚至优于传统配置。这些组合实现了大约 9 ms 的延迟，这与常用的椭圆曲线和基于 RSA 的解决方案相当。但是，在带宽使用方面观察到一致的趋势：基于 PQC 的配置通常会产生更高的数据开销。这是由于抗量子基元的较大密钥和签名大小所特有的。在 PQC 候选方案中，SPHINCS+-SHA2-128f 和 HQC-128 表现出明显更高的延迟和带宽使用率。这些结果突出了后量子稳健性和运营效率之间的权衡，这使得这些算法对于延迟敏感型应用程序不太实用。

表 4 中的基准代表了 DoH 在 NIST 安全级别 1 下的性能，与之前提出的 DoT 基准结果直接可比。对于密钥交换和数字签名的所有分析组合，延迟、CPU 使用率和内存消耗的指标显示 DoH 和 DoT 之间的差异可以忽略不计。主要偏差在于带宽利用率：与 DoT 配置相比，DoH 配置始终导致平均 0.3 至 0.4 KB 的轻微开销。这种增加是由于基于 HTTP 的封装和 DoH 固有的额外协议标头。

表 5 中的结果显示了 NIST 安全级别 3 的 DoT 性能结果，对应于 192 位安全。一个值得注意的观察结果是 MLKEM768 与 MLDSA65 配对的卓越性能，它在延迟方面优于所有经过测试的传统组合，实现了最低的测量值（9.24 毫秒）。与RSA3072或 ECDSA-P384 配对的 FFDHE3072 或 SECP384R1 等传统密钥交换机制相比，这种 PQC 组合可提供更快的 DoT 性能。但是，PQC 算法的带宽成本要高得多，消耗2×至 23×比传统产品带宽更多。例如，具有 SPHINCS+ 特征组合的 HQC192 显著增加了总带宽使用量，与传统配置中低于 5 kB 的值相比，其值超过 87 kB。这说明了后量子安全性和通信开销之间的权衡，在评估带宽敏感环境中的 PQC 部署时必须考虑这一点。

表 6 中的基准测试显示了 NIST 安全级别 3 的 DoH 性能结果。结果显示，与之前的 DoT 基准测试结果相比，没有显著差异。

表 7 中的基准测试显示了 NIST 安全级别 5 的 DoT 性能结果，这对应于传统算法的 256 位安全级别。一个值得注意的观察结果是，MLKEM1024 MLDSA87 的 PQC 算法实现了始终如一的低延迟，实现了低于 10 毫秒的延迟。这些结果优于几种传统组合（例如FFDHE4096 与 RSA4096 的组合），后者的延迟范围为 12 到 18 毫秒。然而，并非所有 PQC 配置都表现出这种效率。HQC256 密钥封装机制与 PQC 或传统数字签名方案配对时，会显著增加延迟，达到 65 毫秒以上的值。这种性能下降主要是由于 HQC 的密钥和密文大小较大，这在 TLS 握手过程中会带来更高的计算和传输开销。

无花果。图 5 显示了 NIST 安全级别 1、3 和 5 下的 DoT 性能比较。值得注意的是，MLKEM 的 KEM 与 MLDSA 或 Falcon 的 DS 算法相结合，无论安全级别如何，都具有始终如一的低延迟，表明性能具有良好的可扩展性。相比之下，HQC 和 SPHINCS+ 等算法的延迟随着安全级别的提高而成比例增加，这反映了它们更大的计算和结构开销。在带宽方面，所有配置都呈现出明显的趋势：随着安全级别的提高，带宽消耗也随之增加。这是因为保持更高级别的加密强度需要更大的密钥和密文大小，特别是对于基于代码或无状态哈希的方案，例如 HQC 和 SPHINCS+。

表 8 中的基准测试显示了 NIST 安全级别 5 的 DoH 性能结果。结果显示，与之前的 DoT 基准测试结果相比，没有显著差异。为避免冗余并提高可读性，省略了比较图表。

表 9 中的该基准显示了 DNSSEC 性能结果。虽然与传统算法相比，基于 PQC 的 DNSSEC 算法表现出更高的带宽使用率，但这种增加主要是由于加密签名和证书的大小更大。尽管有这种开销，但在所有测试的算法中，延迟几乎不受影响。例如，MLDSA44 和 SPHINCS+ 变体的带宽消耗明显高于 RSA2048 或 ED25519，但保持相当的延迟值，这表明即使使用后量子算法，DNSSEC 验证的计算量也保持轻量级。

表 10 中的基准测试显示了 DNSSEC 与 DoT 结合使用 NIST 安全级别 1 的一系列加密算法的性能结果。算法的整体行为与非 DNSSEC 配置保持一致，尤其是在延迟、CPU 和内存使用方面。观察到的主要差异是带宽的增加，这是由于额外的 DNSSEC 相关加密材料所预期的。但是，这种增加不会对延迟或其他系统指标产生重大影响。SPHINCS+ 等算法已经生成了较大的签名大小，这大大增加了带宽开销。因此，与其他算法相比，涉及 SPHINCS+ 的配置表现出明显更高的带宽消耗。

表 11 中的该基准显示了 DNSSEC 在 NIST 安全级别 1 下的 DoH 性能结果。结果显示，与之前的 DoT 基准测试结果相比，没有显著差异。为避免冗余并提高可读性，省略了比较图表。

表 12 中的结果列出了使用 NIST 安全级别 1 的 100 个并发查询的多线程场景下的 DoT 性能。结果显示与早期基准一致的趋势： PQC 密钥交换机制（如 MLKEM512）与 MLDSA44 或 Falcon512 等签名方案相结合，产生的延迟与几种传统组合相当，甚至更低。值得注意的是，尽管带宽显著增加（与并发查询的数量呈线性扩展），但延迟仍然不受影响。这可能是由于每个 DNS 查询和响应的大小较小，这最大限度地减少了网络拥塞并避免了带宽容量饱和，尤其是在典型的现代网络条件下。通过这些观察，DNS 性能证实，延迟通常由加密处理和握手往返决定，而不是数据量本身。但是，计算负载较重的算法（如 SPHINCS+ 和 HQC）会引入更高的延迟，这与服务器端 CPU 使用率的增加相关。观察到的 CPU 影响表明，对于具有较大密钥或签名大小的算法，处理开销（例如，签名验证或密钥解码）成为负载下的主要延迟因素，而不是网络吞吐量。

同时，表 13 中的结果显示了 NIST 安全级别 1 的多线程（100 个并发查询）DoH 性能结果。结果显示，与之前的 DoT 基准测试结果相比，没有显著差异。为避免冗余并提高可读性，省略了比较图表。

与 100 并发查询基准相比，表 14 中给出的 1000 个查询方案揭示了算法组合之间的重要可扩展性差异。虽然一般延迟趋势保持一致，但并发性增加放大了资源处理的差异，尤其是 CPU 使用率和带宽开销。例如，MLKEM512 + Falcon512 等组合继续高效执行，但现在表现出略高的客户端 CPU 利用率，这反映了大规模重复加密作的累积影响。相反，资源密集型算法（如 HQC128 + SPHINCS+ 和 HQC128 + Falcon512）的性能下降更明显：延迟超过 2200 毫秒，服务器 CPU 使用率接近 30%，这表明在高负载下存在压力。带宽随查询量的扩展是可预测的，但带宽密集型方案（尤其是使用 SPHINCS+ 的方案）现在每个会话产生的传输量超过 38 MB，这加剧了对在受限网络中部署的担忧。值得注意的是，涉及 PQC 签名的混合组合（例如 ffdhe2048 + SPHINCS+）显示出类似的趋势，CPU 瓶颈比低并发测试更加明显。

与 1000 个并发查询的场景相比，表 15 中给出的 10000 个查询的基准在加密处理和系统资源使用方面暴露了更明显的可扩展性限制。虽然 MLKEM512 + Falcon512 和 MLKEM512 + MLDSA44 等高性能组合继续表现出良好的延迟，但保持接近或略高于 11000 毫秒的客户端 CPU 使用率现在始终超过 90%，这表明加密作在硬件上接近饱和。签名大小较大、验证成本较高的算法，尤其是 SPHINCS+ 和 HQC，在此负载下性能会显著下降：延迟超过 24,000 毫秒，服务器 CPU 使用率上升到 30% 以上，在极端情况下，内存消耗增加到近 5%。正如预期的那样，带宽开销随查询量线性扩展，但总传输大小变得至关重要，例如，对于 MLKEM512 + SPHINCS+ 来说，超过 380 MB，这在吞吐容量有限的环境中引发了部署问题。FFDHE2048 + SPHINCS+ 和 FFDHE2048 + Falcon512 等混合组合表现出类似的症状，与中等规模测试相比，延迟和 CPU 开销都扩大了差距。这些结果证实，虽然许多 PQC 算法在中等并发水平下仍然可行，但某些方案（尤其是那些具有基于哈希的签名或大型密文的方案）在高吞吐量使用案例中性能较低。

以下分析评估了 PQC 与应用于 DoT、DoH 和 DNSSEC 配置的传统加密技术之间的实验基准测试。这些测量是在受控的 Docker 环境中进行的，主要关注四个主要性能指标：延迟、带宽、CPU 使用率和内存消耗。调查了 NIST 安全级别、算法系列（基于格、哈希和基于代码）和协议层之间的差异，以了解对实际部署的影响。

延迟使用情况：由于 FFDHE 和 RSA 等传统算法的密钥大小紧凑且算术复杂度最小，因此始终表现出更快的握手延迟。在 PQC 方案中，Falcon、ML-KEM 和 ML-DSA 表现出有竞争力的延迟，这得益于高效的实施和硬件加速的整数运算。相比之下，由于复杂的解码逻辑或较深的 Merkle 树结构，HQC 和 SPHINCS+ 表现出更高的延迟（美国国家标准与技术研究院，2022).NIST 安全级别直接影响延迟。更高的级别需要增加内部维度（例如，格环大小、哈希迭代次数），这意味着密钥封装和签名验证期间的计算时间更长。延迟不仅受带宽影响，还受计算工作量的影响。具有高算术复杂性或序列化开销的算法（例如 HQC 中的综合征解码）显着增加了握手持续时间。协议差异（即 DoT 与 DoH）对延迟的影响可以忽略不计，HTTP 帧开销很小。

带宽使用情况：传统方案传输较小的公钥和密文，从而保持握手总大小紧凑。PQC 算法，尤其是基于哈希和代码结构的算法，由于密钥和签名大小较大，因此需要更多的带宽。基于哈希的算法（例如 SPHINCS+）将大型哈希树嵌入到其签名中，从而导致特别高的消息开销。基于代码的方案（如 HQC）涉及用于纠错的扩展密文。基于格的方案（例如 ML-KEM）提供了一个中间地带，由于其紧凑的结构化矩阵和避免大型随机数据，实现了强大的安全性和适度的带宽增加。DoH 的带宽使用率略高于 DoT，因为 HTTP/2 帧和标头会产生额外的开销。这种差异与协议相关，而不是由加密算法（包括 Legacy 和 PQC 方案）引起的。

CPU 使用率：在建立握手期间，CPU 负载在客户端和服务器之间表现出明显的不对称性。在所有算法中，与服务器相比，客户端的 CPU 使用率很可能要高得多。这反映了客户端执行密钥封装和签名验证的双重负担，这通常比服务器的解封装和签名作计算密集。基于晶格的方案（如 ML-KEM 和 ML-DSA）使用矢量化模算术（例如 AVX2）来加速运算（Zheng 等人，2024).这些方案显示客户端的 CPU 使用率很高，但服务器上的负载相对较低，表明高效的解封装例程。基于哈希的方案（如 SPHINCS+）每个时钟消耗的 CPU 周期较少，但在签名验证期间需要许多顺序作。这导致客户端和服务器上的握手持续时间更长，CPU 使用率适中。基于代码的方案（如 HQC）显示客户端和服务器之间的 CPU 负载更加平衡。客户端的 CPU 使用率较低，因为其作虽然涉及一些顺序处理，但计算密集度较低。相比之下，服务器较高的 CPU 使用率是由纠错过程驱动的，该过程涉及复杂和顺序的综合症解码，导致服务器端的负载更重。经典的加密方案，例如带有 RSA 或 ECDSA 的 FFDHE，在客户端和服务器端都展示了稳定且适度的 CPU 使用率。它们跨平台的广泛优化和数十年的硬件支持有助于降低加密开销，使其成为资源受限或延迟敏感型部署的理想选择。然而，这种效率是以易受量子攻击为代价的，这凸显了尽管存在计算权衡，但仍需要过渡到 PQC 替代方案。随着安全级别的提高，客户端和服务器之间的 CPU 负载分配变得更加明显。对于更高的安全级别，由于更复杂的解封装和签名生成过程，服务器 CPU 使用率往往会增加，而客户端 CPU 使用率通常会随着密钥封装和签名验证的提高而降低，这通常受益于硬件加速或更好的优化。底层数学运算（例如基于格的方案中的数论变换、基于代码的方案中的综合征解码或基于哈希的方案中的哈希树遍历）会显著影响 CPU 使用率。这些作不仅会影响总体计算成本，还会影响算法在现代硬件上并行化和优化的效率。此外，更高的安全级别通常会增加计算需求，从而进一步影响客户端和服务器系统的 CPU 利用率。

内存使用情况：在所有测试场景中，内存消耗保持在可管理的范围内。由于 RSA 和 ECDSA 等传统算法具有紧凑的密钥大小和优化的加密例程，因此内存开销最小。在后量子算法中，SPHINCS+ 的内存占用最高，这归因于其无状态签名生成中使用的深度哈希树结构。相反，ML-KEM 和 ML-DSA 由于依赖于结构化格和矩阵算术，因此表现出适度的内存使用。HQC 虽然在解码过程中要求服务器上的内存更多，但总体上保持了可接受的 RAM 使用率。所有经过测试的算法都没有对分配的容器内存产生重大影响，这表明即使在适度的硬件上进行 DNS 部署也是可行的，前提是 CPU 权衡得到解决。

DNSSEC 的影响：当与传统算法一起应用时，DNSSEC 仅引入了少量带宽增加。当与 PQC 签名（例如 SPHINCS+）配对时，由于 DNSKEY 和 RRSIG 记录更大，增加变得更加明显，尽管它不会显着影响延迟。在没有 TLS 的情况下应用 DNSSEC 不会造成可衡量的延迟损失，并且引入了最小的资源开销 - 即使在资源受限的部署中也凸显了其可行性。在 DoT/DoH 与 DNSSEC 的组合场景中，虽然带宽如预期般增加，但其他性能指标（例如传统算法和 PQC 算法之间的延迟或 CPU 使用率）没有观察到显著差异。

指标关系：较大的消息确实有助于增加带宽，但它们不是延迟的主要原因。延迟在很大程度上取决于算法计算时间和硬件优化。高 CPU 使用率可能与更好的性能相关，因为它通常表示有效的并行度。例如，尽管计算强度很高，但充分利用 CPU 资源的基于格的方案实现了更快的握手。由于串行或复杂的内部进程未能利用可用的处理能力，一些 CPU 使用率较低的方案仍然具有较差的延迟。带宽、CPU 和延迟必须一起解释，而不是孤立地解释。没有一个指标可以准确预测所有协议和算法的整体性能。

多线程基准测试结果：出于基准测试目的，评估了几个指标。下面列出了各个指标的分析结果：

• • 

  延迟：与传统算法相比，几种 PQC 算法组合（尤其是 ML-KEM 与 ML-DSA 和 Falcon）在较低或相当的延迟下表现出强大的性能。这表明，即使在高并发性下，基于格的方法可以保持响应能力。但是，SPHINCS+ 和 HQC 等算法需要更多的时间来完成查询事务，这凸显了它们更繁重的加密作。尽管过渡到多线程环境，但总体延迟趋势与在单线程测试场景中观察到的延迟趋势保持一致。

• • 

  带宽：正如预期的那样，PQC 算法消耗的带宽比传统算法多得多。这种增加是由于 PQC 加密技术本身的密钥大小和消息结构更大。此外，该行为与观察到的单线程方法一致 - 带宽值比单个查询会话大约 100 倍，反映了每个会话 100 个并发查询的批处理大小。

• • 

  CPU 使用率：对于传统算法，客户端的 CPU 利用率始终很高。相比之下，PQC 算法根据底层加密系列显示出不同的 CPU 需求。ML-KEM 和 Falcon 等基于格的方案保持了较高的客户端 CPU 使用率和较低的服务器 CPU 使用率，而与传统和基于 Lattice 的算法相比，基于哈希的算法（例如 SPHINCS+）和基于代码的算法（例如 HQC）的服务器 CPU 使用率更高。这些趋势类似于单线程结果，在多线程上下文中没有观察到明显的偏差。

• • 

  内存使用情况：与 CPU 行为不同，由于多线程执行，内存使用量明显增加。虽然传统算法和 PQC 算法的内存消耗都较高，但在 SPHINCS+ 和 HQC 等作占用空间较大的算法中，这种增加更为明显。这种转变反映了并行查询执行的预期结果，对系统内存提出了额外的要求。

无花果。图 6 显示了基于安全级别 1 的多线程（即 100 个并发客户端）DoT 延迟和带宽比较图表，按升序排列，图 3。7 表示 1000 个并发客户端，10000 个并发查询显示在图 1 中。8. 与单线程测试一样，DoH 与 DoT 相比没有显示出明显的性能差异，除了由于 HTTP 标头开销导致预期的带宽利用率略有增加。此模式在多线程设置中也保持一致，这表明协议封装不会导致并发查询负载的额外性能下降。

虽然我们的研究对后量子 DNS 安全机制进行了全面的性能评估，但仍存在一些值得讨论的局限性和悬而未决的问题。

环境配置复杂度：在这项研究的初始阶段，配置一个有效的后量子 DNS 环境带来了相当大的挑战。由于缺乏现有文档或既定部署实践，OpenSSL、liboqs、oqsprovider 和分叉 BIND 实现 （OQS-BIND） 的集成需要大量的手动工作。这些库之间的配置不匹配、加密接口不一致和版本控制不兼容严重延迟了实验进度。这反映了 PQC 部署中更广泛的挑战，即缺乏对生产就绪型 DNS 应用程序的成熟工具和互作性支持。

硬件相关基准测试结果：本文中报告的所有性能指标均来自具有固定硬件规格的受控本地环境。虽然这确保了内部一致性和公平的算法比较，但结果本质上取决于硬件，可能无法推广到其他平台。特别是，CPU 绑定的作（例如基于格的密钥封装或基于哈希的签名验证）对处理器架构、指令集优化（例如 AVX2）和系统负载很敏感。因此，这些结果不应直接与在不同环境中进行的基准测试进行比较。此外，网络抖动、交叉流量和运营商级 NAT 行为对实际性能的影响可能与此处报告的有所不同。未来的工作应将这项研究扩展到广域部署或基于云的 DNS 提供商，例如 Cloudflare、Quad9 或 Google DNS。

安全性和实施注意事项：我们的安全模型假设 PQC 原语的理想实现。在实践中，侧信道电阻高度依赖于仔细的软件和硬件工程。最近的研究（Hochstätter 等人，2023)已经表明，即使是 Kyber 和 Dilithium 的恒定时间实现在实际泄漏下也可能容易受到攻击。此外，如果密码套件协商实施不当，混合 TLS 部署可能会使终端节点遭受降级攻击（Stebila 等人，2023).确保降级弹性仍然是一个公开的挑战，尤其是在必须保持与经典客户端的向后兼容性的过渡部署期间。

DDoS 和运营风险：一个关键的作问题是 PQC 增强型握手容易受到拒绝服务攻击。近期工作（舒尔曼和韦德纳，2023)已经证明，后量子 TLS 所需的更大消息大小和增加的 CPU 周期可以被用来发起针对解析器和服务器的资源耗尽攻击。虽然我们的基准测试包括多线程评估，但未来的研究必须调查高负载场景中的速率限制、客户端难题或自适应限制，以保持解析程序的可用性。

可持续性和可扩展性注意事项：后量子 DNS 部署的长期可行性不仅取决于加密的可靠性，还取决于不同互联网环境的可持续性和可扩展性。后量子算法（尤其是基于格和基于哈希的方案）在计算时间、内存占用和消息大小方面引入了非同寻常的增加。这些开销引发了对能源效率的担忧，尤其是在功率和热预算受到严格限制的边缘和嵌入式部署中。例如，使用 SPHINCS+ 等基于哈希的签名可以放大 CPU 周期和带宽使用，这可能会导致数据中心能源需求增加和对环境的影响更大。虽然 MLKEM 和 Falcon 等基于晶格的方案提供了更有利的性能-能量权衡，但与 X25519 或 ECDSA 等经典方案相比，即使是这些方案也会导致延迟和 CPU 损失。由于全球 DNS 基础设施跨越数千台递归和权威服务器，因此即使每次查询的适度增加也可能累积成大量的运营成本和碳足迹。可扩展性还受到 PQC 性能不对称性的挑战，其中服务器端解封装和签名验证可能主导处理成本。在高吞吐量方案中，例如大型 DNS 提供商或 CDN 面临的方案，这种不平衡可能会限制处理峰值查询负载的能力，而无需进行架构优化，例如硬件加速、TLS 会话恢复或将加密函数卸载到安全 enclaves。为了确保可扩展和可持续的部署，未来的工作必须包括在实际工作负载下进行能量分析、探索后量子硬件加速器以及协议级优化，例如轻量级混合模式和会话缓存。这些增强功能对于使后量子安全性与运营可行性和环境责任保持一致至关重要。

标准化和部署障碍： 尽管 NIST 已经最终确定了几种用于标准化的 PQC 算法，但许多生产级 DNS 解析器（例如 Unbound、PowerDNS）和 TLS 库仍然缺乏稳定的 PQC 集成。我们的实现基于 OQS-BIND 和修补的 OpenSSL 版本，这些版本可能与主流堆栈不同。确保整个生态系统的采用需要 DNS 软件供应商、TLS 库维护者和浏览器制造商之间的协调努力。此外，DNS 安全的监管框架（例如 ICANN 或 DNSSEC 根签名机构）可能需要更新运营策略，以适应混合部署或仅量子后部署。

尽管存在这些挑战，但我们的结果表明，精心挑选的 PQC 原语（尤其是 MLKEM 和 Falcon）可以实现后量子 DNS 安全，而不会造成令人望而却步的性能损失。我们的研究结果可以为量子弹性 DNS 基础设施的未来标准化和部署策略提供信息。

本研究中提出的研究结果强调了在 DNS 基础设施中部署后量子加密算法的技术可行性和实际考虑，特别是在保护 DNSSEC、DNS over TLS、DNS over HTTPS 方面。通过跨关键性能指标（延迟、带宽、CPU 和内存使用情况）评估多个算法类别，这项工作为未来 DNS 安全设计中的明智决策奠定了基础。演示的权衡强调，没有单一算法是普遍最佳的;相反，PQC 方案的适用性在很大程度上取决于其作环境和在 DNS 协议栈中的预期角色。随着抗量子标准的不断发展，使 DNS 安全机制与这些加密技术进步保持一致对于维护全球名称解析系统的长期信任和弹性至关重要。

未来的研究应探索推进后量子安全 DNS 部署的几个关键方向。首先，评估 PQC作的能耗和热行为（尤其是在边缘计算环境中）可以帮助评估其可持续性和可扩展性。其次，将 PQC 机制集成到 DNS-over-QUIC （DoQ） 等新兴传输协议中，将量子弹性扩展到现代低延迟通信层。此外，还需要进一步研究 PQC 如何影响解析器端行为，包括缓存策略和 TTL（生存时间）优化，这对大规模性能和效率至关重要。最后，进行真实世界的用户研究以测量后量子 DNS 部署下的延迟感知和数据包可靠性，将为实际可用性和服务质量影响提供有价值的见解。

未来的工作还应通过在类似生产的环境中部署支持 PQC 的 DNS 来解决这些限制，该设置具有真实世界的流量模式和多个权威区域。特别是，使用分布式测试平台或基于云的 DNS 解析器进行扩展测试可以更深入地了解负载下的性能。此外，应努力衡量协议级弹性，例如 PQC 对有损或移动网络中数据包丢失、重传和握手失败率的影响。最后，鉴于 PQC 标准化的快速发展性质，持续跟踪 NIST 和 IETF 的进展对于使未来的 DNS 部署与批准的加密配置文件保持一致至关重要。