Resumo

  • A APNIC informa que um firewall de rede detectou falha de hardware e reiniciou entre 19h10 e 19h18, UTC+10, em 28 de agosto de 2026.
  • A relação de impactos reúne MyAPNIC, API do registro, Orbit, FTP, protocolos de provisionamento e publicação RPKI e acesso RPKI por rsync.
  • O aviso não relata perda, corrupção, duplicação de atualizações ou incidente de segurança. Também não informa, por interface, se tarefas foram aceitas, concluídas, drenadas ou reconciliadas.
  • Um comprovante de estado operacional pode manter um único incidente e separar trabalho não recebido, aceito, confirmado, visível, seguro para repetir, próprio para consulta ou ainda desconhecido.

Uma janela curta, uma cauda que o relógio não mede

O aviso de 28 de agosto delimita o evento: início às 19h10, encerramento às 19h18, no fuso UTC+10. Um dos firewalls de rede da APNIC detectou falha de hardware e reiniciou. A organização diz que houve interrupções nos serviços listados, que apura a causa com o fornecedor e que trabalha para melhorar o failover de tráfego entre firewalls. O feed de avisos preserva o mesmo registro.

Nada ali prova que o registro inteiro ficou fora do ar, que cada serviço parou por oito minutos completos ou que um dado foi danificado. “Interrupção” pode corresponder a falha de conexão, erro em parte dos pedidos, resposta perdida depois da aceitação, atraso de publicação ou indisponibilidade temporária de leitura. A APNIC não discrimina esses casos, e o artigo não deve escolher um por conta própria.

Oito minutos continuam sendo uma boa notícia. A ressalva é operacional: quando a rede retornou, algumas tarefas poderiam ter um estado próprio a esclarecer.

A API transforma atualizações em tarefas

A APNIC explica na documentação da API de registro que o serviço recupera informações de delegação e administra registros Whois, DNS reverso, ROAs e objetos de rota. Há leituras e há ações capazes de alterar o estado do registro.

As atualizações são assíncronas. O cliente envia a operação, recebe um link para um objeto de tarefa, consulta esse objeto e encontra nele o resultado quando o processamento termina. Lotes de DNS reverso e de gestão abstrata de rotas têm efeito transacional quando possível.

Esse desenho separa o pedido HTTP do trabalho que ele dispara. Uma conexão pode cair antes de o servidor receber a chamada, depois de recebê-la mas antes da aceitação, depois da criação da tarefa ou depois da confirmação interna sem que a última resposta alcance o cliente.

No primeiro caso, repetir pode ser correto. Se a tarefa existe, consultá-la é mais seguro. Se a mudança já foi confirmada, enviar outra atualização pode apenas criar uma nova operação. Não há indício público de repetição indevida ou tarefa perdida em 28 de agosto. O ponto é que o horário das 19h18 não distingue esses estados.

MyAPNIC é uma segunda visão das mesmas funções. A APNIC diz que mudanças feitas na API aparecem no portal e vice-versa. Conseguir abrir o portal depois da recuperação demonstra uma leitura nova. Não certifica que uma tarefa anterior terminou, que todas as camadas atualizaram juntas ou que a fila ficou vazia.

Para o membro, o fechamento útil seria: nenhuma escrita foi aceita; as tarefas aceitas foram verificadas; ainda há tarefas em processamento; ou o estado não é observável. A frase “o tráfego voltou” continua correta, mas pertence à camada de rede.

Orbit e FTP pedem decisões diferentes

O Orbit é a plataforma de comunicação comunitária da APNIC e evolução das listas de discussão. Nele se leem arquivos, publicam-se mensagens e recebem-se entregas por e-mail. Uma leitura que falhou pode ser repetida sem efeito lateral. Uma postagem de resultado incerto pede consulta ao arquivo antes do reenvio. A entrega de e-mail tem outro critério de conclusão.

O aviso não diz qual caminho do Orbit sofreu interrupção. Isso não comprova perda nem duplicação; apenas deixa essas hipóteses sem resposta.

FTP distribui dados públicos. O formato de intercâmbio de estatísticas dos RIRs prevê arquivos acessíveis ao mundo, sem controle de acesso, nomes persistentes para a versão mais recente e materiais de validação.

Falha de download não equivale a arquivo corrompido. Uma edição pode estar gerada e ainda não visível em uma rota. O nome latest e o arquivo datado podem precisar de verificação separada. Não há evidência de que qualquer um desses cenários ocorreu. Um estado público limitado — leitura interrompida, publicação adiada, objeto inalterado, ponteiro verificado ou desconhecido — evitaria tanto o alarme quanto a falsa certeza.

RPKI reúne fluxos opostos

A Declaração de Práticas de Certificação da APNIC distingue protocolo de provisionamento, protocolo de publicação, repositório acessível por rsync e repositório acessível por RRDP. O titular e a autoridade certificadora conversam em um fluxo; o publicador envia objetos ao repositório em outro; a parte confiadora busca objetos em um terceiro.

A RFC 6492 define pedidos e respostas de provisionamento de certificados de recursos. A RFC 8181 define as operações de publicação. A RFC 8182 define o RRDP sobre HTTPS.

O aviso cita “RPKI Provisioning and Publication protocol” e, em separado, “RPKI rsync”. Não cita RRDP. O silêncio não prova disponibilidade, indisponibilidade ou separação de domínio de falha. Só impede que a lista seja tratada como laudo de todo o serviço RPKI.

Uma falha de coleta também não esvazia imediatamente a política dos roteadores. Validadores trabalham com objetos recuperados e validados localmente, em ciclos próprios. O registro público não informa idade de cache, expiração de objeto, comportamento de validador ou consequência para roteamento.

As perguntas precisam seguir a direção do protocolo. O pedido de provisionamento recebeu resposta? A publicação foi confirmada ou deve ser repetida? O conjunto servido por rsync voltou coerente? O RRDP foi observado e está dentro do escopo? Separar as perguntas não pressupõe falha; apenas impede que o nome RPKI apague estados distintos.

Aviso rápido e reconciliação posterior

Seria contraproducente atrasar o alerta até que todas as filas estivessem reconciliadas. A APNIC divulgou um gatilho, um intervalo, as superfícies e a linha de correção. Isso ajuda usuários a relacionar sintomas e reduz investigações paralelas.

O relógio comum também serve para disponibilidade. No relatório do quarto trimestre de 2025, a APNIC combina sondas externas a cada minuto com a taxa de pedidos bem-sucedidos observada pelos usuários e evita contar o mesmo evento duas vezes. Ela já trata alcance de endpoint e resultado de requisição como evidências diferentes.

O passo seguinte pode vir depois: uma pequena reconciliação por classe de operação, ligada ao aviso original. Não é preciso transformar uma falha de oito minutos em relatório interminável.

Como seria o comprovante mínimo

Cada linha teria interface, direção e classe de trabalho: atualização de membro, consulta de tarefa, leitura ou postagem comunitária, geração ou obtenção de arquivo, provisionamento RPKI, publicação RPKI, leitura rsync e observação de RRDP, se incluída.

Os estados cabem em um vocabulário curto: não recebido, recusado antes de aceitar, aceito, confirmado, revertido, pendente, visível em uma representação, seguro para repetir, apenas consultar, desconhecido. Recuperação da interface, esvaziamento da fila e teste entre representações ganham horários próprios.

Faixas de volume preservam privacidade. Pedidos brutos, identidade dos membros, conteúdo dos objetos, endereços internos, credenciais, números de série e topologia sensível permanecem protegidos. Uma correção posterior acrescenta a nova conclusão sem apagar a anterior.

Às 19h18, a APNIC encerrou o evento do firewall. Uma escrita termina quando sua aceitação e seu efeito são conhecidos. Uma publicação termina quando o repositório informa o resultado. Uma leitura termina quando o consumidor obtém uma representação verificável. Um único incidente pode conter todos esses relógios; não deve fingir que eles marcam a mesma coisa.

Fontes