Resumo

  • A ICANN recebe comentários de 10 de agosto a 21 de setembro de 2026 sobre o relatório inicial do Technical Study Group para integrar gTLDs do DNS global a sistemas de nomes alternativos.
  • A regra central é a integração de “cadeia + controlador”: nome e controlador devem coincidir em todos os sistemas, por um registro compartilhado ou por uma fonte de verdade unificada mesmo quando a operação é distribuída.
  • O texto não endossa a integração. Cada operador continuará sujeito à aprovação individual pelo RSEP ou pelo processo da rodada de 2026, e as cláusulas contratuais propostas passarão por outra consulta.
  • Uma consequência relevante ficou fora do escopo técnico: nomes já existentes no sistema alternativo podem obrigar a reserva das cadeias correspondentes no DNS, ainda que nunca sejam ativadas ali.

Uma consulta sobre a condição de entrada

O anúncio de 11 de agosto pode soar como uma decisão de conectar o DNS a nomes em blockchain. O trabalho é mais estreito. Desde 2022, operadores de registros existentes e possíveis candidatos à próxima rodada de gTLDs perguntam à ICANN se podem associar uma cadeia do DNS global à mesma cadeia em outro sistema de nomes. O grupo técnico foi criado para analisar, uma única vez, as perguntas comuns a essa classe de serviço.

Não entram no estudo todas as identidades de carteira, nomes de usuário, raízes privadas ou espaços alternativos. O caso é o de um operador de gTLD que controla a mesma cadeia no DNS e em um ou mais sistemas alternativos, sob o mesmo comando institucional.

Também não há licença geral. O documento de 39 páginas, datado de 10 de agosto, está marcado como rascunho. A consulta o chama de relatório inicial. A pergunta é preliminar dentro da Registry Services Evaluation Policy: esse modelo limitado pode operar sem risco inaceitável à segurança e à estabilidade, e quais requisitos precisa cumprir?

O TSG responde de forma condicionalmente positiva. Considera improvável um risco significativo, no sentido do RSEP, quando o mesmo nome permanece com o mesmo controlador e os controles operacionais são efetivos. O próprio relatório avisa que não prefere esse mecanismo, não rejeita outros e nem sequer endossa a ideia de integração. Viabilidade e consentimento institucional continuam separados.

O invariante é o controle, não a blockchain

O modelo recebe o nome de “string+controller integration”. A cadeia deve ser idêntica e permanecer sob a mesma parte em todos os sistemas; onde não for usada, precisa ficar reservada exclusivamente para essa parte. Se o desenho não sustentar as duas condições, não cabe nessa categoria de integração.

A regra alcança os nomes abaixo do TLD. Alocação, transferência, suspensão e desativação não podem produzir controladores incompatíveis para o que o usuário percebe como o mesmo nome. Em nomes internacionalizados, variantes e Label Generation Rules devem ser processadas antes da integração, pois normalizações divergentes tornariam “igual” uma promessa pouco confiável.

O relatório apresenta duas arquiteturas. A primeira usa o Shared Registration System como porta comum de inscrição. Os sistemas alternativos ficam ligados à infraestrutura tradicional de registro, registrador e titular. Seriam necessárias extensões de EPP para alterar o novo estado e de RDAP para consultar os dados adicionais.

A segunda arquitetura permite distribuir bancos e operadores, desde que exista uma fonte de verdade unificada como propriedade lógica. Nenhum componente pode concluir uma mudança que rompa a relação entre cadeia e controlador. Carteira, identificador persistente ou prova criptográfica podem confirmar o controle. Quando o assentamento do outro sistema é lento, uma operação DNS talvez precise ficar pendente.

O candidato deve provar mais do que a disposição de sincronizar: os participantes não podem quebrar a integração sem instrução ou aprovação do controlador. A infraestrutura distribuída, portanto, não pulveriza a responsabilidade. Mesmo com fornecedores diferentes, o operador do registro continua sendo a pessoa jurídica responsável pelo conjunto.

A primeira colisão de política já está no texto

O desenho altera a disponibilidade quando o sistema alternativo já possui nomes. Para preservar o controlador único, essas cadeias precisam entrar no estado integrado e, no mínimo, ser retidas no DNS, mesmo que nunca sejam publicadas em uma zona DNS. Sem isso, outra parte poderia receber a cadeia equivalente.

O relatório reconhece que a consequência técnica pode gerar implicações de política e as deixa fora do escopo. É exatamente aí que a proteção da unicidade toca a distribuição de direitos. A reserva evita controles contraditórios, mas também retira um nome da oferta do DNS. Uma inscrição no DNS pode limitar o sistema alternativo no sentido inverso.

A especificação não decide qual anterioridade prevalece, como avisar quem perde a disponibilidade, quem paga por uma reserva defensiva, como corrigir uma prova errada ou a quem recorrer quando os históricos divergem. A capacidade de manter bases sincronizadas não cria, por si só, autoridade para resolver essas questões.

Os Estatutos da ICANN oferecem um limite. A organização coordena aquilo que é razoavelmente necessário à abertura, interoperabilidade, resiliência, segurança ou estabilidade do DNS. O relatório também afirma que a ICANN não é responsável por todo sistema de nomes conectado à Internet e não precisa avançar além do ponto em que ele interfere no sistema global.

O princípio de coordenação fina de Lu Heng ajuda a aplicar a fronteira. Unicidade, prova de controle, estado auditável e continuidade podem integrar uma camada comum. Prioridade comercial entre reivindicações anteriores, uso do nome e valor econômico não viram poderes técnicos porque a integração os expôs. Impedir dois controladores pode justificar uma negativa estreita. Consequências maiores precisam de decisor identificado, participação dos principais afetados, razões e revisão.

Aprovação continuará individual e contratual

A consulta não cria autorização automática. Cada operador deverá seguir o RSEP ou o caminho aplicável da rodada de 2026. O RSEP considera segurança, estabilidade e concorrência. O relatório comum reduz a repetição onerosa da mesma análise básica; não elimina o exame da implementação concreta.

O contrato também não está pronto. A ICANN org acompanha o TSG para redigir emendas aos acordos de registro. A página da consulta prevê que o relatório final preliminar e a linguagem contratual sejam publicados juntos em uma etapa posterior. O estatuto do grupo aponta para uma segunda consulta e a versão final em janeiro de 2027. Padrões de prova, frequência de monitoramento, prazos de correção, medidas de cumprimento e recurso permanecem abertos.

A saída importa tanto quanto a entrada. O relatório recomenda um plano obrigatório de desligamento da integração. Observa ainda que o serviço parece ficar fora das funções críticas mantidas pelo Emergency Back-End Registry Operator. Se um registro falhar e entrar em EBERO, o DNS pode continuar enquanto a parte alternativa deixa de operar.

Um serviço vendido como o mesmo nome em vários sistemas pode se partir no momento da falha institucional. A solicitação deve explicar qual estado sobrevive, como dados desatualizados serão neutralizados, o que o titular mantém e como o usuário será informado. Identidade é uma promessa durante todo o ciclo de vida, não um rótulo de lançamento.

Quatro atos que não podem virar um só

A consulta atual pode testar provas de controlador, sincronização, assentamento distribuído, IDNs, RDAP, transferências, suspensão, EBERO e encerramento. Contribuições úteis apontarão uma rota concreta de quebra, em vez de apenas defender ou atacar nomes em blockchain.

A etapa contratual deve separar quatro atos: o TSG conclui que um desenho pode ser seguro; a ICANN aprova ou rejeita um serviço específico; o contrato cria poderes de monitoramento e execução; e uma política decide o destino de nomes ou titulares afetados. Cada ato tem fundamento, decisor e recurso próprios.

O mérito do relatório inicial é trocar a metáfora de uma “ponte” por um invariante operacional, uma entidade jurídica responsável e um problema de desligamento. Sua legitimidade depende de preservar esse limite. A viabilidade técnica abre a avaliação; não decide quem controla a porta.

Fontes