Relatório Incidente dns.br - 20110506
                        Engenharia, Registro.br

                                             Data: 2011-05-25 14:44:32

*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