KSK-2024の切替：Sentinelで信頼状態を確認

この記事は、DNS（ドメイン名に対応するアドレスなどを調べる仕組み）の運用者向けです。公式の鍵・切替情報が示すルートKSKの切替予定日は2026年10月11日です。DNSSECを使うリゾルバは、DNSデータの署名と信頼の連鎖を検証します。DNS問い合わせを受けて名前解決するリゾルバの運用者は、ルートKSK（鍵署名鍵）の切替に備えて新鍵の信頼状態を確認します。信頼アンカーは、DNSSEC検証の出発点としてリゾルバが信頼する鍵などの情報です。

ベンダー配布や自動学習による更新と、現在の状態を確かめる方法を分けて考えます。[1, 3, 5]

Sentinelの条件と、is-ta／not-taの応答

RFC（インターネット技術の仕様文書）8509は2018年12月発行の仕様です。Sentinelは指定したルートKSKをリゾルバが信頼しているかを調べます。Cloudflareは同社の1.1.1.1で切替前に対応したと説明し、1.1.1.1とGateway DNSがKSK-2024を信頼済みだとしています。この説明はCloudflare自身のサービスについてのものです。[5, 4]

Sentinelの応答変更には条件があります。応答のDNSSEC検証結果がSecure（DNSSEC検証に成功した状態）で、問い合わせのCDビット（検証無効化を要求するビット）が未設定であることが必要です。QTYPE（問い合わせるレコード種別）はA（IPv4アドレス）またはAAAA（IPv6アドレス）、OPCODE（操作種別）はQUERY（通常の問い合わせ）を使います。

QNAME（問い合わせ名）の最左ラベルには、次のどちらかの形式を指定します。root-key-sentinel-is-ta-<Key Tag>またはroot-key-sentinel-not-ta-<Key Tag>です。Key Tag（鍵識別番号）は5桁で指定します。RFC 8509

信頼中の判定は、対象のルートKSKがローカルの信頼鍵ストア（検証の基準にする鍵の保存先）にあり、検証に使える状態であることを指します。DNSKEY（公開鍵情報を含むレコード）の集合やファイルに掲載されているだけでは判定対象になりません。AddPend（追加待ち）とRevoked（失効）の状態も対象外です。RFC 8509

運用者は対象リゾルバへ、鍵識別番号38696を含む二つの名前、root-key-sentinel-is-ta-38696とroot-key-sentinel-not-ta-38696を照会します。鍵を信頼中なら、is-taは元の応答（Sentinelが書き換えていない応答）を返します。not-taはSERVFAIL（DNS問い合わせの処理失敗を示す応答コード）を返します。逆の組み合わせなら未信頼です。

ほかの結果は不定として扱います。ここに示すのはRFCの仕様上の期待結果です。RFC 8509

問い合わせ名	鍵を信頼している場合	鍵を信頼していない場合
is-ta	元の応答	SERVFAIL
not-ta	SERVFAIL	元の応答

Cloudflareが示すdnstest.devを使う照会例を、対象リゾルバの指定に置き換えると次の形になります。REPLACE_WITH_RESOLVER_IPは確認したいリゾルバのIPアドレス（ネットワーク上の宛先を示す番号）に置き換えてください。 Cloudflare

運用者は社内DNSを調べる場合、その社内リゾルバのIPアドレスを指定します。宛先を1.1.1.1にすれば、確認するのはCloudflareのリゾルバです。次のコマンドは一次資料に基づく照会方法の例です。Cloudflare

dig @REPLACE_WITH_RESOLVER_IP root-key-sentinel-is-ta-38696.dnstest.dev. A +nocdflag +noall +comments +answer
dig @REPLACE_WITH_RESOLVER_IP root-key-sentinel-not-ta-38696.dnstest.dev. A +nocdflag +noall +comments +answer

3つ目の対照名には、BIND公式文書がDNSSEC検証失敗の確認に使うwww.dnssec-failed.org.を選びます。文書上の期待結果は、検証するリゾルバではSERVFAILです。

BIND DNSSEC Guide

運用者は、使用時にも公式文書の用途を確認し、同じリゾルバへの応答を確かめます。BIND文書では、CD未設定でSERVFAILとなり、同名に+cdflagを付けた再照会で応答が得られれば、検証失敗を切り分けられると説明しています。この再照会は対照名の診断用です。Sentinelの判定にはCD未設定の結果を使います。

BIND DNSSEC Guide

対照名の状態や失敗原因を確認できない場合は、後述の3照会による分類を完了できません。単独のSERVFAILをDNSSEC検証の証拠にせず、結果を不定として扱います。RFC 8509

dig @REPLACE_WITH_RESOLVER_IP www.dnssec-failed.org. A +nocdflag +noall +comments +answer

CDビットを設定しないことを明示するため、例では+nocdflagを付けています。

CD指定の書式はBINDのdig公式文書、SentinelのCD条件はRFC 8509を参照してください。

運用者は、通常の有効な署名付き名が同じリゾルバで引けることも別途確認します。これは名前解決が動作するかの対照確認で、期待結果は通常の応答です。以下の判定表に使うのは、Sentinelの2照会と不正署名名への照会の計3つです。Sentinelの照会名と不正署名名の状態、応答したリゾルバの対応状況が不明なら、3照会の結果を不定として扱います。

RFC 8509

対照照会と観測経路をそろえて結果を読む

RFC 8509の単一リゾルバ判定では、is-ta、not-ta、不正署名名への3照会を組み合わせます。仕様上、Sentinelの2照会が元の応答で、不正署名名がSERVFAILなら、DNSSEC検証中でSentinel非対応のため鍵状態は不明です。3照会すべてが元の応答なら、DNSSEC検証を行っていない分類です。RFC 8509

is-ta	not-ta	不正署名名	仕様上の分類
元の応答	SERVFAIL	SERVFAIL	対象鍵を信頼しています。
SERVFAIL	元の応答	SERVFAIL	対象鍵を信頼していません。
元の応答	元の応答	SERVFAIL	DNSSEC検証中で、Sentinelは非対応です。鍵状態は不明です。
元の応答	元の応答	元の応答	DNSSEC検証を行っていません。
上記以外	—	—	この手順では特性を判定できません。

単独のSERVFAILや照会間の不一致から、鍵が未登録だとは判断できません。ほかの問題でもSERVFAILは起こり得ます。複数台構成では、リゾルバごとに応答が異なることがあります。スタブリゾルバ（利用者端末からの問い合わせを上位のリゾルバへ転送するリゾルバ）が別のリゾルバへ再照会する場合もあります。こうした状況では、単一IPへの照会だけでは結果が不定になります。[5]

RFC 8509

観測経路も確認します。ブラウザの準備状況テストはブラウザが使うリゾルバを調べ、Secure DNS（DNS照会を暗号化する機能）やVPN（仮想私設ネットワーク）の影響を受けることがあります。明示的に1.1.1.1へ送る照会はCloudflareのリゾルバを測ります。企業内の状態を調べる場合は、普段利用するリゾルバ経路を対象に照会します。[4]

DNSSEC検証リゾルバの運用者は、ベンダー手順やRFC 5011による更新状況を確認し、実際に使われる経路へSentinelの対照照会を行います。運用者は、Sentinelへの非対応や複数台構成で結果が不明・不定になる条件を踏まえ、設定確認と照会結果を合わせて判断します。[1, 3, 5]

DNSSEC検証に失敗すると、名前解決に影響します

DNSSECは、DNSデータの署名と信頼の連鎖（親ゾーンから子ゾーンへ署名をたどって信頼を確認する仕組み）を検証する仕組みです。親ゾーンのDS（Delegation Signer、子の鍵を指す情報）レコードには、子ゾーンのDNSKEYを指す指紋（要約値）が含まれます。この指紋は、子ゾーンのDNSKEYの所有者名（DNS名）と内容から計算されます。リゾルバはそれを子の鍵情報と照合します。RFC 4034

ルートには親ゾーンがないため、信頼アンカーが検証の出発点になります。Cloudflareの公式解説

ルートKSKは、公開鍵をまとめたDNSKEYレコード集合に署名します。ZSK（ゾーン署名鍵）は、ルートゾーンのほかのDNSレコードに署名します。ルートKSKを信頼できず検証に失敗すると、信頼の連鎖を確認できず、名前解決に影響します。Cloudflareの公式解説

なぜ今か：切替予定と確認が必要な運用者

IANA（インターネットの番号や名前などを管理する機能）の2026年10月7日時点の表示では、KSK-2017（鍵識別番号20326）がActive（現行）です。KSK-2024（38696）はPre-Publication（鍵の事前公開中）です。IANAは10月11日を切替予定日として示しています。IANAの鍵・切替情報

KSK-2024の生成日は2024年4月26日、ルートゾーンへの公開日は2025年1月11日です。鍵の生成、ルートゾーンへの公開、署名を担当する鍵の切替は、それぞれ異なる段階です。Pre-Publicationの間に、運用者は新鍵が信頼アンカー設定に含まれているかを確認できます。IANAの鍵・切替情報

確認対象はDNSSEC検証を行うリゾルバの運用者です。運用者は新鍵が設定に見当たらない場合、自動更新が有効かを確かめ、リゾルバのベンダーが示す手順で更新します。配布の時期や方法はベンダーごとに異なります。[1, 2]

切替前に、更新と現在の状態確認を分ける

ベンダー配布は信頼アンカー情報を配布・適用します。RFC 5011は、既存の信頼アンカーで検証した新鍵を自動学習する仕組みです。通常の名前解決確認は、その時点で名前を引けるかを見ます。RFC 8509 Sentinelは、問い合わせを処理したリゾルバの現在のルートKSK信頼状態を調べます。[2, 3, 5]

方法	確認・更新するもの	運用上の制約
ベンダー配布	信頼アンカー情報を配布・適用します	配布時期や方法はベンダーによって異なります。[2]
RFC 5011	検証済みの新鍵を自動学習します	学習には待機期間があります。初期設定はRFC 5011の対象外です。[3]
通常の疎通確認	その時点の名前解決を確認します	新鍵への信頼は、設定と専用の照会で確認します。[2]
RFC 8509 Sentinel	問い合わせを処理したリゾルバの現在の鍵信頼状態を確認します	利用にはSentinelへの対応と観測経路の確認が必要です。[5]

SEP（Secure Entry Point）ビットは、DNSKEYで信頼アンカー候補を示すフラグです。RFC 5011では、まず既存の信頼アンカーでDNSKEY集合を検証します。SEPビットを持つ新鍵をその検証済み集合で初めて確認すると、受容タイマーが始まります。待機期間は30日と、初回の集合に設定された元のTTL（Time to Live、キャッシュの有効期間）のうち長い方です。リゾルバは受容前に、新鍵を含む検証済み集合を少なくとも2回確認します。[3]

待機期間の後、リゾルバは新鍵を含むDNSKEY集合を再取得して検証し、その鍵を受容します。RFC 5011は初期の信頼アンカー設定を扱わず、学習完了の確認も行いません。停止中だったリゾルバや、更新・マシン移動で学習状態を失ったリゾルバは、この方式だけでは準備完了を確認できません。Cloudflareは2018年の準備時に、学習状態を失った例を報告しています。

RFC 5011・Cloudflareの準備事例