Estadísticas de cada RPZ ======================== .. image:: _images/pdns-estadisticas.png Esta sección muestra las **estadísticas individuales por cada lista RPZ (Response Policy Zone)**, permitiendo evaluar el desempeño y la latencia de las consultas DNS que se procesan a través de cada servidor. Gráfico de Round-Trip-Time (RTT) -------------------------------- El **gráfico de Round-Trip-Time (RTT)** Indica el tiempo que le costo al rpz poder resolver un query. Por lo que que mas cercanos al autoritativo mas se va a destacar la linea verde. El gráfico presenta varias curvas de colores que permiten distinguir diferentes rangos de tiempo de respuesta: - **Avg RTT (ms)** – línea celeste: promedio general de latencia. - **RTT <10 ms (verde)** – respuestas extremadamente rápidas. - **RTT <100 ms (amarillo)** – rendimiento óptimo. - **RTT <500 ms (naranja)** – latencia aceptable. - **RTT <1600 ms (rojo)** – posibles demoras o congestión. - **RTT > 1600 ms (azul)** – respuestas anómalamente lentas. El eje horizontal muestra la **línea temporal (UTC)**, mientras que el eje vertical representa los **valores de tiempo en milisegundos (ms)**. Este gráfico permite: - Detectar **momentos de latencia alta** o pérdida de rendimiento. - Correlacionar variaciones con cambios de red o carga del resolver. La información se actualiza automáticamente junto con el resto de las métricas, ofreciendo una visión en tiempo real del **estado de salud y desempeño de cada RPZ**. Distribución de consultas y uso de protocolos ============================================= Además del tiempo de respuesta (RTT), cada servidor RPZ incluye una serie de gráficos que permiten comprender el tipo de tráfico DNS recibido y las características del transporte y direccionamiento. .. image:: /pdns/_images/1.png :alt: Gráficos de distribución de consultas DNS, transporte, uso de IPv6 e indicadores de caché :align: center :width: 100% Distribución de tipos de registros (RR Incoming Query Distribution) ------------------------------------------------------------------- Este gráfico circular muestra el porcentaje de consultas recibidas según el tipo de registro DNS solicitado: - **A (74.0%)** – consultas de direcciones IPv4. - **AAAA (16.9%)** – consultas IPv6. - **HTTPS (8.1%)** – resoluciones seguras (HTTP/3 / DoH). - **PTR (0.7%)** – consultas inversas (IP a nombre de dominio). - **ANY (0.3%)** – consultas que solicitan todos los registros disponibles. Este gráfico permite identificar el tipo de tráfico predominante y verificar si las consultas se alinean con el propósito esperado del resolver o RPZ. Consultas entrantes TCP/UDP --------------------------- Indica la proporción de consultas recibidas por los protocolos **UDP** y **TCP**. En la mayoría de los casos, el DNS utiliza **UDP (98%)** para consultas estándar, mientras que **TCP (2%)** solo se usa cuando la respuesta supera los 512 bytes o requiere transmisión confiable (por ejemplo, transferencias de zona o validaciones DNSSEC). Uso de IPv4 / IPv6 ------------------ Este gráfico muestra la proporción de tráfico recibido por tipo de protocolo IP. En el ejemplo, **IPv6 representa el 74.3%**, mientras que **IPv4 equivale al 25.7%** del total. Esto refleja una adopción elevada de IPv6 en los resolvers conectados. El análisis de esta métrica permite: - Verificar la adopción de IPv6. - Detectar resolvers sin soporte IPv6. - Evaluar la conectividad y balance entre ambos protocolos. Caché de consultas (Hits y Misses) ---------------------------------- Este gráfico muestra la proporción entre las consultas que se resuelven directamente desde el caché (**Cache Hits**) y aquellas que requieren resolución completa (**Cache Misses**). **Cache Hits (90.8%)** indican que la respuesta ya estaba almacenada en memoria, lo que acelera la resolución y reduce el tráfico hacia Internet. **Cache Misses (9.2%)** representan consultas que no estaban en el caché, por lo que el resolver debió consultar otros servidores o realizar validaciones adicionales (por ejemplo, DNSSEC). .. note:: Atención: este gráfico se refiere específicamente al *caching de queries*. Cuanto menor sea el porcentaje de *Misses*, mejor es el rendimiento del resolver, ya que se minimiza la necesidad de realizar consultas externas adicionales y se optimiza el tiempo de respuesta global.