Skip to main content
Resources

gTLD 준수 프로그램

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

gTLD 준수 프로그램 [PDF, 936 KB] 에 대한 다음 개요는 단순 안내용입니다. 계약자는 ICANN과의 계약에 따른 모든 요구 사항 및 해당되는 ICANN 정책을 검토하고 준수해야 합니다.

gTLD 준수 프로그램은 gTLD 레지스트리 계약 조항을 일반 준수 영역으로 나눔으로써 개발되었습니다. 이러한 영역은 내부 모니터링 작업, 불만 수리, 업계 소식 등의 외부 리소스 모니터링의 조합으로 이행됩니다. 새로운 서비스나 프로토콜 또는 정책 변경으로 해당 영역의 추가적인 준수 모니터링이 시작될 수 있습니다.

gTLD 레지스트리 계약은 기본 구조는 같지만 구체적인 요구 사항은 다를 수 있습니다. 아래는 일부 gTLD 준수 영역과 신규 gTLD 레지스트리 계약의 관련 조항 일부입니다. 신규 gTLD 레지스트리 계약 형태가 아닌 레지스트리는 요구 사항이 다를 수 있습니다. 자세한 내용은 각 gTLD에 대한 레지스트리 계약에서 확인하십시오.

ICANN은 ccTLD 운영자에 대한 준수 행동을 취할 계약상의 권한이 없습니다.

준수 영역

  1. 기능 및 성능 규정

    기능 규정은 DNS, EPP 및 RDDS 등 레지스트리의 기술 시스템 동작 방식을 말합니다. 성능 규정은 가용성, 중단, 처리 시간, 업데이트 빈도에 대한 기준을 설정합니다. 해당 영역에서 준수 여부 파악을 위해 ICANN은 가능한 곳에 내부 기술 모니터링을 구현합니다. 또한 레지스트리 운영자가 제공하는 월간 레지스트리 보고서를 사용하여 서비스 수준 계약 요구 사항을 보고 달에 대한 내부 기술 모니터링에서 얻은 실제 성능 측정 결과와 비교합니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약 규정 6 및 10이 있습니다. 레지스트리 운영자의 서비스 수준 계약에 관한 불만 사항은 레지스트리 불만 제기 양식(https://www.icann.org/resources/pages/performance-2013-06-28-en)을 사용하여 제출할 수 있습니다.

  2. 등록 데이터 디렉토리 서비스(Whois) 및 일괄 Whois 액세스

    신규 gTLD 레지스트리 계약 형태를 실행한 레지스트리는 포트 43을 통해 공개 Whois 서비스를 제공하고 지정된 형식의 필수 데이터 요소를 포함한 웹 기반 디렉토리 서비스를 제공해야 합니다. 또한 매주 ICANN으로 일괄 등록(Whois) 데이터에 대한 액세스를 제공해야 합니다. ICANN은 레지스트리가 Whois 데이터에 적절한 액세스를 제공하는지 검토하고 요구 사항에 따라 Whois 데이터를 제시하며 업데이트 빈도 요구 사항과 다음 일괄 액세스 조항을 충족합니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약 규정 4 및 10, ICANN 자문: 레지스트리 계약 부수 조항, 해당 등록 데이터 디렉토리 서비스(Whois)에 대한 2013 레지스트라 인가 계약(RAA) 규정이 있습니다.

  3. 데이터 에스크로

    모든 레지스트리는 데이터 에스크로 서비스 조항에 대해 ICANN에서 승인한 데이터 에스크로 에이전트(DEA)를 선택해야 합니다. 준수 팀은 DEA에 의해 유효한 신탁이 이루어졌는지, 레지스트리가 ICANN에 에스크로 알림을 제출했는지 검토합니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약 규정 2가 있습니다.

  4. 레지스트라 데이터의 사용

    신규 gTLD 레지스트리 계약 양식을 실행한 레지스트리는 레지스트라에서 수집한 등록 데이터 보호를 위한 합당한 조치를 취해야 합니다. 레지스트리는 레지스트라에 정보 사용 방식을 알리고 공개되지 않은 이유로 정보를 사용할 수 없습니다. 준수 팀은 개인 데이터 처리에 관한 레지스트리와 레지스트라의 통신을 검토하고 ICANN 불만 제기 양식을 통해 제출된 불만 사항을 처리합니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약의 섹션 2.14 및 2.18과 규정 9가 있습니다.

  5. 레지스트리 서비스에 대한 동등한 액세스 및 행동 규정

    이 영역은 모든 레지스트라에게 동등하고 차별 없는 액세스를 제공하고 모든 레지스트라와 통일되고 차별 없는 계약을 맺어야 하는 신규 gTLD 레지스트리 계약 형태를 실행한 레지스트리의 의무 사항을 포함합니다. 또한 레지스트리가 레지스트라 또는 레지스트라-리셀러 서비스 제공자 역할도 하는 경우 동 규정에 따른 내부 검토를 수행하고 검토 결과를 준수 인증서와 함께 ICANN에 제출해야 합니다(예외가 없음). ICANN은 불만 처리 및 외부 리소스를 통해 해당 조항을 모니터링하고 필요한 연간 인증서를 검토합니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약의 섹션 2.9a와 규정 9 및 13(적용 가능한 경우)이 있습니다. 행동 규정에 관한 불만 사항은 행동 규정 불만 제기 양식(https://www.icann.org/resources/pages/code-of-conduct-2014-01-29-en)을 통해 제출할 수 있습니다.

  6. 등록 제한 사항

    특정 gTLD는 등록 정책으로 제한되며 후원을 받는 gTLD의 경우 헌장의 제한 사항(부록 S)에 따라 제한됩니다. 예를 들어 커뮤니티 gTLD는 관련 커뮤니티와 관련된 등록 제한 사항을 반드시 따라야 합니다. 제한된 레지스트리는 부적절한 등록에 대한 분쟁 해결을 위한 표준을 제시하는 분쟁 정책을 갖추어야 합니다.

    ICANN은 레지스트리 제한 분쟁 해결 절차(RRDRP)를 통해 신규 gTLD 레지스트리 계약 형태를 실행한 레지스트리가 레지스트리 계약의 규정 12에 따른 필수 등록 제한 사항을 따르지 않는다는 초기 보고서를 제출할 수 있도록 하고 있습니다. ICANN은 또한 레지스트리가 등록자가 이용할 수 있는 적절한 분쟁 해결 메커니즘을 갖추었는지 확인합니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약의 섹션 2.19 및 계약 규정 12가 있습니다. 레지스트리 운영자의 규정 12 등록 제한 사항에 관한 불만 사항은 등록 제한 분쟁 해결 절차 불만 제기 양식(https://www.icann.org/resources/pages/rrdrp-2013-10-31-en)을 통해 제출할 수 있습니다.

  7. 우선등록 및 요청 서비스

    신규 gTLD 레지스트리 계약 형태를 실행한 레지스트리와 그 계약된 레지스트라는 상표 정보센터(TMCH)와 협력하여 우선등록 및 요청 서비스를 제공해야 합니다. 이러한 서비스는 TMCH에 상표를 등록한 상표 소유주를 위한 권리 보호 메커니즘입니다. 우선등록 서비스는 이름이 대중에 공개되기 전에 상표 소유주가 상표에 대한 도메인 이름을 등록할 기회를 제공합니다. 요청 서비스 기간 중에 레지스트라는 반드시 TMCH에 등록된 상표와 일치하는 도메인 이름 등록을 시도하는 모든 이에게 상표 요청 고지를 제공해야 합니다. 고지를 받은 당사자가 도메인 이름을 등록할 경우 TMCH는 상표 소유주에게 등록 사실을 알립니다.

    ICANN 은 레지스트리의 공개된 우선등록 분쟁 해결 정책(SDRP)을 통한 구제책이 효과가 없을 때 요청 서비스 위반은 물론 우선등록 서비스 위반 사항에 관한 불만 사항을 수리할 수 있습니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약 규정 7 및 상표 정보센터 권리 보호 메커니즘 요구 사항이 있습니다. SDRP에 따른 처리 후 불만 사항은 우선등록 프로세스 및 절차 보고 양식(https://www.icann.org/resources/pages/sdrp-2013-10-31-en)으로 제출할 수 있고 레지스트리 운영자의 클레임 서비스 요구 사항에 대한 불만 사항은 클레임 서비스 양식(https://www.icann.org/resources/pages/claims-2014-01-29-en)을 사용하여 제출할 수 있습니다.

  8. 예약된 이름

    모든 레지스트리는 레지스트리 계약에 따라 지정된 이름을 예약해야 합니다. ICANN은 준수 파악을 위해 내부 기술 모니터링을 수행하고 외부 불만 사항을 해결합니다. 신규 gTLD 레지스트리 계약 형태를 실행한 레지스트리는 gTLD의 운영 또는 홍보에 필요한 최대 100개의 이름(IDN 버전 포함)을 활성화할 수 있습니다. 레지스트리 계약의 모든 다른 요구 사항을 충족한다면 gTLD에서 레지스트리가 예약할 수 있는 이름의 개수에는 제한이 없습니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약의 부록 6과 규정 5가 있습니다. 레지스트리 운영자의 예약된 이름 또는 차단된 SLD에 대한 불만 사항은 예약 및 차단된 SLD 불만 제기 양식(https://www.icann.org/resources/pages/reserved-2013-06-28-en)을 통해 제출할 수 있습니다.

  9. 이름 충돌

    각 gTLD의 위임 날짜에 따라(2014년 8월 18일 00:00 UTC 전, 당일 또는 후) 신규 gTLD 레지스트리 계약 형태를 실행한 레지스트리는 반드시 (1) 차상위 도메인(SLD) 목록을 차단하여 해당 이름을 활성화하기 최소 90일 전에 Controlled Interruption (CI) 또는 Wildcarded SLD CI를 차단 또는 구현하거나 (2) TLD에 따른 이름 활성화 최소 90일 전 Wildcarded CI를 구현해야 합니다. ICANN은 위임 후 ICANN으로 전송된 영역 파일을 주로 사용하여 CI 구현을 모니터링하고 시간을 맞춥니다. CI 구현 중에 다른 레지스트리 의무 사항은 변동이 없습니다(예: whois.nic.tld에서 RDDS 서비스를 제공하는 DNSSEC).

    관련 조항으로는 신규 gTLD 레지스트리 계약 규정 6, 이름 충돌 발생 관리 프레임워크 및 관련 문서가 있습니다.

  10. 영역 파일에 대한 제3자 액세스

    모든 레지스트리는 영역 파일에 대한 제3자 액세스를 제공해야 합니다. 레지스트리 영역 파일 계약은 레지스트리 또는 후원 계약에 지정된 양식을 사용해야 하고 가능한 경우 중앙 영역 데이터 서비스(CZDS)의 계약 사용을 포함해야 합니다. ICANN은 레지스트리 영역 파일 계약을 검토하고 영역 파일 액세스에 대한 CZDS를 사용하여 제3자의 불만 사항을 처리함으로써 레지스트리가 계약을 변경했는지, 추가 조건을 부과했는지 확인합니다.

    관련 조항으로는 CZDS 약관 및 신규 gTLD 레지스트리 계약 규정 4가 있습니다. 제 3자에 대한 레지스트리 운영자의 영역 파일 액세스 제공에 관한 불만 사항은 영역 파일 액세스 불만 제기 양식(https://www.icann.org/resources/pages/zfa-2013-06-28-en)을 통해 제출할 수 있습니다.

  11. 1남용 연락처 데이터

    신규 gTLD 레지스트리 계약 형식을 실행한 레지스트리는 ICANN을 제공하고 웹사이트에 gTLD의 남용 또는 악성 행위에 관한 질의 처리를 위한 유효한 이메일 주소, 유효한 우편 주소, 기본 연락처를 게시해야 합니다. ICANN이 레지스트리 웹사이트를 검토하여 필요한 연락처가 게시되었는지 확인합니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약 규정 6이 있습니다. 레지스트리 운영자의 남용 연락처 데이터에 관한 불만 사항은 남용 연락처 데이터 불만 제기 양식(https://www.icann.org/resources/pages/abuse-contact-2014-01-29-en)을 사용하여 제출할 수 있습니다.

  12. 공익 보호 노력

    신규 gTLD 레지스트리 계약 형식을 실행한 레지스트리는 특정 필수 및 자발적(해당하는 경우) 공익 보호 노력을 수행해야 합니다. 필수 조항으로는 레지스트리-레지스트라 계약(RRA)에 특정 조항 포함하기와 주기적인 기술 분석 수행하기가 있습니다. 이러한 의무 사항은 공익 보호 노력 분쟁 해결 절차(PICDRP)를 통해 실행할 수 있습니다. ICANN은 불만 수리와 외부 리소스를 통해 이러한 요구 사항에 대한 준수를 모니터링합니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약 규정 11 및 PICDRP가 있습니다. PICDRP 불만 사항은 PICDRP 양식(https://www.icann.org/resources/pages/picdrp-2013-10-31-en)을 통해 제출할 수 있습니다.

  13. 통일신속정지제도(URS)

    ICANN은 URS 절차를 통해 도메인 이름 등록으로 인해 발생하는 확실한 침해 사례를 겪는 권리 소유주를 위해 경제적이고 빠른 구제책을 제공합니다. ICANN의 역할은 신규 gTLD 레지스트리 계약 형태를 실행한 레지스트리가 URS 제공자의 URS 불만 처리 도중 및 이후에 URS 절차 요구 사항을 준수하도록 보장하는 것입니다.

    관련 조항으로는 레지스트리 및 레지스트라를 위한 URS 고도 기술 요구 사항, URS 절차 및 규정, 신규 gTLD 레지스트리 계약의 규정 7이 있습니다. 레지스트리 운영자의 URS 결정 이행 실패에 관한 URS 불만 사항은 URS 양식(https://www.icann.org/resources/pages/urs-2013-10-31-en)을 사용하여 제출할 수 있습니다.

  14. 와일드카드 금지

    신규 gTLD 레지스트리 계약 형태를 실행한 레지스트리는 등록되지 않았거나 유효한 NS 레코드가 제공되지 않은 도메인 이름에 대해 DNS 와일드카드 리소스 레코드, 일체의 DNS 리소스 레코드 합성 수단을 사용할 수 없고 DNS 내 모든 수준에서 리디렉션을 사용할 수도 없습니다. 그러한 도메인 이름에 대한 질의가 있을 경우, authoritative 네임 서버는 "이름 오류" 응답(NXDOMAIN이라고도 함), RFC 1035에 설명된 RCODE 3 및 관련 RFC를 반환해야 합니다. ICANN은 준수 파악을 위해 내부 기술 모니터링을 수행합니다. 이름 충돌 발생 평가 조건에 따라 이 금지 조항에 대한 일시적인 포기가 부여됩니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약 규정 6이 있습니다. 레지스트리 운영자의 와일드카드 금지에 관한 불만 사항은 와일드카드 금지(도메인 리디렉션) 불만 제기 양식(https://www.icann.org/resources/pages/wildcard-prohibition-2014-01-29-en)을 사용하여 제출할 수 있습니다.

  15. ICANN 지불

    모든 레지스트리는 ICANN에 수수료를 지불해야 합니다. 레지스트리 결제 레코드에 대한 데이터는 ICANN 회계 팀에서 구할 수 있습니다. 현재 제공되는 지불 지연에 대한 경고 및 알림은 회계 직원의 조율에 따라 준수 프로그램에 포함되어 있습니다.

    관련 조항으로는 신규 gTLD 레지스트리 계약 제 6조가 있습니다.

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."