DNSSECのルート鍵が10月11日に切り替わる、社内DNSで確認すること

DNSの根元で使われる「ルートKSK」という鍵が、2026年10月11日に新しい鍵へ切り替わります。DNSSEC(DNSの応答が改ざんされていないかを署名で確かめる仕組み)の検証をしている社内のDNSが新しい鍵を信頼していないと、名前解決が失敗するおそれがあります。多くの会社は自動更新で済んでいますが、ICANNは「自動更新が成功したと思い込まず、中身を見て確認する」ことを求めています。

何が、いつ変わるのか

DNSSECでは、ルートから順に署名をたどって答えが正しいことを確かめます。その出発点になる鍵がルートKSKで、DNSSEC検証をするDNSは、あらかじめ「この鍵は信頼する」という情報(トラストアンカー)を持っています。

IANAの日程表では、2026年10月11日にKSK-2024が署名を始め、旧鍵のKSK-2017は署名しなくなります。切り替えの時刻は、確認したページには書かれていません。

新しい鍵の名前はKSK-2024、鍵タグ(鍵の識別番号)は38696です。旧鍵のKSK-2017は20326です。どちらも暗号方式はRSA/SHA-256で、方式の変更は今回ありません(ICANNのガイド、Cloudflare)。

失敗が出るのは、切り替えから最大48時間のあいだ

ICANNのガイドによると、鍵が切り替わった瞬間に全部のDNSが止まるわけではありません。ルートの鍵情報には48時間の有効期限(TTL)があり、DNSは期限が切れて次に鍵を取りに行ったときに、新しい鍵で検証して初めて失敗に気づきます。

つまり、切り替えの後の最大48時間のどこかで、準備できていないDNSから順に失敗が出ます。いつ出るかは予測できない、とガイドは書いています。使っているDNSが1台だけで、全部が未対応なら、ブラウザーの表示崩れやメールの受信不良として現れます。

2026年10月11日は日曜日、10月12日は祝日(スポーツの日)です。連休明けの10月13日(火)に最初の問い合わせが来る、という並びになる会社もあるでしょう。これは暦から見た注意で、失敗が出る時刻の予測ではありません。

影響する会社・しない会社

• 影響する: 自社でDNSSEC検証をするDNS(BIND、Unbound、PowerDNS Recursor、Knot Resolverなど)を運用している会社です。KSK-2024が入っていないと、切り替え後に検証が失敗します。
• 影響する: Active DirectoryのDNSなど、Windows ServerのDNSでDNSSEC検証とトラストアンカーを設定している会社です。検証を有効にしている場合は、トラストアンカーの中身を自分で確かめる必要があります。
• 影響する: ルーター、UTM、DNSアプライアンスなどに、検証機能付きのDNSを持たせている会社です。更新はメーカーの手順に従う必要があります。
• 影響する: コンテナや、DoH(暗号化DNS)などで、アプリが自前のDNSの設定を持っている環境です。ICANNのガイドは、OSの設定とは別の解決先を使っている場合があると指摘しています。
• 影響しない: DNSSEC検証をしていないDNSだけを使っている会社です。ICANNは、検証をしていないリゾルバーは影響を受けないと説明しています。
• 影響しない: ドメインのDNSをCloudflareなど外部に任せ、社内からは大手の公開DNSを使っている会社です。Cloudflareは、自社のDNSと1.1.1.1・Gateway DNSは対応不要としています。他社の公開DNSの状況は、そのサービスの案内で確認してください。
• 影響しない: 権威DNSサーバー(自社ドメインの情報を答える側)の運用だけの会社です。JPRSは、権威DNSに追加の作業はないと案内しています。

公式が示す確認の方法

トラストアンカーの中身を見る

ICANNのブログは、鍵タグ38696があるかを、ソフトごとの保管ファイルで確かめるよう案内しています。

見つからないときは、自動更新(RFC 5011)が有効か、DNSソフトが保管先に書き込める権限を持っているかを確かめます。RFC 5011は、新しい鍵を30日以上観察してから自動で信頼する仕組みです。IANAは、トラストアンカーはソフトの更新で配られることも多く、手順は各メーカーに従うよう案内しています。

Active Directory(Windows Server)のDNS

MicrosoftのWindows Server DNSの説明では、トラストアンカーはPowerShellのGet-DnsServerTrustAnchor(ゾーンごと)とGet-DnsServerTrustPoint(サーバー全体)で見られます。DNSマネージャーの「Trust Points」にも表示されます。ドメインコントローラー上のDNSでは、トラストアンカーはフォレストのディレクトリパーティションに保存され、フォレスト内のドメインコントローラーに複製されます。

ここで一覧に38696があるかを見る、というのが公式資料から組み立てられる確認です。ただし、KSK-2024を対象にしたMicrosoft公式の手順ページは、確認した範囲では見つかりませんでした。更新の手順は、サーバーのOSの版とMicrosoftの案内で確かめてください。

問い合わせて確かめる(RFC 8509)

Cloudflareは、リゾルバーに直接「この鍵を信頼していますか」と聞く方法(RFC 8509)を案内しています。名前はroot-key-sentinel-is-ta-38696.dnstest.devとroot-key-sentinel-not-ta-38696.dnstest.devの2つです。

• KSK-2024を信頼している: is-taは正常に答え、not-taはSERVFAIL(失敗)になります。
• 信頼していない: is-taがSERVFAIL、not-taが正常になります。

ブログの例は1.1.1.1に向けたdigです。社内のDNSに向ければ、同じ質問ができます。この方式に対応していないリゾルバーでは、結果は「不明」で、鍵が無いという意味ではありません。ブラウザー版の準備状況テストは、ブラウザーが使っているDNSを調べるため、VPNや暗号化DNSの設定で結果が変わると書かれています。

日本の公式の案内

JPRS(日本レジストリサービス)は2025年1月14日に、KSK-2024の事前公開と切り替え予定を知らせています。RFC 5011の自動更新に対応したフルリゾルバー(キャッシュDNS)は追加作業が不要で、対応していないものは2026年10月11日までに新しいトラストアンカーを手動で追加する必要がある、という内容です。追加の方法は使っている製品の説明書を見るよう案内しています。

JPCERT/CCなど、ほかの国内機関による今回の個別の案内は、確認した範囲では見つかりませんでした。

情シスが今日やること

1. DNSSEC検証をしているDNSを洗い出します。 社内DNS、ADのDNS、ルーターやUTMのDNS機能、拠点やクラウドのDNSを一覧にします。「検証を入れた覚えがない」機器も、JPNICの2018年の案内は、BINDやUnboundなど多くのキャッシュDNSが既定で検証を有効にしていると書いています。設定で確かめます。
2. それぞれのトラストアンカーに鍵タグ38696があるか見ます。 BINDならbind.keys、Unboundならroot.keyの中身を見ます。ADのDNSはGet-DnsServerTrustPointで確かめます。アプライアンスはメーカーの手順書に従います。
3. 無かったものは、自動更新の設定と書き込み権限を確かめ、メーカーの手順で更新します。 古い版で更新できない機器は、ソフトの更新か、メーカーへの問い合わせが必要です。
4. 応答しない場合の止血の手順を、先に決めておきます。 ICANNのガイドは、検証の一時停止か、ルートへの否定のトラストアンカー(RFC 7646)で止血し、あとからKSK-2024を入れる流れを示しています。誰が判断し、どの機器で行うかを決めます。
5. 連休明けの問い合わせに備えます。 名前解決の失敗、メールの不達、一部のサイトだけ開かない、といった報告が来たら、まずDNSのエラー(SERVFAIL)を疑う、とヘルプデスクに伝えます。

参考にした公式の情報

ICANNは2026年8月11日に、準備のためのガイドの更新を発表しました。切り替え後に何が起きるか、どう復旧するかが書かれています。日本での提供や対応を特に区切った案内ではなく、世界共通の変更です。時刻などの細かな点は、IANAのページとICANNの案内で、実施の直前に再確認してください。