Gráfico de tráfego DNS (Queries/Responses) nos resolvers RPZ

Introdução

Este gráfico permite visualizar, em uma única visão, como o tráfego DNS do resolver se comporta ao longo do tempo e detectar anomalias de carga ou de funcionamento.

O objetivo deste tutorial é explicar:

• O que significa cada curva.

• Como utilizar o gráfico (ligar/desligar séries).

• Como interpretá-lo para entender o comportamento do cache.

• Quais padrões podem indicar problemas.

Métricas exibidas no gráfico

As curvas disponíveis podem variar levemente conforme a versão, mas em geral são:

• queries_received

• queries_sent

• responses_received

• responses_sent

• cached_responses

A seguir, cada uma delas é descrita.

queries_received

• São as consultas DNS que chegam dos clientes ao resolver (PCs, servidores, CPEs etc.).

• Respondem à pergunta: «Quanto estão me consultando?».

• Essa curva normalmente permanece sempre acima de zero enquanto houver tráfego normal.

queries_sent

• São as consultas que o resolver envia para a Internet quando não consegue responder a partir do cache.

• Exemplos: consultas para Akamai, Google, Microsoft etc.

• Respondem à pergunta: «Quanto preciso sair para a Internet?».

Em um resolver saudável e com bom cache:

• queries_sent normalmente é muito menor que queries_received.

• Se ambas as curvas forem parecidas, o cache quase não está ajudando.

responses_received

• São as respostas que o resolver recebe de servidores autoritativos na Internet.

• Estão associadas às queries_sent.

• Idealmente, se não houver erros, a quantidade de responses_received é semelhante a queries_sent no mesmo período (podem existir diferenças devido a NXDOMAIN, timeouts etc.).

responses_sent

• São as respostas que o resolver envia de volta aos clientes que realizaram as consultas.

• Estão associadas às queries_received.

Em condições normais:

• responses_sent deveria acompanhar muito de perto queries_received (o que entra, sai respondido).

• Se responses_sent permanecer muito abaixo de queries_received, pode haver problemas de tempo de resposta ou erros internos.

cached_responses

• É a quantidade de respostas que o resolver conseguiu responder a partir do cache, sem necessidade de sair para a Internet.

• Relacionado com a eficiência do cache.

• Quanto mais alta for essa curva em comparação com responses_sent, melhor o resolver estará aproveitando o cache.

Em termos simples:

• responses_sent = respostas do cache + respostas da Internet

• cached_responses ≈ parte de responses_sent que saiu do cache.

Como utilizar o gráfico

Ver todas as curvas ao mesmo tempo pode gerar uma “bagunça”. Por isso, a chave é ocultar e mostrar séries utilizando a legenda do gráfico.

1. Ir para a página do resolver em dev

   Por exemplo:

   • rpz-185-180-9-84.planisys.net (Netuno-bkp)

   • rpz-cpacf-1.planisys.net (CPACF)

   Lá você verá o gráfico DNS Traffic (Queries/Responses received/sent).

2. Escolher o período de tempo

   • Em alguns gráficos são exibidas as últimas 12 horas, em outros é mostrado um intervalo de 00:00 a 23:00 do dia.

   • Quanto maior o período, mais fácil será visualizar tendências.

3. Ligar e desligar curvas

   • Na parte inferior (legenda), você pode clicar no nome de cada série: queries_sent, queries_received, responses_sent, responses_received, cached_responses.

   • Ao clicar, essa linha é desligada ou ligada.

   • A ideia é não ver todas juntas, mas sim comparar duas ou três no máximo.

4. Comparar curvas em pares

   Alguns exemplos úteis:

   • queries_received vs. responses_sent

   • queries_received vs. queries_sent

   • queries_sent vs. responses_received

   • responses_sent vs. cached_responses

Exemplo 1: tráfego alto com queda brusca (Netuno-bkp)

Neste exemplo (Netuno-bkp, últimas 12 horas):

• Durante a noite e as primeiras horas, as curvas de tráfego são altas, com picos e vales normais.

• Em um determinado momento (próximo das 03:00) ocorre uma queda brusca do nível de tráfego: todas as curvas caem para um valor muito mais baixo e depois se estabilizam.

Como interpretar algo assim:

• Se todas as curvas caem (queries e responses), pode ser:

  • uma redução real do tráfego dos clientes (horário de menor uso),

  • alguma intervenção de rede,

  • ou uma alteração na configuração.

• Se apenas algumas curvas caíssem (por exemplo, responses_sent mas não queries_received), isso sim seria um sinal de problema.

Exemplo 2: aumento progressivo de carga (CPACF)

Neste outro exemplo (rpz-cpacf-1, intervalo 00:00–23:00):

• Durante a madrugada o tráfego é baixo e bastante estável.

• Após as 09:00–10:00 começa a ser visto um aumento progressivo das curvas (queries e responses).

• Perto do meio-dia e nas primeiras horas da tarde aparecem picos mais altos: é o horário de maior atividade dos usuários.

Esse tipo de gráfico serve para:

• Confirmar o padrão diário de uso (horários de pico da rede).

• Verificar se o resolver acompanha o crescimento do tráfego sem problemas.

• Detectar se, durante o pico, existem discrepâncias entre consultas e respostas.

Relaciones esperables entre las curvas

En un resolver sano, sin ataques y con buen caché, es razonable esperar:

• queries_received ≈ responses_sent (casi todo lo que entra se responde).

• queries_sent ≤ queries_received (no siempre hay que salir a Internet gracias al caché).

• responses_received ≈ queries_sent (salvo errores de red, NXDOMAIN, timeouts, etc.).

• cached_responses es una porción importante de responses_sent (el caché está ayudando).

Uso práctico: detectar anomalías

El motivo por el que todas las curvas están juntas en un mismo gráfico es poder detectar anomalías de tráfico.

Algunos ejemplos de cosas para mirar:

• Falta de respuestas

  • queries_received sube pero responses_sent se queda baja.

  • Podría haber saturación, problemas internos o timeouts hacia Internet.

• Exceso de queries hacia Internet

  • queries_sent está demasiado cerca de queries_received.

  • El caché casi no está funcionando (TTL muy bajos, bypass de caché, tráfico muy variado, etc.).

• Problemas con autoritativos

  • queries_sent sube pero responses_received no la sigue.

  • Podría haber pérdida de paquetes, saturación de upstream o problemas con ciertos dominios.

• Cambios de patrón de uso

  • Un aumento repentino e inusual en alguna franja horaria.

  • Picos muy marcados que no se corresponden con el uso típico del cliente (posible ataque o malware).

Tips para mirar el gráfico

• No trates de entenderlo con todas las curvas encendidas: apagá siempre alguna para hacer comparaciones claras.

• Empezá con pares sencillos:

  • queries_received vs. responses_sent.

  • queries_received vs. queries_sent.

• Después agregá cached_responses para ver cuánto ayuda el caché.

• Cuando veas algo raro, acercá el rango horario o cambiá el período (últimas 12h, último día, etc.) para ver el detalle.

Estado actual

• Este gráfico está disponible en dev y los resolvers empezaron a enviar estas métricas hace relativamente poco.

• Al principio podés ver gráficos muy planos; eso se normaliza una vez que hay suficiente historial de datos.

• Cuando se estabilice el comportamiento en dev, se podrá evaluar su despliegue en producción.

Resumen

El gráfico de DNS Traffic (Queries/Responses received/sent) es una herramienta para:

• Visualizar el tráfico DNS de cada resolver.

• Entender la relación entre consultas, respuestas y caché.

• Detectar anomalías de tráfico y posibles problemas antes de que impacten al usuario final.

La clave es jugar con las curvas, apagando y encendiendo series en la leyenda, hasta que el gráfico “se parezca a un gráfico” y no a una simple línea recta. A partir de ahí, con práctica, cada equipo puede desarrollar su propia forma de interpretar patrones normales y de alerta.