# 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/ja/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バイトの署名はECDSA P-256の約38倍で、一般的なDNS over 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)がDNS over UDP応答に一般的に勧告する1400バイトを超える。ドメイン名、ヘッダー、鍵、ほかのDNSSECレコードはさらに加わる。

- **小さなUDP応答:** 通常は一つのデータグラムで低いオーバーヘッドのまま届く。
- **大きな署名付き応答:** サーバーがUDP応答を切り詰め、リゾルバーにTCPでの再試行を促せる。
- **運用コスト:** バイト数、接続状態、遅延が増え、中間装置とDNS実装で検証が必要になる。

TCPへのフォールバックは通常のDNS動作であり、障害ではない。焦点は発生頻度と大規模運用での信頼性だ。Cloudflareは、検証を有効にすることで署名検証コスト、帯域、追加TCP利用を測定できるとしている。


### 移行の罠 — 新旧署名を併存させる難しさ

多くのリゾルバーがML-DSA-44を理解しない間、ゾーンは従来署名を削除できない。両方を公開すれば互換性を保てるが、将来古いアルゴリズムが破られた際、新しいリゾルバーまで偽造された従来経路を受け入れる恐れがある。

Cloudflareは、1.1.1.1が親ゾーンの認証済みDSレコードを合図にし、少なくとも一つの耐量子経路を必須にすると説明する。ただし信頼連鎖そのものが保護されなければ、未対応の親、レジストリ、ルートが弱点として残る。


### 現実との境界 — 完全移行に残る工程

- **リゾルバー対応：** 1.1.1.1以外のリゾルバーやソフトウェアにも実装が必要である。
- **権威署名：** DNS運用者がML-DSA-44の鍵と署名を安定して公開する必要がある。
- **委任対応：** レジストラとレジストリが対応するDSレコードを受け入れ、公開する必要がある。
- **ルート採用：** 完全な保護には耐量子トラストアンカーとルート以下の委任保護が要る。
- **運用証拠：** 応答サイズ、再試行率、遅延、障害、鍵更新を実測する必要がある。

> 一つのリゾルバーが新署名を学んだ段階は、移行の始まりであって終わりではない。


### 利用者への影響 — 設定変更は不要

1.1.1.1を利用中なら手動で有効にする必要はなく、既存のDNSSECゾーンも従来通り検証される。重要なのは権威DNS、レジストラ、レジストリ、ルートの採用を追うことであり、リゾルバーの発表だけで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._