06/05/2011

Relatório Incidente 06/05/2011

*Sumário Executivo

No dia 6/5/2011 a partir das 14:45h [1], quando uma mudança programada de configuração nos servidores DNS para o domínio .br foi efetuada, um problema no software utilizado em parte dos servidores fez com que 3,2% das consultas sobre domínios fossem respondidas incorretamente como domínios inexistentes. Às 15:26h este percentual atingiu seu máximo que foi de 11,6% das consultas, e que se manteve até às 16:39h quando voltou a 0% com a desativação dos servidores com potencial para respostas incorretas.

A característica específica do problema não permitiu a sua imediata identificação, mesmo com os diversos mecanismos de monitoração disponíveis. O diagnóstico do problema confirmou-se às 16:30h e foi resolvido com medidas corretivas aplicadas imediatamente às 16:39h.

Medidas preventivas com a modificação de procedimentos operacionais para a reconfiguração de servidores, modificação nos procedimentos de monitoração e a busca da correção do software defeituoso foram adotadas para que este incidente, que pela primeira vez afetou o .br, não se repita novamente no futuro.

*Histórico

O domínio .br é publicado em 6 clusters ([a-f].dns.br) em configurações uni/anycast com diversidade de acordos de trânsito, hardware e software (3 clusters rodam BIND e 3 clusters rodam NSD).

Em Janeiro de 2011 encontramos um bug no BIND [2]. Este problema consistia na não preservação do RDATA para registros NSEC na representação em disco de forma consistente com o que havia sido transmitido durante a atualização destas zonas via IXFR.

O comportamento incorreto era observado somente em situações em que a configuração do servidor DNS se encontra com a declaração da zona em letras maiúsculas, forma esta que sempre foi a configuração para as zonas do .br.

Como não havia previsão por parte do fornecedor, ISC, para correção do problema no software, a alternativa operacional encontrada pelo Registro.br foi a atualização das configurações dos servidores rodando BIND para minúsculas, o que foi feito no dia 11/1/2011. Os servidores que rodam NSD não foram atualizados nesta mesma época mas tiveram esta alteração programada para um próximo evento, quando fosse necessária a alteração da configuração em função da adição de novas zonas.

Em 4/5/2011 o NIC.br recebeu um novo bloco de endereços (177.64/11) para distribuição pelo serviço de numeração. Nesta mesma data começaram os procedimentos para o provisionamento de DNS reverso para estes endereços.

*Evento

No dia 6/5/2011 novas zonas foram adicionadas às configurações dos servidores e ao mesmo tempo foram alteradas as configurações para as zonas do .br nos servidores rodando NSD, também de letras maiúsculas para minúsculas.

Devido a um bug no NSD [3], estas modificações de configuração tiveram um efeito adverso que terminou por corromper sua base de dados residente nos clusters que rodam NSD (nsd.db), mas manteve a zona com contornos consistentes.

O efeito do bug fez com que as zonas nestes servidores passassem a conter somente os seus registros estruturais (APEX, registros de marcação e infra-estrutura), os quais são atualizados a cada 30 minutos, e os registros que fossem atualizados após a última consolidação do banco de dados do servidor, que ocorreu às 12:50h.

*Monitoração

A monitoração do serviço de publicação, apesar de ser bastante completa em relação a consistência das zonas nos servidores de provisionamento (hidden masters), nos servidores secundários restringe-se aos registros estruturais das zonas e, em função disto, não identificou qualquer problema.

O perfil de tráfego nos servidores afetados pelo incidente, tanto em pps como em bps, também não teve alterações que sugerissem qualquer problema no serviço.

Os primeiros indícios do incidente foram publicados na lista às 15:56h, e às 16:25h a equipe do registro identificou que algo de incorreto estava acontecendo. A constatação e o diagnóstico do problema foram concluídos às 16:30h.

*Medidas corretivas

Após a identificação do incidente a medida corretiva - a mais adequada nestas situações - foi a imediata desativação dos clusters [abe].dns.br que apresentavam indícios de problemas, o que foi concluído às 16:39h.

A partir deste momento, com o parâmetro "minimum" do registro SOA para nossas zonas configurado para 15 minutos, a correta resolução DNS foi totalmente restabelecida às 16:54h.

Imediatamente após a desativação dos clusters, foi preservado seu conteúdo para posterior análise, removida a base de dados e as representações em arquivos de zonas e reiniciados os servidores DNS para nova sincronização via AXFR. Esta operação foi concluída às 18:00h. Após a verificação de todos os servidores presentes nestes clusters, o serviço do conjunto [abe].dns.br foi totalmente restabelecido às 18:10h.

*Impacto

Análise dos logs presentes nestes servidores mostrou que o evento afetou 1/3 do cluster "a" entre 14:45h e 16:30h e a totalidade do cluster "b" entre 15:26h e 16:39h. O cluster "e" não chegou a ser afetado. Isto representou 3.2% das consultas entre 14:45h e 15:26h e 11.6% das consultas entre 15:26h e 16:39h.

Devido às características do DNS de base de dados distribuída, eventos onde exista inconsistência entre os servidores autoritativos para uma zona tem diagnóstico complexo, efeito de intermitência e comportamento muito particular para cada delegação afetada, em função direta do TTL de seus registros.

Zonas delegadas com registros de infra-estrutura (SOA, NSs) com TTLs reduzidos (< 1h) foram mais afetadas do que zonas que tem estes registros com TTLs maiores.

Ressalta-se que no intervalo entre 16:39h e 18:10h, quando somente 1/2 dos servidores autoritativos estavam em operação, o serviço não apresentou problema operacional ou qualquer perda de desempenho mensurável, uma vez que a capacidade dos servidores restantes é ordens de grandeza maior do que a demanda, e o protocolo DNS é preparado para este tipo de situação.

*Medidas preventivas

Foi revisado o procedimento de configuração dos servidores para que qualquer modificação de suas configurações de software e/ou hardware seja sempre seguida por uma resincronização total de suas zonas e a verificação de seus conteúdos, antes que estas máquinas sejam novamente integradas aos clusters.

A verificação do conteúdo das zonas também foi adicionada à monitoração periódica dos registros de infra-estrutura.

Passa-se também a monitorar as respostas dos servidores DNS, o que permite a observação da relação de RCODES NXDOMAIN/NOERROR. Esta medida durante um evento desta natureza mostraria mudança clara de perfil, permitindo sua detecção de forma mais fácil.

O bug do NSD foi informado ao fornecedor do software, NLnetlabs, que já providenciou a correção [3].

O Registro.br contribui no processo de revisão do protocolo IXFR [4], atualmente em discussão no IETF, propondo formas para que clientes IXFR, ao detectarem inconsistências em sua cópia local (solicitação de remoção de registros inexistentes ou adição de já existentes), levem a zona ao estado de expirada, seguido de uma resincronização total via AXFR.

[1] Todos os horários em BRT (UTC -0300)
[2] 3007 [RT #22863]
http://ftp.isc.org/isc/bind9/9.6.3/RELEASE-NOTES-BIND-9.6.3.html
[3] Changelog NSD 3.2 - 20 May 2011
http://www.nlnetlabs.nl/svn/nsd/branches/NSD_3_2/doc/ChangeLog
[4] http://tools.ietf.org/html/draft-ah-dnsext-rfc1995bis-ixfr-02