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) ----------------------------------------------------- .. image:: _images/dns-traffic-netuno-bkp.png 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) ---------------------------------------------- .. image:: _images/dns-traffic-cpacf.png 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.