なぜ今、ポスト量子DNSSECなのか
DNSの応答はデフォルトでは認証されません。攻撃者が応答を偽造できれば、ユーザーを任意のアドレスへ誘導できてしまいます。DNSSECはDNSレコードに署名を付与することでこれを防ぎます。1.1.1.1のような検証リゾルバは、ルートから対象ドメインまで署名チェーンをたどり、応答が真正で改ざんされていないことを確認します。
問題は、現在使われているDNSSECアルゴリズムのほとんど（RSA、ECDSA）が将来の量子コンピュータに脆弱である点です。2030年頃に十分強力な量子コンピュータが登場し秘密鍵を復元できると仮定すると、攻撃者は検証器が受理する偽造署名を生成できます。DNSSECは機密性ではなく真正性を保証する仕組みのため「harvest now, decrypt later」攻撃の対象ではありませんが、アルゴリズムの移行には権威サーバ、レジストリ、レジストラ、検証リゾルバ全体の調整が必要です。特にルートゾーンの署名鍵が破られると、配下のすべてのゾーンに対して偽造検証パスを作れる「一度破れば全ゾーン偽造」のシナリオが成立します。
Cloudflareは2029年までの完全なポスト量子セキュリティを目標に掲げており、今回の1.1.1.1におけるML-DSA-44検証のデフォルト有効化はその第一歩です。背景とロードマップの全体像は根拠資料で確認できます。
核心的な課題：2,420バイト署名が生む連鎖的な影響
ML-DSA-44の署名は1つあたり2,420バイトです。従来のECDSA P-256署名（64バイト）の約38倍に相当します。このサイズがなぜ問題になるのか、まずは表で整理しましょう。
| アルゴリズム | DNSSEC番号 | 公開鍵サイズ | 署名サイズ |
|---|---|---|---|
| RSA-2048/SHA-256 | 8 | 260 bytes | 256 bytes |
| ECDSA P-256 | 13 | 64 bytes | 64 bytes |
| ML-DSA-44 | 18 | 1,312 bytes | 2,420 bytes |
DNS over UDPの実質的な上限は一般に1,232バイト（IPv6の最小MTU 1,280バイトを考慮）、最近のRFC 9715では1,400バイトが推奨されています。ML-DSA-44の署名1つでこの予算を単独で超過するため、権威サーバは切り詰めた応答（truncated）を返し、リゾルバはTCPやDoT/DoHで再試行することになります。
実際に1.1.1.1へ問い合わせると、この流れが確認できます。
# まずUDPで試行 → 切り詰め → TCPで再試行
$ dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssec
;; WARNING: truncated reply from 1.1.1.1@53(UDP), retrying over TCP
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 17546
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 3; AUTHORITY: 0; ADDITIONAL: 1
;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 1232 B; ext-rcode: NOERROR
;; ANSWER SECTION:
valid.mldsa44.dnstest.dev. 0 IN A 188.114.97.0
valid.mldsa44.dnstest.dev. 0 IN A 188.114.96.0
valid.mldsa44.dnstest.dev. 0 IN RRSIG A 18 4 0 20260910114537 20260909104537 23176 valid.mldsa44.dnstest.dev. Qoycouhsc...
;; Received 2563 B
;; From 1.1.1.1@53(TCP) in 20.7 ms
Cloudflare Radarによると、1.1.1.1へのクエリの約85%がUDPで到着し、Big Pineappleプラットフォーム全体では約60%がUDPです。残りの40%はすでにTCP/DoT/DoHを利用しており、トランスポートの多様化自体は運用上珍しいことではありません。ただし、ML-DSA-44の応答は権威サーバ側で追加のTCP再試行を誘発しうるため、コストとして見積もる必要があります。
ダウングレード攻撃という落とし穴
移行期間中は旧リゾルバとの互換性のため、従来アルゴリズムとML-DSA-44を併記して公開する必要があります。しかしRFC 6840は「検証器は有効なパスを1つ受理すればよい」と規定しています。つまりECDSAが破られた後でも、攻撃者がECDSAのみの偽造応答を送れば、リゾルバがこれを受理してしまうダウングレード経路が生じます。
1.1.1.1はこれを防ぐため、親ゾーンが公開するDSレコードを認証シグナルとして利用します。DS RRsetに対応するポスト量子アルゴリズムが含まれていれば、ローカルポリシーで「ポスト量子検証パスを最低1つ必須」とする仕組みです。RFC 4035がローカルリゾルバのポリシーで追加署名の検証可否を決められることを許容しているため、このアプローチが成立します。
展望と注意事項
エコシステム全体での移行が不可欠
ML-DSA-44検証をリゾルバに実装するのはあくまで第一段階です。完全なポスト量子信頼チェーンを構築するには、以下すべてが必要になります。
- 権威サーバ：ML-DSA-44によるゾーン署名
- レジストラ：対応するDSレコードの受付・提出
- レジストリ：親ゾーンへのDSレコード公開
- ルートゾーン：ML-DSA-44の採用とトラストアンカーの移行
どこか一箇所でもポスト量子保護が欠けると、その地点がダウングレードポイントになります。ゾーン鍵を頻繁にローテーションしても解決しません。攻撃者はチェーン上流の脆弱な鍵を1つ狙えばよいからです。
実務上の注意点
- UDP切り詰めは正常動作：ML-DSA-44応答におけるtruncated応答はバグではなく設計された挙動です。監視でTCP再試行の増加を異常と誤検知しないようにしてください。
- ファイアウォール/プロキシの点検：TCP 53番、DoT（853）、DoH（443）の経路が実際に開放されているか確認が必要です。UDPのみ許可された環境ではML-DSA-44ゾーンの解決が失敗する可能性があります。
- DSレコードの配布順序：親ゾーンのDSが先に公開されないと、ダウングレード保護は機能しません。
- クライアント側の検証：1.1.1.1利用者は特別な設定は不要ですが、社内リゾルバを運用している場合はML-DSA-44対応状況を別途確認してください。
次のステップ学習の方向性
dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssecで直接テストし、TCP再試行の流れを観察しましょう。- Cloudflareの「Is your DNS resolver post-quantum ready?」ツールで現在利用中のリゾルバを点検してください。
- ML-DSA for DNSSECのInternet-DraftとRFC 4035のローカルポリシー条項を読むと、ダウングレード防止設計への理解が深まります。
- TLS側のポスト量子移行（X25519Kyber768など）と比較すると、「トランスポート層 vs 署名層」の違いが明確になります。
まとめ：今すぐやるべきこと
1.1.1.1を利用している場合、特別に変更する必要はありません。ゾーンが必要なDNSSECレコードを公開すればML-DSA-44検証は自動的に行われ、既存のDNSSECゾーンは従来どおり検証されます。Cloudflareは次のステップとしてAuthoritative DNSのML-DSA-44署名サポートとRegistrarのDSレコードサポートを無償提供する予定で、署名生成からDNSKEY公開、転送、検証までの全経路を実際に試験できるようになります。
量子コンピュータが明日RSAを破るわけではありませんが、DNSSECの移行は数年単位の調整作業です。今1.1.1.1で大規模テストを始める理由はここにあります。