요약

  • RFC 10026은clientUpdateProhibited와serverUpdateProhibited를 "모든 DS 데이터를 옮길 수 없다는 증명"이 아니라, 특정 참여 주체와 명령 경로를 구속하는 제어로 본다.
  • 키 교체나 알고리즘 이전 기간에 인증되고 수용 검사를 통과한 DS 유지 관리를 계속 수행하는 것이 오히려 DNSSEC 연속성을 유지하는 데 필요한 조치일 수 있다. 잠금 상태, 하위 영역의 요청, 상위 영역의 결정, 최종 게시는 각각 별도로 입증되어야 한다.
  • "잠김" 배지는 변경을 자동으로 승인하지도, 변경이 없음을 증명하지도 않는다. 신뢰할 수 있는 결론은 참여 주체별로 정리된 결정 기록, 알림 사슬, 독립 복구 경로에서 나온다.

스크린샷 하나는 확실감을 만들기 쉽다. 도메인 옆에 초록색 자물쇠가 있고, 계정은 가장 안전한 상태로 보인다. 그러나 사고 복기에서 스크린샷은 대개 아주 좁은 질문 하나에만 답한다. 어느 시점에, 어떤 화면이 어느 사용자에게 무엇을 보여 주었는가. 그것은 EPP 서버가 그 시점에 어떤 상태를 저장하고 있었는지, 그리고 이후 누가 어느 경로로 상위 영역의 DS 집합을 바꾸었는지에는 답할 수 없다.

2026년 7월에 발표된 RFC 10026은 IETF Best Current Practice BCP 246이며, 저자는 Steve Sheng과 Peter Thomassen으로 기록되어 있다. 이 문서는 DNSSEC 위임 서명자(DS) 레코드의 자동 유지 관리를 다루며, 특히 제품 화면이 흔히 가려 버리는 문제를 매우 직접적으로 짚는다. 업데이트 잠금에는 제어 경계가 있다는 것이다. 일상 언어의 "잠금"은 프로토콜의 참여 주체, 권한, 명령 의미를 대신할 수 없다.

잠금의 접두사는 이미 권한의 출처를 말해 준다

RFC 5731은 EPP 도메인 상태에 대해 명확한 명명 규칙을 정한다.client로 시작하는 상태는 스폰서 클라이언트가 설정하고 제거하며, 보통 레지스트라에 해당한다.server로 시작하는 상태는 서버가 제어하며, 보통 레지스트리에 해당한다.clientUpdateProhibited와serverUpdateProhibited는 모두, 해당 상태를 제거하는 요청을 제외하고 서버가 객체에 대한 업데이트 요청을 거부하도록 요구한다.

두 이름은 대칭처럼 보이지만 권력 관계는 대칭이 아니다. 클라이언트는 서버가 설정한 상태를 바꿀 수 없다. 반면 서버는 로컬 정책에 따라 클라이언트 상태를 변경하거나 덮어쓸 수 있다. 따라서 "업데이트 금지"는 실행 주체에서 분리된 추상적 명령이 아니라, 특정 참여 주체 사이에서 효력을 갖는 규칙이다.

clientUpdateProhibited가 존재할 때 주로 가려지는 것은 스폰서 클라이언트로서 제출되는 레지스트라의 일반 업데이트 명령이다. 이 상태를 설정한 레지스트라는 그것을 제거할 수 있고, 레지스트리는 레지스트라가 클라이언트 상태를 설정했다고 해서 자신의 행동 능력을 잃지 않는다. 이 잠금은 고객 포털의 실수나 낮은 권한 계정의 남용 위험을 효과적으로 낮출 수 있지만, 레지스트라와 레지스트리라는 높은 권한의 참여 주체가 기술적으로 행동할 수 없음을 증명하지는 못한다.

serverUpdateProhibited는 레지스트라에 대해 더 강하다. 레지스트라의 업데이트 요청은 거부되어야 하기 때문이다. 그러나 이 역시 서버 운영자가 자신의 로컬 실행 능력을 시스템에서 삭제했다고 주장하지 않는다. 레지스트리가 공개된 정책에 따라 서버 측에서 어떤 조치를 완료했다면, 상태 자체는 그 조치가 권한을 넘었는지를 판정할 수 없다.

따라서 잠금의 첫 번째 유효한 영수증은 적어도 네 항목을 담는다. 상태를 누가 설정했는가, 언제 존재했는가, 어떤 종류의 명령을 거부하는가, 어떤 참여 주체가 여전히 다른 인가된 경로로 행동할 수 있는가. "잠금이 아직 있다"는 그중 한 칸일 뿐, 결론이 아니다.

DNSSEC의 보안 상태는 영원히 정지해 있을 수 없다

도메인을 구성하고 잠그고 오래 두는 것은 어떤 등록 운영에서는 합리적인 습관일 수 있다. 그러나 DNSSEC의 신뢰 사슬에는 시간에 따라 반드시 유지해야 하는 상태가 있다. 서명 키는 교체되고, 알고리즘은 은퇴하고, DNS 공급자는 바뀐다. 상위 영역의 DS 집합은 적절한 시점에 하위 영역을 따라가야 하며, 그렇지 않으면 이전 값이 그대로 있어도 검증 기능이 실패할 수 있다.

바로 여기서 "전면 동결"은 직관에 반하는 위험을 만든다. 하위 영역은 이미 새 키를 준비했는데, 상위 영역은 일반 업데이트 잠금을 영구 금지로 오해해 DS 조정을 미룬다. 오래된 키가 비활성화되면 검증기가 보는 것은 만료된 신뢰 자료를 가리키는 사슬일 수 있다. 잠금은 이전 데이터를 지켰지만, 그 데이터가 지키려던 검증 가능성 자체를 파괴한 것이다.

RFC 7344는 하위 영역이 CDS 또는 CDNSKEY를 통해 상위 영역의 DS 유지 관리 요청을 표현할 수 있도록 허용한다. RFC 9615는 아직 DS 신뢰 경로가 없는 위임에 대해 인증된 자동 부트스트랩 방식을 제공한다. 이 신호들은 익명의 의견도 아니고, 보자마자 실행해야 하는 지시도 아니다. 출처 인증, 일관성 판단, 보안 투영을 거쳐야 하는 프로토콜 증거이다.

그래서 RFC 10026은 다음을 권고한다.clientUpdateProhibited같은 레지스트라 업데이트 잠금이 존재한다는 이유만으로 자동 DS 유지 관리를 중단해서는 안 된다. 레지스트리가 직접 자동화를 수행할 때에도,serverUpdateProhibited같은 레지스트리 업데이트 잠금만으로 그것을 중단해서는 안 된다. 이 원칙은 DS의 최초 게시에도, 이후의 키 교체에도 적용된다. 기본 잠금 도메인이 인증된 초기 DS 집합을 게시하기 위해 기계적으로 먼저 잠금을 풀고 다시 잠그도록 요구되지 않는다.

이것은 시스템에 "잠금을 무시하라"는 뜻이 아니다. 더 정확한 이해는 이렇다. 일반 EPP 업데이트 잠금과, 인증되었고 그 잠금이 금지하는 대상에 속하지 않는 DS 유지 관리 경로는 서로 직교한다. 어떤 사유의 대역 외 레지스트리 잠금은 더 넓게 적용되어 여러 승인자나 오프라인 절차가 필요할 수 있다. 그것은 별개의 제품·권한 계약이며 항목별로 설명해야 하고, 익숙한 "잠금"이라는 단어를 빌려 범위가 같다고 가정해서는 안 된다.

경로를 유지하는 것이 모든 요청을 수락하는 것은 아니다

유지 관리 경로가 잠겨 있지 않다고 해서 어떤 CDS나 CDNSKEY든 상위 영역에 들어갈 수 있는 것은 아니다. RFC 10026은 수용 검문소를 게시 이전에 두며, 먼저 상위 영역 에이전트가 하위 영역의 의도가 명확함을 확인하도록 요구한다.

CDS와 CDNSKEY가 동시에 존재한다면 같은 키를 가리켜야 한다. 관련 신호는 위임이 나열한 모든 권위 있는 네임서버에서 신뢰할 수 있는 일관된 상태로 나타나야 한다. 이어서 시스템은 제안된 DS 집합의 결과를 계산해, 적어도 하나의 유효한 DNSSEC 검증 경로가 유지됨을 확인해야 한다. 의도가 불일치하거나 예상 결과가 지속 검증을 깨뜨린다면 업데이트를 취소해야 한다.

따라서 한 번의 변경에는 서로 대체 불가능한 다섯 가지 판단이 관련된다. 잠금이 실제로 무엇을 구속하는가. 하위 영역이 요청을 게시했는가. 요청이 인증 가능하고 권위 네임서버들 간에 일치하는가. 제안된 상위 영역 상태가 계속 검증 가능한가. 상위 영역이 수용 결과를 실제로 게시했는가.

이 사실들은 서로 "증명을 전달"할 수 없다. 잠금이 존재한다고 CDS가 진짜임이 증명되지 않는다. CDS가 진짜여도 모든 권위 네임서버가 일치함이 증명되지 않는다. 일치해도 변경 후 검증 가능함이 증명되지 않는다. 수용이 통과되어도 상위 영역이 게시했음이 증명되지 않는다. 상위 영역이 게시했어도 모든 재귀 확인기가 이전 DS의 캐시 기간을 넘어섰음이 증명되지 않는다.

이 분해는 또한 이 글과 같은 RFC를 겨냥한 또 다른 문제를 구분한다. 전체 권위 네임서버 검사는 하위 영역이 일관된 요청을 표현했는지를 다룬다. 잠금 범위는 등록 상태가 어느 관리 참여 주체와 명령 경로를 제한할 수 있는지를 다룬다. 앞의 영수증이 뒤의 영수증을 대신할 수 없다.

레지스트라가 설정한 잠금은 레지스트라 자신을 막지 못한다

RFC 10026의 위협 모델은 시장 선전에 호의적이지 않다. 클라이언트 업데이트 잠금은 악의적인 레지스트라나 레지스트리에 대한 충분한 방어가 될 수 없다. 레지스트라는 자신이 설정한 클라이언트 상태를 제거할 수 있고, 서버는 로컬 정책에 따라 그것을 덮어쓸 수 있기 때문이다. 공격자가 이미 두 고권한 주체 중 하나를 장악했다면, 몇 분 전에 잠금 아이콘이 나타났었다는 사실이 이후의 행동을 자동으로 막지 않는다.

이것이 업데이트 잠금에 가치가 없다는 뜻은 아니다. 잠금은 존속 기간 동안 일반 업데이트 명령을 거부해 실수, 도난당한 고객 계정, 자동화 스크립트 오류의 위험을 낮출 수 있다. 문제는 그 가치를 "모든 기관이 행동할 수 없다"는 보증으로 확장할 수 없다는 점뿐이다.

사고 조사는 특히 이 확장에 저항해야 한다. 포털 스크린샷은 표시 계층의 증거다. 서버 상태 읽기는 제어 평면의 증거다. 발신 참여 주체, 인가 방식, 수용 로그, 상위 영역 차이가 진짜 변경 사슬의 증거다. 첫 항목만 있다면 조사자는 변경이 안전하다고 선언할 수도, 화면과 결과의 불일치만으로 침입이라고 선언할 수도 없다.

더 강한 대역 외 잠금은 물론 결론을 바꿀 수 있다. 예컨대 레지스트리 제품이 전화 확인, 이중 승인, 지연 기간, 별도 자격 증명을 요구해야만 어떤 제한을 해제하거나 우회할 수 있게 할 수 있다. 그러나 평가 대상은 그 제품의 실제 해제 권한, 긴급 예외, 감사 기록이지 제품 이름이 아니다.clientUpdateProhibited,serverUpdateProhibited, 이전 잠금, 삭제 잠금, 사유의 레지스트리 잠금을 하나의 제어로 혼동해서는 안 된다.

올바른 변경에도 목격자가 필요하다

등록인–레지스트라–레지스트리 관계에서 레지스트리 측 자동화는 레지스트라의 일반 업데이트 명령을 거치지 않고 합법적으로 DS를 변경할 수 있다. 이것은 유지 관리 연속성을 해결하지만 정보 비대칭을 만들기 쉽다. 레지스트라는 무슨 일이 있었는지 모르고, 등록인에게는 잠금만 여전히 켜져 보인다.

RFC 10026은 이 문제를 별도의 보고 메커니즘으로 처리하도록 요구한다. 레지스트리가 DS 자동화를 수행할 때는 RFC 8590이 정의한 EPP Change Poll 확장이나 유사한 경로로 레지스트라에 알려야 하고, 중대한 업데이트와 비활성화는 관련 연락처에도 통지해야 한다. 등록인 또는 그 지정자는 관리 화면에서 현재 실제로 적용 중인 DS 구성을 볼 수 있어야 한다.

상위 영역 에이전트는 구조화된 결정 기록을 보존해야 한다. 시각, 그 결정을 촉발한 CDS/CDNSKEY 데이터, 사용한 통지 경로, 조회한 권위 네임서버, 각 검증 결과, 최종 결정, 실제 적용된 DS 집합 또는 취소 사유가 포함된다.

이 대장이 있으면 "잠긴 도메인이 올바르게 변경되었다"는 모순이 아니게 된다. 기록은 다음을 증명할 수 있다. 잠금은 본래 보호하려던 경로에서 계속 유효했다. 인증된 다른 신호가 별개의 경로로 들어왔다. 수용 검사를 통과했다. 상위 영역을 다룰 권한이 있는 측이 게시를 완료했다. 관련 참여 주체가 통지를 받았다. 공개된 상위 영역 상태가 결정과 일치한다.

사슬에서 한 고리라도 빠지면 결론은 좁아져야 한다. 통지가 없다는 것은 우선 보고 실패를 증명할 뿐, DS를 자동으로 무인가로 만들지 않는다. 상위 영역 DS의 변화는 게시가 있었음만 증명하지, 하위 영역 신호가 진짜임을 증명하지 않는다. 화면이 여전히 잠김을 표시하는 것은 표시 상태만 증명하지, 서버의 결정을 증명하지 않는다.

복구는 이미 잃어버린 그 키에 의존할 수 없다

자동화가 유일한 입구가 되어서도 안 된다. 하위 영역은 교체 요청의 인증을 제공하던 서명 키를 잃을 수 있다. 다중 운영자 환경에서 한 곳이 협조를 거부할 수 있다. DNS 공급자가 아예 CDS/CDNSKEY를 지원하지 않을 수도 있다.

그래서 RFC 10026은 레지스트리와 레지스트라가 다른 DS 유지 관리 경로를 제공하도록 요구한다. 인적 절차여도 좋지만, 대역 내 증거를 만들 수 없을 때 제어를 회복할 수 있어야 한다. 현재 키로 인증되는 프로토콜은 현재 키가 이미 손상된 뒤 전환을 허공에서 증명할 수 없고, 같은 메커니즘을 반복해도 빠진 암호학적 영수증은 채워지지 않는다.

인적 복구 역시 감사 가능해야 한다. 누가 조직을 대표해 요청했는지, 어떤 대역 외 검증을 했는지, 어떤 DS 상태를 만들려 했는지, 자동화가 임시 중단되었는지, 언제 복구했는지, 상위 영역이 마지막에 무엇을 읽었는지. 그렇지 않으면 "인적 예외"는 또 하나의 경계 불명확한 잠금이 된다.

Steve Sheng의 서명은 기여를 증명할 뿐 운영 권한을 이전하지 않는다

RFC Editor는 RFC 10026의 두 저자로 Steve Sheng과 Peter Thomassen을 기록한다. IETF Datatracker는 Sheng이 참여한 RFC 7485와 RFC 7710도 나열한다. ICANN 공식 회의 기록에 따르면 그는 2022년에 정책 개발 지원 선임 이사 신분으로 관련 회의를 진행했다. 그의 현재 공개 소개에 따르면 2024년에 ICANN에서 15년에 이르는 기술·정책 연구 업무를 마쳤으며, 카네기 멜론 대학에서 공학 및 공공정책 박사 학위를 받았다.

이 자료들은 프로토콜과 기관 운영을 넘나드는 공개 기여의 위치를 잡아 줄 뿐, 어떤 레지스트리, 레지스트라, 상위 영역, 배치에 대한 제어권을 Sheng에게 귀속시키지는 못한다. IETF 합의 문서는 개인이 도메인 보유자에게 내리는 명령이 아니며, 저자 신분도 모든 운영자가 그 권고를 이미 이행했음을 보장하지 않는다.

여기에는 잠금과 비슷한 경계가 있다. 서명은 기여자를 정확히 가리키지만 그래서 운영권을 부여하지 않는다. 상태는 하나의 금지를 정확히 가리키지만 그래서 시스템의 모든 참여 주체를 결박하지 않는다. 인물을 존중하는 가장 좋은 방법은 개인의 권력을 과장하는 것이 아니라, 그의 검증 가능한 기여를 집단적 표준과 실제 배치 사이에 되돌려 놓는 것이다.

최종 증거는 참여 주체별로 정리된 결정 영수증이다

복기 가능한 DS 변경은 공개 및 서버 측 잠금 상태, 설정자와 시각에서 시작해, 제출자, 명령 또는 자동화 경로, CDS/CDNSKEY 원본 자료, 인증 결과, 전체 권위 네임서버 일관성, 지속 검증 투영, 로컬 수용 정책과 결정을 기록해야 한다.

이어서 상위 영역 게시 시각, 최종 DS 집합, 관련 TTL, 레지스트라와 등록인에 대한 통지, 확인기에서 보이는 검증, 독립 복구 입구까지 보충해야 한다. 비밀과 무관한 개인 데이터는 대장에 들어가서는 안 되고, 권한과 결과를 설명하는 데 필요한 증거는 반드시 보존해야 한다.

이것은 "실행 중인 시스템 우선"이라는 제어관이다. 명세는 공통 최소 요구를 제공한다. 일반 등록 잠금이 인증된 DNSSEC 연속성을 우연히 파괴해서는 안 되고, 자동화가 복구 경로를 없애서도 안 된다. 운영자는 더 강한 잠금, 더 많은 검사, 다른 통지 정책을 채택할 수 있지만, 각 선택은 어느 경로를 구속하는지를 설명해야 한다.

"잠기면 안전하다"보다 더 오래 지속되는 규칙은 이것이다. 잠금은 공개된 참여 주체와 명령 경계 안에서만 증거가 된다. 경계 밖에서는 보안 주장마다 자기 영수증이 필요하다.

출처