O mundo todo soube dos problemas que tivemos com  3 dos nossos servidores de DNS (nós temos 6 ao todo), das 16:39 até 18:10 de ontem, sexta-feira, dia 06/05/2011. Boa parte dos brasileiros não conseguiam acessar à Internet. Demi Getschko, diretor-Presidente do NIC.br, órgão que cuida da gestão destes servidores informou que houve um problema no software utilizado por dois dos servidores de DNS hospedados no Brasil e um na Alemanha. Alguns jornais disseram que o problema foi causado devido a atualização do software destes três servidores, já outros disseram que pode ter sido um ataque/invasão hacker, o próprio Demi disse que essa possibilidade não pode ser descartada.

A partir daqui eu lanço as minhas perguntas:

Por que o pessoal da Terramark e do Nic.br estavam atualizando “o software” destes 2 servidores logo às 16:39 de uma sexta-feira ? A Terramark fica sediada em Alphaville, região que possui o anal ótica e de dados mais moderno do Brasil e o NIC.br terceirizou o serviço de hospedagem e gerenciamento, pelo visto, dos DNSs do Brasil para eles. Nada contra a Terramark, mas fazer uma atualização tão importante às 16:39?!?1 Eu vejo poucos motivos para isso acontecer e posso elencar alguns deles:

  • Descobriram que os servidores estavam vulneráveis há algum tipo de ataque.
  • Eles foram atacados e para resolver tinha que implementar algum patch/correção urgente.
  • Foi cagada de algum analista que não pensou em executar esse update na madrugada.

Quem trabalha com TI e que já mexeu em um servidor de DNS sabe como é fácil configurá-lo e instalá-lo. Em poucas linhas de comando, ajustes e um comando de start, o seu servidor de DNS está no ar.

Serei sincero em afirmar que fico preocupado com algumas das declarações feitas pelo NIC.br quanto ao suporte gerenciamento dos nossos servidores de DNS. Temos um dos maiores crescimentos quanto acesso à Internet e empresas statup em todo mundo, e o NIC.br é um órgão, dito com pouca verba, que terceiriza os serviços para uma empresa que executa uma manutenção às 16:39 de uma sexta-feira ? Será que não está na hora de mudar isso ?

Boa parte dos países que possuem o número de pessoas e empresas que estão conectadas à Internet como o Brasil deixam o gerenciamento dos servidores de DN, nas mãos de empresas que possuem muitos recursos, tanto técnicos como financeiros.

P.S.: Atacar servidores de DNS não é uma das tarefas mais difíceis não. Eu já apresentei uma série de ferramentas que fazem isso. Acontece que você tem que saber como e aí que está o pulo do gato.

Compartilhar:

Este post tem 11 comentários

  1. Rubens

    Os serviços do Registro.br não são terceirizados com a Terremark, são administrados pelo próprio Registro.br. O horário citado de 16:39 foi o de recuperação parcial do serviço, não o de quando a alteração (que foi de configuração, não de versão) foi realizada. Vide http://registro.br/anuncios/20110506.html

  2. Davi

    Ou será que os analistas não queriam passar a madrugada de sexta pra sábado trabalhando e pensaram: “Vamos fazer a atualização sexta no finalzinho da tarde que ninguém vai perceber”?
    Casa o “Change Management” ???? kkkkkkkkkkk

  3. Gustavo Lima

    O Rubens passou uma informação que eu não tinha ciência e acredito que boa parte dos jornais que publicaram a notícia quanto a queda dos DNSs e nem boa parte do NIC.br.. estranho, mas válida..

  4. Rubens

    Essa informação equivocada da Terremark saiu apenas no “O Globo”, demais órgãos de imprensa divulgaram apenas a falha propriamente dita sem culpar erradamente a Terremark.

    Quando às 16h39 os clusters com resposta incorreta foram removidos de operação, o problema de resposta incorreta foi resolvido desde que os recursivos DNS respeitassem os 15 minutos máximo de caching de resposta negativa programados nos servidores de .br.

    A partir de 16h54, os únicos problemas existentes deveriam ser eventuais, pois as consultas poderiam demorar de 0 a 4 tentativas para alcançar um cluster em operação, essas retentativas seriam transparentes para o usuário pois seriam feitas pelo servidor DNS recursivo que os atende.

  5. Gustavo Lima

    Não foi só no O Globo que saiu essa informação, teve jornal que mudou depois. Mas de fato, o que aconteceu ?

  6. Rubens

    Mudança de configuração feita algum tempo antes, gerou uma situação onde havia propensão a falha em um dos softwares de DNS usados (o outro não foi afetado). Conforme o tempo passou mais máquinas passaram a apresentar o problema, que era responder “domínio inexistente” às consultas.

    Quando isso foi notado, os clusters com esse software foram tirados do ar… e as pessoas erradamente ligaram o que notavam (problemas de resolução) ao fato de que esses clusters não respondiam.

    O principal problema foram as respostas de domínio inexistente já dadas antes de se tirar esses clusters do ar… o tempo de resolução de .br pode e deve ter aumentado depois de 16h39, mas as inacessibilidades relatadas eram relacionadas às respostas dadas antes disso.

    Quem tiver logs de resolução dos seus DNS recursivos, pode avaliar o impacto pelo aumento de respostas NXDOMAIN na sexta à tarde. Respostas SERVFAIL depois de 16h39 aconteceriam nos casos de timeout por demora até chegar num cluster ativo. Penso que seria interessante para dar uma visão do episódio pelas redes afetadas.

    Call-centers de operadoras, provedores e bancos também seriam interessantes de consultar.

    O impacto dessa falha foi bem difuso conforme a afinidade do servidor DNS de cada rede com algum dos clusters, que surge por um cluster estar mais próximo e com isso responder mais rápido. Há operadores que não notaram problema algum… provavelmente por que com maior probabilidade tiveram respostas de clusters não afetados.

  7. Gustavo Lima

    Blz Rubens, mas por que eles fora mexer nisso em uma sexta-feira à tarde ?

  8. Rubens

    Eu acho que ter sido numa sexta-feira só teria sido um problema se não houvesse resposta ao problema durante o final de semana e o serviço só fosse recuperado na 2a. feira.

    Eu não sei qual a avaliação de risco que quem tomou a decisão de fazer a alteração numa tarde para poder comentar pois estou longe do lado operacional, mas eu posso dizer da minha experiência em grandes portais de Internet e operadoras de telecomunicação de que se fazia nessas instituições alterações de configuração (em geral ligadas a ativação de novos produtos ou provisionamento de novos clientes) durante o horário comercial. É o tipo de coisa que não costuma gerar impactos, exceto por “fat fingers” ou quando se descobrem bugs (que eu suspeito ter sido o caso nesta sexta-feira).

    Isso contrasta por exemplo com instituições financeiras, onde isso só é feito em janelas… entender qual é o modelo de risco apropriado para esse serviço é uma discussão interessante, mas no grande banco que citei ninguém se importava de atrasar lançamentos em duas semanas ou mais. Ninguém também se importava de desligar os serviços do mainframe toda meia-noite deixando Internet Banking e pagamentos de cartões fora do ar… o que gerava naturalmente janelas de manutenção.

    Em registro de domínios, é esperada disponibilidade 7×24 (não há janelas naturais), e as expectativas são de tempos de resposta, não de prazos…

    Há um caminho do meio em algum lugar que atenda da melhor forma essas demandas contraditórias… e esse é o tipo de coisa q ue se determina de forma iterativa. Agora já se sabe de um risco operacional com softwares a princípio bastante simples como os de publicação de DNS que pode dar origem a processos apropriados de controle de risco (ex: fazer alterações no mesmo ritmo mais lento e staging usado para atualizações de versão).

    Um outro exemplo de riscos antes desconhecidos foram os problemas de DNSSEC no .uk e no .fr ; ambos foram atingidos por cenários de falhas que não imaginaram e não eram óbvios a ponto de estarem no manual do escoteiro-mirim… eu suspeito que ainda haverão mais causos de DNSSEC e espero que o .br não esteja entre eles (e de fato o pioneirismo nesse ponto de DNSSEC está a nosso favor), mas quem se acreditar infalível está a meio caminho de provar que isso não é verdade.

  9. Luis Isique

    Aprender com os erros, é tarefa nossa de cada dia, estudar muito e praticar os estudos.
    Acredito que foi inocência de um analista e estupidez de qualquer hacker, derrubar o seu próprio DNS para saída do país, isso com certeza é algum brasileiro muito brasileiro.

Deixe uma resposta