요약

  • RFC 3375는 레지스트라가 스폰서드 도메인 객체를 생성·관리하되, 네임스페이스와 존마다 하나의 레지스트리가 최종 권위를 유지하는 공유 등록 시스템을 기술했다.
  • 또한 식별자 연속성, 스폰서십, 공유 자원 연관, 이전, 레지스트리 트랜잭션 상태, DNS 공개를 분리했다. 한 계층의 성공은 다음 계층의 권위나 완료를 증명하지 못한다.

한 등록인이 소매 레지스트라에게 도메인 생성을 요청하는 상상을 해보자. 레지스트라는 지시를 받아 레지스트리에 인증하고 명령을 제출한다. 레지스트리는 객체를 생성한다. 나중에 도메인은 정체성을 유지한 채 다른 레지스트라로 옮겨갈 수 있다. 첫 번째 레지스트라를 통해 관리되는 네임 서버가 두 번째 레지스트라가 스폰서한 도메인을 서비스할 수도 있다. 결국 선별된 레지스트리 데이터는 권위 있는 DNS 존이 된다. 이 행위들은 하나의 서비스에 속하지만, 하나의 사실은 아니다.

2002년 9월에 정보성(Informational) 문서로 발표된 RFC 3375는 이러한 제도적 분리를 일반 레지스트리–레지스트라 프로토콜의 요구사항으로 전환했다. 인터넷 표준을 정의하지도, 구현을 인증하지도, 채택을 증명하지도 않았다. 공유 도메인 등록이 행정적 예외가 아니라 인프라가 되어가던 시점에 명확히 드러낸 경계들에 이 문서의 역사적 중요성이 있다.

문서는 세 가지 역할을 명명했다. 등록인은 레지스트라를 통해 이름을 등록한다. 레지스트라는 등록인에게 서비스를 제공하고 레지스트리에 접속한다. 레지스트리는 위임과 연관된 중앙 저장소를 유지하며, 일반적으로 존 파일을 생성·배포하는 책임을 진다. 공유 시스템에서 여러 독립 레지스트라가 느슨한 결합을 통해 동일한 레지스트리 서비스를 사용한다.

이 느슨한 결합은 기술적 권위를 해체하지 않은 채 상업적 접근을 재분배했다. RFC 3375는 주어진 네임스페이스와 존에 대해 권위 있는 레지스트리는 하나뿐이라고 명시하면서도, 하나의 레지스트리가 여러 네임스페이스를 담당할 수 있음을 인정했다. 따라서 레지스트라는 네임스페이스의 궁극적 권위의 일부가 아니라 관리 채널을 가진 것이었다. 경쟁은 고객 인터페이스에서 존재할 수 있었고, 네임스페이스의 일관성은 중앙화된 채 유지되었다.

프로토콜은 세션, 질의, 생성, 갱신, 갱신기한 연장, 삭제, 이전을 지원해야 했다. 또한 인증, 권한 부여, 상태 보고, 트랜잭션 식별자가 필요했다. 수정 작업에 붙는 식별자는 교환을 추적 가능하게 만들었다. 성공 응답은 레지스트리가 레지스트리 작업을 수용하거나 수행했음을 보여줄 뿐이었다. 등록인이 왜 변경을 원했는지, 존 파일 투영이 일어났는지, 모든 권위 서버가 이를 적재했는지, 원격 리졸버가 무엇을 관찰할 수 있는지는 증명하지 못했다.

RFC 3375는 객체를 일회용 행이 아니라 지속적인 실체로 취급했다. 모든 객체는 전역적으로 고유한 식별자를 필요로 했다. 이 식별자는 행정적 통제가 바뀌더라도 저장소에서의 객체 수명 기간 동안 변경되지 않아야 했다. 이 규칙은 정체성을 관리권과 분리했다. 이전은 새로운 도메인, 연락처 또는 서버 객체가 태어난 것처럼 꾸미지 않고도 스폰서 레지스트라를 변경할 수 있었다.

이 구분은 공유 자원에서 특히 중요했다. 네임 서버 객체는 서로 다른 레지스트라가 스폰서한 도메인에 유용할 수 있었다. RFC의 예시는 다른 레지스트라가 해당 서버 객체를 관리하더라도 레지스트라가 자신의 도메인에 기존 서버 객체를 연관시키는 것을 허용했다. 참조가 통제를 부여하는 것은 아니었다. 그렇지 않다면 공유 서버를 단순히 사용하는 레지스트라가 다른 등록인이 의존하는 자원을 변경할 수 있게 된다.

따라서 이전은 가벼운 재작성이 아니라 스폰서십의 통제된 변경이었다. 요청은 예상되는 새 관리자가 시작하며, 시스템은 권한 확인, 연관 객체 서술, 이전 상태 보고, 결정 전 취소 허용, 승인 또는 거절 통지를 지원해야 했다. 존 내 네임 서버가 도메인과 함께 이동할 때 프로토콜은 그 결과를 명확히 드러내야 했다. 안정적인 식별자는 변경을 넘어가면서도 감사 기록은 누가 어떤 권한을 얻었는지를 남겼다.

문서는 두꺼운(thick) 레지스트리와 얇은(thin) 레지스트리도 수용했다. 두꺼운 레지스트리는 위임 데이터와 등록과 연관된 사회적·연락처 정보를 모두 저장한다. 얇은 모델은 그 정보 일부를 레지스트리와 레지스트라 사이에 나눈다. 요구사항은 양쪽을 모두 지원하도록 설계되었다. 모든 운영자가 동일한 저장소 설계로 수렴해야 한다고 주장하지 않으면서 최소 공통 문법을 제공한 것이다.

DNS 경계가 가장 흐려지기 쉽다. RFC 3375는 레지스트리에 서비스하는 네임스페이스의 존 파일 생성을 배정했다. RFC 1034와 RFC 1035는 권위 있는 DNS 데이터, 서버, 캐시, 리졸루션을 기술한다. RFC 2136은 DNS 존의 동적 업데이트를 기술한다. 이 메커니즘들은 연결되지만, 레지스트리 객체와 DNS 자원 레코드는 호환되는 영수증이 아니다. 수용된 갱신, 연락처 변경, 이전은 즉각적인 존 효과가 없어도 실재할 수 있다. 위임 변경은 리졸루션을 통해 보이기 전에 이후의 공개 및 적재 과정을 필요로 할 수 있다.

RFC 2832 같은 선행 연구는 이미 레지스트리 레지스트라 프로토콜(Registry Registrar Protocol)을 규정했다. RFC 3375는 기능적 요구사항을 추상화했다. RFC 3730은 이어서 확장형 프로비저닝 프로토콜(Extensible Provisioning Protocol)을 규정했고, RFC 5730이 나중에 그 기본 명세를 대체했으며 RFC 5731, RFC 5732, RFC 5733이 도메인, 호스트, 연락처의 매핑을 정의했다. 이 연표는 공유 인터페이스를 정제해온 명세 작업을 보여준다. 모든 레지스트리가 모든 기능을 구현했거나, 동일한 데이터 모델을 사용했거나, 동일한 운영 타이밍을 제공했다는 것은 확립하지 않는다.

RFC 2119의 규범적 어휘는 문서를 부풀리지 않고 읽는 데 도움이 된다. MUST와 SHOULD는 제안된 프로토콜 설계 내부의 요구사항을 표현할 뿐, 바깥 세계에 대한 증명이 아니다. RFC 2277의 국제화 정책 역시 그 시기의 제약이다. 글로벌 등록 프로토콜은 인간의 이름, 법적 관계, DNS 식별자를 하나의 무차별 필드로 통합하지 않으면서 언어와 문자 문제에 부딪혀야 했다.

Lu Heng의 "Minimum Initial Specification"은 유용한 관점을 제공한다. 공유 프로토콜은 최소한의 상호운용 가능한 동작을 정의하면서 지역 정책과 이후의 결정은 책임 있는 기관에 남겨둘 수 있다. "On Reality Layers"는 감사를 더 예리하게 한다. 등록인 요청, 레지스트라 인증, 객체 스폰서십, 레지스트리 수용, 저장소 상태, 존 생성, 권위 서비스, 리졸버 관찰은 연결된 주장이지만 어느 하나도 다른 모든 것을 대신할 수 없다.

이것이 RFC 3375의 지속적인 교훈이다. 인터넷의 도메인 시장은 네임스페이스에 대한 단일 권위 장부를 유지하면서 매장을 분산시킬 수 있었다. 객체가 정체성을 바꾸지 않고 관리권을 바꿀 수 있게 하고, 다른 레지스트라가 통제권을 물려받지 않은 채 공유 객체를 참조할 수 있게 했다. 그 결과 시스템은 권위를 정확히 분할했기 때문에 확장할 수 있었다. 그 근거 역시 똑같이 세심하게 분할되어야 한다.

출처