Logo
ICANN
ICANN
Filtered Search

Are you sure you want to sign out from http://www.icann.org?

If you want to sign out from both http://www.icann.org and ICANN Account, click here.

Contracted Parties

ICANN’s contracted parties consist of generic top-level domain (gTLD) registry operators and accredited registrars.

In addition to the ICANN Languages, this content is also available in

.COM, .NET 및 .JOBS의 Thick WHOIS 전환 정책

모든 번역 내용 및 문서의 영어 버전은 공식 버전이며, 영어 외 다른 언어의 번역 버전은 정보 제공용으로만 사용할 수 있습니다.

뉴스

2025년 8월 21일부터 본 정책에 따른 요구 사항은 등록 데이터 정책에 명시된 바와 같습니다.

2019년 11월 7일 ICANN 이사회는 계약 준수 시행을 연기하라는 결의안을 통과시켰습니다. ICANN 계약 준수는 다음 사항이 모두 완료되기 전까지 대량 WHOIS 전환 정책의 시행을 연기할 예정입니다.

  • gTLD의 등록 데이터 정책 시행 검토 팀(IRT)은 검토를 마치고 신속한 정책 개발 과정(EPDP) 팀의 권장 사항(ICANN 이사회가 2019년 5월 15일에 채택) 시행을 위한 예상 일정을 세웁니다.
  • ICANN 조직과 IRT는 GNSO 평의회에 기존 정책 및 절차(대량 WHOIS 전환 정책 포함)에 대한 EPDP 팀의 권장 사항에 따른 영향에 관한 필요한 정보를 제공합니다.
  • GNSO 평의회는 대량 WHOIS 전환 정책에 영향을 미치는 관련 정책 및 절차(추가 정책 작업, 지침 또는 향후에 결정될 기타 조치가 포함될 수 있음)의 업데이트에 따른 조치를 취할 것인지 여부를 결정합니다.

이 문서에서 "반드시 해야 한다"(MUST), "절대 해서는 안 된다"(MUST NOT), "요구된다"(REQUIRED), "해야 한다"(SHALL/SHOULD), "해서는 안 된다"(SHALL NOT/SHOULD NOT), "권장된다"(RECOMMENDED), "할 수 있다"(MAY)와 같은 키워드는 http://www.ietf.org/rfc/rfc2119.txt의 RFC 2119 설명에 따라 해석해야 합니다.

  1. 적용 범위:

    이 정책은 .COM, .NET 및 .JOBS gTLD의 레지스트리 운영자와 .COM, .NET 또는 .JOBS gTLD에 도메인 이름 등록을 지원하는 모든 레지스트라에 적용하는 것을 권장한다.

  2. 정의:

    • Thin (등록): 레지스트리 운영자가 기술적 정보(예: 이름 서버, 상태, 생성일)와 도메인 이름에 관련된 지원 레지스트라만 유지하고 제공하는 도메인 이름. 도메인 이름의 연락처 정보는 지원 레지스트라가 유지한다.
    • Thick (등록): 지원 레지스트라가 레지스트리 운영자에게 관련 연락처 정보의 사본을 제공하는 도메인 이름. 레지스트리 운영자는 기술적 정보(예: 이름 서버, 상태, 생성일)와 도메인 이름에 관련된 지원 레지스트라를 유지한다. 도메인 이름의 연락처 정보는 지원 레지스트라가 유지한다.
    • 기존 도메인 이름: 2018년 5월 1일 전에 생성되거나 생성 대기 상태인 도메인 이름.
    • 전환 진행 지표: Thin에서 Thick으로 전환의 진행을 측정할 수 있도록 레지스트리 운영자가 작성하여 레지스트라와 ICANN에 정기적으로 전달하는 지표. 최소한 레지스트라가 관리하는 도메인 총수, 연락처 객체가 첨부된 도메인 수와 비율이 포함된다.

  3. 정책 및 발효일:

    3.1 늦어도 2018년 5월 1일부터 모든 신규 도메인 이름 등록은 Thick으로 제출되어야 한다.

    3.2 기존 도메인 이름의 모든 관련 등록 데이터는 2019년 2월 1일까지 Thin에서 Thick으로 마이그레이션되어야 한다.

  4. 다음 요구 사항은 레지스트리 운영자에게만 적용한다.

    4.1 레지스트리 운영자는 레지스트라가 기존 도메인 이름의 등록 데이터를 마이그레이션(즉 Thin에서 Thick으로 전환)할 수 있도록 2017년 8월 1일까지 EPP 메커니즘과 대체 대량 전송 메커니즘을 구축해야 한다.

    4.2 2017년 5월 1일까지, 레지스트리 운영자는 해당 레지스트라와 ICANN에 섹션 4.1의 요구 사항을 지원하는 데 필요한 시스템 변경이 반영된 문서를 제공해야 한다.

    4.3 2017년 5월 1일까지, 레지스트리 운영자는 레지스트라가 기존 도메인 이름의 등록 데이터 마이그레이션(즉 Thin에서 Thick으로 전환)을 테스트할 수 있도록 관련 운영 테스트 환경(OT&E)에서 EPP 메커니즘과 대체 대량 전송 메커니즘을 구축해야 한다.

    4.4 2017년 8월 1일까지, 레지스트리 운영자는 이 조항에 규정된 대로 RFC5733에서 지정된 모든 연락처 명령을 지원해야 한다. EPP 연락처 필드 <contact:id>, <contact:postalInfo type> 및 <contact:authInfo>는 레지스트리 운영자에 의해 요구된다. 레지스트리 운영자는 "2014년 1월 9일에 승인된 기본 레지스트리 계약"("기본 레지스트리 계약")이나 이후 개정본의 규정 4 섹션 1에 규정된 WHOIS(포트 43을 통해 제공) 및 웹 기반 디렉터리 서비스 요구 사항과, 레지스트리 등록 데이터 디렉터리 서비스 일관성 있는 라벨링 및 디스플레이 정책을 준수하는 데 필요한 다른 모든 등록 데이터 요소를 2019년 2월 1일까지 수락해야 하지만 요구해서는 안 된다.

    4.5 2018년 5월 1일부터, 레지스트리 운영자는 이 조항에 규정된 대로 EPP 도메인 객체 <create> 명령을 위한 Thick 등록 데이터를 요구해야 한다. 레지스트리 운영자는 "2014년 1월 9일에 승인된 기본 레지스트리 계약"("기본 레지스트리 계약")이나 이후 개정본의 규정 4 섹션 1에 규정된 WHOIS(포트 43을 통해 제공) 및 웹 기반 디렉터리 서비스 요구 사항과, 레지스트리 등록 데이터 디렉터리 서비스 일관성 있는 라벨링 및 디스플레이 정책을 준수하는 데 필요한 모든 등록 데이터 요소를 요구해야 한다.

    4.6 2017년 8월 1일과 2019년 2월 1일 사이에, 레지스트리 운영자는 최소한 각 레지스트라에게 매월 다음 달 첫째 날의 UTC 기준 23:59까지 전환 진행 지표를 제공하는 것을 권장한다.

    4.7 2017년 8월 1일과 2019년 2월 1일 사이에, 레지스트리 운영자는 최소한 ICANN에 매월 다음 달 첫째 날의 UTC 기준 23:59까지 모든 레지스트라를 위한 모든 전환 진행 지표를 제공하는 것을 권장한다.

    4.8 레지스트리 운영자는 2017년 8월 1일까지 "2014년 1월 9일에 승인된 기본 레지스트리 계약"("기본 레지스트리 계약")이나 이후 개정본의 규정 4 섹션 1과 함께 레지스트리 등록 데이터 디렉터리 서비스 일관성 있는 라벨링 및 디스플레이 정책("CL&D 정책")의 요구 사항을 실행할 수 있다.

    4.9 레지스트리 운영자는 "2014년 1월 9일에 승인된 기본 레지스트리 계약"("기본 레지스트리 계약")이나 이후 개정본의 규정 4 섹션 1에 규정된 WHOIS(포트 43을 통해 제공) 및 웹 기반 디렉터리 서비스 요구 사항과, 레지스트리 등록 데이터 디렉터리 서비스 일관성 있는 라벨링 및 디스플레이 정책을 신규 등록의 경우 2018년 5월 1일까지, 기존 도메인 이름의 경우 2019년 2월 1일까지 준수해야 한다.

    4.10 2017년 8월 1일과 2019년 2월 1일 사이에, 기존 도메인 이름에서 다음 RDDS 출력 필드의 데이터가 공유 등록 시스템(SRS)에 존재하지 않는 경우 레지스트리 운영자는 다음 RDDS 필드를 "자문: 레지스트리 계약 부수 조항, 해당 등록 데이터 디렉터리 서비스(Whois)에 대한 2013 레지스트라 인가 계약(RAA) 규정"의 부수 조항 1에 규정된 대로 선택 사항으로 처리할 수 있다.

    1. 레지스트리 등록자/운영자/기술자 ID
    2. 등록자/운영자/기술자 이름
    3. 등록자/운영자/기술자 주소
    4. 등록자/운영자/기술자 시/도
    5. 등록자/운영자/기술자 국가
    6. 등록자/운영자/기술자 전화
    7. 등록자/운영자/기술자 이메일

    4.11 "청구" 연락처는 레지스트리 계약에서 달리 요구되지 않는 한 선택 사항이다. 레지스트리 정책에서 필수 사항, 선택 사항 또는 미지원 사항인지를 정의할 수 있다. 지원되는 경우 청구 연락처 정보는 "자문: 레지스트리 계약 부수 조항, 해당 등록 데이터 디렉터리 서비스(Whois)에 대한 2013 레지스트라 인가 계약(RAA) 규정"(섹션 22)에 규정된 대로 디스플레이되어야 한다.

  5. 다음 요구 사항은 레지스트라에게만 적용한다.

    5.1 2017년 8월 1일과 2019년 2월 1일 사이에, 레지스트라는 레지스트리 운영자가 "2014년 1월 9일에 승인된 기본 레지스트리 계약"("기본 레지스트리 계약")이나 이후 개정본의 규정 4 섹션 1에 규정된 WHOIS(포트 43을 통해 제공) 및 웹 기반 디렉터리 서비스 요구 사항과, 레지스트리 등록 데이터 디렉터리 서비스 일관성 있는 라벨링 및 디스플레이 정책을 준수하는 데 필요한, 레지스트라 데이터베이스에서 제공되는 기존 도메인 이름의 모든 필수 필드를 관련 레지스트리 운영자에게 마이그레이션해야 한다.

    5.2 레지스트라는 레지스트리 운영자가 "2014년 1월 9일에 승인된 기본 레지스트리 계약"("기본 레지스트리 계약")이나 이후 개정본의 규정 4 섹션 1에 규정된 WHOIS(포트 43을 통해 제공) 및 웹 기반 디렉터리 서비스 요구 사항과, 2017년 8월 1일에 시작되는 신규 도메인 이름 등록 생성에 대한 레지스트리 등록 데이터 디렉터리 서비스 일관성 있는 라벨링 및 디스플레이 정책을 준수하는 데 필요한 완전한 Thick 등록 데이터를 레지스트리 운영자에게 제공할 수 있다.

    5.3 레지스트라는 레지스트리 운영자가 "2014년 1월 9일에 승인된 기본 레지스트리 계약"("기본 레지스트리 계약")이나 이후 개정본의 규정 4 섹션 1에 규정된 WHOIS(포트 43을 통해 제공) 및 웹 기반 디렉터리 서비스 요구 사항과, 2018년 5월 1일에 시작되는 신규 도메인 이름 등록 생성에 대한 레지스트리 등록 데이터 디렉터리 서비스 일관성 있는 라벨링 및 디스플레이 정책을 준수하는 데 필요한 완전한 Thick 등록 데이터를 레지스트리 운영자에게 제공해야 한다.

실행 기록

현지 정보보호법과 이 정책에 포함된 요구 사항이 상충하는 경우 레지스트리 운영자와 레지스트라는 ICANN WHOIS와 정보보호법 상충의 처리 절차를 이용할 수 있다.

배경 설명

ICANN 이사회는 합의에 의하여 GNSO Thick WHOIS 작업 그룹의 정책 권장 사항을 채택하였다. 이 권장 사항은 모든 gTLD 레지스트리의 Thick WHOIS 사용에 관한 것으로 GNSO 회의가 권장 사항을 승인한 후 2014년 2월 7일에 채택되었다. 권장 사항 #1은 "2013 [레지스트라 인가 계약]의 규정 3에 설명된 모델에 따른 일관성 있는 라벨링 및 디스플레이를 포함한 Thick WHOIS 서비스의 제공이 모든 기존 및 향후 gTLD 레지스트리의 필수 사항이 되는 것을 권장한다."라고 되어 있다. (ICANN 이사회 결의서 2014.02.07.08 - 2014.02.07.09 http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm#2.c 참조).

ICANN은 정책 권장 사항을 실행하기 위해 커뮤니티 구성원 팀(실행 검토 팀)과 함께 작업했다. 실행의 일환으로 권장 사항의 채택 전에, ICANN은 제안된 정책 권장 사항과 이 정책에 포함된 내용에 대한 커뮤니티의 의견을 구했다. (https://www.icann.org/public-comments/proposed-implementation-gnso-thick-rdds-whois-transition-2016-10-26-en 참조).

나아가서 대량 Whois 정책 PDP WG의 최종 보고서[PDF, 1.23MB] 섹션 7.2에는 씬 Whois에서 대량 Whois로 전환을 이행하기 위한 일정과 요구 사항에 관련된 '실행 지침'도 포함되었습니다. 여기서는 “WG는 권장사항의 일부 구현(예: 기존 씬 gTLD 레지스트리에서 대량 모델로 전환)으로 인해 다른 권장사항(예: 해당 데이터의 일관성 있는 라벨링 및 디스플레이) 구현이 지연되어서는 안 된다고 강조한다)"라고 명시하고 있습니다.

결과적으로 ICANN 기구는 Thin Whois 등록에서 Thick으로 전환, Whois 데이터의 일관성 있는 라벨링 및 디스플레이의 병행 실행 경로에 대해 실행 검토 팀과 함께 작업했다. 자세한 내용은 https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en 참조