Resumo

  • O grupo técnico da ICANN examina um desenho específico: a mesma cadeia em um gTLD e em um ou mais sistemas alternativos, sob o mesmo controlador e com coordenação do operador de registro.
  • O relatório recomenda exigir um plano de desligamento e conclui que a integração parece estar fora das cinco funções críticas preservadas por um Emergency Back-end Registry Operator.
  • A primeira consulta pública termina em 21 de setembro de 2026. O documento não é política final, serviço aprovado nem relato de falha de um operador.

Um serviço pode desligar sem que o poder associado ao nome seja desligado com ele.

Essa é a tensão mais importante no relatório inicial publicado em 10 de agosto pelo Technical Study Group da ICANN. O grupo não estudou todos os sistemas alternativos. Seu modelo é estreito: uma cadeia igual no DNS global e em outro ambiente de nomes, controlada pela mesma parte. O operador do registro de gTLD coordena a relação. Pode contratar componentes, mas continua responsável pela política do serviço.

Com controles operacionais adequados, o grupo entende que o modelo provavelmente não produziria problemas significativos de segurança ou estabilidade nos termos do RSEP. A formulação é condicional. O relatório não promete risco zero, não recomenda a integração em geral e não rejeita outros desenhos.

O mesmo rótulo pode guardar poderes diferentes

O texto separa os estados de um nome porque cada um produz consequências próprias. Um nome pode estar disponível, inscrito no conjunto integrado, alocado, retido, ativo, desativado, suspenso ou completamente inabilitado. “Desligado” não substitui essa taxonomia.

Interromper novas inscrições não resolve nomes existentes. Tirar a resposta do ar não diz se o nome alternativo continua alocado ao titular anterior. Remover uma entrada da interface não prova que caches, contratos, livros distribuídos e sistemas terceirizados adotaram o mesmo estado.

Se o nome DNS for transferido enquanto a identidade alternativa continua com o antigo titular, as duas tecnologias podem funcionar corretamente e a autoridade ainda assim estar quebrada. O requisito decisivo não é apenas a mesma sequência de caracteres. É a permanência do mesmo controlador ao longo de transferência, expiração, suspensão e encerramento.

O Internet-Draft ativo do DNSOP trata ciclo de vida, validação de controle, completude e sincronização como controles separados. Ele adverte que uma integração desatualizada pode permitir que alguém diferente do registrante atual controle a identidade vinculada. O documento ainda é trabalho em andamento e não é regra da ICANN, mas sua análise mostra por que a validação feita no início não prova alinhamento no fim.

A rede de segurança EBERO não cobre toda extensão

A ICANN pode ativar um Emergency Back-end Registry Operator quando um operador de gTLD corre o risco de não sustentar cinco funções críticas: resolução DNS, Shared Registration System, serviços de diretório de dados de registro, depósitos de custódia e manutenção de uma zona corretamente assinada com DNSSEC.

A integração com outro sistema de nomes não aparece nessa lista. O relatório entende que ela provavelmente não sobreviveria à operação EBERO e usa esse limite como uma razão adicional para exigir o plano de desligamento.

Isso não demonstra uma falha do EBERO. Demonstra que o mecanismo tem um mandato específico. Continuidade do registro DNS não é automaticamente continuidade de todo serviço construído em volta dele. A prontidão de um provedor EBERO para assumir as cinco funções tampouco prova capacidade para operar ou desfazer um sistema alternativo.

O plano correto ainda pode não funcionar

O grupo recomenda que a definição do serviço diga quais capacidades foram habilitadas e como serão desativadas se a integração deixar de ser viável. Enquanto não houver experiência substancial, esse “turn-down plan” deveria ser obrigatório na avaliação.

Uma política escrita pode, porém, depender de um fornecedor indisponível durante a crise, de uma credencial vencida ou de uma última ação do registrante que perdeu interesse. Pode testar apenas a suspensão de novos nomes e esquecer a situação dos existentes. Pode pressupor que DNS e sistema alternativo sempre se recuperem na ordem prevista.

Essas possibilidades não são prova de que algum operador falhará. Elas estabelecem apenas que plano e resultado pertencem a categorias de evidência diferentes.

O Registry Services Evaluation Policy é o caminho institucional para acrescentar, modificar ou retirar um serviço de registro. A ICANN avalia questões potencialmente significativas de segurança, estabilidade e concorrência. O relatório diz ainda que os requisitos técnicos mínimos não podem ser enfraquecidos só para tornar a proposta comercialmente viável; um desenho enfraquecido seria outro serviço e exigiria nova avaliação.

O mesmo rigor deve valer no teste de saída. Se a simulação deixar estados incompatíveis, a exceção precisa permanecer no registro até que o desenho seja corrigido. Redefinir o significado de conclusão depois do teste apenas esconde a dependência.

A decisão ainda está em formação

A consulta sobre o relatório inicial abriu em 10 de agosto e fecha em 21 de setembro. A carta do grupo prevê análise das contribuições, uma segunda versão e nova consulta em outubro, além de um relatório final em janeiro de 2027. São etapas previstas, não concluídas.

As fontes examinadas não estabelecem uma integração aprovada, falha de registro, operação EBERO envolvendo esse serviço ou caso real de controladores divergentes. A recomendação editorial não responde a um incidente conhecido. Ela aproveita a fase de desenho para decidir qual prova será necessária antes de um incidente tornar a reconstrução cara ou impossível.

Fontes