Skip to main content
Resources

Processos de Transição de Registros

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.

Definições

No contexto deste documento, os termos a seguir são definidos da seguinte forma:

Operador de Registro de Back-end: uma organização contratada por um registro para executar uma ou mais funções críticas de um registro gTLD.

Funções críticas:as funções críticas para a operação de um registro de gTLD:

  1. Resolução do DNS
  2. Zona DNSSEC assinada adequadamente (se o DNSSEC for oferecido pelo registro)
  3. SRS (Shared Registration System, Sistema de Registro Compartilhado), geralmente por meio do EPP (Extensible Provisioning Protocol, Protocolo de Provisionamento Extensível)
  4. RDDS (Registration Data Directory Services, Serviços de Diretório de Dados de Registro), por exemplo, WHOIS fornecido pela porta 43 e por meio de um serviço baseado na web.
  5. Depósito de dados do Registro

Transição de registro: uma alteração de parte contratada no Contrato de Registro de um gTLD com a ICANN. Alguns exemplos de circunstâncias que resultam em uma transição de registro são: alteração de nome da organização que administra o gTLD, uma venda ou transferência do registro, violação do Contrato de Registro por parte do registro atual etc.

Registro sucessor: A nova parte contratada de um Contrato de Registro de um gTLD com a ICANN após uma transição de registro.

Processos de Transição de Registros

A Afirmação de Compromissos, seção 9.2, declara que um dos compromissos da ICANN é:

Preservar a segurança, a estabilidade e a resiliência [do DNS].1

O Estatuto da ICANN identifica os valores essenciais da organização. O valor essencial nº 1 é:

Preservar e aprimorar a estabilidade operacional, a confiabilidade, a segurança e a interoperabilidade global da Internet;2

O Plano Operacional de 2006 a 2007 da ICANN (seção 1.1.2) declara que a ICANN:

Estabelecerá um plano abrangente que será seguido se ocorrer uma falha financeira, técnica ou nos negócios de um operador de registro, incluindo a conformidade total com os requisitos de depósito de dados e os testes de recuperação.3

O processo foi criado em AF06-07 e atualizado continuamente. Hoje em dia, ele é chamado de Estrutura de Continuidade de Registro.4 O Processo de Gerenciamento de Eventos e Incidentes descrito na Estrutura de Continuidade de Registro identifica a necessidade de lidar com situações em que as funções críticas do registro sejam afetadas negativamente.

Em busca do valor essencial nº 1 e como resultado do desenvolvimento da Estrutura de Continuidade do Registro, a ICANN identificou a necessidade de definir processos para a transição de um gTLD de maneira segura, estável e confiável e, ao mesmo tempo, minimizar o impacto nos registrantes e nos usuários do gTLD e proporcionar transparência para as partes envolvidas na transição.

Os três processos a seguir foram desenvolvidos e são descritos neste documento:

  1. Processo de Transição de Registro com um sucessor proposto
  2. Processo de Transição de Registro com RFP (Request For Proposals, Solicitação de Propostas)
  3. Processo de Transição Temporária de Operador de Registro de Back-end para Emergências

 

  1. Processo de Transição de Registro com um sucessor proposto

    Esse processo será usado quando um registro solicitar que a ICANN atribua seu Contrato de Registro para um possível sucessor (por exemplo, se o registro estiver sendo adquirido, se houver uma alteração de nome na organização, se ocorrer uma transição para o provedor de continuidade dos serviços de registro). Esse processo também será usado se, após o término da vigência do Contrato de Registro ou mediante uma ordem judicial emitida por autoridade legal com jurisdição, o governo ou a autoridade pública relevante retirar seu apoio ao operador de registro de um gTLD que seja um nome geográfico e propuser um registro sucessor. O Anexo 2 contém um fluxograma desse processo.

    Todas as avaliações de um sucessor proposto serão sempre examinadas minuciosamente, conforme apropriado. Por exemplo, no caso de uma alteração de nome, a avaliação terá como foco garantir a legitimidade e eliminar a oportunidade de sequestro do TLD.

    Após o recebimento da solicitação do atual registro ou do governo ou autoridade pública relevantes (no caso dos gTLDs geográficos), a ICANN avaliará a situação com base nos fatos coletados, conversas com o registro vigente e o governo ou autoridade pública (se aplicável) e fará uma análise do Contrato de Registro. A avaliação será baseada nas seguintes perguntas:

    • Haveria uma alteração da entidade responsável por alguma função do registro de back-end?
    • O TLD tem uma comunidade relevante que deve ser consultada?
    • Trata-se de um gTLD de nome geográfico, de acordo com a definição no Guia do Solicitante? (Ou foi necessário ter o apoio de um governo no momento de fazer a solicitação?)
    • Há alguma restrição no Contrato de Registro que possa afetar a transição?

    A ICANN também realizará uma avaliação de risco do gTLD, do registro atual e do operador de registro de back-end (se houver alguma alteração nesse sentido). A avaliação será voltada para as particularidades desses três elementos como um todo e de cada elemento individualmente. Por exemplo, será verificado se o gTLD é muito usado por instituições financeiras ou para comércio eletrônico, o que pode acarretar em medidas mais rigorosas quanto à segurança da transição.

    Após a conclusão dessas avaliações, o registro sucessor proposto será verificado a fim de garantir que tenha o apoio externo necessário, se isso for uma exigência. Se o gTLD for um nome geográfico, conforme definido no Guia do Solicitante para Novos gTLDs, a ICANN orientará o sucessor proposto a solicitar apoio com o governo ou a autoridade pública relevante para o possível sucessor e coletar a documentação de apoio/não objeção. Se o Contrato de Registro definir que seja necessário consultar alguma comunidade específica no momento da transição, a ICANN entrará em contato com ela nessa etapa. Nesses casos, é necessário ter o apoio da comunidade relevante ao sucessor proposto para dar continuidade ao processo de transição.

    Se o sucessor proposto tiver o apoio exigido ou se não for necessário nenhum apoio, a ICANN prosseguirá com a avaliação do solicitante usando os processos definidos no Guia do Solicitante para Novos gTLDs. Com base nos critérios dispostos na Matriz de Avaliação de Possível Registro descrita no Anexo 1, a ICANN determinará quais avaliações são necessárias e coletará as informações e a taxa de avaliação. A taxa cobrirá o custo das avaliações, que são realizadas por prestadores de serviços externos.

    As avaliações realizadas internamente pela ICANN não terão custos para o solicitante.

    O escopo das avaliações vai variar para cada caso dependendo do nível exigido e apropriado do exame minucioso. Os três níveis do exame minucioso são apresentados no Anexo 1. O escopo do nível mais amplo (ou seja, Full [Completo]) será semelhante ao escopo da revisão de solicitantes de novos gTLDs. A avaliação será realizada por uma das firmas encarregadas da verificação das solicitações de novos gTLDs. O próximo nível (ou seja, Limited [Limitado]) representa um escopo mais restrito de revisão. Por exemplo, a avaliação técnica e operacional pode consistir em garantir que a nova organização tenha acordos semelhantes em vigor com o operador de registro de back-end existente. O terceiro nível (ou seja, Minimal [Mínimo]) representa um escopo muito restrito de revisão que seria realizada internamente pela ICANN.

    Em seguida, o prestador de serviços realiza as avaliações e entrega um relatório para o solicitante e a ICANN. Se o solicitante não passar na avaliação, ele terá uma chance para remediar as deficiências em até três semanas após a reprovação na avaliação (uma avaliação estendida). Se o solicitante não passar na segunda oportunidade, o processo será encerrado sem nenhuma transição e o solicitante será reembolsado no valor igual ao que foi coletada menos os custos reais da avaliação.

    Se o possível sucessor passar na avaliação, a ICANN buscará as aprovações necessárias e firmará um Contrato de Registro com o sucessor, se aprovado. Se o possível sucessor não for aprovado, o processo será encerrado sem nenhuma transição.

    Após a aprovação do sucessor, o resultado será comunicado interna e externamente, conforme necessário e apropriado. Se a transição não envolver uma alteração do operador de registro de back-end, o sucessor deverá solicitar a alteração na organização patrocinadora com a IANA.

    Se a entidade responsável pelos serviços de operador de registro de back-end for alterada, o sucessor precisará passar nos testes de pré-delegação, conforme definido no Guia do Solicitante para Novos gTLDs. Isso é necessário mesmo que o provedor de back-end seja o operador do registro ou uma parte contratada pelo operador do registro. Após a conclusão dos testes, o novo operador do registro deverá fazer a alteração da organização patrocinadora com a IANA no banco de dados da zona raiz da IANA. Depois de concluir a etapa com a IANA, o operador de registro sucessor executará a migração dos dados e serviços e solicitará as alterações nos registros do DNS e RDDS (WHOIS) com a IANA.

    As últimas etapas no processo de transição serão comunicadas interna e externamente, conforme necessário e apropriado e para a ICANN atualizar suas informações públicas e internas sobre o registro do gTLD.

  2. Processo de Transição de Registro com RFP

    Esse processo será usado principalmente quando um registro de gTLD violar seu Contrato de Registro (o que resulta na rescisão) e não identifica um registro sucessor. Esse processo também será usado se, após o término da vigência do Contrato de Registro ou mediante uma ordem judicial emitida por autoridade legal com jurisdição, o governo ou a autoridade pública relevante retirar seu apoio ao registro de um gTLD geográfico e não propuser um registro sucessor. O Anexo 3 contém um fluxograma desse processo.

    Esse processo é semelhante a um Processo de Transição de Registro com sucessor proposto descrito acima, exceto que ele inclui um subprocesso de RFP (Request for Proposals, Solicitação de Propostas). O objetivo da RFP é identificar e solicitar inscrições de possíveis registros sucessores.

    O processo de RFP será iniciado após a avaliação de risco do gTLD, uma vez que ela pode produzir descobertas que talvez sejam importantes para a RFP. A RFP descreverá os serviços necessários que serão prestados pelo registro sucessor. Além disso, os custos estimados dos serviços da avaliação serão incluídos na RFP e representarão o mínimo aceitável na proposta financeira de um solicitante.

    Se o registro estiver operando um gTLD que seja um nome geográfico, conforme definido no Guia do Solicitante, a ICANN fará uma consulta com o governo ou a autoridade pública para buscar um parecer na RFP. Além disso, se o Contrato de Registro contiver uma disposição que exija que a ICANN consulte uma comunidade específica sobre um possível sucessor antes de uma transição, isso será feito nessa etapa do processo.

    Depois de aprovada, a RFP será publicada por 45 dias, e os solicitantes terão até o término desse período para fornecer uma resposta.

    O solicitante que propuser o maior pagamento para o registro original será examinado a fim de verificar se ele tem o apoio necessário e avaliado conforme descrito no Processo de Transição de Registro com sucessor proposto. Esse mecanismo de seleção proporciona o retorno máximo para o registro original e minimiza despesas desnecessárias para os solicitantes não selecionados, além de garantir, ao mesmo tempo, que o vencedor seja qualificado.

    Se o solicitante tiver o apoio necessário (ou se nenhum apoio foi exigido) e passar na avaliação, o processo continuará conforme descrito no processo mencionado anteriormente. Se o solicitante não tiver o apoio necessário ou não passar na avaliação, o próximo solicitante com a proposta de maior valor será considerado e assim por diante, até que seja encontrado um solicitante com apoio e aprovado na avaliação ou que não haja mais propostas.

    Se nenhuma proposta for recebida durante o processo de RFP ou se não houver solicitantes qualificados, devido à ausência do apoio apropriado ou à incapacidade de passar na avaliação, o processo de desativação do TLD será invocado para que o gTLD seja encerrado. Se um candidato viável for identificado após o encerramento de um processo de RFP que não identificou um sucessor, esse candidato poderá ser considerado com base nas circunstâncias observadas no momento e se essa decisão serve ao interesse público.

    Se esse processo identificar um registro sucessor qualificado, todos os fundos coletados desse solicitante menos os custos da avaliação e as taxas pendentes serão enviados ao operador do registro que disponibiliza o gTLD.

  3. Processo de Transição Temporária de Operador de Registro de Back-end para Emergências

    Esse processo será usado para novos gTLDs principalmente mediante duas condições: (1) o registro está violando seu Contrato de Registro e (2) uma função essencial está sendo realizada com resultados abaixo dos limites de emergência, conforme definido no Contrato de Registro, gerando uma situação de risco inaceitável, de acordo com a definição abaixo. Nesse caso, as operações podem ser transferidas para um prestador de serviços de back-end em caráter emergencial até que o operador do registro consiga restaurar suas operações normais. Essa transição temporária também poder ser iniciada mediante a solicitação do operador do registro, se ele tiver conhecimento ou antecipar uma incapacidade de realizar as funções essenciais adequadamente.

    As medidas para detectar o limite emergencial para as funções essenciais (exceto o depósito de dados) serão retiradas do sistema de monitoramento de SLA (Service Level Agreement, Contrato de Nível de Serviço) do registro usado pela ICANN, conforme descrito no Contrato do Registro.

    Também é importante observar que esse processo de transição tem como finalidade servir como uma medida temporária para proteger os registrantes e os usuários do gTLD. A transição temporária das funções essenciais permanecerá em vigor até que os problemas dispostos sejam solucionados ou que o gTLD seja transferido para outro operador usando um dos processos para a transição de registros descritos anteriormente. Para possibilitar essa transição temporária, o Contrato de Registro para novos gTLDs inclui uma pré-autorização do operador do registro para alterações no banco de dados da IANA para registros do DNS e do RDDS (WHOIS), no caso de uma emergência.

    Depois que o operador do registro estiver pronto para retomar as operações e tiver remediado todos os problemas que possam ter resultado na violação, ele poderá iniciar o Processo de Transição de Registro com sucessor proposto para retomar o controle das operações do gTLD. Essa opção estará disponível para o operador do registro até a data final do período de remediação estipulado para a violação. O operador do registro se identificará como o sucessor proposto nesse processo.

    A ICANN manterá, pelo menos, dois operadores de registro de back-end para emergências (operadores para emergências) com contrato firmado. Um processo de RFP de operador de emergência será emitido a cada cinco anos a fim de renovar os contratos e/ou identificar e selecionar novos operadores de emergência. Os operadores de emergência selecionados serão de diversas regiões geográficas com a finalidade de aumentar a confiabilidade dos operadores de emergência como um todo. Se ocorrer uma catástrofe natural em uma região que afete a capacidade de um operador de emergência para executar suas funções, o outro estará pronto para assumi-las. Os requisitos básicos de elegibilidade dos operadores de emergência são: ter pelo menos três anos de experiência na operação do DNS e um de experiência na operação do RDSS (por exemplo, WHOIS) e serviços de EPP.

    A ICANN selecionará os operadores de emergência com base no valor, ou seja, a melhor combinação de serviço e preço. Os fundos para usar os serviços do operador de emergência em cada caso serão retirados dos respectivos Instrumentos de Operações Contínuas exigidos dos operadores de registros de novos gTLDs, conforme estabelecido na Especificação 8 do Contrato de Registro.

    Os candidatos a operador de emergência serão avaliados usando processos semelhantes para os novos gTLDs, incluindo testes de pré-delegação na infraestrutura que será usada em caso de emergência. A infraestrutura deverá estar pronta para operar durante a avaliação. A ICANN poderá exigir que os recursos do operador de emergência, bem como seu preparo para aceitar e agir em uma situação emergencial, sejam testados periodicamente.

    Assim que a ICANN selecionar os operadores de emergência, ela entregará um Contrato Entre Registro e Registrador básico para todos os registradores, que permitirá aos operadores de emergência executar as funções de SRS durante um processo de transição temporária. É recomendado que os registradores entrem em contato com os operadores de emergência antes da ocorrência de qualquer emergência para que eles estejam prontos para assumir as operações (para, por exemplo, firmar um contrato, garantir que as credenciais de acesso ao SRS tenham sido distribuídas, realizar os testes operacionais com os operadores de emergência etc.) caso ocorra uma transição emergencial de um determinado gTLD.

    Quando ocorrer uma emergência e os serviços do operador de emergência forem necessários, a ICANN entrará em contato com um dos operadores de emergência. Se o prestador selecionado não for capaz de assumir a operação ou se houver um conflito de interesse, a ICANN entrará em contato com outro prestador de serviço. Um operador de emergência ativo poderá se candidatar para se tornar o registro sucessor definitivo ou o operador de back-end do gTLD, caso ocorra uma Transição de Registro, de acordo com as regras normais da RFP. Para que seja realizado um processo de seleção equilibrado, um operador de emergência ativo fornecerá as informações operacionais para a ICANN que deverão estar incluídas em uma RFP para a operação do gTLD.

    Existem muitos casos em que o atual operador de registro de back-end poderá atuar como o operador de emergência, ou seja, se:

    • o operador do registro solicitar à ICANN uma transição de emergência para o operador de registro de back-end como o operador de emergência;
    • o atual operador de registro de back-end estiver operando as funções essenciais de acordo com os termos dos níveis de serviço definidos no Contrato de Registro.
    • a empresa do operador de registro de back-end não estiver relacionada nem afiliada ao operador do registro, e
    • o operador do registro de back-end aceitar operar o gTLD de acordo com os termos aprimorados ou iguais aos que foram acordados pelo Operadores de emergência.

    Em seguida, a ICANN, a seu próprio critério, poderá se oferecer ao operador de registro de back-end para executar as funções de registro do gTLD. Nesse caso, o operador de registro de back-end atuando como o operador de emergência será pago com base nos procedimentos dispostos no Instrumento de Operações Contínuas.

    Os operadores de emergência terão SLRs (Service Level Requirements, Requisitos de Nível de Serviço) para a ativação de cada uma das funções essenciais, da seguinte maneira.

    Função crítica Requisito do nível de serviço
    DNS/DNSSEC 4 horas após a solicitação da ICANN
    RDDS 24 horas após o recebimento dos dados
    SRS (EPP)* 72 horas após o recebimento dos dados
    Depósito de dados 24 horas após o início da operação do SRS

    *Os servidores de SRS precisam estar prontos para aceitar solicitações dos registradores.

    Os operadores de emergência manterão em arquivo, pelo menos, os arquivos de zona diários de todos os gTLDs a fim de permitir que o operador de emergência selecionado possa retomar rapidamente o serviço do DNS em caso de emergência. No caso das outras funções essenciais, os dados serão obtidos com o atual registro e/ou depósitos de dados.

    Os agentes de depósitos de dados dos novos gTLDs deverão concordar com o requisito para a liberação dos dados de gTLDs em até 24 horas mediante uma solicitação em caso de emergência.

    Durante a operação emergencial das funções essenciais para um gTLD, o operador de emergência não cobrará dos registradores pelas operações do SRS.

    Normalmente, o operador de emergência não aceitará a criação, renovações, transferências nem exclusões de nomes de domínio dos registradores. No entanto, em certos casos excepcionais, essas operações serão aceitas, por exemplo, de acordo com a Solicitação Expressa de Segurança no Registro 5, UDRP ou qualquer outro procedimento de resolução de disputas de nome de domínio da ICANN. As transferências de domínios em lote poderão ser aprovadas pela ICANN para domínios patrocinados por registradores que não prestam mais serviços a eles (por exemplo, no caso de registradores que perderam o credenciamento). O operador de emergência não executará a expiração de registros nem a renovação automática deles e incluirá no resultado do RDDS (por exemplo, WHOIS) uma breve explicação (aprovada pela ICANN) antes dos avisos legais (se houver), conforme descrito na seção 1.1 da Especificação 4 do Contrato de Registro, do motivo pelo qual a data de expiração já ter passado. As demais operações de SRS padrão do nome de domínio, contato e host (RFC 5730-34, 5910) serão permitidas. O operador de emergência trabalhará com todos os registradores credenciados que tenham domínios patrocinados no gTLD.

    Um registro sucessor poderá cobrar renovações ou renovações fracionadas a partir da data de início de suas operações. O registro sucessor herdará as taxas do registro que apresentou falha e deverá seguir o processo definido no Contrato de Registro para alterá-las.

    O Anexo 4 contém um fluxograma do processo que deverá ser seguido em caso de emergência.

    Durante a transição de um operador de emergência de volta para o operador de registro anterior ou para um novo operador de registro, o operador de emergência será colaborativo e cooperará com o novo operador a fim de que seja realizada uma transição tranquila com o mínimo de impacto nos registrantes e nos usuários do gTLD.

    A ICANN será responsável pelo monitoramento e a documentação dos processos de transição emergencial quando ou se eles ocorrerem. Serão desenvolvidas métricas, incluindo o desempenho do operador do registro e do EBERO quanto às cinco funções essenciais. A ICANN observará o que funcionou bem e o que pode ser melhorado a fim de propor modificações a esse processo.



1 ICANN. (2009, September 30). Affirmation of Commitments. Retrieved from http://www.icann.org/en/documents/affirmation-of-commitments-30sep09-en.htm

2 ICANN. (2009, September 30). ICANN bylaws. Retrieved from http://www.icann.org/en/general/bylaws.htm#I

3 ICANN. (2006, June 22). 2006-2007 ICANN Operating Plan. Retrieved from http://www.icann.org/announcements/operating-plan-22jun06.htm

4 ICANN. (2009). gTLD Registry Continuity. Retrieved from http://www.icann.org/en/registries/continuity/

5 http://icann.org/en/registries/ersr/

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