WEBサイトDNSのルートの鍵が10月11日に替わる。多くのサイト運営者は何もしなくてよい ── 使っているDNSが新しい鍵を信頼しているかを確かめる13項目（2026年10月時点）
DNSのルートの鍵が10月11日に替わる。多くのサイト運営者は何もしなくてよい ── 使っているDNSが新しい鍵を信頼しているかを確かめる13項目（2026年10月時点）
目次
01 何が起きたか — 2026年10月11日、DNSのルートが使う署名の鍵が、KSK-2017からKSK-2024に替わる
Cloudflareが10月6日に書いた発表
2026年10月7日に、Cloudflareのブログ（10月6日付）を開いた。冒頭に、次の文が書かれている。
"On October 11, 2026, the DNS root is scheduled to change its key-signing key (KSK) for only the second time ever."
（訳: 2026年10月11日に、DNSのルートは、鍵署名鍵（KSK）を替える予定である。これは史上2回目にすぎない。）
替わる鍵の名前は、記事の別の箇所に書かれている。
"The new key is KSK-2024, identified by key tag 38696. It will replace KSK-2017, key tag 20326, as the signer of the root’s DNSKEY set."
（訳: 新しい鍵はKSK-2024で、key tag（鍵の識別番号）は38696である。これは、ルートのDNSKEYの集合に署名する鍵として、key tagが20326のKSK-2017に替わる。）
「何もしなくてよい人」と「確かめる人」
同じ記事は、読み手を2つに分けている。
"Most website operators do not need to make any changes for this rollover. If you run a DNSSEC-validating resolver, check that it trusts the new root key, KSK-2024, and follow your software vendor’s instructions to update its trust anchors if the key is missing."
（訳: ほとんどのウェブサイトの運営者は、この鍵の交代のために、何も変える必要がない。DNSSECを検証するリゾルバーを運用しているなら、それが新しいルートの鍵KSK-2024を信頼しているかを確かめ、鍵が無ければ、ソフトウェアの提供元の案内に従って、信頼アンカーを更新する。）
つまり、ウェブサイトを公開しているだけの運営者の、ほとんどは、何もしなくてよい。確かめる必要があるのは、DNSの問い合わせ先（リゾルバー）を自分で運用している側である。
それでも、自分のサイトを見る人の側で、起きうること
ただし、リゾルバーが新しい鍵を信頼していないと、その先で何が起きるかを、Cloudflareは次のように書いている。
"If a resolver does not trust the replacement key, its users may be unable to reach websites under any top-level domain."
（訳: リゾルバーが、替わりの鍵を信頼していなければ、そのリゾルバーの利用者は、どのトップレベルドメインのウェブサイトにも、たどり着けなくなるかもしれない。）
自社のドメインの設定とは関係なく、閲覧する人の側のリゾルバーが失敗すれば、自社のサイトも開けない。ICANNのガイドは、影響の大きさについて、次のように書いている。
"The vast majority of users are expected to be unaffected."
（訳: 大多数の利用者は、影響を受けない見込みである。）
| 立場 | 公式文書から読み取れること | この記事での扱い |
|---|---|---|
| サイトを公開しているだけ | ほとんどの場合、何も変える必要がない（Cloudflare） | 閲覧者の側の影響だけ、頭に置く |
| 社内にリゾルバーを運用している | 新しい鍵が信頼アンカーに入っているか、確かめる（ICANN） | 手順4 |
| 社内・自宅・外出先の回線を使う人 | 使っているリゾルバー次第で影響が変わる | 手順1と手順2 |
| 運用を制作会社・サーバー会社に任せている | 書かれていない | 手順5の問い合わせ |
02 なぜ・背景 — 鍵は、DNSの答えを確かめる出発点である
ルートの鍵は、信頼の出発点
ICANNのブログ（2026年7月27日付）は、この鍵の役割を次のように書いている。
"At the heart of this system is the root zone Key Signing Key (KSK) – the ultimate cryptographic anchor that secures the Internet’s addressing system."
（訳: この仕組みの中心にあるのが、ルートゾーンの鍵署名鍵（KSK）で、インターネットの住所の仕組みを守る、最も根本の暗号の錨である。）
Cloudflareの説明では、DNSSECの確認は、ルートから「.com」、そして個別のドメインへと、署名の鎖をたどる。親のゾーンは、子の鍵の指紋を載せたDS記録を公開する。ただし、ルートには親がないので、リゾルバーは、あらかじめ信頼している鍵を、出発点として持つ。これが信頼アンカーである。
2回目の交代で、3年ごとの計画の最初になる
最初の交代は2018年10月だった。ICANNのブログによると、その後、新型コロナウイルスの影響と、鍵を守る機器の更新で、計画が遅れた。IANAのページは、3年ごとの交代を理想としていると書いている。今回の交代は、ICANNのガイドによると、その3年周期の計画に沿う最初のものである。
鍵は、2025年1月から公開されている
新しい鍵KSK-2024は、2025年1月11日から、ルートに公開されている（IANAのページ、ICANNのブログ、Cloudflareが一致）。リゾルバーは、新しい鍵を見つけてから、30日以上観察して、信頼に加える。この仕組みはRFC 5011で決まっている。ICANNのブログは、次のように書いている。
"Data shows that the current adoption curve nearly mirrors the successful 2018 rollover, with more than 95 percent of reporting resolvers successfully recognizing and adopting KSK-2024."
（訳: データによると、現在の採用の推移は、成功した2018年の交代とほぼ同じで、報告しているリゾルバーの95%超が、KSK-2024を認識し、採用している。）
この95%は、「報告しているリゾルバー」の数字である。報告しないリゾルバーは、数に含まれていないと読める。公開の時期は、ICANNのFAQのPDF（2026年5月）だけが「2025年2月」と書いていて、他の文書と食い違う。理由は書かれていない。この記事は、1月11日に合わせる。
自動で更新されていても、確かめる理由
Cloudflareは、2018年の交代のときに、ソフトウェアの更新や、機器の間の移行で、リゾルバーが学んだ新しい鍵への信頼を失う例を見た、と書いている。ICANNのページは、確かめることを、次のように求めている。
"Do not assume automatic trust-anchor updates succeeded."
（訳: 信頼アンカーの自動更新が成功したと、思い込まないこと。）
03 用語 — 読み違えやすい言葉を先にそろえる
DNSSECとリゾルバー
用語
DNSSEC：DNSの答えに電子署名を付け、答えが本物で、変えられていないかを確かめる仕組みである。リゾルバー：利用者の機器に代わって、サイトのIPアドレスなどを調べる、DNSの問い合わせ先である。会社のDNS、プロバイダーのDNS、1.1.1.1のような公開のDNSなどがある。
信頼アンカーと、KSK・ZSK
用語
信頼アンカー：リゾルバーが、確認の出発点として、あらかじめ信頼している鍵である。KSK（鍵署名鍵）：ルートの鍵のリスト（DNSKEYの集合）に署名する鍵で、今回替わる。ZSK（ゾーン署名鍵）：ルートの他の記録に署名する鍵で、ICANNのガイドは、3か月ごとに新しいものが公開されると書いている。
key tag
用語
key tag：鍵を見分ける番号である。古い鍵KSK-2017が20326、新しい鍵KSK-2024が38696である。ICANNのブログは、信頼アンカーのファイルで、38696の鍵があるかを探すよう書いている。
RFC 8509の「sentinel」
用語
sentinel（番人）：リゾルバーに、新しい鍵を信頼しているかを、通常のDNSの問い合わせで尋ねる方法である。RFC 8509の概要は、この文書が「利用者が、自分のDNSの問い合わせを処理するリゾルバーの、ルートの鍵の信頼の状態を調べる仕組み」を定めると書いている。
「交代」と「取り除き」は別の段階
Cloudflareは、「鍵が署名をやめること」と「鍵への信頼を取り除くこと」は別の段階だと書いている。10月11日に起きるのは前者で、古い鍵の取り除きは、2027年に予定されている。
04 型別 — 自分の回線のリゾルバーが、新しい鍵を信頼しているかを確かめる
適用範囲 — 影響を受けるのは、DNSSECを検証するリゾルバーを使う人
ICANNのガイドは、DNSSECの検証をしないソフトウェアや回線を使う人は、影響を受けないと書いている。新しい鍵を設定済みのリゾルバーを使う人も、影響を受けない。影響が出るのは、検証をしていて、かつ、新しい鍵を持っていないリゾルバーを使う人である。自分がどちらかは、確かめるまで分からない。
公式文書が書いていないこと
- 自社のドメインがDNSSECで署名されている場合に、DS記録の更新が要るかどうか。開いた3つの文書（Cloudflare・ICANN・確認ページ）には、書かれていない。
- 日本国内のプロバイダーや、社内の機器、家庭用ルーターが、対応済みかどうか。
- 日付が動かないかどうか。ICANNのFAQは、問題が広がれば元に戻す「back-out scenario」（訳: 巻き戻しの筋書き）や、日程の調整がありうると書いている。
この記事が確かめていないこと
読者の回線のリゾルバーが、新しい鍵を信頼しているかは、この記事では確かめていない。回線ごとに違うためである。次の手順は、その確かめ方である。
手順1 — いつもの回線で、確認ページを開く
CloudflareのDNSテストのページ（dnstest.dev/ksk-2024）を、ブラウザで開き、「Run test」を押す。ページは、ブラウザが使うリゾルバーに、新しい鍵を信頼しているかを尋ねる。結果の読み方は、ページに書かれている。
"An inconclusive result alone does not mean the key is missing."
（訳: 結果が判定できなかったというだけでは、鍵が無いという意味にはならない。）
VPNや、ブラウザの暗号化されたDNSの設定が、結果に影響する、とも書かれている。会社・自宅・スマホのモバイル回線の3つで、同じ操作をして、結果を並べる。
手順2 — コマンドで、問い合わせ先を指定して確かめる
確認ページが判定できないときは、問い合わせ先のIPアドレスを指定して、2つの名前を尋ねる。Cloudflareの記事に書かれた方法である。
dig @リゾルバーのIPアドレス root-key-sentinel-is-ta-38696.dnstest.dev. A +noall +comments +answer
dig @リゾルバーのIPアドレス root-key-sentinel-not-ta-38696.dnstest.dev. A +noall +comments +answer出力の「status:」の行を見る。新しい鍵を信頼しているリゾルバーは、1本目に答えを返し、2本目にSERVFAILを返す。信頼していなければ、逆になる。2本とも答えが返る場合は、sentinelに対応していない可能性があり、判定できない。dnstest.devのページが、同じ読み方を書いている。
筆者のWindowsには、digが入っていなかった。標準のnslookupでも、同じ2つの名前を尋ねられる。1.1.1.1に尋ねたとき、1本目に名前とIPアドレスが表示され、2本目に「Server failed」と出た。
nslookup root-key-sentinel-is-ta-38696.dnstest.dev 1.1.1.1
nslookup root-key-sentinel-not-ta-38696.dnstest.dev 1.1.1.1手順3 — 自社のドメインが、DNSSECで署名されているかを見る
自社のドメインの親のゾーンに、DS記録があるかを尋ねる。Verisignの記事は、親のゾーンが、子のゾーンの鍵を保証するのが、DS記録の役目だと書いている。
dig @1.1.1.1 自社のドメイン DS +short行が出れば、署名を使っている状態と読める。何も出なければ、署名を使っていない状態と読める（筆者の読みで、公式文書の言い方ではない）。署名を使っている場合に、鍵の交代で自社の作業が要るかは、開いた文書に書かれていない。ドメインを管理している会社か、DNSの提供元に、聞く。
手順4 — 社内にリゾルバーがあるなら、信頼アンカーのファイルを見る
BIND・Unbound・PowerDNS Recursor・Knot Resolverなどを社内で運用している場合は、ICANNのブログが、確かめるファイルを挙げている。BINDはbind.keys、UnboundとPowerDNS Recursorはroot.key、Knot Resolverはroot.keysである。key tag 38696の鍵があるかを、ソフトの提供元の手順で確かめる。見つからない場合の対応は、次のように書かれている。
"If Key Tag 38696 is missing, verify that automatic trust updates are enabled and that your resolver has write permissions to its storage directory."
（訳: key tag 38696が無ければ、自動の信頼の更新が有効か、リゾルバーが保存先のディレクトリに書き込む権限を持っているかを確かめる。）
Unboundの公式文書も、RFC 5011で自動更新するには、Unboundを動かすユーザーに、ファイルとその置き場所への書き込み権限が要る、と書いている。RFC 5011に対応していないソフトについて、ICANNのFAQは、IANAが公開する信頼アンカーのファイルを、リゾルバーの起動時に取得するよう案内している。
手順5 — 制作会社・サーバー会社に、聞く
運用を任せている場合は、次のように聞く。
2026年10月11日にDNSのルートの鍵が替わります。
1. 貴社が運用するDNSの問い合わせ先（リゾルバー）は、DNSSECを検証していますか。
2. 検証している場合、新しい鍵（KSK-2024・key tag 38696）を信頼していますか。
3. 当社のドメインに、対応が必要な作業はありますか。返事は、日付と要点を、1行ずつ記録する。
手順6 — 10月11日の前後に、何をいつ見るか
ICANNのガイドによると、準備ができていないリゾルバーの失敗は、切り替えのあとの48時間のどこかで、始まりうる。
"Users will likely start seeing the effects at some point in the 48 hours after the rollover happens if their software or network operator’s configurations have not been properly updated."
（訳: 利用者のソフトウェアやネットワーク運営者の設定が、適切に更新されていなければ、利用者は、鍵の交代のあとの48時間のどこかで、影響を見始める可能性が高い。）
したがって、10月10日までに手順1〜5を終え、10月11日・12日・13日に、確認ページをもう一度開く。失敗が出たときの応急の処置は、ガイドの3.4節に、検証を一時的に止めるか、ルートに「否定の信頼アンカー」（RFC 7646）を設定する方法が書かれている。そのあとに、KSK-2024を信頼アンカーに入れて、検証を戻す。これは、06章の注意を読んでから行う。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。項目1〜2が手順1、項目3〜5が手順2、項目6〜7が手順3、項目8〜9が手順4、項目10〜11が手順5、項目12〜13が手順6に対応している。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- 会社・自宅・スマホのモバイル回線の3つで、dnstest.dev/ksk-2024を開いて「Run test」を押し、結果を「信頼している」「信頼していない」「判定できない」のどれかで書く
- 結果が「判定できない」だった回線について、その回線のDNSの提供元（会社のIT担当やプロバイダーの名前）を、1行で書き出す
- dig（Windowsならnslookup）が使えるパソコンで、1本目の名前「is-ta-38696」を、1.1.1.1に尋ねて、答えが返ったかを書く
- 同じパソコンで、2本目の名前「not-ta-38696」を、1.1.1.1に尋ねて、SERVFAILだったかを書く
- 項目3と4の結果を、「1本目が答えあり・2本目がSERVFAIL」の形と見比べ、「信頼している」「信頼していない」「判定できない」のどれかを書く
- 自社のドメインについて「dig @1.1.1.1 自社のドメイン DS +short」を実行し、行が出たかを「出た」か「出ない」で書く
- DS記録が出た場合は、ドメインを管理している会社に、鍵の交代で自社の作業が要るかを聞く文を、2行で書いて送り、送った日を書く
- 社内にDNSの問い合わせ先（リゾルバー）を運用しているかを、IT担当に聞いて、「ある」か「ない」で書く
- 「ある」場合は、ソフトの名前と版を書き、信頼アンカーのファイルに、key tag 38696の鍵があるかを、提供元の手順で確かめて、「ある」か「ない」で書く
- 制作会社かサーバー会社に、手順5の3つの問い合わせを送り、送った日を記録に書く
- 10月10日までに、返事の状態を「対応済み」「未対応」「返事待ち」の3つに分けて、数を数える
- 10月11日・12日・13日の3日間に、確認ページをもう一度開き、結果を日付つきで3行書く
- 10月11日から13日の間に、サイトや外部サービスが開けないという連絡が来たときの連絡先を、IT担当とプロバイダーの2つ、書き出す
チェックリストの使い方
時間が限られているときは、項目1・5・6・10の4つだけでも、「自分の回線の状態」「自社のドメインの署名の有無」「提供元に聞いたか」が分かる。ウェブサイトを公開しているだけの場合は、項目1と6から始める。
06 代替・他の選択肢 — 確かめ方の違いと、応急の処置の注意
確かめ方4つの比較
| 方法 | 必要なもの | 分かること | 分からないこと |
|---|---|---|---|
| 確認ページを開く | ブラウザ | いま使っている回線のリゾルバーの状態 | sentinelに対応していないリゾルバーの鍵の有無 |
| dig・nslookupで尋ねる | コマンドが使えるパソコン | 指定したリゾルバーの状態 | 同上。VPNなどの経路の違い |
| 信頼アンカーのファイルを見る | リゾルバーを運用する権限 | そのリゾルバーが持つ鍵 | 他のリゾルバーの状態 |
| 提供元に聞く | 問い合わせ先 | 提供元が確かめた状態 | 返事までの日数と、正確さ |
応急の処置は、最後の手段
注意
ICANNのガイドは、失敗したあとの応急の処置として、検証の一時停止や、否定の信頼アンカーを挙げている。これらは、DNSSECの保護を一時的に外す操作である。リゾルバーの運用者が、ソフトの提供元に相談したうえで行い、KSK-2024を入れたら、検証を戻す。
複数のリゾルバーがあると、失敗に気づかないことがある
ICANNのガイドは、複数のリゾルバーを設定している利用者は、1つが失敗しても、他へ切り替わって、気づかないことがあると書いている。気づいたときには、動作が遅くなっているだけの場合もある。失敗が一部の人にだけ出ると、原因が分かりにくい。その切り分けの考え方は、当サイトの記事「「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだった」に書いた。
実務のヒント
優先度の高い順に、社内のリゾルバーの確認、制作会社・サーバー会社への問い合わせ、3つの回線での確認ページを行う。前の2つは、自分で変えられない部分を、提供元に確かめる作業である。
外から見える範囲を、記録に残すためのツール
自社のドメインのDNSの記録を一覧で見たいときは、当サイトの無料ツール🔧 WEBサイトの外からできるセキュリティ対策監査ツールが使える（会員限定・無料登録）。説明には、A・AAAA・MX・NS・TXT・CNAME・SOA・SRVの記録の解析が挙がっている。DSやDNSKEYの判定は、挙がっていない。また、10月11日の前後に、主要なページが同じように開けるかを画像で残すには、🔧 WEBサイトのスクリーンショットをまとめて撮るツールが手がかりになる。どちらも、鍵を信頼しているかを判定するツールではない。
入口になるURLを、1つずつ開いて確かめる方法は、当サイトの記事「Chrome 154は、HTTPのページを開く前に既定で確認を出す。最終ページがHTTPSでも、転送の途中がHTTPなら出る ── 自社の入口を1つずつ開いて確認する13項目（2026年10月時点）」で扱った。
07 当サイトで確かめたこと
ルートの鍵の今の状態（2026年10月7日15時51分・日本時間）
1.1.1.1に、ルートのDNSKEYの集合を尋ねた（dig @1.1.1.1 . DNSKEY +dnssec +multi +noall +answer）。集合の中には、ZSKが2つ、KSKが2つあった。KSKのkey idは、20326と38696である。集合に付く署名（RRSIG）は、key tagが20326のもの1つだけだった。10月11日より前の今は、古いKSK-2017が署名をしている、という公式の日程と合っている。
公開のDNS 3つに、同じ質問をした
同じ日時に、3つの公開リゾルバーに、sentinelの名前を尋ねた。結果は次のとおりである。
- 1.1.1.1：is-ta-38696はNOERRORで答えが返り、not-ta-38696と、not-ta-20326はSERVFAILだった。16時21分の8回も、同じ形だった。新しい鍵を信頼している形で、尋ねるたびに変わらなかった。
- 9.9.9.9：15時51分には、is-ta-38696はNOERRORで答えが返り、not-ta-38696はSERVFAILだった。ところが、16時21分に同じ2つの名前を8回ずつ尋ね直すと、8回とも2つの名前の両方に答えが返った。同じリゾルバーでも、尋ねた時刻で形が変わった。このため、9.9.9.9は、信頼しているとも、していないとも言えない。
- 8.8.8.8：is-ta-38696も、not-ta-38696も、NOERRORで答えが返った。2つとも答えが返る形で、この確かめ方では判定できなかった。sentinelに対応していないのか、別の理由かは、確かめていない。
当サイトの運営環境の問い合わせ先でも、判定できなかった。判定できない結果は、鍵が無いという意味ではない。確認ページの文面と同じ読み方である。
当サイトのドメインに、DS記録は出なかった
手順3の方法で、当サイトのドメイン（usersupports.com）のDS記録を、1.1.1.1と8.8.8.8に尋ねた。どちらも、行は出なかった。署名を使っていない状態と読める。同じ命令で、jpのDS記録は行が出たので、命令は動いている。署名の有無は、外から誰でも確かめられる情報である。
この結果から言えることと、言えないこと
言えるのは、公開の3つのうち、1.1.1.1は新しい鍵を信頼している形で、8.8.8.8は判定できず、9.9.9.9は尋ねるたびに結果が変わったことである。言えないのは、当サイトを見る人のリゾルバーの状態である。Cloudflareの記事のとおり、署名していないドメインでも、閲覧する人のリゾルバーが失敗すれば、サイトは開けなくなりうる。
08 このテーマの、これまで
鍵の交代をめぐる、日付つきの記録
| 日付 | 出来事 |
|---|---|
| 2018年10月11日 | 最初の鍵の交代。KSK-2017が署名を始めた（IANAのページ） |
| 2024年4月26日 | KSK-2024が生成された（IANAのページ） |
| 2025年1月11日 | KSK-2024がルートに公開された（FAQは「2025年2月」と書く） |
| 2025年2月10日 | RFC 5011に従うリゾルバーが、新しい鍵を信頼し始める見込みの日（IANAのページ） |
| 2026年7月27日 | ICANNが、更新したガイドとブログを公開した |
| 2026年10月6日 | Cloudflareが、確認ページとともに、この記事で引いたブログを公開した |
| 2026年10月11日 | KSK-2024が署名を始める予定 |
| 2027年第1四半期 | KSK-2017をルートから取り除く予定（ICANNのFAQ） |
10月11日の切り替えが、予定どおりに進むかどうかは、この記事を書いた時点では分からない。ICANNのFAQは、日程の調整がありうると書いている。
当サイトの、関連する過去の記事
- 「AIクローラーが弾かれている」と読みかけた ── 日別に割ったら、正体は数十の名前を名乗る貸しサーバーだった — 一部の人にだけ出る現象を、日別・発信元別に割って、切り分けた記録。
- 「アクセスが0でした」と言われて調べたら、仕組みは全部 正常だった ── 壊れていたのは「誰が見に来ているか」の前提 — 「アクセスが0」と言われて、前提を疑って調べ直した記録。
- 「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数） — 壊れていたのは、作ったものではなく写し方だった話。
- 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った画面が、目当ての画面とは限らなかった話。
- 「リンク切れ0本」も「200が返る」も、まだ2段目だった ── 番号が変わるサイトで見つけた、リンクの3段目のずれ — 確認の段が、もう1つ先にあった話。
現在の貴方のIPアドレス
このサイトで書いている人
