Skip to main content
Resources

Política de Recuperação de Registros Expirados

Esta página também está disponível em:

Por favor, observe que a versão em inglês de todo o conteúdo e dos documentos traduzidos são versões oficiais e que as traduções em outras línguas são apenas para fins de informar.

Atualizada em 21 de fevereiro de 2024 a fim de refletir as alterações necessárias para implementar a Política para Dados de Registro. As partes contratadas poderão implementar essa Política atualizada a partir de 21 de agosto de 2024 e deverão tê-la implementada até, no máximo, 21 de agosto de 2025.

  1. Registrante na Expiração

    1.1. Um RAE (Registrant at Expiration, Registrante na Expiração) é definido como o Titular de Nome Registrado qualificado para renovar um registro de nome de domínio imediatamente antes da expiração desse nome.

    1.2. Se um registro de nome de domínio for modificado de acordo com um termo do contrato de registro autorizando a modificação dos dados de registro no que diz respeito à expiração do registro, o RAE é a entidade ou o indivíduo identificado como o Titular de Nome Registrado imediatamente antes dessa modificação. Em todos os outros casos de transferências de registros de gTLDs entre Titulares de Nome Registrado, o Titular de Nome Registrado que recebe o registro é o RAE.

  2. Renovação de registros

    2.1. Avisos de lembretes de expiração

    2.1.1. Antes da expiração de qualquer registro de gTLD, os registradores deverão notificar o Titular de Nome Registrado sobre a expiração em pelo menos duas ocasiões. Um desses avisos deverá ser enviado aproximadamente um mês antes da expiração, e o outro deverá ser enviado aproximadamente uma semana antes da expiração. Se o registro for transferido para outro Titular de Nome Registrado de acordo com uma disposição do contrato de registro e no que diz respeito à expiração do registro (conforme descrito no parágrafo 1.2), esses avisos de renovação deverão ser transmitidos ao RAE. Nada nesta política impede que os registradores enviem avisos adicionais, contanto que pelo menos dois avisos obrigatórios sejam enviados nas ocasiões exigidas.

    2.1.2. Se um registro não for renovado pelo RAE ou for excluído pelo registrador, em até cinco dias após a expiração do registro, o registrador deverá enviar pelo menos um aviso de expiração adicional ao RAE que inclua instruções para a renovação do registro.

    2.1.3. As notificações de expiração poderão ser apresentadas em um ou mais idiomas, mas deverão ser fornecidas no idioma do contrato de registro e comunicadas de maneira que não exija uma ação afirmativa para receber a notificação, como, por exemplo, por e-mail.

    2.2. Renovação pós-expiração

    2.2.1. Sujeitos às disposições e às políticas consensuais aplicáveis do Contrato de Credenciamento de Registradores (“RAA”), os registradores poderão excluir registros a qualquer momento após a expiração deles.

    2.2.2. No caso de registros excluídos em até oito dias após a expiração: O caminho de resolução existente do DNS especificado pelo RAE deverá ser interrompido pelo registrador a partir da expiração do registro até sua exclusão, contanto que o registro aplicável permita essas interrupções.

    2.2.3. No caso de registros excluídos em oito ou mais dias após a expiração: Durante pelo menos os oito últimos dias consecutivos (após a expiração) em que o registro estiver apto a ser renovado pelo RAE, o caminho de resolução do DNS especificado pelo RAE deverá ser interrompido pelo registrador, contanto que o registro aplicável permita essas interrupções.

    2.2.4. Ao interromper o caminho de resolução do DNS do registro, se o registrador direcionar o tráfego da web para o nome de domínio para uma página da web enquanto ainda for possível renovar o registro pelo RAE, essa página da web deverá indicar claramente que o registro do nome de domínio está expirado e fornecer as instruções para a renovação.

    2.2.5. A partir da data de expiração e durante o período de interrupção do caminho de resolução do DNS descrito nos parágrafos 2.2.2 e 2.2.3, o RAE deverá ser permitido pelo registrador a renovar o registro expirado.

    2.2.6. Após a renovação do registro pelo RAE, o registrador deverá restaurar o caminho de resolução do DNS definido pelo RAE imediatamente ou o quanto antes for comercialmente viável.

  3. Período de Tolerância de Resgate

    3.1. Com a exceção de registros de gTLDs patrocinados, todos os registros de gTLDs deverão oferecer um Período de Tolerância de Resgate (“RGP”) de 30 dias imediatamente após a exclusão de um registro, sendo que, durante esse período, o registro excluído poderá ser restaurado, a pedido do RAE, pelo registrador que o excluiu. Os registros excluídos durante um período de tolerância de acréscimo, se aplicável, não estará sujeito ao RGP.

    3.2. Durante o Período de Tolerância de Resgate, o registro deverá desativar a resolução do DNS e proibir tentativas de transferências do registro. As transferências em massa aprovadas pela ICANN e as transferências em massa parciais permitidas não estão sujeitas à proibição de tentativas de transferências. O registro também deverá indicar claramente nos seus resultados de RDDS (Registration Data Directory Services, Serviços de Diretório de Dados de Registro) que ele está em um Período de Tolerância de Resgate.

    3.3. Os registradores deverão permitir que o RAE possa resgatar um registro excluído durante o RGP (se o RGP for oferecido pelo respectivo registro).

  4. Avisos enviados a Titulares de Nome Registrado sobre taxas e procedimentos

    4.1. Os registradores deverão ter taxas de renovação, taxas de renovação pós-expiração (se diferentes) e taxas de resgate/restauração razoavelmente disponíveis aos Titulares de Nome Registrado e possíveis Titulares de Nome Registrado no momento do registro de um nome de gTLD.

    4.1.1. No mínimo, essas taxas deverão ser exibidas claramente no site do registrador e um link para essas taxas deverá ser incluído nos contratos de registros do registrador. Os registradores que não oferecerem nem prestarem serviços de registrador por meio de um site deverão, no mínimo, incluir as taxas em seus contratos de registros.

    4.1.2. Além disso, os registradores deverão garantir que essas taxas sejam exibidas nos sites de seus revendedores.

    4.2. Os registradores deverão descrever em seus sites (se forem usados) os métodos utilizados para enviar as notificações pré e pós-expiração descritas na seção 2 acima.

    4.2.1. Essa descrição deverá geralmente incluir a mídia/canais de comunicação que serão usados e a identificação do ponto de contato para o qual os avisos serão encaminhados (por exemplo, enviar por e-mail ao Titular de Nome Registrado, fazer uma chamada telefônica ao Titular de Nome Registrado, enviar uma correspondência ao cliente etc.).

    4.2.2. Os contratos de registros dos registradores deverão incluir uma descrição semelhante dos seus métodos de notificação ou um link para a(s) página(s) aplicável(eis) em seu site onde essas informações são disponibilizadas.

    4.2.3. Além disso, os registradores deverão garantir que esses métodos de comunicação sejam descritos nos sites de seus revendedores.

    4.3. Se a ICANN publicar materiais informativos aos Titulares de Nome Registrado sobre a administração apropriada de nomes de domínio e a renovação e resgate de registros de gTLDs on-line, os registradores deverão, após receber um aviso adequado da ICANN, disponibilizar esse material (ou um material semelhante adaptado pelo registrador a suas práticas específicas) aos Titulares de Nome Registrado das seguintes maneiras:

    4.3.1. incluir um link para esse material em uma comunicação enviada ao Titular de Nome Registrado imediatamente após a conclusão da transação do registro e em todos os avisos posteriores de lembretes sobre a precisão dos dados de registro, como os avisos anuais exigidos pela Política de Lembrete para Dados de Registro <https://www.icann.org/resources/pages/drp-2024-02-21-en>; e

    4.3.2. exibir um link para esse material nos sites pelos quais os registros são oferecidos, de maneira e em um local que esteja tão claro e evidente quanto os links para outros documentos e políticas que deverão ser publicados pelo registrador de acordo com seu contrato de credenciamento de registrador e políticas consensuais incorporadas.

Observações

Introdução e histórico: A pedido do Comitê Consultivo At-Large da ICANN, em 5 de dezembro de 2008, a ICANN publicou um Relatório de Assunto <http://gnso.icann.org/issues/post-expiration-recovery/report-05dec08.pdf> [PDF, 422 KB] sobre o tópico de Recuperação de Nomes de Domínio Pós-expiração. O Conselho da Organização de Apoio a Nomes Genéricos (“GNSO”) iniciou um Processo de Desenvolvimento de Políticas em maio de 2009, que resultou no envio de várias recomendações sobre políticas e processos <http://gnso.icann.org/en/resolutions/#201107> à Diretoria da ICANN. A Diretoria da ICANN aprovou as recomendações em 28 de outubro de 2011 <http://www.icann.org/en/groups/board/documents/resolutions-28oct11-en.htm#1.5> e orientou a equipe a implementar essa política.

A Política de Recuperação de Registros Expirados tem como objetivo ajudar a alinhar as expectativas de Titulares de Nome Registrado com as práticas de registradores estabelecendo certos requisitos mínimos para as comunicações, disponibilizando a renovação e o resgate de registros de maneira uniforme em circunstâncias prescritas e com a criação e promoção de materiais informativos aos Titulares de Nome Registrado.

A Política de Recuperação de Registros Expirados foi desenvolvida em consulta com uma Equipe de Revisão de Implementação formada pela GNSO para garantir que a política atenda à carta e à intenção das recomendações de políticas aprovadas pela GNSO e adotadas pela Diretoria da ICANN.

Todos os registradores e registros deverão estar em conformidade com essa política a partir de 31 de agosto de 2013.

Avisos de lembretes de expiração: As recomendações de políticas da GNSO reconhecem que é necessário haver certa flexibilidade em relação ao cronograma dos avisos de renovação pré-expiração. Sendo assim, se os avisos que deverão ser enviados aproximadamente um mês e uma semana antes da expiração, conforme descrito no parágrafo 2.1.1, forem enviados entre 26 a 35 dias e entre 4 a 10 dias antes da expiração, respectivamente, eles serão considerados em conformidade com a política.

Renovação pós-expiração: O parágrafo 2.2.4 da política explica que os registradores deverão incluir um aviso de expiração e instruções de renovação se o registrador direcionar o tráfego da web para o nome de domínio para uma página da web enquanto ainda for possível renová-lo pelo RAE. Para esclarecer, esse requisito se aplica a qualquer momento durante o período em que o registro estiver apto a ser renovado pelo RAE, e não apenas durante o período descrito nos parágrafos 2.2.2 e 2.2.3. As instruções de renovação exigidas nesta seção não precisam ser detalhadas e podem apenas direcionar o RAE ao local apropriado no site do registrador.

O parágrafo 2.2.2 descreve a duração do período em que o registrador deverá interromper o caminho de resolução do DNS de um registro, se o registro for excluído em até oito dias após a expiração dele. Por exemplo, se um registro expira em 1º de outubro, e o registrador excluir o nome em 3 de outubro, o caminho de resolução deverá ser interrompido entre 1 e 3 de outubro. O parágrafo 2.2.3 descreve a duração do período em que o registrador deverá interromper o caminho de resolução do DNS de um registro, se o registro for excluído em oito ou mais dias após a expiração dele. Por exemplo, se um registro expira em 1º de outubro, e o registrador excluir o nome em 20 de outubro, o caminho de resolução deverá ser interrompido, no mínimo, entre 12 e 20 de outubro.

O parágrafo 2.2.6 exige que os registradores restaurem o caminho de resolução do DNS estabelecido anteriormente pelo RAE de maneira imediata ou o quanto antes for comercialmente viável. O termo “comercialmente viável” nesse caso tem como objetivo permitir, por exemplo, situações em que a intervenção manual é necessária para restaurar o caminho de resolução do DNS ou em que o registrador não consegue restaurar o caminho de resolução do DNS imediatamente porque a renovação pós-expiração ocorreu em um feriado ou em outro dia não útil.

Avisos enviados a Titulares de Nome Registrado sobre taxas e procedimentos O parágrafo 4.1.1 da política exige que os registradores incluam, no mínimo, as taxas de renovação, as taxas de renovação pós-expiração (se diferentes) e as taxas de resgate/restauração razoavelmente disponíveis no contrato de registro (e em seus sites, se um site for usado). No entanto, é recomendado que os registradores apresentem essas taxas de maneira suficientemente evidente no momento do registro para ajudar os Titulares de Nome Registrado a tomar uma decisão consciente e evitar confusão, particularmente se os preços da renovação forem possivelmente maiores que as taxas de registro ou de transferência sendo cobradas.

Sugestão de práticas recomendadas: A GNSO sugere as seguintes práticas recomendadas para registradores:

  • Se as notificações pós-expiração descritas no parágrafo 2.1.2 forem normalmente enviadas a um ponto de contato usando o domínio em questão, e a entrega for interrompida por ações pós-expiração (como uma interrupção da resolução do DNS, conforme descrito nos parágrafos 2.2.2 e 2.2.3), as notificações pós-expiração deverão ser enviadas para algum outro ponto de contato associado ao Titular de Nome Registrado, se houver.
  • Os registradores deverão aconselhar os Titulares de Nome Registrado a fornecer o e-mail de um ponto de contato secundário que não seja associado ao nome de domínio em si, de modo que, se ocorrer a expiração, os lembretes possam ser encaminhados para o e-mail desse ponto de contato secundário.
  • A explicação do método de notificação exigida pelo parágrafo 4.2 deverá incluir o endereço de e-mail do registrador do qual serão enviadas as mensagens de notificação e uma sugestão de que os Titulares de Nome Registrado salvem esse endereço de e-mail como um “remetente seguro”, a fim de evitar que os e-mails de notificação sejam bloqueados pelo software de filtro de spam.
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."