Resumo

  • O grupo técnico de ICANN descreve um caso em que o nome DNS deixa de resolver, mas o mesmo nome em um sistema alternativo continua ativo. Isso depende das regras desse sistema e da decisão do titular de conservá-lo.
  • A regra de mesma cadeia e mesmo controlador só vale ao longo do tempo se o serviço disser quem pode iniciar cada mudança, como os sistemas confirmam sua conclusão e o que ocorre enquanto houver uma resposta pendente.

O cadastro vence; a decisão continua

Uma data de vencimento parece simples até que o mesmo nome apareça em dois sistemas. Suponha que o titular não renove exemplo.tld no DNS, mas mantenha o nome equivalente em uma rede alternativa. O relatório preliminar do Technical Study Group (TSG) usa precisamente esse exemplo. Não se trata de um incidente real nem de uma regra universal. O nome DNS é retirado da resolução global; o nome alternativo pode permanecer ativo se o sistema aceitar essa opção e o titular quiser mantê-la.

Se o titular não quiser continuar com o nome alternativo, o relatório descreve outra sequência: desativar os nomes nos sistemas envolvidos, desfazer sua alocação e removê-los da integração. Só depois o nome fica disponível novamente. Assim, o vencimento não encerra necessariamente a identidade que os usuários ainda podem alcançar. Ele abre uma escolha sobre continuidade, controle e eventual transferência da mesma cadeia para outra pessoa.

Esse intervalo é o teste de governança. “Mesma cadeia, mesmo controlador” descreve o vínculo desejado, mas não explica quem decide durante uma renovação, uma troca de titular ou uma ordem de suspensão. Uma captura de duas fichas iguais não prova quem autorizou a alteração nem se todas as partes a receberam. A prova precisa acompanhar o fluxo, inclusive enquanto um dos sistemas ainda não respondeu.

O TSG não aprova um serviço específico

ICANN reuniu o TSG para avaliar se uma operadora de gTLD poderia associar o nome do DNS global ao mesmo nome em outro sistema sem prejudicar a segurança e a estabilidade do DNS. O documento de 10 de agosto de 2026 está marcado como rascunho. Não autoriza uma integração, não declara que todos os sistemas alternativos são equivalentes e não escolhe um único desenho. O grupo examina tanto o uso do sistema compartilhado de registro (SRS) quanto uma abordagem distribuída apoiada por uma fonte única de verdade, a USoT.

A página de consulta pública de ICANN diz que cada operadora que quiser oferecer o serviço deve passar individualmente pela Registry Services Evaluation Policy (RSEP). O relatório do TSG orientará avaliações futuras e cláusulas de contratos, mas a minuta contratual será submetida a outra consulta. O prazo para comentários terminou em 21 de setembro; a página informa 16 de novembro de 2026 como data prevista para o relatório.

Uma avaliação comum ajuda a formular perguntas técnicas recorrentes. Não comprova que uma operadora específica vê os dados mantidos pelo registrador, controla o sistema alternativo ou consegue corrigir divergências. Essas respostas devem estar na solicitação e nos termos aplicáveis ao serviço.

Um centro de comando também precisa provar o controlador

Com um SRS, as alterações podem passar pela plataforma do registro. Um único objeto de domínio associado a um titular torna o vínculo mais fácil de observar; o registro também pode coordenar a publicação dos dois nomes. Mas o TSG alerta que usar o mesmo SRS não demonstra, por si só, que o controlador é o mesmo. O operador precisa manter dados suficientes ou uma garantia contratual e técnica confiável.

Uma USoT distribui armazenamento e execução entre participantes. Isso pode evitar concentrar todos os detalhes em uma única organização, mas deixa em aberto qual estado vale enquanto uma mudança está incompleta, como os participantes recebem a atualização e quem decide se houve uma falha. Sem regras para atrasos e respostas contraditórias, “fonte única de verdade” é apenas uma descrição arquitetural.

O exemplo de mudança interna de titular esclarece a diferença. Um registrador pode atualizar o titular em seus próprios sistemas sem notificar o registro. Nesse desenho, a garantia de que os nomes seguem com o mesmo controlador depende do contrato, a menos que exista um identificador persistente ou prova equivalente. Se o nome DNS e o alternativo forem objetos distintos, ligados a controladores diferentes, o relatório cita como possível solução um comando do registro que transfira ambos juntos.

Suspensão, bloqueio e desativação também não são sinônimos. O TSG diz que a suspensão deve alcançar todos os sistemas integrados ao mesmo tempo. Para uma desativação externa, motivada por abuso ou ordem judicial, propõe desabilitar o nome em todas as redes. Já o clientHold do registrador, que pode apenas interromper a resolução DNS, não deve automaticamente desativar o nome alternativo. Cada evento precisa conservar sua causa, autoridade e consequência.

Os comentários públicos pedem uma visão verificável

A manifestação da Unregistry, hospedada no site de ICANN, apoia a conclusão técnica geral e considera os controles do lado do registro em grande medida suficientes. Sua preocupação recai sobre o usuário: o estado da integração deveria ser visível e o serviço deveria declarar como age diante de uma sincronização que não se resolve. É uma contribuição individual, não um consenso.

O Ministério de Eletrônica e Tecnologia da Informação da Índia recomenda condições mensuráveis antes da aprovação RSEP: estados de transação definidos, limites para operações pendentes, mecanismos de falha segura, plano de encerramento testado, proteção contra uma nova alocação enquanto a contraparte continua ativa e auditorias independentes. Essas são propostas apresentadas pelo Ministério, não obrigações já adotadas por ICANN.

A Intellectual Property Constituency destaca que os direitos associados aos nomes continuam sendo uma questão de política. Sincronizar registros não decide quem deveria controlar uma cadeia, como resolver uma colisão ou onde um usuário prejudicado pode contestar o resultado.

Por isso, a revisão de cada serviço precisa perguntar quem autoriza renovação, transferência, suspensão e remoção; que confirmação cada sistema envia; quanto tempo uma operação pode ficar pendente; e como se impede uma nova alocação no DNS se o nome anterior ainda funciona em outro lugar. Também precisa haver um caminho para corrigir uma divergência e rever quem tomou a decisão.

Registrar a mudança, não apenas o resultado

Uma cópia adicional do cadastro não resolve a responsabilidade. O que ajuda é uma trilha da transição: papel de quem iniciou a mudança, versão da regra aplicada, estado anterior e desejado, sistemas envolvidos, identificador da operação, confirmações recebidas, ordem ou horário dos eventos, tratamento de atrasos e caminho de notificação e revisão. O público pode ver apenas se o nome está ativo, retirado, suspenso ou pendente. Os auditores precisam conseguir reconstruir o motivo sem expor dados pessoais desnecessários.

Essa trilha é uma recomendação editorial para o desenho de serviços, não um requisito já aprovado pelo TSG. Ela responde ao fato de que o poder está dividido: o registrador conhece a relação com o cliente, o registro controla o DNS e o operador alternativo executa a outra parte. Se os estados divergirem, o titular e os usuários dependentes arcam com o efeito prático, embora possam não ter acesso a nenhum dos registros internos.

A política RSEP e as notas de implementação pedem uma descrição do serviço e de seus efeitos para usuários externos. A próxima etapa deveria transformar o princípio técnico comum em condições que possam ser testadas antes da oferta e revistas quando o serviço mudar. “Mesma cadeia, mesmo controlador” é um estado a preservar; a governança demonstra como ele sobrevive a transações, atrasos e falhas.

Fontes