요약

  • ICANN의 기술 연구 그룹은 등록인이 다른 명명 체계에서 동일한 이름을 유지하려는 상태에서 DNS 등록이 만료될 때 무엇이 일어날 수 있는지를 설명합니다. DNS 확인은 보류되지만 대체 이름은 활성 상태로 남을 수 있습니다. 이 선택은 해당 체계의 정책과 등록인의 결정에 달려 있습니다.
  • 이 분기점은 "동일 문자열"과 "동일 통제자"라는 슬로건을 운영상의 의무로 바꿉니다. 레지스트리 서비스는 각 상태를 변경할 수 있는 주체가 누구인지, 시스템들이 수렴했음을 보여주는 증거가 무엇인지, 수렴하지 않았을 때 무엇이 일어나는지를 확인할 수 있어야 합니다.

만료는 거버넌스 이벤트입니다

등록인이 example.tld의 DNS 등록을 만료시키면서 대체 명명 체계에서는 example.tld를 유지하기로 선택하는 경우를 생각해 보십시오. 이는 기술 연구 그룹 초안 보고서에 나오는 시나리오이며, 실제 발생한 사건에 대한 보고가 아닙니다. DNS 이름은 글로벌 DNS에서 보류됩니다. 대체 이름은 자체 규칙이 그러한 결과를 허용하고 등록인이 이를 유지하려는 경우 활성 상태로 남을 수 있습니다.

이 대안은 단순 삭제보다 더 큰 파장을 일으킵니다. 등록인이 대체 이름을 유지하지 않으려는 경우 보고서는 여러 체계에서 이름을 비활성화하고, 할당을 해제하고, 등록 대상에서 제거하는 절차를 설명합니다. 이 일련의 과정이 끝나야 이름이 다시 사용 가능해집니다. 따라서 만료는 이름이 살아남는지 여부에 대한 답이 아니라, 무엇이 살아남는지, 누가 그 선택을 할 수 있는지, 언제 다른 주체가 해당 문자열을 획득할 수 있는지에 대한 일련의 선택을 시작합니다.

바로 이 지점에서 통합 약속이 거버넌스 문제로 바뀝니다. 일치하는 라벨은 쉽게 확인할 수 있습니다. 통제자는 더 어렵습니다. 신원은 갱신, 등록대행업체 관행, 내부 이전, 정지, 체계별 집행 조치를 통해 바뀔 수 있습니다. 동일 문자열/동일 통제자 규칙은 최초 신청 시점의 기록 확인에서만이 아니라 이러한 전환 전반에 걸쳐 유지되어야 합니다.

기술적 기준은 서비스 승인이 아닙니다

ICANN은 레지스트리 운영자와 잠재적 신청자들이 글로벌 DNS gTLD와 동일 문자열의 대체 명명 체계를 연계하는 레지스트리 서비스 제공에 대해 문의한 후 이 기술 연구 그룹을 구성했습니다. 이 그룹은 해당 구성을 안전하고 안정적으로 운영할 수 있는지, 그리고 어떤 기술 요건이 이를 뒷받침할 수 있는지를 검토했습니다.초기 보고서는 2026년 8월 10일자이며 초안으로 표시되어 있습니다.

이 보고서는 어떤 통합을 승인하거나 특정 아키텍처를 지지하지 않습니다. 적절한 통제 하에서 동일 문자열/동일 통제자 운영이 가능할 수 있다고 밝히면서도, 다른 접근 방식을 위한 여지를 명시적으로 남겨둡니다. ICANN의공개 의견 수렴 페이지는 제도적 경계를 분명히 하고 있습니다. 각 레지스트리 운영자는 레지스트리 서비스 평가 정책(RSEP)을 통해 개별적으로 진행해야 합니다. 기술 연구 그룹 보고서는 향후 평가와 계약 문구에 참고 자료를 제공하기 위한 것입니다. 초안 최종 보고서와 제안된 레지스트리 계약 개정안은 이후 별도의 공개 의견 수렴 절차에서 제출될 예정입니다. 공개 페이지는 2026년 11월 16일을 보고서 기한으로 명시하고 있습니다.

이 분리가 중요한 이유는 다음과 같습니다. 공동 기술 연구는 반복되는 분석을 줄일 수 있지만, 모든 운영자가 동일한 시스템, 계약 상대, 통제 수단 또는 상태 관찰 능력을 갖추고 있음을 보여줄 수는 없습니다. 서비스 신청 단계에서 일반적 불변 조건이 특정 레지스트리와 그 파트너를 위한 검증 가능한 약속이 되어야 합니다.

두 가지 운영 모델, 하나의 증명 문제

기술 연구 그룹은 전통적인 공유 등록 시스템(SRS)을 하나의 가능한 통제 표면으로 논의합니다. 두 이름에 대한 변경이 모두 레지스트리의 SRS를 통과하면, 레지스트리는 게시를 조율하고 DNS 기록과 대체 기록을 연결하는 증거를 보유할 수 있을 것입니다. 단일 등록인을 가진 하나의 도메인 객체는 비교적 명확합니다. 그 경우에도 보고서는 공유 SRS만으로 통제자가 동일하다는 사실을 증명하지 못한다고 경고합니다. 서비스는 그 연결을 확립할 수 있을 만큼 충분한 정보 또는 신뢰할 수 있는 계약적·기술적 보증이 필요합니다.

분산형 설계는 대신 여러 체계에 걸친 통합 단일 진실원(Unified Source of Truth, USoT)을 사용할 수 있습니다. 이는 레지스트리 외부에 저장된 기록을 수용할 수 있지만 증명 부담을 옮깁니다. 서비스는 진실원이 통제자를 어떻게 확립하는지, 모든 참여자가 변경을 어떻게 수신하는지, 갱신이 진행되는 동안 어떤 상태를 권위 있는 것으로 간주하는지 보여주어야 합니다. "시스템들이 연결되어 있다"는 말은 지연 중에 누가 안전하게 조치할 수 있는지에 대한 질문의 답이 아닙니다.

보고서의 내부 이전 사례는 이 문제를 구체화합니다. 등록대행업체는 레지스트리에 알리지 않고 자체 사업 시스템 내에서 등록인을 완전히 변경할 수 있습니다. 그러면 레지스트리는 새 통제자를 직접 관찰할 수 없으며, 지속적 신원 연결 또는 다른 증거가 없는 한 통합은 계약 이행에 의존합니다. DNS 이름과 대체 이름이 별도의 통제자를 가진 별도의 객체인 경우, 보고서는 두 객체를 하나의 명령으로 이전시키는 레지스트리 절차가 불변 조건을 유지하는 하나의 가능한 방법이라고 말합니다.

운영 상태 간의 구분도 중요합니다. 보고서는 정지가 모든 명명 체계에 동시에 적용되어야 한다고 명시합니다. 또한 어뷰즈나 법원 명령과 같은 특정 외부 비활성화 이벤트는 등록대행업체의 clientHold와 다르게 다루어야 하며, clientHold는 대체 이름을 자동으로 비활성화하지 않아야 합니다. 이것들은 상호 교환 가능한 일반 "동기화" 조치가 아니라 의도적인 의미 체계입니다. 서비스가 이들을 모두 일반적 일시정지로 라벨링하면 등록대행업체, 등록인, 사용자가 무엇이 여전히 접근 가능한지 예측하기 어려워집니다.

검토 기록은 관찰 가능한 조건을 향합니다

공개 제출물들은 광범위한 기술 원칙이 행정적으로 다루기 어려운 지점이 어디인지 보여줍니다. ICANN에 게시된Unregistry 의견은 보고서의 기본 결론을 지지하면서도, 동기화 실패 중 통합 상태와 동작에 대한 가시성을 포함해 더 얇은 사용자 측 요건에 초점을 맞춥니다. 이는 한 제출자의 견해이지 합의된 결론이 아닙니다.

인도 정부 제출물은 광범위한 요건이 RSEP 승인 전에 측정 가능하고 검증 가능해져야 한다고 요구합니다. 그 제안된 테스트에는 정의된 트랜잭션 상태, 미해결 갱신에 대한 통제, 안전 실패 동작, 테스트된 종료 계획, 만료 및 재할당 관련 보호장치, 독립 보안 테스트가 포함됩니다. 이 역시 한 의견서의 권고 사항이며, ICANN이 채택한 요건이 아닙니다.

지식재산구성체(IP Constituency) 의견은 더 넓은 정책 논의로 남겨진 권리 보호 문제를 지적합니다. 이 경계는 계속 드러나 있어야 합니다. 기술적 통제는 두 기록이 조율되어 있음을 증명할 수 있지만, 누가 이름에 대한 권리를 가져야 하는지, 충돌 해결 방안이 충분한지, 사용자가 어디서 구제를 받을 수 있는지는 결정하지 않습니다.

따라서 신청서는 등록인의 개인 데이터를 노출하지 않으면서 검토자가 실용적인 질문에 답할 수 있어야 합니다. 어떤 주체가 갱신, 이전, 정지 또는 제거를 시작할 수 있는가? 어떤 이벤트가 이를 승인하는가? 각 체계는 무엇을 확인하는가? 부분적 결과가 얼마나 오래 지속될 수 있는가? 이전 등록인의 대응 이름이 여전히 활성 상태인 동안 새 등록인에게 이름이 배정되는 것을 무엇이 막는가? 정보가 다투어질 때 정정 경로는 무엇인가?

전환 기록은 서비스의 일부입니다

부족한 산출물은 또 하나의 라벨이나 등록 사본이 아닙니다. 전환에 대한 서비스 수준 기록입니다. 각 중대 변경에 대해 운영자는 발동 권한, 정책 버전, 이전 및 의도된 상태, 영향받는 체계, 트랜잭션 식별자, 확인 응답, 시간 또는 순서 정보, 재시도와 봉쇄 규칙, 통지 또는 검토 경로를 보유할 수 있습니다. 공개 신호는 감사 기록보다 훨씬 작을 수 있습니다. 사용자는 통합된 이름이 활성, 보류, 정지 또는 미해결 상태인지만 알면 되고, 감사자는 그 이유를 보여주는 증거가 필요할 수 있습니다.

이 기록은 기술 연구 그룹이 이미 채택한 요건이 아니라 향후 서비스 설계를 위한 권고입니다. 이것이 중요한 이유는 각 주체가 트랜잭션의 서로 다른 단면을 보기 때문입니다. 등록대행업체는 고객 관계를 알 수 있고, 레지스트리는 DNS 게시를 통제할 수 있으며, 대체 체계 운영자는 대응 측의 실행을 통제할 수 있습니다. 이 단면들이 불일치하면 실질적 비용은 등록인이 부담합니다. 책임을 명시하면서 증거를 관찰 불가능하게 둔 계약은 사건 발생 후 집행이 어렵습니다.

만료는 유용한 테스트입니다. 한 체계에서의 권리가 끝난 후 서비스가 "동일 통제자"를 무엇으로 정의하는지 말하도록 강제하기 때문입니다. 대체 이름이 활성 상태로 남을 수 있다면, 그 지속은 의도적이고, 전달되며, 이후 할당 해제에 관한 명확한 규칙과 연결되어야 합니다. 모든 대응 이름을 비활성화해야 한다면, 서비스는 그 조치가 여러 체계에서 어떻게 완료되고, 한 체계를 사용할 수 없을 때 어떻게 동작하는지 보여주어야 합니다.

ICANN의RSEP 정책과시행 노트는 이미 운영자별 서비스 설명과 외부 사용자에 미치는 영향을 중심에 둡니다. 이제 남은 질문은 다음 검토 주기가 기술 연구 그룹의 공동 기술 기준을 출시 전에 테스트하고 조건이 바뀔 때 감사할 수 있는 서비스 조항으로 전환할 것인지입니다. 그 전까지 "동일 문자열, 동일 통제자"는 시작 조건일 뿐입니다. 서비스가 그 조건을 시간에 걸쳐 어떻게 증명하는지 설명할 때 거버넌스가 시작됩니다.

출처