Resumo

  • Um registro da RIPE NCC publicado em 30 de outubro situa falhas intermitentes entre 11h42 e 19h40 UTC de 28 de outubro. A página original marcou resolução às 19h32 UTC.
  • A apuração diz que nenhum pedido fracassado alteraria uma delegação reversa: não havia mudança no pedido ou ele falhou nas verificações de pré-delegação do Zonemaster. Os registros mostram impactos “major” e “none”.

Para uma equipe que administra DNS reverso, o que importa é se a operação chegou ao cadastro — e em que momento. A apuração publicada em 30 de outubro diz que nenhum dos pedidos fracassados mudaria uma delegação reversa. Só que a janela informada termina às 19h40 UTC de 28 de outubro, oito minutos depois do encerramento anunciado pela própria RIPE NCC.

Os registros contam relógios diferentes. Em 28 de outubro, a página original marcou a correção sob monitoramento às 20h23 CET e resolveu o incidente às 20h32 CET — 19h32 UTC. O registro posterior diz que as falhas intermitentes de atualização seguiram até 19h40 UTC. Essa diferença importa quando uma equipe cruza o status público com o horário da própria tentativa.

A mesma apuração começa o período às 11h42 UTC, sete horas e 22 minutos antes da primeira nota pública de investigação, às 19h04 UTC. A página original dizia que algumas atualizações não estavam sendo processadas e que objetos domain afetavam o DNS reverso. Seu impacto estava marcado como “major”.

A conclusão posterior é mais específica sobre o efeito nos dados: nenhum pedido que falhou teria mudado uma delegação reversa. Alguns não continham alteração; outros pararam nas verificações de pré-delegação do Zonemaster. A documentação da RIPE Database sobre DNS reverso explica que o objeto domain solicita a delegação e que a checagem dos servidores vem antes da propagação pela RIPE NCC.

A falha ficou no caminho de escrita; a apuração não encontrou mudança de delegação causada pelos pedidos recusados. Ainda assim, a API atribui “none” ao registro posterior, enquanto mantém “major” no incidente inicial. A RIPE NCC não explica a diferença nem publica quantos pedidos falharam ou quais objetos estavam envolvidos. Uma lista por objeto mostraria quantos operadores podem encerrar suas próprias pendências sem adivinhar.

Fontes