Resumo

  • O RIPE NCC publicou às 15:03 CEST de 13 de agosto seu post-mortem para NRTM e arquivos split.
  • A explicação oficial diz que um objeto RPSL inválido interrompeu o serviço e dessintonizou os clientes da RIPE Database.
  • Mudanças de validação, de comportamento do stream e de monitoramento foram anunciadas; Whois 1.124 é previsto para 27 de agosto.

Um fluxo que não avançava deixou de ser apenas um espelho

O RIPE NCC informa que o serviço de espelhamento NRTM foi afetado aproximadamente entre 00:06 UTC de 2 de agosto e 12:30 UTC de 4 de agosto. O objeto RPSL inválido foi gravado na RIPE Database; quando o NRTM o alcançou, deixou de funcionar, e os clientes passaram a ficar fora de sincronia a partir desse ponto.

Há também um efeito dependente registrado na página do incidente. O provisionamento de DNS reverso depende de NRTM, e atualizações de objetos domain deixaram de aparecer no DNS global enquanto o caso era investigado. Depois, o RIPE NCC afirmou ter processado e publicado as atualizações pendentes. A fonte não diz quais clientes de NRTM, zonas ou espelhos foram afetados, portanto não sustenta uma conclusão mais ampla que essa cadeia documentada.

A prevenção começa antes do consumidor do fluxo

O relatório atribui a entrada do objeto inválido a uma alteração feita no Whois 1.122 em abril. Linhas novas adicionais nos atributos descr: e remarks: foram permitidas inadvertidamente. Segundo o RIPE NCC, a substituição de pontos de código UTF-8 foi alterada para não gravar essas quebras extras.

Na outra ponta, o NRTM não pulava objetos RPSL inválidos: falhava com erro interno. O comportamento divulgado agora é ignorar o objeto inválido e registrar o erro. Depois, a equipe da base pode corrigi-lo para que a atualização apareça mais adiante no stream. As duas correções são atribuídas ao próximo Whois 1.124, com data prevista para quinta-feira, 27 de agosto. A página anuncia uma entrega futura; ela não a confirma como concluída.

Monitorar uma faixa é melhor que testar uma porta

O RIPE NCC também aperfeiçoou a monitoração para requisitar uma faixa recente de atualizações NRTM e validar a resposta. Isso procura evidência de fluxo recente utilizável, não apenas de que uma instância respondeu a uma conexão.

Para quem consome dados de registro, o ponto operacional é testar a continuidade dos dados e manter tratamento explícito para entradas inválidas. O post-mortem não mede impacto em cada consumidor nem publica uma lista completa de objetos. Ainda assim, ele torna verificável a relação entre validação de entrada, tolerância controlada no stream e detecção de avanço real.

Fontes