Skip to main content
Resources

레지스트리 등록 데이터 디렉터리 서비스 일관성 있는 라벨링 및 디스플레이 정책

이 페이지는 다음과 같은 언어로 제공됩니다.

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

이 문서에서 "~해야 한다", "~해서는 안 된다", "요구된다", "~하는 것을 권장한다", "~하지 않는 것을 권장한다", "~할 수 있다"와 같은 키워드는 RFC 2119(http://www.ietf.org/rfc/rfc2119.txt)에서 설명된 대로 해석합니다.

.com, .jobs 및 .net1을 제외한 레지스트리 운영자는 WHOIS(포트 43을 통해 제공) 및 웹 기반 디렉터리 서비스 요구 사항을 준수하기 위해 "2014년 1월 9일에 승인된 기본 레지스트리 계약"("기본 레지스트리 계약")이나 이후 개정본의 규정 4의 1항과 함께 이 요구 사항을 실행해야 합니다. .com, .jobs 및 .net 레지스트리 운영자는 기본 레지스트리 계약에서 thin 레지스트리에 관한 규정 4의 1절에 따라 이 정책을 이행해야 합니다.

  1. 도메인 이름 객체 쿼리에 대한 응답에서 아래 필드는 (1) "레지스트라 IANA ID" 필드의 바로 뒤 또는 (2) 마지막 필드("ICANN Whois 부정확성 불만 신고 양식의 URL: https://www.icann.org/wicf/")의 바로 앞에 다음 순서대로 와야 합니다.
    • 레지스트라 남용행위 연락처 이메일
    • 레지스트라 남용행위 연락처 전화번호
  2. 도메인 이름 객체 쿼리에 대한 응답에서 다음 필드는 선택 사항으로 간주되며 "자문:레지스트리 계약 부수 조항, 해당 등록 데이터 디렉터리 서비스(Whois)에 대한 2013 레지스트라 인가 계약(RAA) 규정" ("WHOIS 자문")의 부수 조항 1에 규정된 대로 처리되는 것을 권장합니다.
    • 레지스트라 등록 만료일
    • 리셀러
  3. 표시된 경우 "리셀러" 필드는 "도메인 상태" 필드 바로 앞에 나타나야 합니다.
  4. 표시된 경우 "리셀러" 필드의 값은 반드시 조직 이름(리셀러가 법인인 경우) 또는 자연인 이름이어야 합니다.
  5. 표시된 경우 "레지스트라 등록 만료일" 필드는 "레지스트리 만료일" 필드 바로 뒤에 나타나야 합니다.
  6. 다음 필드의 값 섹션(콜론 오른쪽)은 반드시 다음 규정을 준수해야 합니다.
    1. "레지스트라 남용행위 연락처 이메일"(이메일 필드에 대한 EPP RFC의 정의를 따름)
    2. "레지스트라 남용행위 연락처 전화번호"(전화번호 필드에 대한 EPP RFC의 정의를 따름)
    3. "리셀러"는 토큰(확장 마크업 언어 1.1 참조)으로 정의됨
    4. "레지스트라 등록 만료일"(날짜 필드에 대한 EPP RFC의 정의를 따름)
  7. 레지스트리 운영자는 도메인 이름, 이름 서버, 레지스트라 개체의 출력에서 다음과 같이 키 이름을 업데이트해야 합니다. 다음 표는 기본 레지스트리 계약 규정 4의 원본 버전에서 이름이 변경된 키를 표시합니다. 다른 모든 규정(예: 값 섹션의 형식 규정)은 변경 사항이 없습니다.
    기본 레지스트리 계약 규정 4의 원본 키 새로운 키 이름 키가 표시되는 개체 쿼리
    도메인 ID 레지스트리 도메인 ID 도메인 이름
    WHOIS 서버 레지스트라 WHOIS 서버 도메인 이름, 레지스트라, 이름 서버
    조회 URL 레지스트라 URL 도메인 이름, 레지스트라, 이름 서버
    후원 레지스트라 레지스트라 도메인 이름
    지원 레지스트라 IANA ID 레지스트라 IANA ID 도메인 이름
    레지스트라 이름 레지스트라 레지스트라
    등록자 ID 레지스트리 등록자 ID 도메인 이름
    운영자 ID 레지스트리 운영자 ID 도메인 이름
    기술자 ID 레지스트리 기술자 ID 도메인 이름
  8. "청구처"가 표시된 경우 레지스트리 운영자는 아래 정의된 것과 같이 도메인 이름 출력에서 키 이름을 업데이트해야 합니다. 다른 모든 규정(예: 값 섹션의 형식 규정)은 계속해서 적용됩니다.
    WHOIS 자문의 원본 키 새로운 키 이름 키가 표시되는 개체 쿼리
    청구 ID 레지스트리 청구 ID 도메인 이름
  9. 도메인 이름 객체 쿼리에 대한 응답에서 다음 필드2는 ">>> Whois 데이터베이스의 마지막 업데이트: <날짜 및 시간> <<<" 바닥글 앞에 와야 합니다.
  10. 레지스트리 계약에서 수정된 RDDS 출력을 제공하도록 허락된 레지스트리 운영자는 WHOIS 자문의 부수 조항 1에 규정된 대로 레지스트리의 공유 등록 시스템(SRS)에 데이터가 있는지 여부에 관계없이 다음 필드를 선택 사항으로 처리할 수 있습니다. 수정된 RDDS 출력은 레지스트리 운영자의 레지스트리 계약에서 관련 RDDS 조항과 일치해야 합니다.
    • 레지스트리 등록자/운영자/기술자 ID
    • 등록자/운영자/기술자 이름
    • 등록자/운영자/기술자 조직
    • 등록자/운영자/기술자 주소
    • 등록자/운영자/기술자 시/도
    • 등록자/운영자/기술자 지역
    • 등록자/운영자/기술자 우편번호
    • 등록자/운영자/기술자 국가
    • 등록자/운영자/기술자 전화
    • 등록자/운영자/기술자 전화 내선
    • 등록자/운영자/기술자 팩스
    • 등록자/운영자/기술자 팩스 내선
    • 등록자/운영자/기술자 이메일
  11. "레지스트리 운영자/기술자/청구/등록자 ID:" 필드는 RFC 5733에서 지정된 연락처 객체에 대한 리포지토리 객체 식별자(ROID)를 말합니다(기본 레지스트리 계약의 규정 4에서 운영자/기술자/등록자 ID라고 함).
  12. 레지스트리 운영자는 WHOIS 자문에 정의된 대로 ICANN의 추가 승인 없이 추가 RDDS 필드를 출력할 수 있습니다. 각 추가 필드의 키와 값은 브라우저 실행 코드(예: Javascript)를 포함하거나 어떤 종류의 기밀 정보를 제공하거나 인터넷 DNS 또는 다른 시스템의 보안, 안정성, 복원력에 부정적인 영향을 끼쳐서는 안 됩니다. 배포 전에 레지스트리 운영자는 모든 추가 RDDS 필드의 목록을 ICANN에 제공해야 합니다. 레지스트리 운영자는 추가 RDDS 필드 목록의 변경 사항을 배포하기 전에 그러한 변경 사항을 ICANN에 제공해야 합니다.

발효일: 2017년 8월 1일

실행 기록

  1. 2015년 4월 27일에 ICANN은 해당 등록 데이터 디렉터리 서비스(일반적으로 WHOIS로 알려짐) 규정에 대한 레지스트리와 레지스트라의 질의에 대한 응답으로 자문을 게시했습니다. 레지스트리 운영자는 레지스트리 계약 준수를 위해 꾸준히 이 자문을 참조해야 합니다.
  2. 다음 절에서는 쿼리 개체에 대한 출력 예시를 설명합니다.

도메인 이름 데이터:

  • 쿼리 형식: whois EXAMPLE.TLD
  • 응답 형식:
    도메인 이름: EXAMPLE.TLD
    레지스트리 도메인 ID: D1234567-EXAMPLE
    레지스트라 WHOIS 서버: whois.example-registrar.tld
    레지스트라 URL: http://www.example-registrar.tld
    업데이트일: 2009-05-29T20:13:00Z
    생성일: 2000-10-08T00:45:00Z
    레지스트리 만료일: 2010-10-08T00:44:59Z
    레지스트라 등록 만료일: 2010-10-08T00:44:59Z
    레지스트라: EXAMPLE REGISTRAR LLC
    레지스트라 IANA ID: 5555555
    레지스트라 남용행위 연락처 이메일: email@registrar.tld
    레지스트라 남용행위 연락처 전화번호: +1.1235551234
    리셀러: EXAMPLE RESELLER1
    도메인 상태: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
    도메인 상태: clientRenewProhibited https://icann.org/epp#clientRenewProhibited
    도메인 상태: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
    레지스트리 등록자 ID: 5372808-EXAMPLE
    등록자 이름: EXAMPLE REGISTRANT
    등록자 조직: EXAMPLE ORGANIZATION
    등록자 주소: 123 EXAMPLE STREET
    등록자 시/도: ANYTOWN
    등록자 지역: AP
    등록자 우편번호: A1A1A16
    등록자 국가: AA
    등록자 전화: +1.5555551212
    등록자 전화 내선: 12347
    등록자 팩스: +1.5555551213
    등록자 팩스 내선: 4321
    등록자 이메일: EMAIL@EXAMPLE.TLD
    레지스트리 운영자 ID: 5372809-EXAMPLE
    운영자 이름: EXAMPLE REGISTRANT ADMINISTRATIVE
    운영자 조직: EXAMPLE REGISTRANT ORGANIZATION
    운영자 주소: 123 EXAMPLE STREET
    운영자 시/도: ANYTOWN
    운영자 지역: AP
    운영자 우편번호: A1A1A1
    운영자 국가: AA
    운영자 전화: +1.5555551212
    운영자 전화 내선: 1234
    운영자 팩스: +1.5555551213
    운영자 팩스 내선: 1234
    운영자 이메일: EMAIL@EXAMPLE.TLD
    레지스트리 기술자 ID: 5372811-EXAMPLE
    기술자 이름: EXAMPLE REGISTRANT TECHNICAL
    기술자 조직: EXAMPLE REGISTRANT LLC
    기술자 주소: 123 EXAMPLE STREET
    기술자 시/도: ANYTOWN
    기술자 지역: AP
    기술자 우편번호: A1A1A1
    기술자 국가: AA
    기술자 전화: +1.1235551234
    기술자 전화 내선: 1234
    기술자 팩스: +1.5555551213
    기술자 팩스 내선: 93
    기술자 이메일: EMAIL@EXAMPLE.TLD
    이름 서버: NS01.EXAMPLE-REGISTRAR.TLD
    이름 서버: NS02.EXAMPLE-REGISTRAR.TLD
    DNSSEC: signedDelegation
    ICANN Whois 부정확성 불만 신고 양식의 URL: https://www.icann.org/wicf/
    >>> WHOIS 데이터베이스의 마지막 업데이트: 2009-05-29T20:15:00Z <<<

레지스트라 데이터:

  • 쿼리 형식: whois "registrar Example Registrar, Inc."
  • 응답 형식:
    레지스트라: Example Registrar, Inc.
    주소: 1234 Admiralty Way
    시/도: Marina del Rey
    지역: CA
    우편번호: 90292
    국가: US
    전화번호: +1.3105551212
    팩스번호: +1.3105551213
    이메일: registrar@example.tld
    레지스트라 WHOIS 서버: whois.example-registrar.tld
    레지스트라 URL: http://www.example-registrar.tld
    운영자 연락처: Joe Registrar
    전화번호: +1.3105551213
    팩스번호: +1.3105551213
    이메일: joeregistrar@example-registrar.tld
    운영자 연락처: Jane Registrar
    전화번호: +1.3105551214
    팩스번호: +1.3105551213
    이메일: janeregistrar@example-registrar.tld
    기술자 연락처: John Geek
    전화번호: +1.3105551215
    팩스번호: +1.3105551216
    이메일: johngeek@example-registrar.tld
    >>> WHOIS 데이터베이스의 마지막 업데이트: 2009-05-29T20:15:00Z <<<

이름 서버 데이터:

  • 쿼리 형식: whois "nameserver (nameserver name)" 또는 whois "nameserver (IP Address)"
  • 응답 형식:
    서버 이름: NS1.EXAMPLE.TLD
    IP 주소: 192.0.2.123
    IP 주소: 2001:0DB8::1
    레지스트라: Example Registrar, Inc.
    레지스트라 WHOIS 서버: whois.example-registrar.tld
    레지스트라 URL: http://www.example-registrar.tld
    >>> WHOIS 데이터베이스의 마지막 업데이트: 2009-05-29T20:15:00Z <<<

배경 설명:

이 합의 정책은 ICANN 이사회 결의서 2014.02.07.08 - 2014.02.07.09에 따른 정책 실행의 결과물이며 이 결의서에서는 Thick Whois에 관한 새로운 합의 정책을 위한 GNSO 회의 정책 권장 사항을 채택했습니다.

2013년 10월 31일에 GNSO 회의에서 채택된 Thick Whois 정책 개발 프로세스(PDP) 작업 그룹(WG)의 권장 사항 #1은 다음과 같습니다. "2013 RAA의 규정 3에 설명된 모델에 따른 일관성 있는 라벨링 및 디스플레이를 포함한 Thick Whois 서비스의 제공이 모든 기존 및 향후 gTLD 레지스트리의 필수 사항이 되는 것을 권장한다."

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

결과적으로 ICANN 스태프와 실행 검토 팀(IRT)은 일관성 있는 라벨링 및 디스플레이가 Thin에서 Thick으로 전환의 실행에서 분리될 수 있음에 동의했습니다.

ICANN은 2015년 12월 3일에 공공 의견을 듣기 위한 일관성 있는 라벨링 및 디스플레이 요구 사항의 실행에 관한 원안을 제출했습니다. 커뮤니티의 의견을 고려한 후 Thick Whois IRT와 협업하여, ICANN은 이 합의 정책에 반영된 대로 원안을 개정했습니다.

참고로 GNSO 정책 권장 사항을 실행할 때 ICANN의 목표는 적절한 경우 권장 사항 실행을 등록 데이터 액세스 프로토콜 (RDAP)의 채택과 같은 다른 관련 이니셔티브와 동기화하여 등록자, 최종 사용자, 계약 당사자, 전체 등록 데이터 디렉터리 서비스(RDDS) 시스템에 끼치는 영향을 최소화하는 것이었습니다.


1 .com, .jobs 및 .net의 레지스트리 운영자는 2014년 2월 7일에 ICANN 이사회에서 채택한 Thick Whois GNSO PDP 권장 사항의 실행에 따른 Thin에서 Thick 레지스트리로 전환의 일환으로 이 정책에 규정된 요구 사항을 실행해야 할 것으로 예상됩니다.

2 참고로 이 필드는 현재 2013 RAA (2013년 9월 17일에 ICANN 이사회에서 승인)의 규정 3에서 사용되는 용어와 URL을 업데이트합니다.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."