Resumo

  • Segundo a RIPE NCC, uma interrupção curta no enlace de rede do balanceador principal acionou o reserva. Uma configuração incorreta encaminhou novas conexões de atualização Whois a um banco somente de leitura; as conexões existentes continuaram no banco principal.
  • A janela de falhas de 28 de outubro foi de 11h42 a 19h40 UTC. A análise posterior concluiu que as solicitações de delegação reversa que falharam não alterariam uma delegação: não continham mudança ou reprovavam nas verificações prévias do zonemaster.

Dois caminhos para a mesma operação

O relatório posterior da RIPE NCC descreve uma sequência curta. O enlace do balanceador principal sofreu uma interrupção breve, o tráfego migrou para o equipamento reserva e novas conexões de atualização Whois começaram a chegar a um banco de dados de leitura. As conexões já abertas na aplicação permaneceram ligadas ao banco principal e seguiram funcionando. Por isso a falha parecia intermitente. O serviço não alternava magicamente entre bom e ruim; cada conexão carregava o resultado de sua escolha inicial de rota.

Um banco somente de leitura serve consultas. Não recebe uma alteração de objeto de registro. O balanceador podia estar vivo, o reserva podia responder e parte dos pedidos podia avançar pelas sessões antigas. Nada disso garantia que a primeira atualização feita por uma sessão nova alcançasse o banco gravável. A sobrevivência das conexões antigas reduzia a visibilidade do defeito justamente quando um teste superficial de disponibilidade poderia celebrar o failover.

A RIPE NCC situa as falhas de atualização em 28 de outubro, das 11h42 às 19h40 UTC. O aviso inicial falava em atualizações não processadas e em objetos ligados ao DNS reverso. Só o relatório de 3 de novembro expôs o desvio para a função de banco errada. Ele não informa qual parâmetro estava incorreto, quantas novas conexões falharam ou quais métodos de envio foram afetados. Um registro de configuração e resultados por canal permitiria dimensionar o alcance.

Há uma diferença adicional na parte de delegação reversa. A revisão da RIPE NCC concluiu que nenhuma solicitação fracassada desse grupo mudaria a delegação: algumas não alteravam dados, outras falhavam na checagem prévia de zonemaster. A falha do caminho de escrita existiu. O conjunto publicado não registra uma mudança válida de zona reversa que tenha se perdido.

A confirmação está no objeto

As regras de processamento da RIPE Database tratam cada objeto enviado separadamente e devolvem uma confirmação. O guia de confirmações explica que uma resposta HTTP 200 em Syncupdates pode vir com erro em uma operação individual. O resultado detalhado e uma consulta posterior ao registro são o recibo útil ao operador. O indicador verde do balanceador mede outra coisa.