요약

  • JPRS가 파산하거나 채무불이행 상태가 될 경우.jp의 후계자를 결정할 권한은 2002년 1월 31일자 JP 도메인 이름 관리·운영 이전 계약 제14조(6)항에 따라 JPNIC과 일본 정부 당국이 공동으로 가지며, ICANN에게 있지 않다(이전 계약).
  • JPRS는 후계자가 결정될 때까지.jp 운영을 계속해야 하며, 이후 관련 레지스트리 데이터를 모두 이전해야 한다(같은 계약 제13조(11)항 및 제13조(12)항)(이전 계약).
  • 데이터 에스크로는 3자 구조다: JPRS는 암호화된 레지스트리 데이터를 매일 JPNIC과 정부 당국이 승인한 에스크로 에이전트에 전송하고 JPNIC이 그 과정을 감사하며, 에이전트는 지시에 따라 데이터를 인도해야 한다(에스크로 개요).
  • ICANN과 JPRS 간.jp ccTLD 후원 계약에는 Continued Operations Instrument도 지정된 긴급 임시 운영자도 없다. 장애 시 ICANN의 역할은 기술적 루트 기능이지 운영자 교체가 아니다(후원 계약;ICANN.jp 페이지).
  • 반면 JPRS의 gTLD 레지스트리 계약 —.jprs와 류큐(Ryukyu) 문자열 — 에는 Continued Operations Instrument와 긴급 이전 체계가 포함되어 있다(.jprs 계약;류큐 계약).
  • JP DNSSEC 실천 선언(JP DPS)은 후계자에게 가장 어려운 문제를 만든다: 서비스 정보는 에스크로되지만 개인 서명 키는 그렇지 않아, 후계자는 새 키를 생성하고 루트 존의.jp DS 레코드를 교체받아야 한다(JP DPS).

gTLD식 답이 틀리는 질문

gTLD 체계에 깊이 익숙한 운영자에게 레지스트리가 실패하면 어떻게 되느냐고 물으면 답은 술술 나온다: ICANN 레지스트리 계약의 Continued Operations Instrument(COI), 긴급 이전(Emergency Transition) 절차, 긴급 백엔드 운영자로 나서는 ICANN. 그 체계는 존재하고, 계약상 명시되어 있으며, 공개적으로 논의된 적도 있다. JPRS가 gTLD 레지스트리 운영자로 보유한 문자열에는 이것이 기대되는 답이다.

.jp에 대해 그 기대되는 답은 그저 틀렸다. 2002년 2월 27일 ICANN과 JPRS가 서명하고 ICANN 자체 문서 아카이브에 게시된.jp ccTLD 후원 계약에는 Continued Operations Instrument도 없고 긴급 임시 운영자 지정도 없다(후원 계약). 거기에 담긴 것은 표준 ccTLD 프레임워크다: ICANN은 JPRS를.jp의 후원 조직(Sponsoring Organization)으로 인정하고, 루트 데이터베이스 항목과 행정 연락처를 유지하며, 루트 존에.jp 위임을 게시한다(ICANN.jp 페이지). 내일 JPRS가 무너진다 해도 ICANN의 문서들은 누가 레지스트리 운영 업무를 인수하는지 누구에게도 알려주지 않는다. ICANN에게 루트를 어떻게 처리할만 알려줄 뿐이다.

진짜 답은 다른 곳에 있다 — 대부분의 비(非)일본어 독자가 읽어 본 적 없는 국내 계약과, 후계 체계를 사전에 볼 수 있도록 JPRS가 직접 공개하는 문서들에.

이전 계약: JPNIC과 정부 당국이 트리거를 쥐고 있다

JP 도메인 이름 관리·운영 이전 계약은 2002년 1월 31일 JPNIC과 JPRS 사이에서 체결되어 2002년 4월 1일 효력이 발생한,.jp의 핵심 연속성 문서다. JPRS는 문서 색인에 이를 게시한다(문서 색인). 쌍무 계약으로서 JPNIC이 갑(甲), JPRS가 을(乙)이며, 정부 당국(政府当局)은 JPNIC이 동의를 구해야 하는 제3의 당국으로 전반에 등장한다.

후계 권한은 제14조에 있다. 제14조(6)항에 따르면 JPRS가 파산하거나 지급능력을 상실하거나, 또는 전(前)항에 따라 재이전이 결정된 경우 JPNIC과 정부 당국이 서로 협의하여 신속히 새로운 수수(受託)자를 정한다(이전 계약). 제14조의 앞 항들은 이 두 주체에게 단계적 절차를 부여한다: JPNIC은 JPRS의 명시된 책무에 대한 중대한 위반에 대해 개선 권고를 하고, JPRS가 정당한 사유 없이 이를 시정하지 않으면 JPNIC과 정부 당국이 협의해 재이전을 서면 예고하며, 이후 공동으로 재이전을 결정한다(이전 계약).

제13조는 그 동안 JPRS가 지닐 의무를 정의한다. 제13조(11)항은 재이전 대상이 결정될 때까지.JP의 관리·운영을 계속할 것을 JPRS에 부과하고, 제13조(12)항은 관련 레지스트리 데이터를 그 대상에 모두 이전할 것을 요구한다(이전 계약). 운영자의 자유를 연속성과 관련된 방식으로 제한하는 두 조항도 있다: JPRS는 ICANN이 위임한 JP 레지스트리 관리자 지위를 제3자에게 양도할 수 없고(제13조(7)항), ICANN에 통지하지 않고 기술적 ccTLD 레지스트리 운영의 전부 또는 일부를 하도급할 수 없다(제13조(8)항)(이전 계약).

제15조는 국내 문서를 국제 문서와 묶는다: 이전 계약은 그 밖의 조건과 함께 ccTLD 후원 계약이 체결되었을 때에만 효력이 발생한다(이전 계약). 재위임 기록도 그 순서와 맞물린다. 일본 정부는 2002년 1월 30일 JPRS를.jp 관리자로 승인했고, IANA 재위임 보고서는 2002년 2월 8일에 이어졌다. ICANN의 ccTLD 페이지는 2002년 2월 8일자 이사회 승인을 기록하는 반면, IANA의 두 번째 보고서는 이사회 승인을 2002년 2월 12일로 기록한다 — 해결하지 않되 기록해 둘 만한 작은 문서상 불일치다(ICANN.jp 페이지;IANA 보고서;IANA 두 번째 보고서). 후원 계약은 2002년 2월 27일 서명되었고, JPNIC–JPRS 이전은 2002년 4월 1일 효력이 발생했다. ICANN 계약을 조건으로 하고, 기능상으로는 그보다 오래 지속되는 국내 계약이다.

JPNIC과 JPRS의 2021년 양해각서(MOU)는 프레임워크의 실무 조건을 갱신하며, 2013년 양해각서도 같은 공개 시리즈에 놓여 있다(2021년 양해각서). 장애 시나리오에서 중요한 후계 조항은 구조가 그대로다: JPNIC과 정부 당국이 공동으로 쥐고 있다.

에스크로: 후계자가 사용할 데이터 경로

JPNIC과 정부 당국이 후계자를 정하면, 후계자에게는 레지스트리 데이터가 필요하다. 에스크로 체계가 제공하는 것이 바로 그것이며, 쌍무적 예치가 아니라 의도적으로 3자 구조로 설계되어 있다.

.jp 데이터 에스크로 시스템의 공개 설명은 역할을 정리한다: 레지스트리 운영자인 JPRS는 암호화된 에스크로 데이터의 매일 추출·전송을 수행하고, 에스크로 에이전트는 안전한 오프사이트 저장을 제공하며 예치된 데이터를 보관하고, JPNIC은 감사자로서 전 과정을 통제·감사하며 에이전트는 감사자의 지시에 따라 데이터를 인도해야 한다(에스크로 개요). 에스크로 에이전트는 JPNIC과 JPRS가 정한 기준에 따라 JPRS가 선정하되, 이전 계약에 따라 후계 권한을 쥔 바로 그 두 주체인 JPNIC과 정부 당국의 승인을 받아야 한다(에스크로 개요).

두 사실이 그림을 선명하게 한다. 첫째, 에스크로 구성의 선정 세부사항과 결과는 의도적으로 공개되지 않으며, 조사한 기록에서 현재 에이전트의 신원은 공개되지 않았다. 둘째, 이 역할은 주기적으로 재입찰된다: JPRS는 2023년 7월 에스크로 에이전트 후보 모집을 공고했다(JPRS 공고; 문서 색인에 RFP 문서 목록이 있다). 에스크로 에이전트 사업에 대한 2008년 RFP 개요 문서도 JPNIC의 공개 자료에 남아 있다(RFP 개요).

설계 의도는 계약서만으로 읽힌다: 이전 계약 제14조(8)항은 재이전 대상이 결정되면 에스크로 에이전트가 레지스트리 데이터를 후계자에게 신속히 이전할 것을 요구한다(이전 계약). 에스크로는 후계자의 공급망이고, 그 감사는 후계자의 품질 보증이다. 그리고 그 거버넌스 — 에이전트는 JPRS가 선정하고, 후계 당국이 승인하고, JPNIC이 감사하는 — 는 어느 한쪽에게도 데이터에 대한 일방적 통제를 주지 않으면서 모든 당사자를 고리에 두고 있다.

DNSSEC: 데이터 에스크로가 메우지 못하는 연속성 공백

JPRS가 공개한 JP DNSSEC 실천 선언(JP DPS)은 후계자의 일이 어디서 어려워지는지 보여주는 문서다.

JP DPS는 레지스트리에 긴급 키 롤오버, 사전 정의된 복구 절차, 원격 백업 사이트로부터의 재개, 긴급 키 세리머니 수행의 책임을 부과한다(JP DPS). 조직의 폐쇄 — 해산 또는 중단 — 시에는 JP DNSSEC 서비스에 필요한 정보가 에스크로 에이전트에 예치된다고도 명시한다.

그러나 같은 문서는 개인키 에스크로는 수행되지 않는다고 밝힌다. 키 자료는 핵심 시설의 잠금 금고에 보관된 하드웨어 보안 모듈(HSM)에 여러 사본으로 존재하며, 일부 사본은 오프사이트에 저장된다(JP DPS). 이 두 조항을 함께 읽으면, 후계자 운영자는 서명 키 자체를 물려받지 못한다. 새 키를 생성하고 새 DNSKEY 레코드를 게시한 뒤, 루트 존의.jp DS 레코드를 교체받아야 한다 — 이는 IANA 루트 존 변경 절차에, 즉 국내에서 선출된 후계자와 ICANN/IANA 루트 기능 간 조정에 달려 있다(JP DPS).

여기서 두 제도적 트랙이 필연적으로 만난다. 국내 체인은 후계자가 누구인지 정하고, 국제 체인은 후계자의 서명을 전 세계 리졸버에 권위 있는 것으로 만든다. 어느 하나만으로는 충분하지 않으며, 공개 기록은 그 상호작용을 단일 문서로 명시하지 않는다.

JPRS의 gTLD 문자열에 있고.jp에는 없는 것

JPRS 자신의 gTLD 사업과의 대조는.jp의 설계 선택이 우연이 아니라는 점을 드러나게 한다.

ICANN에 제출된 JPRS의.jprs 레지스트리 계약에는 표준 gTLD 연속성 체계가 담겨 있다: ICANN이 레지스트리 기능을 긴급 운영자로 이동시키는 방식을 명시한 Continued Operations Instrument와 긴급 이전 조항이다(.jprs 계약)..ryukyu 계약도 마찬가지다(류큐 계약). 이 문자열들에 대해서는 ICANN이 계약상 교체 레버를 쥐고 있다.

.jp에는 그런 조항이 존재하지 않는다. TLD를 살려두는 체계는 국내적이고 계약적이며, ICANN 문서보다 4주 앞선 쌍무 계약에 명문화되어 있다. 주목할 점은, JPRS 자신의 재해에 강한 DNS에 관한 연구조차.jp가 아니라.jprs 문자열을 사용했다는 것이다 — 두 트랙이 하나의 회사의 하나의 장애 모드가 아니라 별개의 체제로 운영된다는 또 다른 신호다.

2019년 ICANN 행사에서 JPRS가 발표한 재해 대비 발표는 JPRS가 구축한 운영 강화 — 이중화 시설, 재해 DNS 체계, 훈련 프로그램 — 를 설명한다(재해 대비 발표). 이는 비상계획 문서에 가장 가까운 공개 자료이며, 운영자의 회복탄력성을 설명할 뿐 운영자의 후계를 설명하지 않는다. 조사한 기록에서.jp 레지스트리의 단독 공개 사업연속성 계획은 발견되지 않았다; 연속성 의무는 이전 계약, JP DPS, 에스크로 문서 안에 나타난다.

기록이 보여주는 것과 남겨두는 것

공개 기록은 장애 질문에 대한 두 층의 답을 뒷받침한다. 국내적으로는 JPNIC과 정부 당국이 도산 시 후계자를 공동으로 결정하고, JPRS는 그때까지 운영을 계속하며 레지스트리 데이터를 이전해야 하고, 에스크로 에이전트는 JPNIC의 지시에 따라 데이터를 인도한다. 국제적으로는 ICANN이 루트 항목과 위임을 유지하며, 새로운 DNSSEC 운영자가 필요로 하는 DS 교체를 포함해 후계자의 루트 존 변경을 처리할 것이다.

기록이 남겨두는 것도 똑같이 중요하다. 현재 에스크로 에이전트의 신원이 공개되지 않아 데이터 경로의 완전성은 외부에서 검증할 수 없다. 이전 계약상 부처급 당국인 정부 당국이 실제 도산에서 어떻게 움직일지는 한 번도 행사된 적이 없어, 제14조(6)항의 타임라인은 선례가 아닌 약속이다. 그리고 DS 레코드 교체 단계 — 국내 후계와 전역(全域) 해석 사이의 경첩 — 는 이전 계약도 JP DPS도 인용하지 않는 루트 존 변경 절차가 다룬다.

인프라 관찰자에게 교훈은 올바른 문서를 읽는 것이다. “.jp 도메인을 누가 계속 운영하는가”에 대한.jp의 답은 ICANN의 계약에 없다. JPRS가 공개하는 2002년 쌍무 계약과, JPNIC이 감사하는 에스크로 시스템, 무엇이 에스크로되고 무엇이 아닌지 솔직히 밝히는 DNSSEC 실천 선언 속에 있다. 그 체계는, 일본어를 읽고 어디를 볼지 아는 사람에게는 공개되어 있다. 이 보고서는 그 기록을 영어로 읽어내기 위해 존재한다.

출처

  1. JP 도메인 이름 관리·운영 이전 계약
  2. JPNIC–JPRS 양해각서, 2021년 12월
  3. JPRS 문서 색인
  4. .jp ccTLD 후원 계약
  5. ICANN.jp ccTLD 페이지
  6. IANA 재위임 보고서, 2002년 2월 8일
  7. IANA 두 번째 보고서, 2002년 4월 1일
  8. .jp 데이터 에스크로 개요
  9. 에스크로 에이전트 RFP 개요, 2008년
  10. JP DNSSEC 실천 선언
  11. .jprs 레지스트리 계약
  12. .ryukyu 레지스트리 계약
  13. JPRS 재해 대비 발표, ICANN, 2019년
  14. JPRS 관계자 간 거래 공지, 2024년
  15. JPRS 문서 색인
  16. JPNIC–JPRS 양해각서, 2021년 12월
  17. JPNIC–JPRS 양해각서(일본어)
  18. 후원 계약 부속서 3
  19. JPRS 레지스트리 보고서 2024
  20. JP 도메인 이름 데이터 취급 규칙
  21. JPRS 기술 정보(영어)
  22. JPRS 주제 공지, 2022년 11월
  23. JPRS 보도자료, 2017년 10월
  24. JPRS 주제 공지, 2023년 7월
  25. JP DNSSEC 실천 선언(일본어, v1.6)
  26. JP DNSSEC 실천 선언(일본어, v1.4)
  27. JPRS 기술 색인
  28. .jp 후원 계약(ICANN 자료 페이지)
  29. JPNIC 주제 공지, 2023년 7월
  30. JPRS 디렉터리 항목, BTW