Resumo

  • Na futura Governance Phase, a função Security Incident Reporting poderia suspender as operações de um RSO quando, em situação extrema, o descumprimento representasse ameaça significativa ao RSS. A autoridade só surgiria depois de onze marcos, avaliação pública, consulta e voto formal; o registro consultado não mostra que isso já ocorreu.
  • A remoção definitiva pertence a DNR, que investiga, oferece oportunidades de correção, recomenda a decisão ao Council e coordena a retirada ordenada das fontes DNS descritas no RSSAC030. O modelo não define se a suspensão de SIR alcança essas fontes, qual é o prazo, que efeito tem um recurso ou quem autoriza a volta.
  • Antes do Milestone 12, o Council deveria aprovar um comprovante versionado de suspensão e retorno, com autoridade, escopo, relógio, correção, recurso e desfecho na camada pública, deixando detalhes que possam favorecer ataques em anexo protegido.

O problema não é ter uma medida de emergência

Uma estrutura responsável pela segurança de uma infraestrutura crítica não pode depender apenas de pedidos voluntários. Se identifica uma vulnerabilidade material, solicita correção e encontra resistência enquanto a ameaça cresce, precisa de alguma forma de contenção.

O relatório final do RSS Governance Working Group reconhece esse problema. Em uma fase plenamente habilitada, SIR poderia abrir investigações, exigir dados e cooperação, determinar melhorias de segurança, impor medidas corretivas e autorizar ações emergenciais. No limite, poderia suspender as operações de um Root Server Operator quando o descumprimento produzisse ameaça significativa ao Root Server System.

É uma hipótese estreita: caso extremo, não conformidade e ameaça significativa. O texto não cria um poder geral de licenciamento.

Mesmo assim, a consequência não foi especificada. “Suspender operações” pode significar congelar o status do operador dentro da nova governança, limitar uma obrigação, isolar determinada infraestrutura, restringir instâncias ou interferir no modo como o serviço aparece nas fontes da raiz. Cada leitura tem efeitos diferentes para o operador, IANA, os demais RSO, resolvedores e usuários.

O relatório também não define reintegração, retorno ou restabelecimento. Há investigação, correção, recurso e uma trilha separada para remoção. Falta o ato que transforma correção técnica em mudança formal de status.

Não há evidência de que algum RSO atual esteja sujeito a essa medida. A questão é anterior: o poder proposto não deveria ser ativado sem uma saída verificável.

O futuro condicional importa

O modelo tem três fases, e essa arquitetura impede atribuir o poder a instituições atuais.

Initiation formaria Council e Secretariat com escopo limitado. Establishment criaria as funções, suas cartas, políticas de segurança, critérios de desempenho, financiamento, processos de designação e remoção, devido processo e recursos. Governance seria a fase de exercício pleno.

A transição depende de requisitos concretos. Todas as funções precisam existir e operar. As políticas centrais devem ser ratificadas. A conclusão dos Milestones 1–11 precisa constar de avaliação abrangente e pública. Deve haver consulta antes do voto, participação das comunidades interessadas e decisão formal do Council. Somente então o Milestone 12 habilita a estrutura.

O histórico público examinado mostra a entrega do relatório, não a execução desse roteiro. O GWG aprovou o texto por consenso em 18 de fevereiro de 2026 e o apresentou ao Board da ICANN e às demais partes em 20 de fevereiro. A presidente do Board agradeceu e mencionou o caminho adiante. Não anunciou adoção. O planejamento operacional da ICANN falava em adoção esperada e subordinava passos posteriores a decisão e priorização.

Por isso, a forma precisa é “o modelo permitiria”. Nem o Board atual, nem RSSAC, IANA ou RZM recebem automaticamente essa competência pelo simples fato de o relatório existir.

SIR e DNR não decidem a mesma coisa

A função de SIR tem origem no incidente. Seu objeto é reportar, entender e mitigar uma ameaça à disponibilidade, integridade ou confidencialidade da raiz. A informação pode chegar incompleta e a resposta pode precisar começar imediatamente.

Designation and Removal, ou DNR, tem outro objeto: o status duradouro do operador. Investiga problemas de desempenho ou descumprimento, estabelece medidas e prazos de remediação e somente recomenda remoção depois de oportunidades suficientes de correção. O Council dá a aprovação final. DNR então coordena o desligamento ordenado e a retirada das fontes DNS, mantendo comunicação crítica com IANA.

Essa divisão evita dois erros. O primeiro seria aguardar um processo de remoção enquanto uma ameaça urgente permanece. O segundo seria transformar uma ação urgente em decisão permanente sem devido processo.

No entanto, a separação cria uma passagem que precisa de custódia. Uma suspensão de SIR pode terminar por correção, provimento de recurso, redução da medida ou abertura de caso em DNR. O modelo não indica qual documento transfere o caso, quem mantém o estado intermediário ou qual autoridade encerra a suspensão.

“Remediação concluída” não deve atualizar silenciosamente “status restaurado”. O primeiro é um fato comprovável; o segundo é uma decisão. O sistema precisa dos dois e da ligação entre eles.

Três camadas que não podem ser confundidas

O RSSAC030 descreve as três fontes por meio das quais as informações dos servidores raiz chegam ao sistema comum: o arquivo root hints, a zona raiz e a zona root-servers.net. O operador das funções IANA mantém essas fontes. Elas ligam nomes do serviço a endereços IPv4 e IPv6 controlados pelos RSO. A inclusão da organização identifica sua condição de operador.

O modelo cita o RSSAC030 no escopo de DNR. A remoção permanente envolve coordenar o desligamento e retirar o RSO dessas fontes. A seção de SIR não diz isso.

Daí surgem três camadas independentes. A camada de governança registra o status suspenso. A camada operacional registra que serviços, instâncias ou sistemas foram limitados. A camada das fontes registra se IANA alterou qualquer uma das três referências.

Uma sanção de governança não é automaticamente uma retirada das fontes. Isolar um componente durante um incidente não equivale a remover a organização. E alterar uma fonte sob o rótulo de suspensão não deveria antecipar a decisão que o próprio modelo reserva a DNR e ao Council.

O procedimento pode permitir diferentes combinações conforme a emergência. Mas precisa nomeá-las. Também precisa indicar a autoridade separada e a reversão de qualquer ação sobre as fontes.

O recurso precisa de um estado provisório

O modelo autoriza recursos de decisões de SIR perante o Council. As decisões de DNR também podem ser recorridas diretamente, e a remoção depende de aprovação final. SIR ainda deve publicar relatórios, usar revisão por pares e passar por avaliações externas periódicas.

Nada disso define, sozinho, o que acontece enquanto o recurso tramita.

O protocolo precisa dizer se a apresentação suspende a execução, se o Council pode conceder uma medida provisória, se partes não afetadas do serviço continuam e se a vitória no recurso restaura imediatamente todas as condições anteriores. Em um caso originado por vulnerabilidade, uma decisão jurídica ou de governança pode precisar ser seguida de teste técnico antes da volta.

A proteção do sistema trabalha em minutos. O contraditório e a avaliação de documentos trabalham em dias. Não é necessário escolher um relógio. É necessário registrar três: contenção imediata, condição provisória durante a revisão e decisão final.

Sem isso, uma pessoa pode considerar o RSO suspenso, outra pode entender que o recurso paralisou a medida e uma terceira pode executar uma alteração técnica sem saber qual estado institucional deveria produzir.

A camada pública pode ser pequena

O RSSAC062 recomenda formalizar o relato de incidentes, mas preserva uma regra operacional básica: relatar não pode atrapalhar a mitigação, e a resolução do incidente vem primeiro.

O documento permite proteger detalhes pelo Traffic Light Protocol, exige canais autenticados e confidenciais e manda excluir o que possa facilitar novo ataque. Também prevê uma versão pública TLP:Clear em tempo adequado.

O comprovante de suspensão e retorno não precisa ser maior do que essa fronteira. O público pode conhecer autoridade, classe geral do gatilho, alcance, data, próxima revisão e resultado. O anexo reservado guarda chaves, topologia, logs, vulnerabilidades e provas forenses.

É possível registrar o custodiante do anexo, o nível de acesso e uma trilha de integridade sem revelar o conteúdo. A transparência fiscaliza a duração e o uso do poder; não publica um manual de exploração.

A defesa do modelo é válida, mas incompleta

O modelo pode alegar, com razão, que os detalhes pertencem à fase de Establishment. As pessoas que escreverem as cartas de SIR e DNR terão condições melhores de integrar autonomia operacional, resposta a incidentes, proteção de provas e coordenação com IANA.

Também há salvaguardas reais: o limiar extremo, funções distintas, recursos ao Council, oportunidades de correção antes da remoção, revisão por pares, avaliação externa, relatório anual e consulta pública antes do pleno poder.

A diversidade do RSS reforça a justificativa de contenção. Em algumas circunstâncias, limitar temporariamente um elemento pode proteger a disponibilidade coletiva. Um sistema sem essa opção também pode ser frágil.

Essas razões levam ao mesmo ponto: a saída precisa ser requisito de ativação. Milestone 7 trata de segurança, resposta e escalonamento. Milestone 8 trata de designação, remoção, devido processo e recurso. Milestone 10 trata de responsabilização e revisões adicionais. A avaliação dos onze primeiros marcos deve demonstrar que os três blocos formam uma sequência única.

A ideia de Running-Code Primacy, de Heng Lu, ajuda a limitar o significado institucional. Uma declaração deve corresponder a um efeito técnico mínimo e verificável. Se “suspenso” produzir interpretações incompatíveis entre SIR, o operador e IANA, a autoridade simbólica não virou estado operacional confiável.

Sua distinção sobre continuidade também é pertinente quando usada com cuidado. O objetivo é proteger serviço, registros, cadeia de segurança e usuários, não preservar automaticamente cada poder da instituição ou cada posição do operador. Uma suspensão pode proteger o conjunto. Um retorno ou uma remoção explícita impede que a própria medida vire risco de continuidade.

Um comprovante versionado de suspensão e retorno

O Council deveria exigir um registro comum antes de Milestone 12. Ele seria aberto com poucos campos no instante da ação e completado à medida que os fatos se estabilizam, sem atrasar a mitigação.

O registro público deveria mostrar:

  • identificador estável do caso e do RSO;
  • função, base de autoridade, versão da política e papel responsável;
  • classe não sensível do gatilho e uso de procedimento emergencial;
  • alcance sobre status, obrigação de serviço, infraestrutura e fontes;
  • início, duração inicial máxima e revisão obrigatória;
  • medidas para manter a continuidade coletiva do RSS;
  • correções e seu estado público de conclusão;
  • custódia e classificação da prova reservada;
  • recurso, pedido de suspensão cautelar e decisão correspondente;
  • autoridade, critérios e teste técnico para retorno;
  • revisão independente ou por pares;
  • cada prorrogação, com nova decisão e motivo;
  • desfecho: restaurado, reduzido, substituído ou remetido a DNR;
  • ação separada de IANA ou RZM e seu estado de reversão.

Os termos não podem ser atalhos. Recurso interposto não significa execução suspensa. Correção concluída não significa retorno autorizado. Remessa a DNR não significa remoção aprovada. Remoção aprovada não significa fontes alteradas.

Até os nulos precisam ser explícitos: nenhuma ação nas fontes, nenhum recurso, decisão de retorno pendente. Um campo vazio entrega a interpretação a quem lembrar da conversa.

O comprovante não dá veto ao RSO, não transfere a resposta ao público e não revela o ataque. Ele apenas impede que uma medida provisória exista sem autoridade, alcance, prazo e estado terminal.

Limites da evidência

As fontes analisadas não demonstram adoção formal pelo Board, transição para Governance Phase ou suspensão de qualquer RSO segundo o modelo. Tampouco permitem avaliar um operador atual como inseguro ou descumpridor.

A ausência de uma palavra de reintegração não prova que os futuros procedimentos não possam criá-la. Mostra que devem criá-la antes da habilitação. Como “suspender operações” não tem objeto técnico definido, o Artigo não afirma que a medida alteraria necessariamente root hints, zona raiz ou root-servers.net.

A proposta publica estado e autoridade. Evidência que possa favorecer ataque ou expor informação operacional legitimamente sigilosa pode permanecer protegida.

Fontes

  1. ICANN — The Root Server System Governance Structure, 18 de fevereiro de 2026
  2. ICANN — Governance Principles for the Root Server System
  3. Brad Verd — entrega do relatório final do GWG
  4. Tripti Sinha — resposta da presidência do Board
  5. ICANN Public Comment — Functional Model for Root Server System Governance
  6. RSSAC030 — Statement on Entries in DNS Root Sources
  7. RSSAC058 — Success Criteria for the RSS Governance Structure
  8. RSSAC062 — Security Incident Reporting
  9. RSSAC055 — Principles Guiding the Operation of the Public Root Server System
  10. ICANN — projeto de plano operacional e financeiro FY2027–2031
  11. Heng Lu — Running-Code Primacy
  12. Heng Lu — The Registry Continuity Fallacy
  13. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile