# 1.1.1.1试水后量子DNSSEC

> Cloudflare公共解析器已能验证ML-DSA-44签名，但2420字节的大签名也把真正难题摆上台面：更大的DNS响应如何可靠传输。

_Source: Cloudflare engineering announcement, checked against NIST FIPS 204, the IANA DNSSEC algorithm registry, RFC 9715, and independent technical coverage · 2026-09-11 · 6 min read · Verified against primary sources_

Canonical: https://iyu.app/zh/e/cloudflare-post-quantum-dnssec

## 60 秒版本

Cloudflare称1.1.1.1现已验证ML-DSA-44 DNSSEC签名，为后量子迁移提供互联网规模的解析器测试场。

**要点**

- NIST已经标准化ML-DSA，IANA把ML-DSA-44列为DNSSEC算法18，目前签名和验证均为可选实施。
- 2420字节的ML-DSA-44签名接近ECDSA P-256的38倍，单独就超过常见DNS UDP响应尺寸目标。
- 超大响应可能触发TCP重试，因此带宽、延迟和中间设备兼容性成为核心部署问题。
- 完整信任链仍需权威服务器、注册商、注册局和DNS根区采用后量子签名与降级保护。

**结论.** 这是有意义的解析器端里程碑和压力测试，但不能证明整个DNSSEC已经抗量子。

## 全文

Cloudflare称，**1.1.1.1公共解析器现已验证DNSSEC中的ML-DSA-44签名**。[NIST](https://csrc.nist.gov/pubs/fips/204/final)已经标准化该算法，[IANA](https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml)则把它登记为DNSSEC算法18。这是解析器真正完成的一次升级，但不是整个DNS已经完成抗量子迁移。

> **⚑ Caveat:** 部署状态、流量占比和2029路线图均为**Cloudflare自报**。NIST独立确认ML-DSA标准，IANA独立确认DNSSEC登记；两者都没有独立审计1.1.1.1的生产运行。


### 发生了什么 — 解析器现在能做什么

DNSSEC为DNS记录添加数字签名，让解析器可以沿着从根区、父区到目标域名的信任链验证响应。当前常见算法依赖RSA或椭圆曲线密码，未来足够强的量子计算机可能威胁这些体系。

ML-DSA采用基于格结构的设计。NIST于2024年在FIPS 204中正式发布标准，IANA注册表现在把ML-DSA-44分配为算法18。Cloudflare为1.1.1.1加入了验证能力：域名发布相应记录后，解析器可自动检查。

> **i** 今天还没有能实施这类攻击的量子计算机。DNSSEC保护公开记录的真实性，不是加密秘密数据，因此不属于“现在收集、未来解密”风险。提前开始，是因为全球基础设施协同换代非常慢。


### 数据包压力 — 2420字节为何改变传输

- **2420 B** — 单个ML-DSA-44签名
- **1312 B** — ML-DSA-44公钥
- **64 B** — 对照用ECDSA P-256签名

ML-DSA-44签名接近ECDSA P-256的38倍，而且它单独就超过[RFC 9715](https://www.rfc-editor.org/rfc/rfc9715.html)通常建议的1400字节DNS UDP响应上限；此时还没有计入域名、头部、公钥和其他DNSSEC记录。

- **小型UDP响应:** 通常用一个数据报完成传输，协议开销较低。
- **超大签名响应:** 服务器可把UDP响应标记为截断，要求解析器改用TCP重试。
- **运行成本:** 更多字节、更多连接状态和潜在延迟，需要在中间设备与DNS实现中实测。

TCP回退本来就是正常DNS行为，不等于故障。问题在于它会多频繁发生、在大规模流量下是否可靠。Cloudflare称，启用验证后可以测量签名验证成本、额外带宽和TCP使用量。


### 迁移陷阱 — 新旧签名必须并存

大量解析器尚不理解ML-DSA-44时，域名不能直接删除传统签名。同时发布两套签名可以兼容旧解析器，却可能留下未来的降级路径：旧算法可被伪造后，新解析器仍可能错误接受一条传统路径。

Cloudflare称，1.1.1.1会把父区中经过认证的DS记录作为信号，要求至少一条后量子路径验证成功。这种策略只有在信任链本身得到保护时才有效；任何未升级的父区、注册局或根区仍可能成为薄弱点。


### 现实边界 — 完整迁移还缺什么

- **解析器支持：** 1.1.1.1能验证算法18，其他解析器与软件也需要各自实现。
- **权威签名：** DNS运营者必须能够可靠发布ML-DSA-44公钥和签名。
- **委派支持：** 注册商和注册局需要接受并发布对应DS记录。
- **根区采用：** 完整保护需要后量子信任锚，以及从根向下受保护的每一级委派。
- **运行证据：** 仍需测量响应大小、回退率、延迟、失败模式和密钥轮换表现。

> 一个解析器学会新签名，是迁移起点，不是终点。


### 普通用户 — 无需修改任何设置

已经使用1.1.1.1的人不需要手动启用功能，现有DNSSEC域名也照常验证。真正值得跟踪的是权威DNS、注册商、注册局和根区的采用进度，不应把一次解析器公告误读成整个系统已经抗量子。


## Primary sources

- [Cloudflare: 1.1.1.1 now supports post-quantum DNSSEC](https://blog.cloudflare.com/post-quantum-dnssec-1111/)
- [NIST FIPS 204: Module-Lattice-Based Digital Signature Standard](https://csrc.nist.gov/pubs/fips/204/final)
- [IANA DNS Security Algorithm Numbers registry](https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml)
- [IETF Datatracker: ML-DSA for DNSSEC Internet-Draft](https://datatracker.ietf.org/doc/draft-westerbaan-dnssec-mldsa/)
- [RFC 9715: DNS Transport over TCP implementation requirements](https://www.rfc-editor.org/rfc/rfc9715.html)
- [PPC Land: independent technical coverage](https://ppc.land/cloudflares-1-1-1-1-now-validates-2-420-byte-quantum-safe-dns-signatures/)

---
_Published by iyu (https://iyu.app) — the day's AI news, checked against primary sources and rewritten in plain language. Free to quote with attribution and a link to the canonical URL._