루트 서버 거버넌스 모델은 운영 정지를 허용하지만 재개는 정의하지 않는다

요약

• 루트 서버 시스템 거버넌스 워킹그룹의 최종 모델은, 불이행이 루트 서버 시스템(RSS)에 중대한 위협이 되는 극단적 사안에서 향후 보안 사고 보고(SIR) 기능이 루트 서버 운영자(RSO)의 운영을 정지할 수 있게 한다. 이 권한은 완전한 권한을 갖춘 거버넌스 단계로의 단계적 전환을 마친 뒤에만 존재한다. 검토한 공개 기록은 그 단계나 권한이 오늘날 존재함을 보여주지 않는다.
• 영구 해제는 별도의 경로를 따른다. 지정 및 해제(DNR) 기능은 시정 기회를 제공하고, 이사회에 해제를 건의하며, RSSAC030이 확인한 세 개의 DNS 루트 소스에서 질서 있는 제거를 조율한다. 이 모델은 일시적 SIR 정지가 해당 소스에 영향을 미치는지, 얼마나 지속되는지, 운영자가 어떻게 재개되는지는 말하지 않는다.
• 권한 부여에 앞서 이사회는 버전화된 정지·복귀 연속성 접수증을 비준해야 한다. 접수증은 권한, 범위, 시계, 시정, 항소, 복귀 검증 및 DNR 이관을 드러내되, 공격을 가능하게 하는 증거는 보호 부록에 두어야 한다.

하나의 동사가 미완성 상태를 연다

루트 서버 시스템 거버넌스 워킹그룹은 약 4년에 걸쳐 이전 RSSAC 권고를 기능 모델로 만들어 왔다. 2026년 2월 18일 워킹그룹이 승인한 최종 보고서는 향후 거버넌스 구조가 필요로 할 책임에 대해 소극적이지 않다.

완전한 권한을 갖춘 거버넌스 단계에서 보안 사고 보고(SIR) 기능은 보안 사고를 조사하고, 데이터와 협력을 요청하고, 보안 강화를 명령하고, 보안 정책을 집행하며, 시정 조치를 부과할 수 있다. 가장 심각한 사안에서는 불이행이 루트 서버 시스템에 중대한 위협이 되는 경우 “RSO의 운영을 정지”할 수 있다.

고려할 만한 정당한 권한이다. 보고서를 수집만 하고 급격한 위험을 봉쇄할 수 없는 핵심 인프라 거버넌스는 문제를 발견하면서도 시스템을 보호하지 못할 수 있다.

문제는 그 동사 다음부터 시작된다. 보고서는 정지의 대상을 정의하지 않는다. 이 조치가 거버넌스 구조 내 운영자의 지위만 변경하는지, 특정 서비스 의무를 제한하는지, 운영자 인프라의 일부를 격리하는지, 하나의 루트 식별자에 영향을 주는지, 아니면 궁극적으로 DNS가 루트 서버 운영자를 식별하는 공개 소스를 변경하는지 명시하지 않는다.

또한 재개(reinstatement)라는 용어도 등장하지 않는다. 최종 86페이지 모델을 검색해도 시정, 기술적 준비성, 항소, 권한 회복을 연결하는 복귀 상태는 나타나지 않는다. 정지는 사용 가능한 권한으로 제시되고, 회복은 미래의 기구가 작성해야 할 절차에 맡겨져 있다.

이는 현재 RSO가 안전하지 않다는 증거가 아니다. ICANN, RSSAC 또는 IANA가 오늘날 하나를 정지할 수 있다는 증거도 아니다. 제안된 구조가 그 동사를 실행할 수 있는 단계에 도달하기 전에 해결해야 할 설계상 질문이다.

그 권한은 제안된 것이지, 활성화된 것이 아니다

모델의 단계 구성은 성급한 경보에 대한 가장 강력한 대답이다.

개시 단계는 이사회와 사무국을 구성한다. 이는 의도적으로 범위와 권한이 제한된다. 설립 단계는 기능들을 만들어 헌장을 부여하고, 보안·성능 정책을 작성하며, 지정과 해제를 정의하고, 적법 절차와 항소를 구축하고, 재정을 확보하며, 이 구조와 ICANN·IANA·RSSAC의 관계를 문서화한다.

전환 관문은 엄격하다. 모든 기능이 운영 중이어야 한다. 핵심 거버넌스 정책이 비준되어야 한다. 마일스톤 1~11의 완료가 포괄적인 공개 평가에 기록되어야 한다. 공개 의견 수렴이 이루어져야 하고, 참여 이해관계 커뮤니티가 합의에 따라 자문받아야 하며, 이사회가 구조가 준비되었다고 정식 표결해야 한다. 그때에야 마일스톤 12는 구조가 RSS 거버넌스 권한을 갖고 운영을 시작한다고 명시한다.

본 기사에서 검토한 공개 기록은 그 순서가 일어났음을 보여주지 않는다. GWG 의장은 2026년 2월 20일 최종 모델을 ICANN 커뮤니티, 이사회, IETF/IAB, RSSAC 및 RSO에 전달했다. 이사회 의장은 감사 인사로 답하고 이사회가 앞으로의 경로를 기대한다고 밝혔다. 그것은 접수이지 채택 결의가 아니다. ICANN 기획 자료는 이사회 채택과 이후 이행을 예상했지만, 예측은 실행된 결정이 아니다.

이 구분이 핵심이다. 본 기사는 제안된 모델이 활성화하기에 충분히 완결적인지 검증할 수 있다. 그러나 미래의 권한을 현재의 사실로 바꿀 수는 없다.

SIR과 DNR은 서로 다른 시계로 작동한다

최종 보고서는 모든 형태의 운영자 책임을 하나의 위원회에 넣지 않는다. SIR과 지정 및 해제(DNR) 기능은 출발점과 산출물이 다르다.

SIR은 보안 사고에서 출발한다. 그 범위는 표준화된 보고, 사고 후 검토, 보안 통제, 감사, 취약점 완화 및 외부 소통을 포함한다. 거버넌스 단계에서는 긴급성을 위해 설계된 조사·집행 권한을 얻는다. 시정을 명령하고, 긴급 조치를 승인하고, 극단적으로 운영을 정지할 수 있다.

DNR은 성능 모니터링·평가 기능을 통해 확인된 성능 우려나 불이행에서 출발한다. DNR은 조사하고, 정해진 시한 내에서 운영자와 함께 개선 작업을 진행하며, 충분한 시정 기회가 주어졌음에도 요구 기준이 충족되지 않을 때만 해제를 건의한다. 이사회가 최종 승인한다. 이후 DNR은 IANA에 통보하며 DNS 루트 소스로부터의 질서 있는 종료와 제거를 조율한다.

이 구분은 연속성과 공정성을 모두 보호한다. 영구 지위 사건이 조사되기 전에 보안 대응이 필요할 수 있다. 영구 해제는 운영자 커뮤니티의 구성을 바꾸므로 더 높고 느린 기준을 요한다.

그러나 두 경로는 인수인계 문제를 낳는다. 일시적 SIR 정지는 시정 성공, 다툼이 있는 판정, 더 좁은 조치 또는 DNR 사건으로 이어질 수 있다. 모델은 어느 사건이 관할을 이전하는지, 기능 사이에서 운영자의 지위를 누가 소유하는지, 어떤 공개 결정이 SIR 사건을 종결하는지 말하지 않는다.

시정 조치 계획은 재개가 아니다. 개선 완료는 기술적·절차적 작업에 관한 사실이다. 재개는 권한 부여된 상태 변경이다. 모델이 이 두 사실을 연결하지 않으면, 일시적 조치는 적극적 결정이 아니라 조직 기억 속에서 계속 유효할 수 있다.

RSSAC030은 이 모호함을 기술적 문제로 만든다

“정지”는 RSSAC030과 나란히 읽기 전까지는 거버넌스 용어처럼 들릴 수 있다.

이 한 페이지 성명은 IANA 기능 운영자가 관리하는 세 가지 핵심 소스, 즉 루트 힌트 파일, 루트 존, root-servers.net 존을 확인한다. 이들은 클라이언트가 루트 서버를 정의하는 데 사용하는 이름과 IP 주소를 담고 있다. 조직의 정보가 이 소스에 포함되는 것이 그 조직을 루트 서버 운영자로 식별하고, 통상적 시스템을 통해 서비스가 발견되도록 한다.

기능 모델은 DNR의 해제 범위에서 RSSAC030을 인용한다. DNR은 질서 있는 종료와 RSO의 해당 소스로부터의 제거를 조율한다. SIR 정지에는 그 문구를 사용하지 않는다.

그 결과 최소한 세 개의 별개 상태가 남는다.

첫째는 거버넌스 지위다. 기구의 결정이 운영자를 정지 상태로 선언한다. 둘째는 운영 상태다. 사고 대응 중 일부 또는 전부의 서비스 활동이 제한, 격리 또는 변경될 수 있다. 셋째는 루트 소스 상태다. IANA 관리 소스가 수정되어 조직을 식별하는 서비스 정보가 제거되거나 변경된다.

이 상태들은 서로에게서 추론되어서는 안 된다. 거버넌스 정지가 자동으로 루트 소스 항목을 지우는 것은 아니다. 사고 중 기술적 격리가 영구 해제인 것은 아니다. 모델이 영구 해제를 DNR과 이사회 승인에 한정한다면, 루트 소스 변경은 정의되지 않은 일시 조치의 그늘에서 일어나서는 안 된다.

따라서 공개 기록은 무엇이 변경되었는지 말해야 한다. 그 필드가 없으면 두 독자가 같은 단어를 보고 서로 다른 결과를 상상할 수 있다. 하나는 일시적 컴플라이언스 지위이고, 다른 하나는 사실상의 루트 제거이다.

항소만으로는 서비스가 복구되지 않는다

모델은 검증 장치를 제공한다. SIR은 연례 보고서를 발행하고, 외부 피드백 채널을 유지하며, 보안 권고를 동료 검토에 제출하고, 주기적 외부 검토를 받아야 한다. RSO와 기타 이해관계자는 이사회를 통해 SIR 결정에 항소할 수 있다. DNR 결정에는 이사회 직접 항소가 있고, 해제 건의에는 이사회 최종 승인이 필요하다.

항소 경로는 상태 머신이 아니다.

규정은 항소 제기가 정지의 효력을 정지시키는지 말하지 않는다. 이사회가 긴급 효력 정지를 발할 수 있는지, 검토가 진행되는 동안 어떤 서비스 상태가 적용되는지, 성공적 항소가 이전의 모든 권한을 자동으로 회복시키는지도 명시하지 않는다. 보안 취약점으로 인한 정지 이후 기술적 준비성을 재검증해야 하는지도 말하지 않는다. 시정 조치의 완료를 인증하는 주체도 특정하지 않는다.

이 질문들은 첫 극단적 사안에서 즉석으로 다루기에 위험하다. 운영자는 신속한 복귀와 기한 없는 제재로부터의 보호를 원할 것이다. SIR은 중대한 위협이 사라졌다는 확신을 원할 것이다. 다른 RSO는 동료 검토가 경쟁적 무기로 변하지 않는 가운데 집단 회복력을 원할 것이다. IANA와 루트 존 관리자는 소스나 조율 조치가 관련된다면 정확한 지시가 필요하다. 리졸버와 사용자는 분쟁이 결정되는 동안 집단 서비스가 계속되기를 원할 것이다.

적법 절차와 운영 연속성은 서로 다른 시계로 작동한다. 이사회는 증거 검토에 며칠이나 몇 주가 필요할 수 있다. 사고 완화는 몇 분이 필요할 수 있다. 완전한 절차는 신속한 봉쇄, 정의된 중간 상태, 이후의 본안 결정을 허용해야 하며, 어느 하나를 다른 것의 대체물로 취급해서는 안 된다.

공개 책임성에 익스플로잇 공개는 필요 없다

RSSAC062가 올바른 기밀성 경계를 제공한다. 이 2025년 가이드는 RSS의 가용성·무결성·기밀성에 중대한 악영향을 미치는 사고에 초점을 맞춘다. 보고가 완화를 방해해서는 안 되며 해결이 우선한다. 상세 보고서에는 TLP(Traffic Light Protocol) 제한이 붙을 수 있다. 미래의 공격자에게 도움이 될 정보는 제외해야 한다.

같은 문서는 인증된 제출, 기밀 취급, 시의적절한 공개 TLP:Clear 버전을 권한다. 기능 모델 역시 민감하지 않은 보안 요약을 요구하면서 민감한 운영 세부사항을 보호한다. 공개 의견 처리 결과에서 상세 기밀 규칙은 향후 SIR 절차에 맡겨졌다.

이 결합으로 최소한의 공개 접수증이 가능해진다. 공개는 개인 키, 토폴로지, 쿼리 로그, 미패치 취약점 세부사항, 포렌식 레시피를 필요로 하지 않는다. 공개가 필요한 것은 열거된 권한이 작동했다는 사실, 트리거의 일반 유형, 조치의 범위, 검토 시계, 현재 결과이다.

보호 부록에는 증거, 이름, 상세 개선 내역, 공격 지표가 담길 수 있다. 그 존재, 관리자, 접근 등급, 무결성 이력은 내용을 공개하지 않고 기록할 수 있다. 투명성은 권한 행사에 관한 것이며, 시스템을 두 번째 공격에 노시하라는 명령이 아니다.

가장 강한 방어는 절차를 완수할 이유다

제안된 모델은 가장 좋은 방어를 받을 자격이 있다.

RSS는 핵심 인프라다. 중복성은 시스템 전체의 위협을 감내하는 것보다 위험한 구성 요소 하나를 격리하는 것이 더 안전하게 만들 수 있다. 극단적 사안의 정지 권한은 일반적 허가 재량보다 좁다. 모델은 기능을 분리하고, 항소와 감독을 요구하며, 영구 해제 전에 운영자에게 시정 기회를 주고, 정책과 책임 메커니즘이 구축되고 공개 평가될 때까지 전체 권한을 유예한다.

기능 모델이 이행 세부사항을 설립 단계에 맡기는 것도 합리적이다. 헌장을 작성할 사람들은 실시간 대응, 보호 증거, IANA 조율, 운영자 자율성을 통합해야 한다. 최상위 보고서가 모든 사고 플레이북을 규정할 수는 없다.

그러나 그 어느 것도 복귀 경로를 선택 사항으로 만들지 않는다. 세부 위임은 활성화 체크리스트가 그 세부사항의 존재를 요구할 때만 타당하다. 마일스톤 7은 이미 보안 정책, 사고 대응, 에스컬레이션을 요구한다. 마일스톤 8은 지정, 해제, 적법 절차, 항소, 분쟁 해결을 요구한다. 마일스톤 10은 책임성과 추가 검토 절차를 요구한다. 이 마일스톤들이 하나의 통합된 정지·복귀 수명 주기를 요구하기에 자연스러운 장소다.

Lu Heng의 러닝 코드 우선 원칙(Running-Code Primacy)은 문자 그대로의 템플릿을 제공하지 않으면서 여기서 유용한 규율을 준다. 기구적 권한은 실행 중인 시스템이 요구하는 최소한의 기술적 효과에 대해 검증되어야 한다. 거버넌스 구조가 “정지”라고 말한다면, 상징적 지위가 균일한 기술적 현실을 만들 것이라고 가정하는 대신 운영상 변경을 특정해야 한다.

그의 레지스트리 연속성 구분도 신중히 적용하면 마찬가지로 유용하다. 연속성은 서비스, 보안 체계, 기록, 하류 사용자에 속한다. 그것은 관리자의 모든 권한이나 운영자의 모든 지위를 보존하는 것을 자동으로 의미하지 않는다. 정지는 집단적 RSS를 보호하기 위해 정당화될 수 있다. 바로 그 목표가 임시 조치가 연속성 리스크가 되지 않도록 경계된 복귀 또는 해제 경로를 요구한다.

정지·복귀 연속성 접수증을 공개하라

거버넌스 단계가 시작되기 전에 이사회는 모든 SIR 정지에 대한 버전화된 접수증을 비준해야 한다. 접수증은 조치 시점에 최소 메타데이터로 열리고 사고가 안정되면서 성숙해진다. 접수증은 절대 봉쇄를 지연시켜서는 안 된다.

접수증은 다음을 기록해야 한다:

• 안정적인 사건 식별자와 영향받은 RSO;
• SIR 권한, 정책 버전, 책임 있는 기구적 역할;
• 민감하지 않은 트리거 유형 및 긴급 절차 사용 여부;
• 정확한 범위: 거버넌스 지위, 서비스 의무, 인프라 하위 집합, 루트 소스 영향 여부;
• 결정 시각, 최초 최대 기간, 다음 필수 검토;
• 집단 RSS 연속성이 어떻게 보존되고 있는지;
• 시정 조치와 공개 완료 상태;
• 민감한 내용을 제외한 보호 증거 보관 및 분류;
• 항소 상태, 효력 정지 요청 여부, 정지 승인 여부;
• 복귀의 권한과 기준;
• 기술적 준비성 및 동료 또는 독립 검토 상태;
• 새로운 결정과 사유가 함께 기록된 모든 기간 연장;
• 종국 결과: 복원, 축소, 대체 또는 DNR 이관; 그리고
• 권한과 되돌림 상태를 포함한 별도의 IANA, RZM 또는 루트 소스 조치.

용어는 정확해야 한다.항소 제기는효력 정지 승인이 아니다.시정 완료는복귀 승인이 아니다.정지 검토는정지 연장이 아니다.DNR 이관은해제 승인이 아니다.해제 승인은루트 소스 변경 완료가 아니다.

접수증은 명시적 널(null) 상태도 담아야 한다. 루트 소스 조치가 없었다면 그렇게 말해야 한다. 항소가 제기되지 않았다면 그렇게 말해야 한다. 복원이 결정되지 않았다면 필드를 비워두는 대신pending decision으로 표시해야 한다. 거버넌스 오류는 독자가 부재, 지연, 의도된 부정적 결과를 구분할 수 없기 때문에 빈 셀 안에서 살아남기도 한다.

이 기록은 RSO 거부권을 만들지 않는다. SIR에 익스플로잇 공개를 강제하지 않는다. 공개 의견이 긴급 완화를 뒤집게 하지 않는다. 각 강제 상태가 권한, 범위, 시계, 종국 결정에 대해 책임을 지게 만들 뿐이다.

근거의 한계

검토한 근거는 기능 모델의 정식 채택이나 거버넌스 단계의 활성화를 보여주지 않는다. 이사회에의 전달, 감사 인사, 운영 계획상 기대는 채택 결의와 완료된 마일스톤의 대체물이 아니다.

검토한 어떤 출처도 이 모델에 따라 RSO가 정지되었음을, 어떤 현재 운영자가 불이행 상태임을, 어떤 현재 기구가 제안된 권한을 보유함을 보여주지 않는다. “재개”라는 단어의 부재는 미래의 헌장 작업이 복귀 절차를 만들 수 없다는 증거가 아니다. 그 절차가 왜 권한 부여의 조건이어야 하는지 보여줄 뿐이다.

suspend operations의 의미는 특정되지 않았다. 따라서 본 기사는 정지가 루트 힌트 파일, 루트 존 또는 root-servers.net 존의 항목을 제거한다고 주장하지 않는다. RSSAC030은 그러한 영향이 왜 별개의, 식별 가능한 기술적 조치가 될지를 보여주는 데 사용되었다.

마지막으로, 제안된 접수증은 민감한 사고 증거에 대한 요구가 아니다. 그 공개 계층은 권한과 상태에 관한 것이다. 상세 사실은 공개가 공격을 도울 수 있거나 정당한 운영 기밀을 노출할 수 있을 때 보호될 수 있다.

출처

1. ICANN — 루트 서버 시스템 거버넌스 구조, 2026년 2월 18일
2. ICANN — 루트 서버 시스템 거버넌스 원칙
3. GWG 의장 Brad Verd — 최종 보고서 및 산출물
4. ICANN 이사회 의장 Tripti Sinha — GWG에 대한 회신
5. ICANN 공개 의견 수렴 — 루트 서버 시스템 거버넌스 기능 모델
6. RSSAC030 — DNS 루트 소스 항목에 관한 성명
7. RSSAC058 — RSS 거버넌스 구조의 성공 기준
8. RSSAC062 — 보안 사고 보고
9. RSSAC055 — 공개 루트 서버 시스템 운영을 인도하는 원칙
10. ICANN 초안 운영·재정 계획 FY2027–2031 — 전략 이니셔티브 33
11. Lu Heng — 러닝 코드 우선 원칙(Running-Code Primacy)
12. Lu Heng — 레지스트리 연속성 오류(The Registry Continuity Fallacy)
13. Lu Heng — 현실의 계층, 상징적 권력, 그리고 명확성이 왜 이토록 적대적으로 느껴지는가