Skip to content
Published on

2026年10月11日、ルートKSKが変わる — 今ルートゾーンに実際に入っているもの

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに — 87日後に起きること

2026年10月11日、DNSルートゾーンの鍵署名鍵(KSK)がKSK-2017からKSK-2024に変わります。今日が7月16日なので、残り87日です。

この一文は2通りに読めます。検証(validation)をしないリゾルバを使っているなら、これはニュースではありません。何も起きません。DNSSEC検証を行うリゾルバを運用していて、トラストアンカーが更新されていなければ、その日そのリゾルバはすべての名前に対してSERVFAILを返し始めます。ルートを信頼できなければ、その下すべてを信頼できないからです。

ICANNのFAQはこの状況を控えめに表現しています — 準備ができていない状態でDNSSECを有効にしていた場合「重大な財務的影響(significant financial impact)」を受ける可能性があり、エンドユーザーはドメインを問い合わせるたびにエラーを目にし、それがサポートへの問い合わせにつながりかねないと。

本稿は抽象的な説明の代わりに、ルートゾーンを直接開くところから始めます。

今ルートゾーンに実際に何があるか

ルートサーバーに直接問い合わせればいいだけです。以下は2026年7月16日に私自身が実行した結果です。

$ dig . DNSKEY +dnssec +norec @a.root-servers.net

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8931
;; flags: qr aa; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
.  172800  IN  DNSKEY  256 3 8 AwEAAeCYD6Z7WWKVLeuWgowKP+3g...   ; ZSK
.  172800  IN  DNSKEY  257 3 8 AwEAAaz/tAm8yTn4Mfeh5eyI96WS...   ; KSK-2017
.  172800  IN  DNSKEY  257 3 8 AwEAAa96jeuknZlaeSrvyAJj6ZHv...   ; KSK-2024
.  172800  IN  RRSIG   DNSKEY 8 0 172800 20260801000000 (
                                         20260711000000 20326 . ...

;; MSG SIZE  rcvd: 1139

ここで読み取るべき点がいくつかあります。

レコードは4つ。フラグ256のZSKが1つ、フラグ257のKSKが2つ(KSK-2017とKSK-2024)、そしてRRSIGが1つです。両方のKSKはすでに何年もゾーンに並んで載っています。

ところがRRSIGは1つだけで、署名した鍵タグは20326です。これはKSK-2017です。つまり今日時点でルートDNSKEYセットに署名している鍵は依然としてKSK-2017ひとつなのです。KSK-2024はゾーンに載っているだけで、まだ何にも署名していません。10月11日に変わるのは正確にはこの点です — 署名者が20326から38696へ移ります。

署名の有効期間も見えます。20260711000000から20260801000000まで、つまり7月11日から8月1日までです。ルートKSK署名は四半期ごとに開かれる鍵署名式(key ceremony)で事前に生成され、スロット単位で公開されます。

そして応答サイズは1139バイトです。この数字は後でまた出てきます。

2つの鍵の正体 — IANAトラストアンカーファイル

IANAが公開しているトラストアンカーファイルを取得して実際にパースすると、こうなります。

id=Kjqmt7v  tag=19036  alg=8  validFrom=2010-07-15  validUntil=2019-01-11  (公開鍵なし)
id=Klajeyz  tag=20326  alg=8  validFrom=2017-02-02  validUntil=(なし)     RSA 2048ビット、e=65537
id=Kmyv6jo  tag=38696  alg=8  validFrom=2024-07-18  validUntil=(なし)     RSA 2048ビット、e=65537

3点押さえておきます。

第一に、ファイルには鍵が3つ入っています。19036はKSK-2010で、2019年に廃止されvalidUntilが刻まれています。このファイルをパースするコードを自分で書くなら、validFromとvalidUntilは必ず見なければなりません。「ファイルにある鍵をすべてトラストアンカーに入れる」という素朴な実装は、すでに死んだ鍵まで取り込んでしまいます。

第二に、KSK-2024のvalidFromは2024-07-18です。これはルートゾーンに公開された日ではなく、IANAファイルに載った日です。この日付は後でまた意味を持ちます。

第三に、最も重要な点 — 3つの鍵すべてがアルゴリズム8です。そして公開鍵を直接デコードしてみると、KSK-2017とKSK-2024はどちらも指数65537のRSA 2048ビット鍵です。つまり今回のロールオーバーは鍵を変えますが、暗号アルゴリズムは変わりません。この話は後で別立てにします。

8段階、6年

ICANNのFAQ(2026年5月22日付)によれば、KSKのライフサイクルは約6年にわたる8つの段階で構成され、鍵が実際に署名に使われる期間は約3年です。各段階は鍵署名式に紐づいています。

Phase A  鍵生成            2024年4月    最初の鍵管理施設でKSK-2024を生成
Phase B  鍵複製            2024年7月    2番目の施設へ複製 -> 運用投入の資格を得る
Phase C  最初の署名生成     2024年10月   Phase Dで使う署名を事前生成
Phase D  公開              2025年2月    KSK-2024がルートゾーンに登場
Phase E  ロールオーバー     2026年第4四半期  KSK-2024だけがルートゾーンに署名   <- 2026-10-11
Phase F  失効              2027年第1四半期  KSK-2017をルートゾーンから除去
Phase G  削除1             2027年第2四半期  最初の施設のHSMでKSK-2017を破棄
Phase H  削除2             2027年第3四半期  2番目の施設のHSMでKSK-2017を破棄

ここでささやかながら正直に指摘しておくべき食い違いが1つあります。ICANNのFAQはPhase D(公開)を「2025年2月」と記していますが、ルートゾーンを運用するVerisignは、KSK-2024がルートゾーンに登場した日を2025年1月11日と明記しています。Verisign側の日付は自社データと符合しており、後述する30日ホールドダウンの後、採用率が2月10日から急上昇したという観測と正確に一致するからです。実際にゾーンに載った日は1月11日と見るのが正しそうです。

ところで、なぜよりによって毎回10月11日なのでしょうか。偶然ではありません。ICANNのアルゴリズムロールオーバー提案書がその構造を説明しています — 各四半期は約10日ずつの公開スロット9個に分かれており、鍵の変更は四半期の11日目、つまりスロット2で公開されます。第4四半期は10月1日に始まるので、スロット2は10月11日になります。2017年に予定されていたロールオーバー日も、実際に実行された2018年のロールオーバー日も10月11日だったのはこのためです。

RFC 5011 — なぜほとんどの人は何もしなくていいのか

ルートゾーンには親がありません。.comの鍵はルートゾーンのDSレコードが保証しますが、ルートの鍵を保証してくれる上位ゾーンは存在しません。だからリゾルバはルートKSKをトラストアンカーとして直接設定する必要があります。では、その鍵が変わるときはどうするのか — それがRFC 5011(Automated Updates of DNS Security (DNSSEC) Trust Anchors、現在はInternet Standard)です。

動作はこうです。新しいKSKがトラストポイントのDNSKEYセットに初めて現れると、リゾルバはそれを候補として記憶します。そしてその鍵が有効な署名付きで存在し続けると、Add Hold-Downタイマーが動き出します。RFC 5011の定義をそのまま訳すと、Add Hold-Down時間は「30日、またはその新しい鍵を最初に含んだトラストポイントDNSKEYセットの元のTTL満了時間のうち長い方」です。この条件の目的は明示的です — リゾルバが鍵を受け入れる前に、新しい鍵を含む検証済みDNSKEYセットを最低2回は見るようにするためです。ルートDNSKEYのTTLは上記のdig結果で172800秒(2日)なので、実際には30日の方が支配的になります。

30日が経つと、リゾルバは新しい鍵を永続的なトラストアンカー設定に加えます。運用者は何もしていません。

これが今回のロールオーバーがほとんどの人にとって非事件である理由です。KSK-2024は2025年1月からルートゾーンに載っており、RFC 5011を実装したリゾルバはすでに2025年2月にそれを受け入れています。10月11日に署名者が変わっても、そのリゾルバはすでに新しい鍵を知っているので、何も起きません。

RFC 5011には知っておく価値のある条項がもう2つあります。1つは、準拠リゾルバがトラストポイントごとにSEP鍵を最低5個は管理できなければならないということ。もう1つは失効(revocation)の規則で、これが次節の核心です。

10月11日の崖 — そしてよくある誤解

このロールオーバーを扱った記事でこういう記述を何度も見かけました。「10月11日以降もKSK-2017はDNSKEYセットに残っており、失効するのは2027年1月なので、期限を逃した運用者にはそれまで直す最後のチャンスがある。」

これは誤りです。 正確に言えば、時間があるという部分は正しいのですが、「それまでは動く」という含意が誤りです。

DNSSEC検証の連鎖をたどれば理由が見えます。リゾルバがルートDNSKEYセットを信頼するには、そのセットに付いたRRSIGのうち自分がトラストアンカーとして持つ鍵で署名されたものが必要です。ICANNのFAQはPhase Eをひと言で説明しています — 「KSK-2024だけがルートゾーンに署名する(Only KSK-2024 is used to sign the root zone)」。つまり10月11日以降、DNSKEYセットのRRSIGは38696のものひとつだけになります。

KSK-2017しか信頼しないリゾルバにとっては、DNSKEYセットの中にKSK-2017が見えることは何の助けにもなりません。そのセットを検証する方法がないからです。自分が知る鍵で署名されたRRSIGがないのですから。そのリゾルバは10月11日にその場で死にます。2027年1月ではありません。

では、なぜKSK-2017をあえてゾーンに残しておくのでしょうか。答えはRFC 5011の失効規則にあります。RFC 5011は、鍵をセットから外すだけでは失効にならないよう設計されています。文書の説明をそのまま訳すと、失効ビットがなければ、ある鍵BがAを単に除いた鍵セットを公開するだけでAを無効化できてしまうため、それを防ぐために該当DNSKEYの秘密鍵を知っている者だけがそのDNSKEYを失効させられるメカニズムを加えた、ということです。

具体的にRFC 5011はこう規定します — 鍵が失効したと見なされるには、リゾルバがその鍵を自己署名された(self-signed)RRSetの中でREVOKEビットが1に設定された状態で見る必要があります。そして自己署名されたRRSetとは、そのDNSKEYを含み、かつその鍵で検証されるRRSIGが付いたセットを指します。

つまり2027年第1四半期にKSK-2017をきちんと失効させるには、その時点のDNSKEYセットはKSK-2024と失効済みKSK-2017の両方で署名されている必要があります。まだKSK-2017をトラストアンカーとして持っているRFC 5011リゾルバがその失効を見て、自分のストアから削除できるようにするためです。KSK-2017が10月以降もゾーンに残るのは、後で規定どおりに失効させられるためであって、更新に失敗したリゾルバを生かしておくためではありません。

副次的に、このときDNSKEY応答にRSA 2048署名がもう1つ加わります(署名データだけで256バイト)。今日測定した1139バイトがその分大きくなるということです。この応答サイズの問題は、本稿後半の主役になります。

RFC 5011のもう1つの細部。REVOKEビットが設定されたDNSKEYは、ビットがないときと指紋(fingerprint)が変わります。 鍵タグが変わるということです。失効の局面で20326というタグをそのまま期待して書かれた監視は、そのとき誤動作します。

2017年の教訓 — テレメトリが実際に明らかにしたもの

このロールオーバー計画がなぜこれほど慎重なのか — 2年近い事前公開期間、6年のライフサイクル — を理解するには、2017年に戻る必要があります。

もともとKSK-2010からKSK-2017へのロールオーバーは2017年10月11日に予定されていました。ところが9月27日、ICANNは延期を発表します。当時の告知を直接読むと、判断の根拠が出てきます。

ICANNはDNSSEC検証リゾルバを使うインターネットユーザー数の推定値を根拠に、世界のインターネットユーザーの4人に1人、約7億5千万人がこのロールオーバーの影響を受ける可能性があると述べました。(これは被害者数の予測ではなく、露出規模の推定です。原文も「could be affected」です。)そして延期の理由をこう記しています — 最近入手したデータが、ISPやネットワーク事業者が使う相当数のリゾルバがまだ準備できていないことを示している、と。

その「最近入手したデータ」が何かも告知に説明されています。リゾルバが自分の設定した鍵をルートサーバーへ報告し返せるようにする、ごく最近のDNSプロトコル機能だと。名指しはしていませんが、RFC 8145(Signaling Trust Anchor Knowledge in DNSSEC)です。2017年4月に出たので、標準が出てからわずか5か月で、その標準が生んだデータが世界最大規模の暗号鍵交換を止めたことになります。

ところが、ここでの本当の教訓は次の一文にあります。ICANNは、運用者が新しい鍵を持っていない理由は複数あり得るとしたうえで、そのひとつとしてこう記しました — 広く使われているリゾルバプログラムの1つで最近見つかった問題が、鍵を本来あるべき形で自動更新しないように見え、その原因はまだ調査中だと。

これが要点です。テレメトリが明らかにしたのは「運用者が怠慢だった」ではありませんでした。RFC 5011の自動更新を実装したソフトウェアにバグがあったということでした。自動化はオンにされていて、自動化が静かに機能していなくて、テレメトリがなければ10月11日になって初めて気づいたはずのことです。

当時のICANN CEOだったゴラン・マービーはこう述べました — 発表済みの10月11日という日付でロールオーバーを強行するより、慎重かつ合理的に進める道を選ぶ、と。

ロールオーバーは結局、ちょうど1年後の2018年10月11日に実行されました。

今、自分のリゾルバは準備できているか — そしてこの確認が思ったより難しい理由

一番確実な方法はリゾルバに直接尋ねることです。BINDならrndc managed-keys status、Unboundならルートアンカーファイル(通常root.key)を開いて38696があるか見ればいいだけです。自分のインフラにアクセスできるなら、これが答えです。

アクセスできないリゾルバ(たとえば上流のISPリゾルバ)を外から突いてみるには、RFC 8509(A Root Key Trust Anchor Sentinel for DNSSEC)があります。リゾルバが特定の鍵をトラストアンカーとして持っているかをクライアント側から突き止める仕掛けです。

動作原理はこうです。問い合わせ名の一番左のラベルがroot-key-sentinel-is-ta-<key-tag>またはroot-key-sentinel-not-ta-<key-tag>だと、リゾルバは特別な処理をします。真理値表はRFCにこう示されています。

ラベル      | 鍵を信頼する          | 鍵を信頼しない
--------------------------------------------------------
is-ta       | 元の応答を返す        | SERVFAILを返す
not-ta      | SERVFAILを返す        | 元の応答を返す

注意点が2つあります。鍵タグは5桁でゼロパディングする必要があります(RFCの例のとおり、42は00042)。38696と20326はたまたますでに5桁なので、そのまま使います。そして特別処理が発動するには前提条件をすべて満たす必要があります — 応答がDNSSEC検証を経ていること、検証結果がSecureであること、CDビットがオフであること、QTYPEがAまたはAAAAであること、OPCODEがQUERYであること。1つでも外れると、リゾルバは応答に手を加えません。

この前提条件が実戦では足をすくいます。私が最初にiana.orgの下にセンチネルラベルを付けてテストしたときは、すべてNXDOMAINになりました。存在しない名前だったので、センチネルが発動する条件ではなかったのです。Secureな応答が返る名前を下敷きにする必要があります。

そこで、きちんとした対照群を立てて測定し直しました。存在しないことが確実な鍵タグ00000を対照群として使います。センチネルが実際に発動しているなら、is-ta-00000は必ずSERVFAILになるはずです。これが出なければ、その測定は何も証明していません。

2026年7月16日に実測した結果です。

Quad9 (9.9.9.9)
  is-ta-38696   x12  ->  NOERROR 12
  is-ta-00000   x12  ->  SERVFAIL 9,  NOERROR 3      <- 混在
  not-ta-38696  x14  ->  SERVFAIL 5,  NOERROR 9      <- 混在

Cloudflare (1.1.1.1)
  is-ta-00000   x14  ->  NOERROR 14                  <- センチネル動作は観測されず

Google (8.8.8.8)
  is-ta-00000   x14  ->  NOERROR 14                  <- センチネル動作は観測されず

読み方はこうです。

Quad9でis-ta-00000がSERVFAILを出したことがあるのは、一部のバックエンドが実際にRFC 8509を実装している証拠です(対照群通過)。そのバックエンドでnot-ta-38696がSERVFAILだというのは、真理値表上KSK-2024を信頼しているという意味であり、is-ta-38696が常にNOERRORであることとも矛盾しません。3つの結果が互いに一貫しています。

ただ正直に言うと、この測定の本当の教訓はその結論ではなく、結果が混在して出たという事実そのものです。同じ問い合わせを繰り返したのに、SERVFAILとNOERRORが入れ替わり出てきます。1つのエニーキャストアドレスの後ろに複数のバックエンドインスタンスがあり、そのうち一部だけがセンチネルを実装していると考えれば説明がつきます。実際、私は最初1回ずつしか問い合わせなかったときには、きれいな真理値表が得られて結論を出すところでした。繰り返してみると、再現しませんでした。

だから、こう整理するのが正しいでしょう。センチネルはリゾルバインスタンス単位のテストであり、大規模なエニーキャストリゾルバに対しては決定的な診断ツールではありません。 問い合わせ1回では何も証明されません。最低でも反復測定と対照群の鍵タグが必要です。そしてCloudflareとGoogleでセンチネル動作が観測されなかったことは、彼らがKSK-2024を信頼していないという意味ではまったくありません — ただ、この方法ではわからないというだけです。

採用率は今どれくらいか — 公開された数字はありません

では、世界中のリゾルバのうち何パーセントがKSK-2024を信頼しているのでしょうか。

公開されている最新の数値は、VerisignのDuane Wesselsが2025年3月19日に書いた記事にあるもので、2025年3月3日時点でリゾルバの91.3パーセントがKSK-2024を信頼するとシグナルを送っていたというものです。この数字はベンダー自己測定であり、条件をはっきりさせる必要があります — RFC 8145のシグナルを送るリゾルバの標本(a sampling of resolvers)についてのものであり、全数ではなく、RFC 8145を実装していないリゾルバはそもそも見えません。Verisignは、この採用ペースが直前のロールオーバーの同じ時点と正確に一致すると付け加えています。

2026年半ば時点の最新の採用率は公開されていません。 私が調べられる範囲では、ロールオーバーまで87日を切った今の時点で公式な数値はどこにも掲示されていません。そのため、ここに数字を書くことはしません。

同じ記事でより興味深いのは、むしろほかの2つの観測です。

1つ。リゾルバの100パーセントがKSK-2017をトラストアンカーとして持っており、Verisignは2027年初めにKSK-2017が失効するまでその状態が続くと見ています。当然です — それが今のところ唯一の署名鍵だからです。

2つ。2019年に失効したKSK-2010を依然として信頼しているリゾルバがかなりあります。 Verisignはその原因を、OSのソフトウェアアップデートにその鍵が残存していることによる可能性が高いと見ています。7年前に死んだ鍵が、いまだにトラストストアに残っているわけです。これがDNSSEC展開の現実です — プロトコルはきれいで、展開された世界は雑然としています。

そしてIANAファイルのvalidFromが2024-07-18だったことを覚えているでしょうか。Verisignは、2024年7月、つまりIANAトラストアンカーファイルに鍵が載った直後から、少数のリゾルバがKSK-2024をトラストアンカーに加え始めたと観測しています。運用者が手動で設定したものと見ていると。独立した2つの出典が同じ日付で符合しています。

このロールオーバーが変えないもの — アルゴリズム

先ほど、両方のKSKともアルゴリズム8、RSA 2048ビットだと述べました。ここでその話をする番です。

ICANNのアルゴリズムロールオーバー提案書は、この状況を淡々とまとめています — ルートゾーンのDNSSEC署名は2010年にRSAベースのアルゴリズムで始まり、KSKは2018年に一度交換されたものの暗号アルゴリズム自体は変わったことがなく、すでに進行中の2026年10月11日のロールオーバーもやはり同じアルゴリズムを維持する、と。そして決定的な一文 — ルートゾーンを別の署名アルゴリズムへ移行する確立されたメカニズムは存在しない、というものです。

この空白は2021年に発行されたICANNの第2次セキュリティ・安定性・回復力レビュー(SSR2)が指摘し、理事会は同年7月にその勧告を採択しました。その結果が2024年のルートゾーンアルゴリズムロールオーバー研究であり、それをもとに2026年3月2日にパブリックコメントに付されたのがProposal for Root Zone KSK Algorithm Rolloverです。

計画はこうです。RSA/SHA-256(アルゴリズム8)からECDSA P-256 with SHA-256(アルゴリズム13) へ移行します。2027年に新しいECDSA鍵を生成することから始まり、交換されたRSA KSKを最終的に破棄する2030年まで、約4年をかけます。方式は二重署名(double-signing)です。

ここで1つ、押さえておくべき点があります。RSA/SHA-256が弱いから移行するわけではありません。

アルゴリズム推奨の正本は、2025年11月に出たRFC 9904(DNSSEC Cryptographic Algorithm Recommendation Update Process、RFC 8624を廃止)です。この文書の表を直接開くと、こうなっています。

No. Mnemonics        Use/Signing   Use/Validation  Impl/Signing  Impl/Validation
 8  RSASHA256        RECOMMENDED   RECOMMENDED     MUST          MUST
13  ECDSAP256SHA256  RECOMMENDED   RECOMMENDED     MUST          MUST

両方のアルゴリズムの等級は完全に同じです。RSASHA256は廃止対象でも非推奨でもありません。ECDSA P-256が選ばれた理由は、ICANN研究の基準 — IETFですでに標準化されていること、そしてDNSSEC検証について必須実装(MUST)に指定されていること — を満たしつつ、すでに多数のTLDに展開されており、BIND、Unbound、Knot Resolver、PowerDNSなど主要ソフトウェアがすべて対応しているためです。

では、なぜあえて移行するのか。提案書が挙げる実質的な動機は、応答サイズの管理と、そもそも 「移行手順が存在することを証明すること」 です。アルゴリズムロールオーバーを一度もやったことがなければ、本当に必要な瞬間(あるアルゴリズムが破られたとき)にできません。SSR2が指摘した空白は、まさにこれでした。

加えて、RFC 9904はアルゴリズム要件の正本を、RFC文書からIANAレジストリへ移しました。 つまり上の表はスナップショットであり、今後推奨等級が変わればRFC改訂ではなくレジストリが更新されます。コードやドキュメントでRFC 8624を参照しているなら、今が直しどきです。

アルゴリズムロールオーバーの逆説 — 1536ビット論争

さて、本稿で最も興味深い部分です。

ECDSA P-256へ向かう理由の1つは署名が小さいことですが、そこへたどり着くには、まず応答をずっと大きくしなければなりません。 二重署名方式なので、移行期間中ルートゾーンはRSAとECDSA両方で署名され、DNSKEYセットには両方の鍵が載ります。

提案書はこの問題を正面から説明しています。2018年とその次のKSKロールオーバーで応答サイズが問題にならなかった理由は、アルゴリズムが変わらないロールオーバーではDNSKEY応答のサイズだけが影響を受けるからです。そしてルートサーバーが受け取る全問い合わせのうち、DNSKEY問い合わせは0.5パーセントにも達しません。DNSKEY応答が切り詰められてTCPで再試行されても、ルートサーバーシステムに与える影響は無視できる程度です。

ところが二重署名のアルゴリズムロールオーバーでは、委任(referral)応答やNXDOMAIN応答まで大きくなります。 これはルートトラフィックの大半です。ここに、2020年のDNS Flag Dayがデフォルトの最大UDPバッファサイズを1232バイトへ押し進めたことが重なります。提案書の結論は冷淡です — 2048ビットZSKで二重署名すると、ほとんどのルートサーバー応答が切り詰められてTCP再試行につながる、というものです。

そこで出てきた対策がこれです。アルゴリズムロールオーバーを始める前に、RSA ZSKを2048ビットから1536ビットへ下げる。 1536は1024と2048の中間値であり、このサイズであってこそ(四半期ごとのZSKロールオーバー中のDNSKEY応答を除けば)ほぼすべての応答が1232バイト以下に収まります。

つまり、応答サイズを守るために、暗号鍵をわざと弱くするわけです。それも約3年間にわたって。

パブリックコメントで最も多く争われた点が、まさにここでした。パブリックコメント結果報告書によれば、合計12件が提出され、ここにはICANNセキュリティ・安定性諮問委員会(SSAC)の遅延提出1件が含まれます。RSSAC、RySG、Verisignの3組織は支持を表明し、4人が推奨事項を付けたうえで支持し、4人が懸念や反対を表明しました。

反対側の論拠は具体的です。1536ビットはNISTが認める標準RSA鍵サイズではなく、この縮小はZSKの有効なセキュリティ強度を約112ビットから約90〜96ビットへ下げ、この低下した状態がロールオーバー期間である約3年間続く、というものです。

ICANNの回答も読む価値があります。要点は露出窓(exposure window)です。SSACの分析に同意しつつ、各ZSK鍵が実際に使われ、公に観測可能な期間は約110日であり、この期間は1536ビット鍵に対する総当たり攻撃が現在の能力で実現可能になるには短すぎると見ています。そしてこう記しました — 「2048ビット鍵に対するセキュリティの低下は実在するが、この運用窓によって限定される(The security reduction relative to a 2048-bit key is real but bounded by this operational window)」。この一文を和らげて訳さないことが重要です。ICANNはセキュリティが下がるという事実そのものを否定していません。

NIST標準サイズではないという指摘については、NISTの鍵管理指針が1024・2048・3072ビットを参照サイズとして挙げているのは事実だが、DNSSEC運用において非標準のRSA鍵サイズは前例のないことではなく、ルートゾーンのZSK自体がかつて1280ビットだったと答えています。

数字の面では、VerisignがRSSAC-002トラフィックデータに基づく実証分析を併せて提出しており、1536ビットRSA ZSKとECDSA ZSKの組み合わせは応答の約1〜5パーセントを1232バイトより上へ押し上げるという結果でした。完璧ではないが、2048ビットを維持する側より実質的に良い結果だというのがICANNの判断です。これも提出者自身の測定であり、RSSAC-002トラフィックデータという特定のデータセットに基づく推定値です。

もう1つ提起された懸念は、段階のスケジュール調整を引き起こす基準が定義されていないということでした。いつ延長し、いつ後退するかの判断基準が明文化されていないという指摘です。2017年の延期が結局は判断の問題だったことを考えれば、正当な指摘です。

結果はこうです。計画に構造的な変更はありませんでした。 ICANNは提案どおりに進めつつ、段階移行の基準を別途公開し、運用者コミュニティ向けに的を絞ったアウトリーチを行うと表明しました。

技術的に面白い反論がもう1つありました。提案されたPhase DDは、ECDSA署名を先に公開し、対応するECDSA DNSKEYはまだ公開しない段階ですが、これについて、署名だけを公開してもセキュリティ上の利点はなく、どのみちECDSA公開鍵は署名から復元可能だという指摘が出ました。暗号学的に正しい指摘です。

いつこれがあなたの問題ではないか

正直に整理すると、この記事を読んでいる大半の人は何もする必要がありません。

気にする必要がない場合

  • DNSSEC検証を行っていない。(社内のリゾルバの大半はここに該当します。)
  • Cloudflare、Google、Quad9のようなパブリックリゾルバを使っている。それは彼らの問題であって、あなたの問題ではありません。
  • マネージドリゾルバを使い、ベンダーがトラストアンカーを管理している。
  • 最新のBIND/Unbound/Knotをデフォルト設定で動かしていて、RFC 5011の自動更新が有効になっており、2025年2月以降ずっと稼働し続けている。この場合、すでにKSK-2024を持っています。

確認すべき場合

  • 検証リゾルバを自分で運用している。
  • トラストアンカーを手動で設定した、あるいは構成管理ツールでroot.keyファイルを配布している。RFC 5011がオフなら自動更新は起きません。ICANNがRFC 5011を使わないソフトウェア向けにIANAのウェブサイトでトラストアンカーファイルを公開しているのはこのためで、推奨事項はリゾルバ起動時とルートDNSKEYセットのKSKが変わったときにそのファイルを取得することです。
  • コンテナイメージやアプライアンスにトラストアンカーが焼き込まれている。イメージが2025年2月より前にビルドされ、その後再ビルドされていない場合、そしてRFC 5011の状態ファイルが永続ボリュームではなくコンテナレイヤーにあって再起動のたびに初期化される場合、30日ホールドダウンは永遠に完了しません。これが現代的なデプロイ環境で最もありそうな失敗モードです。
  • エアギャップ環境である、あるいはルートサーバーへのアウトバウンドが制限されている。

確認方法は単純です。リゾルバのトラストアンカーストアに38696があるか見ればいいだけです。あれば終わりです。

おわりに

まとめるとこうです。2026年10月11日、ルートKSKがKSK-2017からKSK-2024へ移ります。今日ルートゾーンを開いてみると2つの鍵がすでに並んで入っていて、署名はまだKSK-2017が行っています。RFC 5011を有効にしているリゾルバは2025年2月にすでに新しい鍵を受け入れているので、その日何も経験しません。受け入れられなかったリゾルバは、その日すぐに死にます — 2027年1月までの猶予期間のようなものはありません。KSK-2017がゾーンに残っているのは、規定どおりに失効させられるためです。

2017年の教訓は今も有効です。あのときロールオーバーを1年止めたのは怠慢な運用者ではなく、広く使われるリゾルバの自動更新バグであり、それを見つけたのは出てからわずか5か月のテレメトリ標準でした。自動化をオンにしていることと、自動化が実際に機能していることは別の話です。だから今回の計画は2年近い事前公開期間を設けました。

そして今回のロールオーバーはアルゴリズムを変えません。本当に難しい作業 — RSAからECDSAへ — は2027年に始まり2030年まで続く別のプロジェクトであり、その計画は応答サイズを守るためにRSA ZSKを3年間わざと弱くしようという提案のせいで、最も多くの反論を受けました。ICANNはその低下が「実在するが限定的だ」と認めつつ、計画どおりに進みます。

この2つが、本稿の本当の要点かもしれません。インターネットの信頼アンカーを変える作業は暗号学の問題ではなく展開の問題であり、展開された世界では7年前に死んだ鍵がいまだにトラストストアに残っています。そして安全な移行を設計していると、移行している間だけは安全性が下がることを受け入れなければならない瞬間がやってきます。正直な計画はそれを隠さず、文書に書きます。

今すぐやるべきことがあるとすれば1つだけです。検証リゾルバを運用しているなら、トラストアンカーストアを開いて38696があるか確認してください。残り87日です。

参考資料

Discuss on Twitter • View on GitHub