Skip to main content
Resources

만료된 등록 복구 정책

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

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

등록 데이터 정책을 시행하는 데 필요한 변경 사항을 반영하기 위해 2024년 2월 21일에 업데이트했습니다. 계약 당사자는 2024년 8월 21일부터 이 업데이트된 정책을 시행할 수 있으며 2025년 8월 21일보다 늦지 않게 시행해야 합니다.

  1. 만료 시점 등록자

    1.1. 만료 시점 등록자("RAE")는 만료 직전에 도메인 이름 등록을 갱신할 자격이 있는 등록명 보유자로 정의됩니다.

    1.2. 등록 만료와 관련하여 등록 데이터 수정 권한을 부여하는 등록 계약의 조항에 따라 도메인 이름 등록이 수정되는 경우, RAE는 수정 직전에 등록명 보유자로 식별된 법인 또는 개인입니다. 등록명 보유자 간에 이루어지는 모든 다른 gTLD 등록 이전의 경우 등록을 받는 등록명 보유자가 RAE입니다.

  2. 등록 갱신

    2.1. 만료 미리 알림 통지

    2.1.1. gTLD 등록 만료 이전에 레지스트라에서 만료에 대해 등록명 보유자에게 2회 이상 통지해야 합니다. 첫 번째 만료 미리 알림 통지는 만료 약 1개월 이전에 보내고 다음 통지는 만료 약 1주일 이전에 보내야 합니다. 1.2절에 명시된 대로 등록 만료와 관련하여 등록 계약의 조항에 따라 다른 등록명 보유자에게 등록이 이전되는 경우, 갱신 통지를 RAE에게 대신 전송해야 합니다. 본 정책의 어떤 조항도 레지스트라에서 추가 통지를 보내는 것을 금지하지 않습니다. 단, 최소 2회의 필수 통지는 필요한 시점에 발송해야 합니다.

    2.1.2. RAE가 등록을 갱신하지 않거나 레지스트라에서 등록을 삭제한 경우 레지스트라는 등록 만료 후 5일 이내에 등록 갱신 지침이 포함된 추가 만료 통지를 RAE에게 1회 이상 발송해야 합니다.

    2.1.3. 만료 통지는 하나 이상의 언어로 제공될 수 있지만 등록 계약 언어를 반드시 포함해야 하며, 이메일 등과 같이 통지를 받기 위해 동의 조치가 필요하지 않은 방식으로 전달되어야 합니다.

    2.2. 만료 후 갱신

    2.2.1. 레지스트라 인가 계약("RAA")의 관련 합의 정책 및 조항에 따라 레지스트라에서 만료 후 언제든지 등록을 삭제할 수 있습니다.

    2.2.2. 만료 후 8일 이내에 등록을 삭제하는 경우: 레지스트라에서 등록 만료 후 삭제할 때까지 RAE가 지정한 기존 DNS 확인 경로를 중단해야 합니다(소관 레지스트리가 중단을 허용하는 경우).

    2.2.3. 만료일로부터 8일 이상 경과한 후에 등록을 삭제하는 경우: RAE가 등록을 갱신할 수 있는 (만료 후) 최소 마지막 8일에 대해, 레지스트라에서 RAE가 지정한 기존 DNS 확인 경로를 중단해야 합니다(소관 레지스트리가 중단을 허용하는 경우).

    2.2.4. 등록의 DNS 확인 경로를 중단할 때 RAE가 아직 등록을 갱신할 수 있는 동안에 레지스트라에서 해당 도메인 이름에 대한 웹 트래픽을 웹 페이지로 전달할 경우 해당 웹 페이지에 도메인 이름 등록이 만료되었다고 명시하고 갱신 지침을 제공해야 합니다.

    2.2.5. 만료 시점부터 2.2.2절 및 2.2.3절에 명시된 DNS 확인 중단 기간까지 RAE는 만료된 등록을 갱신하려면 레지스트라의 허가를 받아야 합니다.

    2.2.6. RAE가 등록을 갱신하면 레지스트라에서 RAE가 설정한 DNS 확인 경로를 즉시 또는 상업적으로 합리적인 시간에 최대한 빨리 복원해야 합니다.

  3. 회복 유예 기간

    3.1. 주관 gTLD 레지스트리를 제외한 모든 gTLD 레지스트리는 등록 삭제 직후 30일 간의 회복 유예 기간("RGP")을 제공해야 합니다. 이 기간 동안 RAE의 요청이 있을 경우 등록을 삭제한 레지스트라에서 삭제된 등록을 복원할 수 있습니다. 레지스트리의 추가 유예 기간 중에 삭제된 등록에는 RGP가 적용되지 않습니다.

    3.2. 회복 유예 기간 동안 레지스트리는 DNS 확인을 비활성화하고 시도된 등록 이전을 금지해야 합니다. ICANN 승인 대량 이전 및 허용 부분 대량 이전에는 시도된 이전 금지가 적용되지 않습니다. 또한 레지스트리는 등록 데이터 디렉터리 서비스(RDDS) 결과에 등록이 회복 유예 기간 중이라는 사실을 명시해야 합니다.

    3.3. 레지스트라에서 RGP(해당 레지스트리가 RGP를 제공하는 경우) 동안 RAE가 삭제된 등록을 회복할 수 있도록 허용해야 합니다.

  4. 등록명 보유자에게 수수료 및 절차 통지

    4.1. 레지스트라에서 gTLD 이름을 등록할 때 등록명 보유자와 예지 등록명 보유자가 합리적으로 이용할 수 있는 갱신 수수료, 만료 후 갱신 수수료(다른 경우), 회복/복원 수수료를 제공해야 합니다.

    4.1.1. 최소한 레지스트라의 웹사이트에 관련 수수료를 명확하게 게시하고 레지스트라의 등록 계약에 해당 수수료에 대한 링크를 포함해야 합니다. 웹사이트를 통해 레지스트라 서비스를 제공하지 않는 레지스트라에서 최소한 등록 계약에 수수료를 포함시켜야 합니다.

    4.1.2. 또한 레지스트라에서는 이 수수료가 등록 대행 업체의 웹사이트에 표시되는지 확인해야 합니다.

    4.2. 레지스트라에서 웹사이트(사용되는 경우)에서 위 2절에 설명된 만료 전 통지와 만료 후 통지를 제공하는 데 사용되는 방법을 설명해야 합니다.

    4.2.1. 이 설명에는 일반적으로 사용할 통신 채널/미디어와 통지를 발송할 연락처 식별(예: 등록명 보유자에게 이메일, 등록명 보유자에게 전화 통화, 고객에게 우편 등)이 포함되어야 합니다.

    4.2.2. 레지스트라의 등록 계약에는 통지 방법에 대한 유사한 설명 또는 이 정보를 확인할 수 있는 웹사이트의 해당 페이지 링크가 포함되어야 합니다.

    4.2.3. 또한 레지스트라에서는 이 통신 방법이 등록 대행 업체의 웹사이트에 설명되는지 확인해야 합니다.

    4.3. ICANN에서 도메인 이름에 대한 적절한 관리권과 gTLD 등록의 갱신 및 회복을 다루는 등록명 보유자 교육 자료를 온라인으로 게시하는 경우, 레지스트라에서 ICANN의 합리적인 통지 후 다음과 같은 방식으로 이 자료(또는 레지스트라에서 특정 관행에 맞게 조정한 유사한 자료)를 등록명 보유자에게 제공해야 합니다.

    4.3.1. 등록 거래 완료 직후 등록명 보유자에게 발송되는 통신물과 모든 후속 등록 데이터 정확성 알림 통지(예: 등록 데이터 알림 정책 <https://www.icann.org/resources/pages/drp-2024-02-21-en>에 요구되는 연례 통지)에 이 자료에 대한 링크 포함

    4.3.2. 등록이 제공되는 웹사이트에서 레지스트라 인가 정책과 편입된 합의 정책에 따라 레지스트라에서 게시해야 하는 다른 문서 및 정책에 대한 링크만큼 최소한 분명하고 눈에 띄는 위치에 그러한 방식으로 이 자료에 대한 링크 표시

참고

소개 및 배경 설명: ICANN의 At-Large 자문 위원회의 요청에 따라 2008년 12월 5일에 ICANN은 도메인 이름 만료 후 복구라는 제목으로 문제 보고서 <http://gnso.icann.org/issues/post-expiration-recovery/report-05dec08.pdf>[PDF, 422KB]를 발행했습니다. 일반 최상위 도메인 이름 지원 기구("GNSO")는 2009년 5월에 정책 개발 과정에 착수하여 다양한 정책 및 프로세스 권고 사항 <http://gnso.icann.org/en/resolutions/#201107>을 ICANN 이사회에 제출했습니다. ICANN 이사회는 2011년 10월 28일 <http://www.icann.org/en/groups/board/documents/resolutions-28oct11-en.htm#1.5>에 이 권고 사항을 승인하고 직원들에게 이 정책을 이행하도록 지시했습니다.

만료된 등록 복구 정책은 특정한 최소 통신 요건을 설정하고, 규정된 환경에서 일률적으로 사용할 수 있도록 등록을 갱신 및 회복하며, 등록명 보유자 교육 자료를 생성하고 홍보하여 레지스트라의 관행에 따라 등록명 보유자의 기대를 충족하는 것을 목적으로 합니다.

만료된 등록 복구 정책은 이 정책이 GNSO가 승인하고 ICANN 이사회가 채택한 정책 권고안의 문구 및 의도를 충족하는지 확인하기 위해 GNSO가 소집한 실행 검토 팀과의 협의를 통해 개발되었습니다.

모든 레지스트라와 레지스트리는 2013년 8월 31일부터 이 정책을 준수해야 합니다.

만료 미리 알림 통지: GNSO의 권장 정책에서는 만료 전 갱신 통지 시기에 있어서 어느 정도의 유연성이 필요함을 인정하고 있습니다. 따라서 2.1.1절에 기술된 만료일 기준 약 1개월 전과 1주일 전에 발송되어야 하는 통지가 각각 만료 전 26~35일 사이와 4~10일 사이에 전송된다면 이는 정책을 준수한 것으로 간주됩니다.

만료 후 갱신: 이 정책의 2.2.4절에는 RAE가 아직 등록을 갱신할 수 있는 동안에 레지스트라에서 도메인 이름에 대한 웹 트래픽을 웹 페이지로 전달할 경우 만료 통지와 갱신 지침을 포함해야 한다고 규정되어 있습니다. 정확히 말해 이 요건은 2.2.2절 및 2.2.3절에 명시된 기간뿐만 아니라 RAE가 등록을 갱신할 수 있는 모든 기간에 적용됩니다. 이 절에 요구되는 갱신 지침은 상세히 기술할 필요가 없으며 RAE를 레지스트라 웹사이트의 적절한 위치로 안내할 수 있으면 됩니다.

2.2.2절에는 만료일 기준 8일 이내에 등록이 삭제된 경우에 레지스트라에서 등록의 DNS 확인 경로를 중단해야 하는 기간이 명시되어 있습니다. 예를 들어, 등록이 10월 1일에 만료되고 레지스트라에서 10월 3일에 이름을 삭제할 경우 10월 1~3일 사이에 확인 경로를 중단해야 합니다. 2.2.3절에는 만료일 기준 8일이 경과한 후 등록이 삭제된 경우에 레지스트라에서 등록의 DNS 확인 경로를 중단해야 하는 기간이 명시되어 있습니다. 예를 들어, 등록이 10월 1일에 만료되고 레지스트라에서 10월 20일에 이름을 삭제할 경우 최소 10월 12일~20일 사이에 확인 경로를 중단해야 합니다.

2.2.6절에서는 레지스트라에서 즉시 또는 상업적으로 합리적인 기간 내에 RAE가 이전에 설정한 DNS 확인 경로를 복원해야 한다고 규정합니다. "상업적으로 합리적인"이란 표현은 DNS 확인 경로를 복원하기 위해 수동 개입이 필요하거나, 만료 후 갱신이 휴일 또는 영업일이 아닌 다른 날짜에 발생하여 레지스트라에서 DNS 확인 경로를 즉시 복원할 수 없는 경우 등에 사용할 수 있습니다.

등록명 보유자에게 수수료 및 절차 통지: 본 정책의 4.1.1절에서는 레지스트라에서 등록 계약 및 웹사이트(웹사이트를 사용하는 경우)에 최소한 갱신 수수료, 만료 후 갱신 수수료(다른 경우), 회복/복원 수수료를 포함해야 한다고 규정합니다. 하지만, 특히 부과될 등록 수수료 또는 이전 수수료보다 갱신 가격이 높을 것으로 예상되는 경우, 레지스트라는 등록 시 수수료를 충분히 눈에 잘 띄게 표시하여 등록명 보유자가 정보에 기반하여 결정을 내리고 혼동을 방지할 수 있도록 하는 것이 좋습니다.

제안된 모범 사례: GNSO는 레지스트라를 위해 다음과 같은 모범 사례를 권고합니다.

  • 2.1.2절에 명시된 만료 후 통지가 일반적으로 관련 도메인을 사용하는 연락처로 전송되고 만료 후 조치(예: 2.2.2절 및 2.2.3절에 기술된 DNS 확인 중단)로 인해 전달이 중단된 것으로 알려진 경우 등록명 보유자와 연결된 다른 연락처(있는 경우)로 만료 후 통지를 발송해야 합니다.
  • 레지스트라는 등록명 보유자에게 도메인 이름과 연결되지 않은 보조 이메일 연락처를 제공하여 만료 시 이 보조 이메일 연락처로 알림을 전달할 수 있도록 해야 합니다.
  • 4.2절에 요구되는 통지 방법 설명에는 통지 메시지를 보내는 레지스트라의 이메일 주소와 등록명 보유자에게 이 이메일 주소를 '수신 허용 발신자'로 저장하여 통지 이메일이 스팸 필터 소프트웨어에 의해 차단되지 않도록 제안하는 내용이 포함되어야 합니다.
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."