Gráfico de tráfico DNS (Queries/Responses) en los resolvers RPZ

Introducción

Este gráfico permite ver, en una sola vista, cómo se comporta el tráfico DNS del resolver a lo largo del tiempo y detectar anomalías de carga o de funcionamiento.

El objetivo de este tutorial es explicar:

• Qué significa cada curva.

• Cómo usar el gráfico (encender/apagar series).

• Cómo leerlo para entender el comportamiento del caché.

• Qué patrones pueden indicar problemas.

Métricas que se grafican

Las curvas disponibles pueden variar levemente según la versión, pero en general son:

• queries_received

• queries_sent

• responses_received

• responses_sent

• cached_responses

A continuación se describe cada una.

queries_received

• Son las consultas DNS que llegan desde los clientes al resolver (PCs, servidores, CPEs, etc.).

• Responden a la pregunta: «¿Cuánto me están consultando?».

• Esta curva suele estar siempre por encima de cero mientras haya tráfico normal.

queries_sent

• Son las consultas que el resolver envía hacia Internet, cuando no puede responder desde su caché.

• Ejemplos: consultas hacia Akamai, Google, Microsoft, etc.

• Responden a la pregunta: «¿Cuánto tengo que salir a Internet?».

En un resolver sano y con buen caché:

• queries_sent suele ser mucho menor que queries_received.

• Si ambas curvas son parecidas, el caché casi no está ayudando.

responses_received

• Son las respuestas que el resolver recibe desde servidores autoritativos en Internet.

• Están asociadas a las queries_sent.

• Idealmente, si no hubo errores, la cantidad de responses_received es similar a queries_sent en el mismo período (puede haber diferencias por NXDOMAIN, timeouts, etc.).

responses_sent

• Son las respuestas que el resolver envía de vuelta a los clientes que hicieron las consultas.

• Están asociadas a las queries_received.

En condiciones normales:

• responses_sent debería seguir muy de cerca a queries_received (lo que entra, sale respondido).

• Si responses_sent se queda muy por debajo de queries_received, puede haber problemas de tiempo de respuesta o errores internos.

cached_responses

• Es la cantidad de respuestas que el resolver pudo contestar desde su caché, sin necesidad de salir a Internet.

• Relacionado con la eficiencia del caché.

• Cuanto más alta sea esta curva en comparación con responses_sent, mejor está aprovechando el caché el resolver.

En términos simples:

• responses_sent = respuestas desde caché + respuestas desde Internet

• cached_responses ≈ parte de responses_sent que salió del caché.

Cómo usar el gráfico

Ver todas las curvas al mismo tiempo puede generar un “matete”. Por eso, la clave es ocultar y mostrar series usando la leyenda del gráfico.

1. Ir a la página del resolver en dev

   Por ejemplo:

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

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

   Allí verás el gráfico DNS Traffic (Queries/Responses received/sent).

2. Elegir el período de tiempo

   • En algunos gráficos se muestran las últimas 12 horas, en otros se ve un rango de 00:00 a 23:00 del día.

   • Cuanto más largo el período, más fácil es ver tendencias.

3. Encender y apagar curvas

   • En la parte inferior (leyenda) podés hacer clic en el nombre de cada serie: queries_sent, queries_received, responses_sent, responses_received, cached_responses.

   • Al hacer clic, esa línea se apaga o se enciende.

   • La idea es no ver todas juntas, sino ir comparando de a dos o tres como máximo.

4. Comparar curvas de a pares

   Algunos ejemplos útiles:

   • queries_received vs. responses_sent

   • queries_received vs. queries_sent

   • queries_sent vs. responses_received

   • responses_sent vs. cached_responses

Ejemplo 1: tráfico alto con caída brusca (Netuno-bkp)

En este ejemplo (Netuno-bkp, últimas 12 horas):

• Durante la noche y primeras horas, las curvas de tráfico son altas, con picos y valles normales.

• En un momento determinado (cerca de las 03:00) hay una caída brusca del nivel de tráfico: todas las curvas bajan hasta un valor mucho más bajo y luego se estabilizan.

Cómo interpretar algo así:

• Si bajan todas las curvas (queries y responses), puede ser:

  • una baja real de tráfico de los clientes (horario valle),

  • alguna intervención de red,

  • o un cambio en la configuración.

• Si sólo bajaran algunas curvas (por ejemplo, responses_sent pero no queries_received), eso sí sería una señal de problema.

Ejemplo 2: aumento progresivo de carga (CPACF)

En este otro ejemplo (rpz-cpacf-1, rango 00:00–23:00):

• A la madrugada el tráfico es bajo y bastante estable.

• Después de las 09:00–10:00 empieza a verse una subida progresiva de las curvas (queries y responses).

• Cerca del mediodía y primeras horas de la tarde aparecen picos más altos: es el horario de mayor actividad de los usuarios.

Este tipo de gráfico sirve para:

• Confirmar el patrón diario de uso (horas pico de la red).

• Ver si el resolver acompaña el crecimiento de tráfico sin problemas.

• Detectar si en el pico hay discrepancias entre consultas y respuestas.

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.