要約

  • APNICの10月報告は、7月のRFC 8145リゾルバーシグナルと、新しいRFC 8509端末テストを併記する。約90％と70％は異なる観測経路を表し、差し引いたり平均したりできない。
  • ネットワーク表は確認先を示すウォッチリストであり、ISPの準備度や顧客の被害人数を評価するものではない。運用者は自分の検証リゾルバーを確認する必要がある。

分析

割合には観測経路が必要だ

DNSSECルート鍵の切り替えを2日後に控えると、準備度の割合は誰もが欲しがる答えに見える。大半のリゾルバーが後継鍵を持てば安全で、十分でなければ誰かが停止を求めるべきだ、と。しかし「大半」が何を数えたのかが問題になる。リゾルバーのシグナル、利用者端末からのテスト、そのネットワークに依存する人々は、同じ単位ではない。

10月9日に公開され、8日付で執筆されたAPNICの報告は、KSK-2024をめぐる二つの観測を扱う。ひとつはRFC 8145で、検証リゾルバーが信頼する鍵タグを、権威サーバー運用者に見える問い合わせに含めて知らせる仕組みだ。もうひとつはRFC 8509のRoot Key Trust Anchor Sentinelである。端末からテストを送り、返答を手掛かりにリゾルバーの信頼状態を推測する。同じ鍵と切り替え日を見ているが、測定対象は異なる。

RFC 8145の説明には、記録しておくべき差がある。APNICは7月の図を、報告を送るリゾルバーのおよそ90％がKSK-2024を追加した状態と説明する。Verisignの7月28日の更新は、シグナルを送る情報源での採用が約500日後に95％を超えたとしている。APNICは図の出典をVerisignとしているが、公開文面には両者を照合できる同一の抽出日と指標定義がない。異なる時点や要約を指している可能性はあるものの、本文からは判断できない。これは測定失敗の証拠ではなく、残すべき説明上の空白だ。

新しい70％はさらに比較しにくい。APNICによれば、広告ベースの測定基盤は1日平均約1,600万件の端末テストを実施した。約600万件はDNSSEC検証リゾルバーの背後に端末があることを示し、約180万件はRFC 8509のセンチネル機能を明確に支持するシグナルだった。センチネルを支持すると見られたテストのうち、約70％がKSK-2024の読み込みを示した。この分母は明確なシグナルを返したテストの一部であり、全1,600万件、すべての検証リゾルバー、全インターネット利用者ではない。

二つの仕組みが答える二つの問い

RFC 8145は、検証リゾルバーが信頼チェーンにある鍵タグを知らせる方法を定める。EDNSオプションと特殊な問い合わせという任意の手段があり、ルートゾーンでは権威インフラの運用者がそのシグナルを観測できる。シグナルを送る情報源の申告状態が時間とともにどう変化するかを示すデータだ。

ただし、各リゾルバーの背後に何世帯、何社、何サービスがいるかは分からない。数百万の利用者を担当する再帰リゾルバーもあれば、1台の装置や1組織だけを支えるものもある。転送経路が根サーバー運用者に見える内容を変える場合もある。従って、報告シグナルの割合はシグナルについての問いに答えるのであり、利用者の露出度を測るものではない。

RFC 8509は別の経路を使う。特殊なDNS問い合わせに対し、対応する検証リゾルバーは、指定されたルート鍵を信頼するかどうかに応じて応答する。APNICは広告ベースの測定基盤で端末からこのテストを行う。端末が利用する解決経路に近い観測ではあるが、リゾルバーの対応と返答の分類可能性に依存する。端末の背後にある全リゾルバーや、同じリゾルバーを共有する全利用者を特定するものではない。

10月5日のRIPE Atlasテストは三つ目の視点であり、全体を確認したわけではない。2,900の自律システムにあるプローブのうち、1,230件は新鍵が読み込まれた状態と整合し、47件は読み込まれていない状態と整合した。各ネットワーク内のプローブ結果であり、2,900システムの全体や、各結果に依存する顧客数を示すものではない。

部分的な測定でも、どの問いに答えるかを明確にすれば有用だ。RFC 8145はルートへシグナルを送るリゾルバーの申告を、RFC 8509は端末背後の対応経路の応答を、RIPE Atlasは別の観測地点を示す。どれか一つで、全インターネットを利用者数で加重した完全な分母を得られるわけではない。

ウォッチリストは判定表ではない

APNIC報告で最も実務的なのは全体割合ではない。表3は、直近1週間でKSK-2024の受け入れ率が低かった50ネットワークを載せ、センチネル対応リゾルバーを示すテストが1,000件未満のネットワークを除いている。この条件は一度だけの観測より参考になるが、準備度監査にはならない。

表にはタイのNational Telecom、バングラデシュのTeletalkなどアジア太平洋のネットワークが含まれる。APNICの報告値は、センチネル対応テスト1,355件でNational Telecomが48.4％、2,046件でTeletalkが48.2％だ。追加確認を検討する対象を示す数字である。両社の全リゾルバーが同じ状態にあること、各応答が別々の人を表すこと、同じ割合の顧客がアクセスを失うことは示していない。

APNICは、掲載ネットワークに対し、Cloudflareのテストページなどで自らの解決経路を確認し、DNS設定を見直すよう提案する。表の適切な使い方は、外部の判定ではなく運用者が追跡する手掛かりにすることだ。事業者は複数の再帰サービスを運用したり、一部を転送したり、ベンダー配布の鍵に依存したりする。公開表だけではその構成を判断できない。

日程には三つの状態変化がある

IANAの現行日程では、KSK-2024は2025年1月11日にルートゾーンへ入った。RFC 5011に従うリゾルバーはその1か月後から信頼し始める想定だ。2026年10月11日にはKSK-2024が署名を開始し、KSK-2017は署名を終える予定である。旧鍵の失効は2027年1月11日、削除は3月22日の予定だ。

これらは別々の状態を表す。「新鍵の署名開始」は「旧鍵の失効」ではなく、失効はゾーンからの削除でもない。RFC 5011の追加保留期間は、後継鍵を観測し検証してから自動的に信頼するための時間を設ける。だが、仕組みがあるからといって、特定の環境で有効化され、状態を書き込め、必要な観測を受け取ったと証明されるわけではない。

役割も分けて考える必要がある。IANAはルートの信頼アンカーと日程を公開し、ICANN/PTIはルートKSK運用を担う。Verisignはルートゾーン保守などを行い、ルートサーバーの観測点も持つ。APNICは自身の測定を報告する。顧客が使う再帰リゾルバーには、各ネットワーク運用者が責任を持つ。APNICは証拠を提供できるが、ルート鍵を制御したり、世界的な切り替えの実施を決めたりはしない。

運用者がすぐに行うべき確認はローカルなものだ。配置済みリゾルバーが正しい後継鍵を信頼しているか、自動更新または承認済みの手動手順が実際に働くか、利用者が本番で通る解決経路を検査する。IANAは信頼アンカーファイルを公開し、ベンダーはそれぞれの手順を示す。公開測定は調査箇所を示せても、組織の代わりに確認はできない。

10月9日の証拠から言えるのは限定的なことだ。後継鍵は1年以上公開され、多くの観測シグナルとテスト経路が読み込みを示し、APNICは重点確認の候補を挙げた。90％、95％超、70％の説明は一つの準備度スコアにはならない。10月11日の実務上の問いは、個別の検証経路が新鍵で署名されたルートを受け入れるかどうかであり、どの数字を見出しにするかではない。

出典

APNICの10月9日測定報告、IANAの信頼アンカーとロールオーバー日程、RFC 8145、RFC 8509、RFC 5011、Verisignの7月28日更新、ICANN 2026年運用者向けFAQ、CloudflareのKSK-2024リゾルバーテスト。