Resumo

  • Em 13 de novembro de 2025, a ARIN bloqueou administrativamente todo o acesso aos repositórios Hosted e RPS entre 13h30 e 14h30 EST. Às 14h35 confirmou redundância plena e às 14h50 informou o retorno ao nível anterior ao teste.
  • O exercício demonstra recuperação após perda de acesso ao repositório. O registro público não identifica classes de dependência externa, domínios comuns, relações circulares ou o conjunto de observação levantado pela sugestão ACSP 2025.7.
  • Uma declaração versionada por serviço e domínio de falha pode registrar o plano protegido, o limite do teste, os marcos, as premissas restantes e o gatilho de notificação sem revelar uma topologia útil a atacantes.

O ponto mais revelador não é a palavra “failover”. É a proximidade de quatro datas que precisam continuar separadas.

Em 23 de outubro de 2025, a ARIN recebeu de um cliente um relato sobre o Hosted RPKI após implantar o suporte a ROAs em transferências. O relatório público de 27 de outubro restringe o problema a uma condição específica de configuração e a um cliente. A ARIN interrompeu transferências em andamento, localizou um defeito de código, aplicou uma correção e acrescentou validações.

Em 28 de outubro, Ramakant Pandrangi apresentou a sugestão 2025.7. O pedido ia além de um erro de software: queria dependências descritas serviço a serviço, aviso prévio de mudanças operacionais ou arquitetônicas relevantes e objetivos de continuidade, inclusive RTO e RPO. O texto mencionava DNS, CDN, endereços IP, rotas BGP, provedores e dependências sistêmicas ou circulares.

Em 12 de novembro, a ARIN respondeu que preparava um plano para documentar dependências, esclarecer a gestão de mudanças e expor objetivos de resiliência e continuidade, com posterior consulta à comunidade. No dia seguinte, realizou o exercício de failover em produção.

O incidente, a sugestão e o teste não são três versões da mesma história. O primeiro trata de uma mudança de software. A segunda pergunta de que condições os serviços dependem. O terceiro verifica a recuperação diante de uma interrupção definida.

O que cinco horários conseguem provar

O aviso arquivado na lista técnica informa que, às 13h EST, a ARIN começou a restringir o acesso aos sites que atendiam os repositórios Hosted e RPS. Às 13h30, bloqueou todo o acesso para simular indisponibilidade completa. Às 14h30, restaurou o acesso. Cinco minutos depois, confirmou redundância plena; às 14h50, informou que o sistema voltara aos níveis anteriores.

A ARIN também explicou a escolha de produção: um ambiente de teste não representaria de modo fiel o desempenho e a preparação para falhas do repositório. Isso transforma “alta disponibilidade” em evidência datada. Há um serviço nomeado, uma intervenção e uma sequência de recuperação.

O limite também deve ser preservado. Um bloqueio administrativo simula falta de acesso, mas não revela se as rotas de recuperação compartilham DNS, CDN, trânsito, instalação, energia ou identidade. O aviso não especifica qual domínio físico ou lógico foi removido por trás do bloqueio. Também não lista validadores externos usados na confirmação nem mede qualquer efeito de roteamento.

Essas ausências não anulam o exercício. Apenas impedem que seu resultado seja estendido a todas as dependências possíveis.

Redundância não é sinônimo de independência

Uma dependência circular aparece quando duas saídas aparentemente distintas precisam da mesma condição para funcionar. Dois servidores podem estar separados e ainda depender do mesmo sistema de nomes. Mas o simples uso de um fornecedor externo não cria fragilidade: a relação pode ser diversificada, substituível, armazenada em cache ou isolada.

Uma lista de fornecedores, portanto, seria ao mesmo tempo sensível e insuficiente. A pergunta operacional é outra: qual propriedade do serviço deve sobreviver à perda de uma classe de dependência?

Num repositório RPKI, pode ser a leitura contínua do último estado aceito, a integridade do material publicado, um limite para a idade da publicação ou a reconciliação ordenada de gravações depois da recuperação. Cada resposta pertence a um plano diferente. Quem baixa dados, quem altera um ROA, quem envia conteúdo de uma CA delegada ao RPS e quem restaura o serviço não realiza a mesma operação.

O aviso de manutenção de julho de 2026 já ilustra essa separação. ARIN Online, RESTful Provisioning, RPKI Up/Down e RPS ficariam indisponíveis, enquanto o repositório continuaria no ar sem novas publicações. Um artigo anterior de Theo March analisou os dois relógios, disponibilidade e atualização. Aqui o foco é diferente: qual domínio de falha alcança cada plano e qual combinação foi efetivamente testada.

Três modelos distribuem a custódia

A página atual da ARIN afirma que mais de 95% de suas implantações RPKI usam Hosted. Nesse modelo, a ARIN opera a autoridade certificadora e publica o repositório de alta disponibilidade. Em Delegated, o titular pode operar CA e repositório. No RPS, ele conserva a CA e a chave privada, enquanto a ARIN mantém a publicação.

A página do RPS explica que um repositório consolidado pode ficar fora do âmbito administrativo de quem emite o conteúdo RPKI. Uma organização pode desejar controle criptográfico sem assumir um repositório 24 horas por dia. A divisão é legítima e útil.

Ela também cria duas perguntas de continuidade. O emissor consegue produzir material válido? O repositório consegue recebê-lo e servi-lo? Um teste de recuperação de acesso ao repositório informa a segunda capacidade. Não testa automaticamente a CA, o protocolo de publicação, a conta usada para autorizar mudanças ou as comunicações operacionais.

Confundir essas funções reduziria o valor do RPS. A separação entre autoridade criptográfica e disponibilidade de publicação não é um detalhe a eliminar; é a escolha que o serviço oferece.

Disponibilidade mede desempenho, não domínio de falha

O relatório anual de 2025 atribui 99,9% de disponibilidade aos repositórios RRDP e Rsync da ARIN. É uma medida importante. Ela torna o desempenho anual comparável e dá conteúdo numérico a uma afirmação de confiabilidade.

Não informa se dois caminhos compartilham uma dependência, qual é o RTO, qual perda de estado é tolerável nem qual cenário foi exercitado. Pode haver disponibilidade excelente sem mapa público de dependências. Também pode haver uma arquitetura robusta que registre uma interrupção.

O incidente de outubro ocupa outra coluna. A ARIN o vinculou a um defeito de código após uma implantação, limitado a uma condição e a um cliente. O relatório serve para avaliar mudança, contenção e correção. Não permite dizer que um fornecedor externo ou a redundância do repositório falhou.

Uma boa prestação de contas começa ao impedir que uma evidência seja usada para responder a uma pergunta diferente daquela que ela mediu.

Divulgar classes, não o diagrama interno

Há uma objeção séria à transparência detalhada. Nomes de fornecedores, locais, rotas, pontos de controle e condições de comutação podem orientar um ataque. Contratos podem impor sigilo. Um mapa exato também envelhece rapidamente.

A alternativa prática é uma declaração curta para cada serviço e plano. Ela incluiria:

  1. a função pública e quem lê ou grava;
  2. as classes de dependência e premissas de falha comum, sem fornecedor ou local sensível;
  3. a propriedade que deve ser preservada;
  4. o cenário e o limite introduzido no teste mais recente;
  5. os horários observados de restrição, restauração, confirmação e normalização;
  6. os modos ainda não testados;
  7. a meta aplicável de disponibilidade, RTO ou RPO;
  8. a mudança material que exige aviso aos membros; e
  9. a versão, a data de revisão e o histórico de correções.

“Resolução de nomes”, “entrega de conteúdo”, “conectividade”, “identidade” e “instalação” são classes suficientes para a camada pública. A precisão nasce da ligação entre classe, propriedade protegida e resultado, não da exposição de coordenadas.

A declaração precisa expirar. Se uma migração alterar um domínio comum, um resultado correto de 2025 não deve continuar sendo aplicado automaticamente. A sugestão 2025.7 relaciona transparência e gestão de mudanças justamente porque uma afirmação de resiliência depende da arquitetura que existia quando foi testada.

Open descreve o processo, não o trabalho invisível

Na data de corte, a sugestão ainda aparece como Open. A resposta da ARIN dizia que permaneceria assim até a implementação e que o plano seria apresentado à comunidade. Isso autoriza uma descrição do registro público. Não autoriza afirmar que não há trabalho interno, que existe atraso comprovado ou que uma fraqueza está sendo escondida.

O próximo marco útil não precisa prometer perfeição. Basta uma primeira declaração delimitada: serviço, planos, classes de dependência, cenário testado, premissas restantes e data de revisão. O teste seguinte então acrescenta evidência comparável.

A ARIN já fez algo difícil: interveio em produção e publicou uma cronologia em minutos. A questão das dependências permanece aberta porque recuperar um cenário e eliminar todas as condições comuns são proposições diferentes. Explicitar a fronteira entre elas faria o resultado durar mais que a notícia do dia.

Fontes