Como entendo o uso da CPU em um servidor DNS?

No Serverfault, geralmente informamos que não podemos ajudar com seu planejamento de capacidade. Isso é por um bom motivo: não conhecemos as especificidades do seu ambiente e as respostas sobre como medi-lo são praticamente as mesmas. Infelizmente, a medição da capacidade do DNS é um tópico mal compreendido e a maioria dos administradores presumirá que o alto uso da CPU significa que é hora de considerar a adição de capacidade. Esta é uma ideia muito, muito ruim, e escalar para um DNS DDoS inevitavelmente levará ao bloqueio de seus dispositivos de rede. (ou pior, pessoas entrando em contato com seu departamento jurídico)

Os logs do servidor e as capturas de pacotes são o que a maioria dos administradores tentará aproveitar primeiro, mas a verdade simples é que o SNMP pode dizer muito mais sobre o ambiente do que seus logs. Não ignore logs e capturas de pacotes, mas o SNMP geralmente pode ajudá-lo a detectar a existência de um problema mais rapidamente.

Além de rastrear as estatísticas padrão do sistema fornecidas por sua ferramenta de monitoramento SNMP (que deve incluir carga da CPU, taxa de transferência por interface e contadores de pacotes, E/S de disco, etc.), recomendo adicionar os seguintes OIDs:

• UDP-MIB
  • Receber erros de fila: udpInErrors (cor vermelha raivosa altamente recomendada)
  • Contadores de datagramas UDP: udpInDatagrams ,udpOutDatagrams
  • (opcional) Datagramas inesperados: udpNoPorts
• TCP-MIB
  • Contadores de segmento TCP: tcpInSegs ,tcpOutSegs

Interpretando os gráficos

Esses gráficos podem ser agrupados em duas categorias: métricas que indicam um problema e métricas que ajudam a diagnosticá-lo.

Indicadores

• A alta utilização da CPU é ruim. Isso é um fato, mas quando isso acontece, você precisa procurar outras métricas para correlacionar. Se a alta utilização da CPU for mapeada para um pico na utilização da rede de saída (taxa de transferência ou número de pacotes), é muito provável que você esteja sendo usado em um ataque DDoS. Detalhes específicos sobre como interpretar a natureza do ataque estão na seção a seguir.
• udpInErrorsé o principal sinal de um problema de capacidade. Esse contador aumenta toda vez que o kernel descarta um datagrama UDP porque o aplicativo não está processando o tráfego rápido o suficiente. Isso significa que seu serviço DNS está sobrecarregado e não consegue acompanhar o tráfego de entrada.
  • A maioria dos guias de desempenho de rede dirá que aumentar o tamanho da sua fila de recebimento não é a solução correta: eles geralmente estão certos. Tente encontrar um motivo que explique por que o servidor está sobrecarregado, seja observando os outros gráficos ou analisando os logs.
  • Se sua empresa opera servidores de e-mail que usam tabelas DNSBL, lembre-se de que os ataques com raquetes de neve podem criar breves picos no tráfego DNS legítimo que podem esgotar o espaço em suas filas de recebimento. Este é um dos casos em que pode valer a pena aumentar o tamanho de suas filas de recebimento de soquete (já que é uma condição temporária conhecida), mas geralmente é melhor colocar mais hardware no problema para manter sua latência baixa.

Se você não puder correlacionar aumentos nessas métricas a outros problemas de desempenho no sistema, parabéns: você está legitimamente próximo/acima da capacidade e é hora de adicionar servidores. Considere-me impressionado. :)

diagnosticando

Isso cobre apenas itens específicos de DNS. Use sua cabeça aqui e não espere que isso seja tudo incluído. (exemplo: a saturação de E/S do disco não é um problema específico do DNS)

• Em um servidor recursivo ocupado, a taxa de transferência de saída deve permanecer em torno de 2x sua entrada. Isso ocorre porque as respostas geralmente são muito maiores do que as consultas associadas. Picos sustentados significativamente acima desse nível indicam que seu servidor está participando de um ataque de amplificação . Você provavelmente está operando um resolvedor aberto .
• Os pacotes de entrada devem ser aproximadamente iguais aos pacotes de saída, mesmo em um servidor DNS recursivo. Embora haja uma necessidade ocasional de retransmissão de uma consulta devido a um tempo limite, isso não acontece com tanta frequência a ponto de causar uma distorção significativa do gráfico. Um aumento significativo nos pacotes de saída indica um problema de rede ou que seu cluster está sendo usado em um ataque contra servidores de nomes autorizados. Isso não sugere necessariamente que você esteja operando um resolvedor aberto: outros servidores DNS podem estar encaminhando consultas para você que não podem ser armazenadas em cache.
• Pode parecer redundante sugerir gráficos de E/S UDP+TCP além dos gráficos por interface, mas esses gráficos não estão vinculados a interfaces e também fornecem informações sobre a natureza do ataque em andamento quando você tem experiência suficiente com seu software de servidor de nomes.

Nota lateral: udpNoPortsnão é realmente uma métrica de capacidade, mas é útil para identificar tentativas de envenenamento de cache. Esse contador é incrementado toda vez que um pacote UDP é visto em uma porta inesperada, e uma parede sustentada deles durante a operação normal pode sugerir que alguém está tentando forjar uma resposta. (ou isso, ou um de seus ouvintes não está funcionando: ligue isso de volta em foo'!)

Com servidores DNS (na verdade, qualquer tipo de servidor), às vezes você precisa observar e analisar as solicitações que estão sendo feitas, caso uma configuração incorreta (possivelmente em outro lugar) esteja ampliando o volume de solicitações (consulte, por exemplo , servidores DNS do Windows solicitando registros repetidamente na zona quando recebem a resposta SERVFAIL ). Observe as proporções de consultas e respostas e tente encontrar um comparador para verificar a normalidade.