요약

  • RFC 8334는 Launch Registration과 Launch Application을 구분합니다. 신청 모델에서는 레지스트리가 아직 도메인을 할당하지 않은 상태에서도 유효한 create 명령이 EPP 결과 코드 1001, 할당된applicationID및pendingCreate를 받을 수 있습니다.
  • 그 결과는 명령 수락에 대한 정확한 영수증이지, 상표 우선권·할당·등록·레지스트리 공개·DNS 위임·서비스 도달 가능성을 압축해 증명하는 것은 아닙니다. 이 동사들은 서로 다른 주체와 서로 다른 시계에 속합니다.
  • 감사 가능한 기록은 트랜잭션 ID, 단계와 정책, 신청 상태, 순서화된 poll 메시지, 최종도메인:panData를 결합한 뒤, 결과로 생성된 도메인 객체와 DNS 각 층을 별도로 확인해야 합니다. 하나의 초록불 '성공' 표시가 이 사슬을 파괴합니다.

RFC 8334에서 가장 유의미한 부분은 기이한 XML 요소가 아니라 평범해 보이는 성공 메시지입니다.

예시 서버 응답에는Command completed successfully; action pending이라고 적혀 있습니다. 결과 코드는 1001입니다. 응답에는 launch 단계와applicationID가 담겨 있습니다. 대시보드를 빠르게 훑는 운영자에게는 문장의 앞부분, 즉 '성공적으로 완료'가 압도적으로 보일 수 있습니다. 고객에게 성공은 도메인이 자신의 것이 되었다는 뜻처럼 들립니다. 경영진에게는 완료된 create가 등록 이벤트처럼 보일 수 있습니다.

그러나 문장의 뒷부분이 주장의 대상을 바꿉니다. 명령은 성공했습니다. 할당 결정은 아직 이루어지지 않았습니다.

바로 이 구분이 EPP(Extensible Provisioning Protocol)의 Launch Phase Mapping의 핵심입니다. RFC 8334는 2018년 3월 IETF Standards Track에서 발표되었으며 J. Gould, W. Tan, G. Brown이 공동 집필했습니다. IANA EPP Extension Registry는 RFC 8334를 참조 문헌으로 이 매핑을 등록하고 있습니다. Gavin Brown이 이 글에서 다루는 인물인 이유는, 그의 표준 작업이 수락된 지시와 운영적 사실 사이의 구간을 명확하게 들여다볼 수 있는 길을 제공하기 때문입니다. 그는 유일한 저자도, 레지스트리도, 검증 기관도, 할당 주체도 아닙니다.

2026년 8월 31일에 확보한 IETF Datatracker 프로필에 따르면 Brown은 DNS 및 도메인 이름 산업에서 25년의 경력을 쌓았으며, 그중 22년을 구 CentralNic인 Team Internet PLC에서 보냈고 그중 14년을 CTO로 근무했으며 현재는 ICANN에서 일하고 있습니다. 이 프로필은 RFC 8334를 포함한 네 개의 RFC와 RESTful Provisioning Protocol 작업 의장, ARTART 검토자 등 현재 공개 직책을 나열합니다. 이 날짜가 있는 사실들은 그의 전문 영역을 설명합니다. 그러나 어떤 레지스트리의 launch 재량도 그에게 이전하지 않습니다.

create라 불리는 서로 다른 두 가지

RFC 8334는 일상적 상태 용어가 자주 뒤섞는 두 launch 모델을 처음부터 분리합니다.

Launch Registration은 서버가 선착순 모델을 사용하는 launch 단계에서 이루어지는 단일 등록입니다. 서버는 작업이 성공하는 순간 도메인 등록을 생성합니다. Launch Application은 다릅니다. 이는 서버가 동일 도메인에 대해 여러 신청을 수락할 수 있고 나중에 하나를 골라 할당하는 모델에서, 도메인 등록 의사를 나타냅니다.

'여러 신청'은 이 모델의 기능이지 launch에 관한 보편적 사실이 아닙니다. 레지스트리는 다른 모델을 선택할 수 있습니다. 단계 자체가 자체 규칙을 부과할 수도 있습니다. Launch Application을 지원하지 않는 서버는 그 형식을 거부해야 합니다. 표준은 이 선택에 대한 상호운용 가능한 언어를 제공할 뿐, 레지스트리의 할당 정책을 대신 정하지 않습니다.

Launch Application의 create가 유효할 때 프로토콜적 결과는 정확합니다. 서버는 신청 객체를 생성하고, 신청 식별자를 부여하고, RFC 5731의pendingCreate상태를 설정하며,applicationID를 반환해야 합니다. 이 식별자 덕분에 여러 신청이 동일 도메인 이름에 관한 경우에도 이후 작업이 특정 하나의 신청을 참조할 수 있습니다.

이것은 진짜 성공입니다. 서버는 적용 가능한 프로토콜 맥락 아래 형식이 올바른 작업을 수락했고, 추적해야 하는 상태를 생성했습니다. 도메인이 아직 할당되지 않았다는 이유만으로 이를 실패라 부르는 것은 잘못입니다.

그러나 이 영수증을 등록으로 격상시키는 것도 똑같이 잘못입니다. 생성된 것은 신청 객체입니다. 상태는 보류입니다. 식별자는 신청을 식별합니다. 이 사실 어느 하나도, 안정 상태의 도메인 객체가 지금 신청자의 소유라는 뜻이 아닙니다.

문법이 중요한 이유는 운영 시스템이 상투적으로 명사를 평탄화하기 때문입니다.domain_create_success라는 데이터베이스 열은 자신이 신청 수락을 담는지 등록을 담는지 숨길 수 있습니다. 고객 통지는 객체 이름을 밝히지 않은 채 '생성됨'이라 말할 수 있습니다. 재무 시스템은 할당 결정 전에 매출을 인식할 수 있습니다. 보안 검토는 실제로는 신청 기록만 존재하는 상태에서 도메인 객체를 검색할 수 있습니다.

수정은 원리상 단순합니다. 나체의 동사를 저장하지 말 것. 어떤 객체가, 어떤 단계와 정책 아래, 언제 바뀌었고 무엇이 아직 미결인지 기록할 것.

결과 1001이 실제로 수취하는 것

RFC 5730은 EPP의 코어를 정의합니다. 결과 1001은 요청된 조치가 아직 보류 중인 상태에서 명령이 성공적으로 완료되었음을 의미합니다. 트랜잭션 응답은 클라이언트가 제공한 클라이언트 트랜잭션 식별자를 유지할 수 있으며, 서버 트랜잭션 식별자는 반드시 제공해야 합니다. 이 값들 덕분에 요청과 응답을 로그 간에 상호연관시킬 수 있습니다.

따라서 Launch Application에 유용한 영수증에는 최소한 클라이언트·서버 트랜잭션 ID, 서버 시각, 스폰서링 클라이언트, 도메인 이름, 단계, 선택적 하위 단계, create 형식, 결과 코드, 신청 식별자, RFC 5731 객체 상태, launch 상태가 포함됩니다.

이 묶음은 다음처럼 좁은 진술을 지지합니다. 이 서버가, 이 프로토콜과 정책 맥락 아래, 이 시각에, 이 신청 작업을 수락하고 기록했다.

반면 '성공'이라는 단어와 함께 자주 다니는 여섯 가지 더 넓은 진술은 지지하지 않습니다.

  1. 신청자가 법적 또는 상표적 권리를 입증했다.
  2. 레지스트리가 경쟁 신청 가운데 이 신청을 선택했다.
  3. 도메인 등록이 이제 최종 상태로 존재한다.
  4. 공개 레지스트리 데이터 또는 RDAP가 이미 도메인을 노출한다.
  5. 도메인이 권한 존에서 위임되었다.
  6. 도메인의 서비스에 도달 가능하거나 신청자가 그 서비스를 통제한다.

각 진술은 나중에 참이 될 수 있습니다. 그러나 어느 하나도 1001에 담기지 않습니다.

이것은 프로토콜 문제인 동시에 대리(agency) 문제입니다. 등록기관 클라이언트는 제출할 수 있습니다. 검증 제공자는 상표나 통지 자료를 평가할 수 있습니다. 레지스트리는 launch 정책을 적용하고 할당할 수 있습니다. 레지스트리 공개 시스템은 데이터를 노출할 수 있습니다. 존 운영자는 위임을 공개할 수 있습니다. 권한 네임서버는 응답할 수 있습니다. 서비스 운영자는 애플리케이션을 구성할 수 있습니다. 한 주체의 성공 동사가 다음 주체의 권한을 묵시적으로 부여하지는 않습니다.

단계 이름은 정책을 담고 있지 않다

RFC 8334는 sunrise, landrush, claims, open, custom 등 launch 단계 값을 정의합니다. 클라이언트는 대상 단계를 명시해야 합니다. 서버는 단계를 검증해야 하며, 하위 단계를 활성 구성에 비추어 검증할 수도 있습니다. 단계는 겹칠 수 있고, 선택적 name 속성은 하위 단계를 세분하거나 custom 단계에 이름을 붙일 수 있습니다.

이 필드들은 필요한 상호연관 근거입니다. 그러나 완전한 정책 문서는 아닙니다.

두 레지스트리가 같은 단계 라벨을 쓰면서 서로 다른 제출 기간, 검증 제공자, 수수료 규칙, 동순위 결정 절차, 신청자 제한, 할당 일정을 적용할 수 있습니다. RFC 8334는 서버 정책의 상당 부분을 의도적으로 대역 외에 둡니다. 프로토콜은 명령이 어떤 단계를 대상으로 했는지 말할 수 있어도, 그 결과를 가능하게 한 모든 규칙을 설명하지는 않습니다.

따라서 조사는 EPP 기록 옆에 적용 가능한 정책 버전과 효력 시점을 함께 보존해야 합니다. 'sunrise'만으로는 특정 상표 형식이 의무였는지, 신청이 둘 이상 허용되었는지, 검증이 언제 이루어졌는지, 경쟁하는 유효 신청이 어떻게 순위가 매겨졌는지 알 수 없습니다. 'claims'만으로는 모든 필수 통지가 제시되고 확인되었다는 것을 증명할 수 없습니다.

RFC 7848은 관련 launch 메커니즘이 사용하는 상표 및 서명된 상표 구조를 제공합니다. RFC 8334는 단계와 명령 형식에 따라 mark, signed-mark, validation code 또는 notice 자료를 운반할 수 있습니다. 이 출처 정보는 해당될 때 중요합니다. 그래도 상표 객체가 할당 결정을 만들지는 않습니다.

유효한 서명된 상표는 검증 단계를 지지할 수 있습니다. 통지 확인은 통지 워크플로가 발생했다는 증거가 될 수 있습니다. 검증자 식별자는 검증 맥락을 명명할 수 있습니다. 그러나 그 입력을 자기 정책 아래에서 해석할 책임은 레지스트리에 남습니다. 자료를 자동 권리로 취급하면 근거가 권위로 붕괴됩니다.

반대 오류도 가능합니다. 감사자는 활성 단계, 형식, 정책이 mark나 notice 필드를 의무로 요구했음을 확인하기 전까지, 그 필드의 부재를 비난해서는 안 됩니다. 최소 초기 사양은 교환을 조정하고, 책임 가능한 선택은 현지 정책이 공급합니다. 근거는 어느 쪽도 서로를 사칭하지 않은 채 양쪽을 모두 보존해야 합니다.

pending는 라벨이 아니라 역사다

RFC 8334는pendingValidation,validated,invalid,pendingAllocation,allocated,rejected,custom등 launch 상태를 정의합니다. launch 상태를 지원하는 경우, 최종 상태가 아닌 신청은 RFC 5731의pendingCreate를 유지합니다. 표준은 서버 정책이 모두 같은 순서를 쓰지 않기 때문에 상태를 건너뛰는 것을 허용합니다.

이 상태 모델의 목적은 더 예쁜 최종 배지를 만드는 것이 아닙니다. 결정의 순서를 보존하는 것입니다.

동일 도메인에 대한 세 개의 신청을 생각해 보십시오. 하나는 검증에 실패할 수 있습니다. 다른 하나는 검증을 통과했지만 할당 절차를 기다릴 수 있습니다. 셋째는 동일한 검증 단계를 요구하지 않는 정책 아래 바로 진행할 수 있습니다. 시스템이 최신 상태만 저장한다면, 어떤 검사가 일어났고 어떤 것이 정책에 의해 건너뛰어졌으며 어떤 메시지가 스폰서링 클라이언트에 전달되었는지 잃어버립니다.

RFC 5730의 poll 큐는 비동기 변화에 운영적 채널을 제공합니다. 메시지에는 식별자가 있습니다. 클라이언트는 대기 중인 메시지를 요청하고 수신한 것을 확인(acknowledge)합니다. RFC 8334는 서버가 중간 신청 변화에 poll 메시지를 사용해야 한다고 말합니다. 최종allocated또는rejected상태에서는 서버가 RFC 5731의도메인:panData보류 조치 메시지를 삽입해야 합니다.

이 최종 메시지는 단순한 알림 편의가 아닙니다. 보류 조치에 대한 프로토콜 역사를 닫습니다. 감사 가능한 사슬은 메시지 ID, 큐 적재 시각, 수신 시각, 확인 여부, 결과, 도메인, 신청 ID, 클라이언트·서버 트랜잭션 식별자, 그리고 이를 산출한 정책 상태를 함께 보관합니다.

할당과 거절은 대칭적인 비즈니스 결과가 아니지만, 둘 다 최종 launch 근거입니다.Allocated는 신청이 선택되었고 대응하는 등록을 RFC 5731 도메인 객체로 표현할 수 있음을 의미합니다.Rejected는 이 신청이 그 등록이 되지 않았음을 의미합니다. 어느 단어도 침묵, 타임아웃, 빈 공개 검색으로 만들어져서는 안 됩니다.

기밀성 절은 이 경고를 명시적으로 만듭니다. 신청의 존재 자체와 그 내용까지 기밀일 수 있습니다. 무단 작업은 결과 2201을 받아야 하고, 서버 정책은 일부 클라이언트에 필터링된 정보를 제공할 수 있습니다. 신청을 볼 수 없는 공개 관찰자가 그 신청이 존재하지 않는다고 결론 내릴 자격은 없습니다. 접근 통제는 관찰 표면을 바꿀 뿐, 기밀의 상태를 바꾸지 않습니다.

할당조차 아직 가동 중인 도메인이 아니다

최종 poll 메시지가allocated라고 가정해 보십시오. 근거 객체가 바뀌었습니다. 신청자는 이제 성공한 할당 결과를 갖고, 레지스트리는 결과 RFC 5731 도메인 객체를 승인된 클라이언트에 노출할 수 있어야 합니다.

그 다음의 흔한 실수는 할당이 나머지 운영 사슬을 삼키게 하는 것입니다.

레지스트리 안의 도메인 객체가 같은 순간 RDAP에서 공개일 필요는 없습니다. 공개에는 자체 처리 경로와 필터링 규칙이 있을 수 있습니다. 등록된 도메인이 TLD 존에서 위임되었을 필요는 없습니다. 위임된 도메인이 아직 유용한 권한 응답을 반환하지 않을 수 있습니다. 권한 응답이 HTTPS 서비스가 구성되었거나, 모든 네트워크에서 도달 가능하거나, 관찰자가 가정한 주체가 통제한다는 것을 증명하지는 않습니다.

이것들은 교조적 지연이 아닙니다. launch가 멈춘 것처럼 보일 때 누가 움직여야 하는지를 결정합니다. 신청이 보류 중이면 레지스트리 할당 워크플로가 그 문제의 주인입니다. 할당은 최종인데 도메인 객체가 없으면 레지스트리 프로비저닝 또는 프로젝션을 점검해야 합니다. 도메인 객체는 존재하는데 상위 존에 위임이 없으면 존 공개 경로가 문제입니다. 위임은 있는데 서비스가 실패하면 등록인의 네임서버 또는 애플리케이션 계층이 인시던트의 주인일 수 있습니다.

Running-Code Primacy가 규율을 공급합니다. 영수증은 실제로 관찰하는 층에 대해서만 수용하십시오. EPP 상태는 EPP 상태를 증명합니다. 레지스트리 재판독은 레지스트리 상태를 증명합니다. RDAP는 그 서비스의 관찰 지점에서 공개하는 것을 증명합니다. 상위 존과 권한 네임서버는 특정 시각과 관찰 지점에서의 DNS 사실을 증명합니다. 연결 시도는 서비스 관찰을 증명합니다. 어느 것도 다른 것을 사칭해서는 안 됩니다.

근거 조인을 재구성하라

launch 신청에 대한 유의미한 기록은 서로 이어지는 영수증으로 재구성 가능해야 합니다.

  1. 제출:클라이언트·서버 트랜잭션 ID, create 시각, 스폰서링 클라이언트, 정확한 도메인, 결과, 서버 엔드포인트.
  2. 정책 맥락:단계, 하위 단계, 명령 형식, 정책 버전, 효력 구간, 관련 할당 절차.
  3. 신청 신원:applicationID, 초기pendingCreate, 초기 launch 상태, 승인된 열람자.
  4. 검증 출처:적용 형식이 요구하는 경우에 한해 검증자, mark 또는 signed-mark 참조, 코드, 통지 근거.
  5. 상태 이력:순서화된 상태, poll 메시지 ID, 생성·검색 시각, 확인 여부, 건너뛴 상태의 근거, 예외.
  6. 최종 조치:관련 트랜잭션 및 신청 식별자와 함께allocated또는rejected의도메인:panData.
  7. 도메인 재판독:할당된 경우 결과 RFC 5731 도메인 객체, 스폰서링 클라이언트, 객체 상태, 타임스탬프 포함.
  8. 운영 재판독:레지스트리 또는 RDAP 공개, 상위 존 위임, 권한 DNS 응답, 서비스 도달 가능성을 별개의 시각이 있는 관찰로 기록.
  9. 기밀성:접근 근거, 필터링 규칙, 보존, 공개 경계, 감사 책임자.

이 사슬은 성공 열보다 일부러 길다. 그것은 모든 참여자를 보호합니다. 신청자는 서버가 신청을 수락했음을 증명할 수 있습니다. 레지스트리는 수락이 할당이 아니었음을 보여줄 수 있습니다. 검증자는 최종 선택을 주장하지 않으면서 자신이 평가한 것을 보여줄 수 있습니다. 운영은 지연을 올바른 경계에서 찾아낼 수 있습니다. 감사자는 워크플로가 존재했다는 것만 증명하려고 기밀 신청 데이터를 노출하는 실수를 피할 수 있습니다.

RFC 8334의 성취는 '성공'을 단순하게 만든 것이 아닙니다. 미완의 부분에 이름을 붙이게 만든 것입니다. 신청 ID는 보류 상태에 지속 가능한 신원을 부여하고, 상태와 poll 모델은 이후 결정에 순서화된 채널을 주며, 최종 보류 조치 데이터는 종결을 기록합니다. 좋은 거버넌스는 이 구분들을 지우기를 거부하는 데서 시작합니다.

출처