Resumo

  • O crescimento dos novos gTLDs, carteiras com centenas de domínios e atualizações frequentes de DNSSEC mudaram o volume e o tipo de trabalho que o RZMS precisava atender.
  • A reconstrução trouxe limiares de aprovação por tipo de solicitação, pedidos simultâneos, uma API e verificações técnicas independentes; cada gestor de TLD continuou responsável por regras adequadas e continuidade das contas.

Análise

Mais solicitações mudaram o formato do trabalho

O RZMS anterior não havia falhado. Ele já automatizava etapas, melhorava a precisão e reduzia o tempo de processamento, além de oferecer aos gestores de TLD um portal de autosserviço para tarefas comuns. A pressão veio de outra carga: o programa de novos gTLDs ampliou o número de delegações, algumas organizações passaram a administrar centenas de domínios e as atualizações de chaves de assinatura DNSSEC se tornaram mais frequentes.

Em maio de 2022, Davies disse que a equipe de Engenharia e TI da ICANN decidiu reconstruir a plataforma com uma arquitetura modular. Uma pequena equipe multidisciplinar conduziu o projeto por vários anos. O relato descreve as escolhas e o contexto operacional; não diz que ele desenvolveu o sistema sozinho. A questão era absorver novos padrões de solicitação sem prender cada mudança a um fluxo rígido.

Crescimento exigiu uma plataforma mais flexível

O sistema mais antigo já havia automatizado etapas do processo, melhorado a precisão e reduzido o tempo de tratamento. Também oferecia um portal de autosserviço para ações frequentes. Com o crescimento de novos gTLDs, porém, algumas organizações passaram a administrar centenas de domínios, e atualizações mais frequentes de chaves DNSSEC criaram novos padrões de solicitação. A arquitetura anterior começou a limitar a evolução do serviço.

Davies atribuiu a decisão de reconstruir a plataforma à equipe de Engenharia e TI da ICANN e ao trabalho de um grupo multidisciplinar. Esse relato credita o projeto à equipe, em vez de apresentar o executivo como programador individual. O changelog da IANA registra que a primeira versão renovada permitia mais de dois aprovadores, limiares diferentes por tipo de pedido e uma API para operações programáticas. Também passou a suportar solicitações simultâneas. A checagem de conformidade técnica foi separada da interface de gestão, para que as duas frentes pudessem ser aperfeiçoadas sem depender uma da outra.

O limite institucional continua relevante. A IANA atribui a si funções como designar gestores de TLD, registrar dados técnicos de delegação e publicar um registro. Sua visão geral da zona raiz distingue o Root Zone Database, que lista gestores, detalhes técnicos e contatos, do arquivo de dados DNS da zona raiz. Uma autorização interna permite que uma solicitação siga adiante; não substitui a análise nem torna o aprovador dono do domínio.

A segurança evoluiu em etapas

MFA não foi obrigatória no lançamento de 2022. Davies disse que a ferramenta precisava funcionar para usuários de qualquer país e para clientes que poderiam ficar anos sem acessar o sistema. A recuperação importa porque o acesso de um representante pode se tornar necessário precisamente quando um dispositivo ou uma credencial já não está disponível.

O estudo do processo de atualização da zona raiz publicado em 2022 registrou opiniões distintas. Entre seus respondentes, 82% consideravam suficientes as proteções existentes; 18% apontaram fragilidades potenciais, e alguns sugeriram MFA. Esses números descrevem a pesquisa e seu momento, não todo o universo de gestores nem a situação atual. O estudo também tratou do princípio então vigente de que solicitações podiam ser iniciadas por pessoas além de contatos formalmente designados. Davies citou esse contexto ao explicar por que uma exigência geral de MFA foi adiada.

Em janeiro de 2025, ele anunciou MFA e verificação de identidade como recursos opcionais. A orientação atual da IANA, revisada em julho de 2026, exige verificação para ativar MFA ou usar a API, mas não para as demais funções do RZMS. A API só executa ações permitidas para aquele usuário; o ambiente OTE serve para testar integrações sem alterar a produção, segundo o guia oficial.

A identidade também envolve dados. Um fornecedor externo retém as imagens do documento e da selfie por até sete dias. A IANA mantém nome legal, data de nascimento e resultado da validação enquanto a conta estiver ativa. O mecanismo pode ajudar a recuperar o acesso após a perda do autenticador, mas deve ser entendido como uma troca entre recuperação, segurança e privacidade.

A escala também transfere responsabilidades ao gestor

Limiares configuráveis e solicitações simultâneas tornam o serviço mais adaptável, mas o software não escolhe uma política de aprovação adequada para cada organização. O gestor de TLD precisa manter sua lista de representantes atualizada, decidir quantas pessoas aprovam cada tipo de pedido e prever a recuperação de contas usadas apenas de tempos em tempos. Poucos aprovadores criam um gargalo de continuidade; exigir muitos pode atrasar a manutenção de rotina.

A API amplia o controle para fluxos programáticos, mas continua sujeita às permissões do usuário. O ambiente Operational Test and Evaluation da IANA permite testar integrações antes da produção. As verificações de conformidade técnica também são separadas da autorização: uma configuração tecnicamente válida não aprova uma solicitação, e uma aprovação não substitui análise ou implementação.

O RZMS é apenas uma parte da gestão da zona raiz. A IANA designa gestores de TLD, registra dados técnicos de delegação e publica o Root Zone Database, distinto do arquivo DNS da zona raiz. O changelog de junho de 2026 lista a versão 3.6.1. A contribuição duradoura da reconstrução é um fluxo de trabalho adaptável, não a garantia de que cada organização o configurará bem. O resultado depende de as regras locais, a recuperação de contas e os testes técnicos acompanharem a carga real.

Fontes