要約

  • RFC 9904はIETFの標準化過程に属するRFCであり、2025年11月に公開された。RFC 8624を正式に置き換え、RFC 9157を更新する。
  • RFC 8624にあったDNSSECアルゴリズムの実装要件と利用に関する推奨を、IANAのDNS Security Algorithm NumbersおよびDS Digest Algorithmsレジストリへ移す。ただし、RFC 9904自体は、継承したMUST、MAY、RECOMMENDEDなどの推奨状態を変更しない。
  • 一つの番号に対するバリデーター実装、署名者実装、検証での利用、署名での利用は別々の欄である。推奨値の変更には標準化手続き上の承認が必要で、移行と相互運用性への影響を説明しなければならない。

これは、IANAが標準化手続きなしに値を変更できるという意味ではない。RFC 9904が移すのは、正規の推奨を参照する場所と、将来の変更を扱う仕組みである。RFC 9904以後、現在の推奨を確認する際には該当するIANAレジストリを参照し、変更の条件と手続きはRFC 9904で確認する。RFC 9157のDNSSECレジストリに関する考慮事項も、RFC 9904によって取り込まれ、更新されている。RFC 9364はDNSSEC認証と否定の存在証明に関するプロトコル上の背景を示すが、RFC 9904による推奨変更を示すものではない。

四つのセルを一つにまとめると、運用上の非対称性が消える。バリデーターが実装すべきかどうかは、署名者が実装すべきかどうかと同じではない。検証側で使うべきかどうかも、署名側で使うべきかどうかとは別である。したがって、単純な「対応済み／非対応」というラベルでは、どの役割の変更を判断したのかを後から説明できない。

Theo Marchの分析では、時刻付きレジストリの記録、責任の分離、重複署名と検証のテスト、段階的な変更、ロールバック証拠の保存を、運用上の選択肢として扱う。これらはRFC 9904自体が追加する強制要件ではない。実務では、参照したレジストリ名、記録、観測時刻、四つのセルの値を記録し、再帰的なバリデーター、権威DNSの署名者、検証ポリシー、署名ポリシーを別々の責任として整理できる。退役を検討する場合、Theo Marchの分析は新旧アルゴリズムの重複署名と検証、成功・失敗、時間枠、復旧手順の記録を提案する。早すぎる退役は、そのアルゴリズムだけで署名されたゾーンを、バリデーターから実質的に未署名に見せる可能性があるため、退役は慎重に、できれば段階的に行うべきである。

出典