요약

  • RFC 9904는 2025년 11월 발행된 IETF Standards Track RFC로, RFC 8624를 공식 대체(obsoletes)하고 RFC 9157을 갱신한다.
  • 이 문서는 DNSSEC 알고리즘 구현 요구사항과 사용 지침에 관한 표준적(canonical) 내용을 IANA의 DNS Security Algorithm Numbers 및 DS Digest Algorithms 레지스트리로 옮긴다.
  • 네 개의 셀은 서로 교환할 수 없다. 검증자와 서명자의 구현 의무가 다를 수 있고, 검증 용도 권고와 서명 용도 권고도 서로 다를 수 있다.
  • RFC 9904 자체는 RFC 8624에서 계승된 MUST, MAY, RECOMMENDED 등 어떤 권고 상태도 변경하지 않는다. 이후 변경에는 Standards Action과 전환 및 상호운용성 논거가 필요하다.

이 메커니즘이 중요한 이유는 알고리즘 번호가 단일 정책 스위치가 아니기 때문이다. 레지스트리는 네 가지 서로 다른 질문을 표현할 수 있다. 검증자가 해당 알고리즘을 구현해야 하는지(MUST/SHOULD), 서명자가 구현해야 하는지, 검증에 사용하는 데이터에 권고되는지, 그리고 서명 데이터에 권고되는지. 이 질문들을 분리해 두면 비대칭적 전환이 가시화된다. 따라서 서명자 정책이 검증자 요구사항과 달라지더라도 두 역할을 동일하게 취급하지 않을 수 있다.

RFC 9904는 종합(omnibus) RFC에 주기적으로 교체되던 정적 권고 표 전체를 두는 대신, 관리되는 레지스트리 제어 표면을 두도록 한다. RFC 9904 이후에는 레지스트리가 권고 지침을 참조하는 표준적(canonical) 위치가 된다. RFC 본문은 프로세스에 대한 권위를 유지한다. 이후 RFC는 Standards Action을 통해 열을 수정할 수 있으며, 변경 설명에는 전환과 상호운용성에 미치는 영향을 다뤄야 한다. 이는 IANA가 그러한 절차 없이 권고 값을 바꿀 수 있도록 허용하는 것이 아니다.

출발점은 의도적으로 보수적이다. RFC 9904는 RFC 8624에서 계승한 지침을 옮길 뿐, 새로운 알고리즘 판정을 발표하지 않는다. RFC 9157은 갱신된 DNSSEC 레지스트리 고려사항 맥락을 제공하고, RFC 9364는 DNSSEC 인증과 부재 증명(denial-of-existence)에 대한 프로토콜 맥락을 제공한다. 고정된 원천 자료는 현재 채택 현황, 벤더 지원, 인시던트 빈도, 성능, 마이그레이션 비용, 미래 암호학적 판단을 확립하지 않는다.

Theo March 분석:운영 결정 기록에는 관련 두 IANA 레지스트리의 타임스탬프가 찍힌 스냅샷, 출처와 관측 시점, 정책에 반영된 네 개 셀의 내용을 담아야 한다. 배포 환경이 허용하는 곳에서는 기존 알고리즘과 대체 알고리즘의 오버랩 테스트 결과, 검증자와 서명자의 커버리지를 구분한 기록, 단계적 변경 증거, 롤백 자료를 기록에 포함해야 한다. 이는 분석적 변경 관리 권고이며, RFC 9904가 부과하는 요구사항이 아니다.

RFC 9904가 기술하는 운영상 위험은 구체적이다. 알고리즘을 너무 이르게 은퇴시키면 해당 알고리즘으로만 서명된 존이 검증자에게 사실상 서명되지 않은 것처럼 보일 수 있다. 따라서 은퇴는 신중하게, 이상적으로는 점진적으로 이뤄져야 한다.Theo March 분석은 이 경고를 결정 경로로 바꿔 제시한다. 관련 레지스트리 상태를 관찰하고, 역할을 구분하고, 오버랩을 테스트하고, 가능한 곳에서는 변경을 단계화하며, 롤백을 위한 증거를 보존하라는 것이다. 고정된 원천 자료는 이러한 시나리오가 현재 상황인지, 흔한지, 빠른지, 비용이 큰지를 확립하지 않는다.

운영자 결정 경로

Theo March 분석:

  1. 관찰:결정에 사용된 IANA DNS Security Algorithm Numbers 및 DS Digest Algorithms 레지스트리 스냅샷을 타임스탬프와 함께 기록한다.
  2. 분류:예정된 조치를 검증자 구현, 서명자 구현, 검증 용도, 서명 용도 중 어느 것에 해당하는지 매핑한다. 셀을 합쳐서는 안 된다.
  3. 확인:해당 RFC의 전환 및 상호운용성 논거를 읽고, 관련 서명 경로와 검증 경로 전반에서 오버랩을 테스트한다.
  4. 단계화:가능한 곳에서는 신중하고 점진적인 변경을 적용하며, 존이 검증자에게 사실상 서명되지 않은 것처럼 보일 수 있는지에 대한 증거를 확보한다.
  5. 복구:롤백 자료, 레지스트리 스냅샷, 테스트 결과, 정책 소유자의 결정 기록을 보존한다.

이 단계들은 수명 주기 제어 문제에 대한 Theo March 분석을 표현한 것이며, 추가적인 RFC 9904 요구사항이 아니다.

출처