IETF는 2020년 11월 17일 RFC 8909 「Registry Data Escrow Specification」을 표준화 트랙(Standards Track)의 제안 표준(Proposed Standard)으로 발표했습니다. 이 문서는 주로 도메인 이름 레지스트리를 대상으로, 데이터 에스크로 예치물(deposit)의 형식과 내용을 정합니다. 맡기는 객체의 종류와 상관없이 쓸 수 있도록 설계했기 때문에 도메인 레지스트리가 아닌 곳에서도 활용할 수 있습니다.
무엇이 발표되었나
레지스트리 데이터 에스크로(Registry Data Escrow, RDE)란 레지스트리가 에스크로 기관(escrow agent)이라는 제3자에게 데이터를 주기적으로 맡기는 절차입니다. 예치물에는 레지스트리가 기능을 잃었는데도 서비스를 질서 있게 넘길 수 없거나 넘기려 하지 않을 때, 제3자가 운영을 이어받는 데 필요한 최소한의 데이터가 들어갑니다. 도메인 레지스트리나 등록대행자(registrar)라면 등록된 도메인 이름과 관련된 모든 객체, 즉 도메인 이름, 연락처(contact), 네임서버 등이 해당합니다.
RFC는 이 제도의 목적을 등록 서비스의 회복력(resiliency)을 높이는 것이라고 밝힙니다. 레지스트리 데이터에 기대는 서비스의 이용자도 혜택을 받는 쪽이라는 설명입니다.
규격의 주요 내용은 다음과 같습니다.
- 예치물 형식은 XML 1.0과 XML 스키마(XML Schema) 표기법으로 정의합니다.
- 이 문서는 맡기는 객체와 상관없는 공통 형식만 정합니다. 맡길 레지스트리나 객체 집합마다 별도의 규격이 따로 필요합니다.
- 예치물은 다음 세 종류입니다.
- 전체 예치(Full Deposit): 정해진 기준 시점(Timeline Watermark)의 레지스트리 데이터베이스 전체 상태
- 차등 예치(Differential Deposit): 직전 예치(전체·증분·차등 중 어느 것이든) 이후 추가·수정·삭제된 모든 객체
- 증분 예치(Incremental Deposit): 직전 전체 예치 이후 추가·수정·삭제된 모든 객체. 마지막 전체 예치 이후에 증분이나 차등 예치가 또 있다면, 더 최근의 예치물은 앞선 예치물의 트랜잭션을 모두 담아야 합니다(MUST).
RFC는 차등(Differential)과 증분(Incremental)의 정의가 데이터 백업 분야에서 흔히 쓰는 뜻과 다르다고 직접 강조합니다. 그러니 백업 용어에 익숙한 담당자는 2장(Terminology)을 꼭 확인하는 것이 좋습니다.
영향 범위
RFC에 따르면 도메인 레지스트리 영역에서 등록 데이터 에스크로는 일반 최상위 도메인(gTLD)의 의무 사항입니다(예: ICANN Base Registry Agreement의 Specification 2). 일부 국가 코드 최상위 도메인(ccTLD) 관리 기관도 이미 데이터를 맡기고 있고, ICANN 인증 등록대행자에게도 비슷한 요구가 있습니다.
따라서 이 규격과 직접 관련된 곳은 레지스트리, 등록대행자, 에스크로 기관입니다. 권한 DNS 서버나 재귀 리졸버(recursive resolver)를 운영하는 쪽에서는 DNS 프로토콜 동작이나 설정이 바뀌지 않습니다.
운영자가 할 일
- 레지스트리·등록대행자 운영자: 에스크로 예치물을 만들고 검증하는 체계가 이 규격의 XML 형식과 세 가지 예치 유형 정의를 따르는지 확인하세요. 특히 차등 예치와 증분 예치를 백업 관례대로 해석하지 않았는지 점검해야 합니다.
- 객체 규격 확인: RFC 8909는 공통 형식만 다루므로, 실제로 맡기는 객체 유형에 맞는 별도 규격도 함께 따라야 합니다.
- 일반 DNS 서버 운영자: 따로 조치할 것은 없습니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.