Skip to main content
Resources

Política de Recuperação de Registros Expirados (ERRP)

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.

  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 registrantes, 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 devem notificar o titular de nome registrado sobre a expiração em pelo menos duas ocasiões. Um desses avisos deve ser enviado aproximadamente um mês antes da expiração e o outro deve 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 devem 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 deve 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 podem ser apresentadas em um ou mais idiomas, mas devem ser fornecidas no idioma do contrato de registro e serem 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 de consenso aplicáveis do RAA (Registrar Accreditation Agreement, Contrato de Credenciamento de Registradores), os registradores podem 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 do DNS existente especificado pelo RAE deve 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) que o registro pode ser renovado pelo RAE, o caminho de resolução do DNS especificado pelo RAE deve 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 deve 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 deve ser permitido pelo registrador a renovar o registro expirado.

    2.2.6. Após a renovação do registro pelo RAE, o registrador deve 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 devem oferecer um RGP (Redemption Grace Period, Período de Tolerância de Resgate) de 30 dias imediatamente após a exclusão de um registro, sendo que, durante esse período, o registro excluído pode 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 deve estar sujeito ao RGP.

    3.2. Durante o Período de Tolerância de Resgate, o registro deve 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 deve indicar claramente nos seus resultados de WHOIS do registro que ele está em um Período de Tolerância de Resgate.

    3.3. Os registradores devem 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 registrantes sobre taxas e procedimentos

    4.1. Os registradores devem 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 nomes registrados e possíveis titulares de nomes registrados no momento do registro de um nome de gTLD.

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

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

    4.2. Os registradores devem 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 deve 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 contato administrativo, enviar uma correspondência ao cliente etc.).

    4.2.2. Os contratos de registros dos registradores devem 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 devem garantir que esses métodos de comunicação sejam descritos nos sites de seus revendedores.

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

    4.3.1. Incluindo 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 WHOIS, como os avisos anuais exigidos pela Política de Lembretes de Dados do WHOIS <http://www.icann.org/resources/registrars/consensus-policies/wdrp> ; e

    4.3.2. Exibindo 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 devem ser publicados pelo registrador de acordo com seu contrato de credenciamento de registrador e políticas de consenso 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 Nome de Domínio Pós-expiração. O Conselho da GNSO (Generic Names Supporting Organization, Organização de Apoio a Nomes Genéricos) 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 registrantes 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 registrantes.

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 devem 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 devem 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, isso seria considerado como 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 devem 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 ele pode ser renovado pelo RAE. Para esclarecer, esse requisito se aplica a qualquer momento durante o período em que o registro pode 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 deve 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 deve 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 deve 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 deve 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 antes estabelecido pelo RAE imediatamente ou o quanto antes for comercialmente viável. O termo "comercialmente viável" neste 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 registrantes 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 registrantes 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 devem ser enviadas para algum outro ponto de contato associado ao titular de nome registrado, se houver.
  • Os registradores devem aconselhar os titulares de nomes registrados 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 deve incluir o endereço de e-mail do registrador do qual são enviadas as mensagens de notificação e uma sugestão de que os titulares de nomes registrados 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.

Tempo para entrar em conformidade: Todos os registradores credenciados pela ICANN e registros de gTLDs devem estar em conformidade com a ERRP até 31 de agosto de 2013. A seção 2.1 da política exige que os registradores enviem avisos pré-expiração a todos os registrantes de gTLDs. Os registradores devem começar a fornecer esses avisos em 31 de agosto, de acordo com o cronograma definido na ERRP. Em outras palavras, se um registro deve expirar em menos de 30 dias após 31 de agosto de 2013, o registrador não é obrigado a enviar o lembrete um mês antes da expiração. Da mesma forma, se um registro deve expirar em menos de 7 dias após 31 de agosto, o registrador não é obrigado a enviar o lembrete uma semana antes da expiração. No entanto, os registradores ainda são obrigados, de acordo com a seção 3.7.5 do Contrato de Credenciamento de Registradores, a enviar dois lembretes de expiração para todos os registros prestes a expirar, mesmo aqueles que expirarão em menos de um mês ou menos de uma semana após a implementação da ERRP. Consulte a tabela abaixo para mais esclarecimento.

Registros prestes a expirar: 1º aviso de expiração da ERRP obrigatório (um mês antes da expiração) 2º aviso de expiração da ERRP obrigatório (uma semana antes da expiração) Pelo menos 2 avisos de expiração (inclusive os avisos da ERRP) obrigatórios
Antes de 7 de setembro de 2013 x
7 de setembro de 2013 – 30 de setembro de 2013 x x
1 de outubro e posteriormente x x x
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."