要約

  • RFC 9904により、DNSSECの署名・委任・検証について、「利用」と「実装」の勧告を分けて示すIANAレジストリが正本になった。
  • RFC 9905はSHA-1ベースのDNSKEY、RRSIG、DSを新たに作ることを MUST NOT とする一方、検証機能の維持を求める。したがって、表への準拠は移行記録の入口であり、ゾーン移行完了の証明ではない。

RSASHA1の行にある署名利用欄が MUST NOT に変わった朝、ある権威サーバーはまだSHA-1のDNSKEYとRRSIGを返していた。親側の委任情報も旧構成のままだった。これは矛盾ではない。標準化の時計は進んだが、子、親、キャッシュ、検証器の時計は一斉には進まないからだ。

2025年11月の RFC 9904 は、RFC 8624 に収められていたDNSSECアルゴリズム勧告をIANAレジストリへ移した。RFC Editorの記録は、その標準化状態と RFC 9157 などとの関係を明示している。発行時点で既存の勧告強度をまとめて変えたのではなく、今後の変更を置く権威ある場所を変えた。

重要なのは表の置き場所よりも、責任の分解である。DNS Security Algorithm Numbersレジストリは、署名に使うべきか、検証に使うべきか、署名ソフトが実装すべきか、検証ソフトが実装すべきかを別々に示す。DS digestレジストリも、委任の生成と検証を区別する。「対応済み」という一語では、もう四つの義務を覆い隠せない。

RFC 9905 はこの仕組みを使い、RSASHA1およびRSASHA1-NSEC3-SHA1で新たなDNSKEY、RRSIG、DSを作ることを禁じた。ただし、検証器実装には当該署名アルゴリズムの支持を残す。新しい依存は作らず、残存ゾーンが退出する前に互換性を奪わない。この非対称性こそ、安全な縮退の設計である。

実際のロールオーバーは複数の管理主体を横断する。子ゾーンの署名器がDNSKEYとRRSIGを生成し、レジストラまたはレジストリ経路が親ゾーンのDSを更新する。権威サーバー群は新しいシリアルへ収束し、再帰キャッシュはTTLが切れるまで古いRRsetを保持する。検証器ごとにバージョン、実装アルゴリズム、観測時刻も異なる。ひとつの処理が成功しても、経路全体の成功にはならない。

観測結果の呼び方も厳密でなければならない。RFC 9364はDNSSECを起点認証の広い系譜に位置づけ、RFC 4035はsecure、insecure、bogus、indeterminateを区別する。RFC 9905が定めるのは、受理可能な代替が成立しない特定のSHA-1ケースをinsecureとして扱うことだ。SHA-1を含む全ゾーンがbogusまたは到達不能だ、という包括的主張ではない。

手順を省略すると、正しい目標が停止事故に変わる。RFC 9904は、新しいKSKの導入と同時にDSアルゴリズムを変えると検証障害が起こり得るため、DSアルゴリズムの更新を先に行うよう注意する。RFC 6781が示すとおり、アルゴリズムの追加・削除にはRRSIG、DNSKEY、DSの段階的な移行と、伝播・キャッシュ失効の待ち時間が要る。署名器の完了表示は、遠隔の検証器が安全な組合せを見た証拠ではない。

完了判定には、IANA表のスナップショットと根拠RFC、署名ソフトと設定の版、ゾーンシリアル、DNSKEY/RRSIG/DSの正確な集合、親側トランザクションの受領記録、独立した複数地点からの権威応答、TTL窓、検証器の版と判定、エラー計測、ロールバック素材、そしてサービス上の目的を結び付ける必要がある。どれか一枚の証拠に、連鎖全体の意味を代行させてはならない。

Heng Luの最小初期仕様は、共通表を狭く保ち、採用手順を説明責任のある運用者に残す。動くコードの優位は、実レコードと検証器で確かめることを求める。現実の層は、勧告、設定、公開RRset、利用者の結果を一つの制度的宣言に潰さない。これらは明示した編集上の原則であり、DNSOPに新しい要件を課すものではない。

レジストリは進むべき方向を定められる。あるゾーンとその検証経路が到達したかどうかを示せるのは、時刻付きで再現可能な証拠だけである。

Sources