ICANNの最高技術責任者（CTO）を務めるJohn Crain氏が、DNSSECを将来の量子コンピューターによる攻撃から守るため、開発を加速する考えを示した。10月26日付のThe Registerによる独自取材で、バリ島で開催されたICANNの会合に参加したCrain氏は「開発のスピードを上げていく」と発言。対策に残された時間についても「3年なのか5年なのかは分からないが、おそらく10年ではない」との見方を示した。ただし、これは正式な移行期限でも、量子コンピューターの実用化時期を確定的に予測したものでもない。DNSSECは、DNSのデータが正当な発信元から送られ、改ざんされていないことを電子署名で検証する仕組みであり、量子コンピューターによる秘密鍵の解読と偽造署名への対策が課題となる。Cloudflareの公開DNSリゾルバー「1.1.1.1」はすでに耐量子署名の検証に対応しているものの、インターネット全体の移行には、大きくなるDNS応答の転送や、ルートから各ドメインへと続く信頼の連鎖を保護する仕組みが必要だ。

AD

2,420バイトの署名がDNSの通信方式に与える影響

Cloudflareは2026年9月10日、公開DNSリゾルバー「1.1.1.1」で耐量子署名方式「ML-DSA-44」の検証に対応したと発表した。リゾルバーは利用者に代わってDNSの問い合わせを処理し、DNSSECの署名を検証する役割を担う。同社は、現在の暗号方式を破れる量子コンピューターはまだ存在しないと説明しており、今回の対応は将来の脅威に備えるものだ。なお、DNSSECが保護するのはDNSデータの真正性と完全性であり、DNS over HTTPS（DoH）などが担う通信内容の秘匿とは役割が異なる。

今回の移行では、従来のRSAやECDSAの鍵を単純に長くするのではなく、数学的な仕組みが異なる耐量子署名方式への切り替えが必要になる。その際、大きな課題となるのが署名や公開鍵のデータサイズだ。Cloudflareの比較によると、ECDSA P-256の署名が64バイトなのに対し、ML-DSA-44の署名は2,420バイトと約37.8倍に達する。公開鍵も1,312バイトあり、DNSの応答サイズに大きく影響する。ただし、約37.8倍という数字は署名部分だけの比較であり、DNS応答全体のサイズや通信量、応答時間が同じ倍率で増えるわけではない。

この署名サイズは、DNSで一般的に使われるUDP通信の制約を超えている。多くのDNS実装ではUDP応答の上限を1,232バイトに設定しており、RFC 9715が推奨する上限も1,400バイトだ。これらはDNS全体に適用される絶対的な上限ではないが、ML-DSA-44ではヘッダーやDNSレコードを追加する前に、署名だけで両方の値を超えてしまう。そのため、従来のように一つのUDP応答で署名付きのデータを返すことが難しくなる。

UDPパケットの分割を避ける場合、権威DNSサーバーは応答を切り詰めたことを通知し、問い合わせ側は通常、TCPで再試行する。つまり、新しい署名を検証できるようにするだけでなく、大きくなったDNS応答を確実に転送できる環境も必要になる。特に、公開鍵を取得するDNSKEY応答には、鍵そのものに加えて、そのレコード集合を認証する署名も含まれる。移行期間中は新旧両方式の鍵や署名が共存し、鍵の更新時にはさらに多くの鍵が含まれる可能性があるため、通信への影響は単一の署名サイズだけでは判断できない。

一方、IANAのDNSSECアルゴリズム登録簿では、ML-DSA-44にアルゴリズム番号「18」が割り当てられている。ただし、署名と検証に関する実装上の推奨度はいずれも「MAY」であり、必須ではない。アルゴリズム番号の割り当ては導入に向けた前進ではあるものの、DNS全体での対応や、IETFによる正式な標準化の完了を意味するわけではない。

新旧の署名を併用しても、耐量子保護は完成しない

移行期間中、互換性を維持するために従来方式の署名を残せば、古い検証器も引き続きDNSの応答を検証できる。しかし、耐量子署名に対応した検証器まで従来方式の署名だけで応答を受け入れてしまうと、将来その方式を破れる攻撃者に悪用される恐れがある。攻撃者が弱い署名方式での検証に誘導できれば、耐量子署名を導入した意味が失われる。これは「ダウングレード攻撃」と呼ばれ、耐量子暗号への移行で対処すべき重要な問題の一つだ。

DNSSECの検証は、対象ドメインの署名だけで完結するわけではない。権威DNSサーバーが公開する鍵の正当性を確認するには、一つ上の階層にある親ゾーンのDSレコードを利用する。DSレコードには子ゾーンの公開鍵に対応するハッシュ値が含まれており、親ゾーンが認証した情報を通じて、子ゾーンの鍵が正しいことを確認できる。こうした検証をDNSのルートにある信頼アンカーから各階層へとつないでいく仕組みが「信頼の連鎖（Chain of Trust）」である。

Cloudflareは1.1.1.1に、この仕組みを考慮した独自の検証方針を導入したと説明している。具体的には、認証済みの親ゾーンのDSレコード集合に、検証器が対応する耐量子アルゴリズムが含まれている場合、少なくとも一つの耐量子方式による検証経路が成功することを要求する。従来方式の署名だけで検証が成功したと判断するのを防ぎ、ダウングレード攻撃への耐性を高めるためだ。ただし、これはCloudflareが採用した検証方針であり、すべてのDNSSEC検証器に共通する標準動作ではない。

さらに、子ゾーンに耐量子署名を導入するだけでは、信頼の連鎖全体を保護できない。ルートの信頼アンカーから対象ドメインに至るまでのどこかに従来方式だけで保護された部分が残れば、そこが攻撃の足掛かりになり得る。そのため、権威DNSサーバーやリゾルバーに加え、ドメインの登録を扱うレジストラ、親ゾーンを管理するレジストリなどの連携が欠かせない。子ゾーンの鍵に対応するDSレコードを親ゾーンに登録し、最終的にはルートまで耐量子暗号による保護を広げる必要がある。

Cloudflareも9月10日の発表で、検証側の対応に続き、権威DNSサービスでのML-DSA-44による署名と、レジストラによるDSレコードの取り扱いに対応する計画を示している。ただし、この発表だけでは、その後の実装や提供状況まで確認できない。DNSSEC全体の耐量子化には、各事業者による技術的な対応と、それらを結ぶ運用体制の整備が求められる。

AD

MTLで署名処理を効率化しても、TCP通信は残る

大きな署名による負担を軽減するため、複数のデータをまとめて認証する方式も検討されている。2026年10月19日に更新された「ML-DSA-MTL」のInternet-Draft（draft-03）では、マークルツリーラダー（Merkle Tree Ladder：MTL）を利用する仕組みが提案された。DNSSECでは、同じドメイン名とレコード種別を持つDNSレコードの集合をRRsetと呼ぶが、この方式は複数のRRsetを効率的に認証することを目的としている。

ML-DSA-MTLでは、複数のRRsetを認証するための「ラダー」と呼ばれるデータ構造に署名し、それぞれのRRsetが認証対象に含まれることをマークル証明によって確認する。複数のRRsetをまとめて処理することで、基礎となる署名の生成コストを分散できるほか、検証済みのラダーを追跡することで、繰り返しの検証やデータ保存に伴う負担も軽減できる可能性がある。個々のDNS応答ごとに大きな署名を生成・検証する際の負担を抑えようとする方式だ。

ただし、署名処理の効率化と、DNS応答をUDPで転送できるかどうかは別の問題である。現行のdraft-03で定義されているのは、必要な認証情報を含む「full型」の応答のみだ。草案の第10節では、この方式によるfull型の応答は必ずDNS over UDPで扱えるサイズを超えると明記されている。そのため、従来方式よりTCP通信が増えることを想定しており、UDPでの問い合わせ後にTCPで再試行する負担を避けたいクライアントには、対象ゾーンへの問い合わせを最初からすべてTCPで行うことを推奨している。

したがって、MTLを採用すればUDPのサイズ制約も解消できると考えるのは早計だ。ただし、この制約は10月19日版の草案が定義するfull型の応答に関するものであり、将来の拡張方式まで同じ制約を受けると決まったわけではない。また、ML-DSA-MTLは現時点で個人提出のInternet-Draftにとどまっており、IETFの正式標準ではない。ML-DSA-MTL自体に割り当てられるDNSSECアルゴリズム番号も、まだ決まっていない。

署名方式を選ぶ際には、データサイズ以外の要素も考慮する必要がある。ICANNのPaul Hoffman氏が10月2日に公開した耐量子DNSSECアルゴリズムの選定に関する個人草案では、650バイトの署名なら一つだけの場合はUDP応答に収まっても、複数の署名が含まれるとTCPへの切り替えが必要になる可能性を指摘している。署名の生成・検証に必要なCPU処理能力や、秘密鍵を保護するハードウェアセキュリティモジュール（HSM）への対応も重要な評価項目だ。さらに、暗号解析による安全性の検証状況や特許ライセンスも考慮する必要がある。同草案は、こうした選定上の論点を整理したものであり、ICANNやIETFが特定の方式を採用する方針を決めた文書ではない。

DNSSECの耐量子移行はどこまで進んだのか

DNSSECの耐量子化がどこまで進んだかを判断するには、新しい署名方式の導入件数だけでなく、検証器の対応、通信経路、親ゾーンへの委任、ルートまでの信頼の連鎖を分けて確認する必要がある。Cloudflareの実装説明、MTL草案、IANAの登録情報を整理すると、それぞれの工程で進展はあるものの、移行を完了するための条件はまだそろっていない。特に、2,420バイトの署名を確実に転送する仕組みと、新旧方式が併存する環境で安全な検証を維持する仕組みは、署名アルゴリズムそのものとは別に解決すべき課題だ。

工程 確認できた進展 残る課題
新方式の検証 Cloudflareの1.1.1.1が9月10日にML-DSA-44の検証対応を発表。IANAはアルゴリズム番号18を割り当てた 他の検証器や権威DNSサーバーでの署名対応を進める必要がある
DNS応答の転送 ML-DSA-44の署名は2,420バイト。10月19日版MTL草案のfull型応答もUDPのサイズ制約を超える TCPでの再試行や、最初からTCPを利用する通信方式への対応が必要になる
新旧方式を併用する際の検証 1.1.1.1は認証済みの親DSレコードに応じて、耐量子方式による検証経路の成功を要求する 従来方式へのダウングレード攻撃を防ぎ、各検証器の動作を適切に管理する必要がある
親ゾーンからルートまでの保護 親ゾーンのDSレコードを通じて子ゾーンの鍵を認証する既存の仕組みを利用できる 権威DNS、レジストラ、レジストリが連携し、ルートの信頼アンカーを含む各階層を耐量子化する必要がある

この表は、同じ移行に必要な異なる工程を整理したものであり、公式のロードマップやDNS全体の対応率を示すものではない。検証器への実装、アルゴリズム番号の割り当て、個人草案の更新は、それぞれ異なる段階の進展である。また、署名サイズの違いから通信の遅延や移行に必要な年数を推計したものでもない。

Crain氏が表明した開発加速の成果を評価するには、耐量子署名に対応する検証器が増えるだけでなく、大きなDNS応答をTCPで確実に転送できるか、新旧方式の併用による安全性の低下を防げるか、そしてルートまでの信頼の連鎖を保護できるかが重要になる。DNSSECの耐量子化は、暗号アルゴリズムを置き換えるだけでなく、DNSを構成する複数の事業者やシステムが連携して進める必要がある。これらの対応がそろって初めて、将来の量子コンピューターによる署名偽造に対し、個々のドメインだけでなく、そこに至る検証経路全体の安全性を確保できるようになる。