インターネットでドメイン名をIPアドレスに変換するDNSには、応答が途中で改ざんされていないことを確かめるDNSSECという仕組みがあります。その信頼の出発点となる最上位の鍵が、10月11日に新しいものへ切り替わります。この鍵の更新は2018年以来2回目で、今回は1年9か月前から予告されてきました。多くの会社にとって作業はありませんが、自社でDNSサーバーを運用している場合は、今週中に一度確認しておく価値があります。
何が起きるのか
ICANNは2026年10月11日（協定世界時）、DNSSECのルートゾーンで使う鍵署名鍵（KSK）を、2017年から使われてきたKSK-2017（鍵タグ20326）から、2025年1月に事前公開されていたKSK-2024（鍵タグ38696）へ切り替えます。この日以降、ルートゾーンの署名は新しい鍵だけで行われるため、DNSSECの検証を行うリゾルバー（キャッシュDNSサーバー）が新しい鍵を信頼する設定になっていないと、署名されたドメインの名前解決に失敗し、利用者はWebサイトやメールに届かなくなります。JPRSやCloudflareの案内によれば、トラストアンカーの自動更新（RFC 5011）に対応したリゾルバーや、新しい鍵をあらかじめ組み込んだ最近のソフトウェアでは追加の作業は不要で、一般の利用者やWebサイトの運営者にも作業はありません（JPRS、Cloudflare、INTERNET Watch）。
なぜ自社に関係があるのか
まず、対象かどうかの切り分けです。社員のPCやサーバーが、プロバイダーのDNS、Cloudflareの1.1.1.1、Googleの8.8.8.8、クラウドサービスが提供するDNSを使っているなら、何もする必要はありません。影響を受けるのは、自社でDNSSECの検証を有効にしたDNSサーバー（BIND、Unbound、Windows Serverなど）や、DNS機能を持つUTM・ルーターを運用している場合です。社内のDNSが検証を有効にしているかどうかを、担当者が把握していないこともあります。
次に、壊れ方の特徴です。10月11日を境に、特定のサイトだけが見られなくなるのではなく、署名されたドメイン全般が引けなくなります。Webは開かず、メールは届かず、クラウドサービスにもつながりません。社内で一斉に起きるため、原因として「DNSの鍵」を疑える人がいないと、復旧までに時間がかかります。
もうひとつは、この更新そのものから学べることです。インターネット全体の信頼を支える鍵を、1年9か月前に公開し、自動更新の仕組みを用意し、事前に確認できるテストまで公開して入れ替える。これは、暗号アジリティの記事で書いた「鍵と証明書の入れ替えを計画的に行う」ことの、世界規模の実例です。PQC（耐量子暗号）への移行では、各社がこれと同じ段取りを自社の規模で行うことになります。
明日やること
- 社内のキャッシュDNSサーバー、UTM、ルーターのDNS機能が、DNSSECの検証を有効にしているかを確認する。有効なら、ソフトウェアが最新か、新しい鍵（鍵タグ38696）を信頼しているかを確認する。確認用のテストサイト（dnstest.dev/ksk-2024/）で判定できる
- DNSの運用を外部に委託している場合は、保守先に「10月11日のルートKSK更新への対応状況」を一文で確認し、回答を記録する
- 10月11日以降に「Webが開かない、メールが届かない」が社内で一斉に起きたら、DNSの鍵を最初に疑う。切り分けの手順と連絡先を、週末の前に決めておく（インシデント発生時の初動対応）
もっと知るには
証明書の信頼が最上位の鍵から順につながっている考え方は、TLSとPKIで解説しています。鍵や暗号方式を入れ替えられる状態を保つ設計は暗号アジリティとは、障害が起きたときの動き方はインシデント発生時の初動対応をご覧ください。
