IETF는 2021년 5월 28일 RFC 9022 "Domain Name Registration Data (DNRD) Objects Mapping"을 표준 제안(Proposed Standard)으로 발행했습니다. 이 문서는 도메인 이름 레지스트리가 에스크로 기관(escrow agent)에 정기적으로 예치하는 도메인 이름 등록 데이터(DNRD, Domain Name Registration Data)의 형식, 내용, 의미를 정합니다. 저자는 G. Lozano, J. Gould, C. Thippeswamy입니다.
무엇이 발표되었나
레지스트리 데이터 에스크로(RDE, Registry Data Escrow)는 레지스트리가 정기적으로 데이터를 제3자인 에스크로 기관에 맡기는 절차입니다. 예치 데이터는 레지스트리가 기능을 잃었는데 서비스를 질서 있게 이전할 수 없거나 이전할 의사가 없을 때, 제3자가 운영을 다시 시작하는 데 필요한 최소한의 데이터입니다. RFC 9022는 에스크로 절차 자체를 다루는 RFC 8909(Registry Data Escrow Specification)를 따르는 도메인 레지스트리가 쓸 표준 객체 집합을 정의합니다.
정의된 객체는 다음과 같습니다.
- Domain: 확장 가능 등록 프로토콜(EPP, Extensible Provisioning Protocol) 도메인 매핑(RFC 5731)으로 등록하는 도메인 이름. RFC 5731의 속성을 모두 지원합니다.
- Host: EPP 호스트 매핑(RFC 5732)으로 등록하는 호스트 이름(네임서버 등).
- Contact: EPP 연락처 매핑(RFC 5733)으로 등록하는 개인·조직 정보.
- Registrar: 도메인, 호스트, 연락처 객체를 후원하는(sponsor) 조직.
- NNDN(NNDN's not domain name): 등록 불가 예약어 목록처럼 도메인 객체로 저장하지 않는 이름을 예치하기 위한 경량 객체.
이 밖에 의사 객체(pseudo-object)로 국제화 도메인 이름(IDN) 테이블 참조, 레지스트리가 지원하는 EPP 파라미터, 특정 시점의 객체 개수(Timeline Watermark 기준)를 담는 Header, 레지스트리 사업 모델에 따라 선택(OPTIONAL) 요소를 필수로 지정하는 Policy를 정의합니다.
예치 방식으로는 XML 모델과 CSV(쉼표로 구분된 값) 모델 두 가지를 둡니다. 두 모델은 동등하며, 문서는 어느 쪽도 권장하지 않습니다. 한 예치분에 두 모델을 섞을 수 있지만, 한 객체는 한 가지 모델로만 예치해야 합니다(MUST). 원문은 관계형 데이터베이스(RDBMS)의 CSV 내보내기를 쓰는 레지스트리에는 CSV 모델이, EPP용으로 개발한 코드를 재사용하는 레지스트리에는 XML 모델이 맞을 수 있다고 예를 듭니다.
영향 범위
원문에 따르면 등록 데이터 에스크로는 일반 최상위 도메인(gTLD)에서는 의무 사항이고(ICANN 기본 레지스트리 계약 Specification 2), 일부 국가 코드 최상위 도메인(ccTLD) 관리자도 데이터를 예치하고 있습니다. ICANN 인증 등록대행자(registrar)에게도 비슷한 요구 사항이 있습니다.
이 문서는 레지스트리의 등록 데이터 보관 형식을 다루므로 DNS 프로토콜 동작이나 권한 서버·재귀 서버 설정에는 직접 영향이 없습니다. 주로 TLD 레지스트리 운영자, 등록대행자, 에스크로 기관이 관련됩니다.
운영자가 할 일
- 레지스트리나 등록대행자 시스템을 운영한다면 현재 에스크로 예치 형식이 RFC 8909와 RFC 9022의 객체 정의, XML·CSV 모델 규칙에 맞는지 확인하세요.
- 일반 DNS 서버 운영자는 따로 조치할 필요가 없습니다. 레지스트리 데이터 보호 방식을 이해하는 참고 자료로 보시면 됩니다.
- 문서의 현재 상태와 정오표(errata)는 RFC Editor 페이지(https://www.rfc-editor.org/info/rfc9022)에서 확인할 수 있습니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.