Double-Signed Fragmented DNSSEC for Countering Quantum Threat

基本信息

• 论文ID: 2411.07535
• 标题: Double-Signed Fragmented DNSSEC for Countering Quantum Threat
• 作者: Syed W. Shah, Lei Pan, Dinh Duc Nha Nguyen, Robin Doss, Warren Armstrong, Praveen Gauravaram
• 机构: Deakin Cyber Research and Innovation Centre (Australia), Cyber Security Cooperative Research Centre (Australia), Quintessence Labs (Canberra), Tata Consultancy Services (Brisbane)
• 分类: cs.CR (Cryptography and Security)
• 发表会议: C'25, November 2025 (初步版本已被ITNAC 2025接收)
• 论文链接: https://arxiv.org/abs/2411.07535

摘要

DNSSEC作为DNS安全扩展，对于准确地将域名转换为IP地址至关重要。数字签名为这种可靠转换提供了基础，然而量子计算机的发展使传统数字签名变得脆弱。NIST最近选择了能在传统计算机上运行并抵御量子计算机攻击的后量子数字签名。由于这些后量子数字签名仍处于早期开发阶段，在彻底安全分析之前，用后量子候选方案替换DNSSEC中的前量子数字签名存在风险。本研究探讨在DNSSEC中采用"双重签名"的可行性，结合后量子数字签名和经典签名。双重签名将同时提供针对量子威胁和未知非量子攻击的保护。然而，两个签名的包含与DNSSEC响应的最大允许大小（1232B，由物理链路MTU限制）存在冲突。为解决此问题，本文采用应用层分片方法处理带有双重签名的DNSSEC响应。在OQS-BIND上实现的解决方案表明，双重签名和应用层分片对解析过程效率影响微小，适合在量子计算机完全实现之前的过渡期使用。

研究背景与动机

1. 核心问题

DNSSEC通过数字签名确保DNS响应的真实性和完整性，但面临量子时代的三重困境：

• 量子威胁：密码学相关量子计算机(CRQC)可通过Shor算法在多项式时间内破解基于整数分解和离散对数的传统签名
• 后量子不成熟：NIST选定的后量子签名(FALCON, DILITHIUM, SPHINCS+)尚未经过充分的密码学分析，可能存在可被经典计算机利用的设计缺陷
• 过渡期风险：从现在到CRQC完全实现的"过渡期"内，单独依赖传统或后量子签名都存在安全隐患

2. 问题重要性

• DNS是互联网基础设施的核心，任何安全漏洞都可能将用户导向恶意服务器
• 根据ENISA建议，过渡期内简单替换密码算法可能降低整体安全性
• 未公开的CRQC突破或后量子算法漏洞都可能使DNSSEC失效

3. 现有方法局限性

• 仅用传统签名：无法抵御未来的量子攻击
• 仅用后量子签名：可能存在未知的经典攻击向量
• 现有分片方案：ARRF使用非标准RR可能导致中间盒兼容性问题；QBF未考虑双重签名场景
• TCP回退机制：许多名称服务器缺乏TCP支持，且TCP不如UDP轻量

4. 研究动机

采用"双重签名"策略（detached-message interface）：

• 只要一个签名安全，整体系统就保持安全
• 为过渡期提供最大安全保障
• 需要解决双重签名导致的消息大小超限问题（>1232B触发IP层分片）

核心贡献

1. 完整的双重签名DNSSEC实现：开发了基于Docker的DNSSEC测试平台，使用商业级BIND9软件，能在单个UDP响应消息中同时处理前量子和后量子签名及公钥
2. 应用层分片与重组机制：针对双重签名场景，设计了改进的QBF分片方案：
   • 利用z-bits标识后量子算法类型
   • 使用TTL偏移量维护RR原始顺序以避免压缩指针错误
   • 支持所有前量子(ECDSA256, RSASHA256)与后量子(FALCON512, DILITHIUM2, SPHINCS+)组合
3. BIND9源码修改：深入研究并修改BIND9解析器组件，使其能够在标记响应为已认证前验证两个签名
4. 性能评估：通过实证分析证明双重签名对DNSSEC解析时间影响可忽略（<9%增幅），确认其适用于过渡期

方法详解

任务定义

输入：DNS查询（如test.example.com的A记录）
输出：带有双重签名验证的IP地址
约束条件：

• UDP消息大小≤1232B（避免IP层分片）
• 同时验证前量子和后量子签名
• 保持与现有DNS基础设施的兼容性

双重签名架构设计

1. 签名生成（名称服务器端）

采用分离消息接口(detached-message interface)：

• 使用BIND9工具生成两对密钥(ZSK和KSK)
• 对同一RRSet独立生成两个签名：
  • 前量子签名X（ECDSA256或RSASHA256）
  • 后量子签名Y（FALCON512/DILITHIUM2/SPHINCS+）
• 两个RRSIG和DNSKEY都存储在签名区文件中

示例（图13）：
test0.socratescrc. 3600 IN RRSIG A 13 ... (ECDSA签名)
test0.socratescrc. 3600 IN RRSIG A 249 ... (后量子签名)

2. 验证策略（解析器端）

修改BIND9验证逻辑：

• 独立验证两个签名
• 仅当两个签名都通过验证时才接受响应
• 提供针对量子和经典攻击的双重保护

应用层分片机制

核心挑战

典型双重签名响应大小：

• A记录响应：~2500B（ECDSA+FALCON512最小组合）
• DNSKEY响应：4462B（RSASHA256+FALCON512）
• 远超1232B阈值

分片策略

基本原则：

• 前量子RRSIG和DNSKEY始终在第一个分片中完整发送（尺寸较小）
• 后量子签名/密钥根据需要分片

A记录响应分片（图8a）：

1. 第一个分片包含：Header + Question + 完整前量子RRSIG/DNSKEY + 部分后量子RRSIG
2. 解析器从第一分片推断总分片数
3. 并行请求剩余分片（格式：?n?domain_name）

DNSKEY响应分片（图8b）：

• 某些组合（如RSASHA256）导致第一分片无法容纳任何后量子数据
• 创新解决方案：

Z-bits标识法：

利用RFC 1035中的z-bits（3位）：
- 编码后量子算法类型（FALCON/DILITHIUM/SPHINCS+）
- 解析器根据z-bits和已收到的前量子RR推断总大小

TTL偏移量机制：

问题：DNS压缩指针依赖RR顺序
解决：在DNSKEY响应的TTL字段添加偏移量
作用：重组时恢复RR原始位置，避免"bad compression pointer"错误

工作流程（图10）

名称服务器daemon：

1. 拦截DNS响应，检查大小是否>1232B
2. 计算所需分片数
3. 设置z-bits（如需要）和TTL偏移量
4. 设置TC flag=1，发送第一分片
5. 缓存其余分片

解析器daemon：

1. 接收第一分片，检查TC flag
2. 解析z-bits确定后量子算法
3. 利用前量子RR信息推断总分片数
4. 并行请求所有剩余分片（?2?test.socrates, ?3?test.socrates...）
5. 收集所有分片后重组：
   • 使用TTL偏移量恢复原始RR顺序
   • 重置TC flag和其他header值
6. 将完整消息传递给OQS-BIND验证

技术创新点

1. 标准RR兼容：不同于ARRF的自定义RR，使用标准DNS格式确保中间盒兼容性
2. z-bits复用：创新性地利用未充分使用的header bits解决DNSKEY响应信息不足问题
3. TTL偏移量方案：解决DNS压缩机制与分片重组的冲突，这是双重签名场景特有的问题
4. 并行分片请求：解析器并行获取所有分片，最小化延迟
5. 算法无关性：支持所有NIST选定的后量子算法与常见前量子算法的任意组合

实验设置

测试平台架构

基础设施：

• Amazon EC2 t2.xlarge实例（4核2.3GHz Intel Xeon, 16GB RAM）
• Docker容器化部署（Docker 25.0.3）
• 组件：Client, Resolver, Root Server, Authoritative Server

软件栈：

• OQS-BIND：基于BIND9的后量子增强版本
  • OpenSSL 1.1.1
  • OQS liboqs 0.7.2
  • 支持FALCON512, DILITHIUM2-AES, SPHINCS+-SHA256-128S（128位安全级别）
• 修改的QBF daemon：实现双重签名分片/重组逻辑

网络拓扑（图11）：

Client → Resolver → Root Server → Authoritative Server
        ↑                            ↓
        └────────────────────────────┘

数据集设置

• 测试域名：10个A记录（test0.socratescrc - test9.socratescrc）
• 签名组合：6种双重签名配置
  • 前量子：ECDSA256, RSASHA256
  • 后量子：FALCON512, DILITHIUM2, SPHINCS+-SHA256-128S
• 信任链：DS记录正确配置，建立完整信任链

评价指标

1. 解析时间：从查询发送到收到验证响应的端到端延迟
2. 分片数量：A记录和DNSKEY响应所需的分片数
3. 性能开销：双重签名相对于单一后量子签名的时间增幅百分比

网络条件模拟

使用Linux tc工具模拟：

• 带宽：50 Mbps
• 延迟：10 ms
• 模拟真实互联网条件

实验方法

1. 对每个域名迭代查询解析器
2. 记录每次查询的解析时间
3. 计算10次查询的平均解析时间
4. 对比双重签名与单一后量子签名的性能

实验结果

分片数量分析（表1）

关键发现：

• FALCON和DILITHIUM组合仅增加1个分片
• SPHINCS+组合不增加额外分片（daemon优化移除非关键RR）
• 分片增量可控，未导致指数级增长

平均解析时间

FALCON组合（表2）：

DILITHIUM组合（表3）：

SPHINCS+组合（表4）：

主要结果

1. 性能开销可接受：
   • 所有双重签名组合的性能开销<9%
   • 远低于TCP回退的开销（通常>50%）
2. 最优配置：
   • FALCON+RSASHA: 204.5ms（最快双重签名）
   • DILITHIUM+RSASHA: 220.7ms
   • 比SPHINCS+单签名(245.6ms)快14-22%
3. RSA优于ECDSA：
   • 所有组合中RSA验证速度更快
   • 例如：DILITHIUM+RSA(220.7ms) vs DILITHIUM+ECDSA(225.6ms)
4. 签名验证成功率：
   • 所有组合的双重签名均正确验证
   • 修改后的BIND9解析器成功验证两个签名（图14）

实验发现

1. 基于格的算法优势：
   • FALCON和DILITHIUM（格基）签名尺寸较小
   • 解析时间显著优于SPHINCS+（哈希基）
2. SPHINCS+的劣势：
   • 签名尺寸最大（23个分片用于A记录）
   • NIST选择它主要为避免过度依赖格基算法
   • 在双重签名场景下不是最优选择
3. 分片重组可靠性：
   • TTL偏移量机制有效解决压缩指针问题
   • z-bits方案准确传达算法信息
   • 无消息丢失或验证失败
4. 安全性增益：
   • 双重签名提供"fail-safe"机制
   • 即使格基算法被突破，RSA/ECDSA仍提供经典安全性
   • 即使量子计算机实现，后量子算法提供保护

相关工作

后量子DNSSEC研究

1. Müller et al. (2020)：
   • 分析NIST第三轮候选算法用于DNSSEC的需求
   • 未考虑双重签名方案
2. Beernink (2022)：
   • 提出带外传递大型密钥的方法
   • 未解决双重签名的消息大小问题
3. Goertzen & Stebila (2022) - ARRF：
   • 请求式应用层分片
   • 引入RRFRAGS伪RR（非标准）
   • 存在内存耗尽攻击风险
4. Rawat & Jhanwar (2024) - QBF：
   • 基于QName的分片，使用标准RR
   • 并行分片请求提高效率
   • 不支持双重签名

本文贡献对比

密码学组合器研究

• ENISA (2022)推荐过渡期使用混合密码系统
• 本文是首个在DNSSEC中实现并评估双重签名的工作
• 采用detached-message interface（更易集成）

结论与讨论

主要结论

1. 技术可行性：双重签名DNSSEC在现有基础设施上完全可行，无需协议级修改
2. 性能可接受：性能开销<9%，远低于TCP回退，不会显著影响用户体验
3. 安全性增强：提供针对量子和经典攻击的双重保护，适合过渡期部署
4. 最佳实践：推荐使用FALCON或DILITHIUM与RSA的组合，平衡安全性和性能

局限性

1. 测试规模有限：
   • 仅在单个EC2实例上测试
   • 未模拟大规模互联网部署场景
   • 缺乏真实网络流量测试
2. 网络条件简化：
   • 仅模拟50Mbps带宽和10ms延迟
   • 未考虑丢包、抖动等复杂情况
   • 未测试不同MTU环境
3. daemon开销：
   • 分片/重组逻辑在独立daemon中实现
   • 进程间通信可能引入额外延迟
   • 未直接集成到BIND9核心
4. 中间盒兼容性：
   • 未全面测试防火墙、NAT等中间盒行为
   • z-bits复用可能在某些实现中引起问题
5. 缓存影响：
   • 未分析分片对DNS缓存效率的影响
   • 多个分片可能增加缓存复杂度
6. 安全性分析不足：
   • 未进行形式化安全证明
   • 未评估针对DoS攻击的鲁棒性
   • 未分析分片重组的侧信道风险

未来方向

1. BIND9直接集成：
   • 将分片逻辑直接集成到BIND9核心
   • 预期可进一步降低解析时间
2. 大规模部署测试：
   • 在真实DNS基础设施上进行试点
   • 评估与各类中间盒的兼容性
3. 优化算法选择：
   • 根据查询类型动态选择算法组合
   • 探索自适应分片策略
4. 标准化推进：
   • 向IETF提交草案
   • 推动双重签名成为过渡期标准实践
5. 安全性增强：
   • 添加DoS防护机制
   • 研究分片重组的时序攻击防御

深度评价

优点

1. 问题定位准确：
   • 清晰识别过渡期的安全困境
   • 双重签名策略符合ENISA等权威机构建议
   • 解决了实际部署中的关键技术障碍
2. 技术方案完整：
   • z-bits和TTL偏移量是创新性的工程解决方案
   • 兼顾性能、兼容性和安全性
   • 实现细节充分（源码修改、daemon设计）
3. 实验设计合理：
   • 使用商业级BIND9软件增强实用性
   • 测试了所有主流算法组合
   • 网络条件模拟符合实际场景
4. 结果说服力强：
   • 性能数据清晰（<9%开销）
   • 验证了所有组合的正确性
   • 提供明确的部署建议（FALCON/DILITHIUM+RSA）
5. 工程价值高：
   • 基于开源OQS-BIND，可复现性好
   • Docker化部署便于推广
   • 为实际部署提供了可行路径

不足

1. 理论分析欠缺：
   • 缺乏双重签名方案的形式化安全证明
   • 未讨论签名组合的密码学强度
   • 对"一个签名失效另一个仍安全"的假设缺乏严格论证
2. 评估范围有限：
   • 仅10个测试域名，样本量小
   • 未测试高负载、高并发场景
   • 缺乏长期稳定性测试
3. 与现有方案对比不足：
   • 未与TCP回退进行直接性能对比
   • 未评估相对于EDNS(0) padding等替代方案的优势
   • 缺少与纯FALCON、纯DILITHIUM部署的安全性对比分析
4. 实用性考虑不全：
   • 未讨论密钥管理复杂度（两套密钥）
   • 未分析对现有DNSSEC基础设施的升级成本
   • 缺乏向后兼容性测试（旧版resolver）
5. 写作可改进：
   • 某些技术细节描述冗长（如Section 2的DNS基础）
   • 图表可更清晰（图8、图10较复杂）
   • 缺少算法伪代码

影响力

对领域的贡献：

• 开创性：首个实现并评估DNSSEC双重签名的工作
• 时效性：及时响应NIST PQC标准化进程
• 实用性：提供了可立即部署的过渡方案

实用价值：

• 短期：为DNS运营商提供过渡期安全增强方案
• 中期：为IETF标准化提供实证数据
• 长期：为其他协议的量子安全过渡提供参考

可复现性：

• ✓ 基于开源软件（OQS-BIND）
• ✓ 详细的实现描述
• ✗ 代码未公开发布（论文中未提及GitHub链接）
• ✓ Docker化部署降低复现难度

潜在影响：

• 可能推动DNS社区采纳双重签名策略
• 为其他应用层协议（如TLS, SSH）提供分片策略参考
• 有助于加速后量子密码学的实际部署

适用场景

理想应用场景：

1. 关键基础设施DNS：金融、政府等对安全要求极高的域名
2. 过渡期部署：2025-2030年CRQC威胁日益临近但后量子算法仍需验证的阶段
3. 高价值目标：容易受国家级攻击者威胁的组织

不适用场景：

1. 资源受限环境：IoT设备、嵌入式系统（计算和存储开销）
2. 低延迟要求：实时通信系统（额外8%延迟可能不可接受）
3. 后量子时代：一旦后量子算法完全成熟，双重签名的必要性降低

部署建议：

• 优先在根服务器和TLD服务器部署
• 使用FALCON+RSA或DILITHIUM+RSA组合
• 与现有DNSSEC基础设施共存（渐进式升级）
• 建立监控机制跟踪性能和安全性

参考文献（关键文献）

1. Shor (1994): "Algorithms for quantum computation" - 量子威胁的理论基础
2. NIST PQC Standardization: FALCON, DILITHIUM, SPHINCS+算法规范
3. RFC 4034: DNSSEC资源记录规范
4. RFC 6891: EDNS(0)扩展机制
5. ENISA (2022): "Post-Quantum Cryptography Integration Study" - 双重签名策略的政策依据
6. Goertzen & Stebila (2022): ARRF分片方案
7. Rawat & Jhanwar (2024): QBF分片方案（本文的直接基础）

总结

本文针对DNSSEC量子安全过渡期的独特挑战，提出了一个工程上可行的双重签名解决方案。通过巧妙的应用层分片设计（z-bits标识、TTL偏移量），成功解决了双重签名导致的消息超限问题。实验证明性能开销可控（<9%），适合实际部署。这是一个典型的"工程驱动研究"案例，虽然理论创新有限，但工程价值显著，为DNS社区提供了及时且实用的过渡方案。论文的主要价值在于首次实现和验证，而非理论突破，这在应用密码学领域同样重要。建议作者在后续工作中补充形式化安全分析和大规模部署测试，并推动代码开源以增强影响力。