Servidor DNS
    Actualizado mayo de 2026
    CoreDNS logo

    CoreDNS Seguimiento

    Supervisa en tiempo real las tasas de consultas de CoreDNS, los índices de aciertos en caché, la latencia de resolución y las tasas de error sin necesidad de configuración.

    ¿Por qué realizar un seguimiento? CoreDNS?

    CoreDNS es el servidor DNS predeterminado para Kubernetes y entornos nativos de la nube. La supervisión de CoreDNS garantiza una resolución DNS rápida, un rendimiento óptimo de la caché y una detección de servicios fiable para tu infraestructura.

    Detección automática mediante Xitogent
    Monitorización de la tasa de consultas
    Ratio de aciertos/fallos de caché
    Seguimiento de la latencia de resolución
    Tasa de errores y SERVFAIL
    Métricas por zona
    Monitorización a nivel de plugin
    Intervalos de recolección de 1 minuto
    Umbrales de alerta personalizables para cada métrica
    Intervalos de recopilación de métricas de 1 minuto listos para usar
    ¿Qué es el monitoreo de CoreDNS?

    Monitoreo de CoreDNS, explicado

    El monitoreo de CoreDNS detecta picos de SERVFAIL, caídas en la tasa de aciertos de caché, latencia del plugin forward y reinicios por panic antes de que se conviertan en fallos de resolución DNS en todo el clúster. Como cada microservicio depende del DNS para el descubrimiento de servicios, un CoreDNS sin monitorear es un modo de fallo sin monitorear para todo su clúster de Kubernetes: los problemas de DNS aparecen como "connection refused aleatorios" en todas partes. Xitoring detecta automáticamente su CoreDNS, raspa :9153/metrics y envía las alertas a Slack, PagerDuty, Telegram o su sistema de guardias existente.

    Métricas

    Lo que monitorizamos

    Consultas/s

    Tasa de consultas DNS.

    Ratio de aciertos de caché

    Porcentaje de consultas servidas desde caché.

    Latencia de resolución

    Tiempo medio de resolución DNS.

    Tasa de SERVFAIL

    Porcentaje de resoluciones fallidas.

    Tasa NXDOMAIN

    Tasa de consultas a dominios inexistentes.

    Latencia upstream

    Tiempo de respuesta de consultas reenviadas.

    Latencia del plugin forward

    `coredns_forward_request_duration_seconds` por resolver upstream. Separa la latencia interna de CoreDNS de la latencia del resolver upstream, fundamental para diagnosticar un 8.8.8.8 lento frente a un CoreDNS lento en sí mismo.

    Tasa de solicitudes forward

    `coredns_forward_request_count_total` por upstream. Combinada con la tasa de aciertos de caché, muestra cuánto tráfico abandona realmente CoreDNS para la resolución upstream.

    Caché de conexiones proxy

    `coredns_proxy_conn_cache_hits_total` / `_misses_total`. Rastrea la reutilización de conexiones TCP a los resolvers upstream: una tasa baja de aciertos significa rotación de conexiones, lo que aumenta la latencia upstream.

    Fallos del plugin health

    `coredns_health_request_failures_total`: el propio recuento de fallos del plugin `health:8080`. Un valor distinto de cero significa que la sonda de actividad está fallando de forma intermitente.

    Panics

    `coredns_panics_total`: cualquier valor distinto de cero es un bug de CoreDNS o un fallo de plugin que provocó un panic de goroutine. Combínelo con el recuento de reinicios para obtener el contexto post-mortem completo.

    Runtime de Go

    `process_resident_memory_bytes` (RSS), `go_goroutines` (recuento de goroutines, detecta fugas), `go_gc_duration_seconds` (tiempo de pausa del GC). Crecimiento de memoria sin reinicios = fuga; crecimiento del recuento de goroutines = plugin bloqueado o upstream lento.

    Desencadenantes y alertas

    Configurables condiciones de activación de alertas

    Configura alertas personalizadas en tu panel de control para recibir una notificación en cuanto las métricas de «CoreDNS» superen los umbrales que hayas definido.

    CoreDNS panel de control de la configuración de los desencadenantes de supervisión

    Tasa de SERVFAIL

    crítico

    Se dispara ante una alta tasa de fallos de resolución.

    Ratio de aciertos de caché

    advertencia

    Alerta cuando la efectividad de la caché cae.

    Latencia de resolución

    advertencia

    Se activa en caso de resolución DNS lenta.

    Tasa de consultas

    advertencia

    Se dispara ante un volumen de consultas inusual.

    01

    Importancia de monitorización de CoreDNS

    El DNS es la base de la conectividad de red. Una resolución DNS lenta o fallida afecta a todos los servicios de su infraestructura.

    • Garantizar una resolución DNS rápida
    • Detectar picos de SERVFAIL al instante
    • Monitorizar la caché para un rendimiento óptimo
    • Seguir el estado de los resolvers upstream
    Monitorización de CoreDNS
    Analítica DNS
    02

    Por qué elegir Xitoring

    Monitorización CoreDNS sin configuración.

    • Instalación con un solo comando
    • Nodos globales
    • Panel unificado
    • Alertas multicanal
    Vista general
    Alertas
    Casos de uso

    Escenarios habituales de monitoreo de CoreDNS

    Dónde suele ejecutarse CoreDNS hoy en día — y qué podría salir mal si nadie está vigilando.

    DNS dentro de una aplicación de Kubernetes

    Cada parte de una aplicación de Kubernetes utiliza CoreDNS para encontrar todas las demás partes. Cuando se ralentiza o empieza a fallar, los usuarios ven errores extraños e intermitentes en toda la aplicación. Detectamos la ralentización en el momento en que comienza, para que un pequeño problema de DNS no se manifieste a los clientes como una interrupción misteriosa.

    Clusters grandes con cachés DNS locales

    Las configuraciones de Kubernetes más grandes colocan una pequeña caché DNS en cada servidor para mantener la velocidad. Cuando una de esas cachés funciona mal, solo una parte del tráfico se interrumpe — lo que dificulta su detección. Nos aseguramos de que cada una cumpla su función para que un solo nodo defectuoso no degrade silenciosamente a una fracción de tus usuarios.

    DNS público para tu dominio

    Cuando CoreDNS es el que responde a las consultas DNS de tu dominio en internet, una interrupción significa que la gente no puede acceder a tu sitio en absoluto. Vigilamos las señales que demuestran que el servicio está saludable y respondiendo, para que la marca y los ingresos no se vean afectados silenciosamente mientras el DNS falla en silencio.

    Antes de empezar

    Requisitos previos para CoreDNS

    Asegúrate de tener todo esto en su sitio — la mayoría de las instalaciones tardan 60 segundos una vez listo.

    • CoreDNS 1.x ejecutándose en el servidor
    • Plugin Prometheus habilitado en tu Corefile (puerto predeterminado 9153)
    • Conectividad de red desde Xitogent hacia el endpoint de metrics
    Guía de configuración

    Empieza con minutos

    1

    Instalar Xitogent en tu servidor

    Si aún no lo has hecho, instala el agente de monitorización ligero Xitogent en el host que ejecuta CoreDNS.

    curl -s https://xitoring.com/install.sh | sudo bash -s -- --key=YOUR_API_KEY
    2

    Habilitar el plugin prometheus en CoreDNS

    CoreDNS expone métricas en formato Prometheus a través de su plugin prometheus (endpoint por defecto :9153/metrics). Añade `prometheus :9153` a tu Corefile, recarga CoreDNS y confirma que el endpoint de metrics es accesible desde el host del agente.

    sudo xitogent integrate
    3

    Habilitar la integración de CoreDNS

    Usa el panel de Xitoring o la CLI para habilitar la integración de CoreDNS. Xitogent detecta automáticamente el endpoint de metrics y comienza a recolectar métricas de consultas, caché y latencia.

    4

    Configurar umbrales de alerta (opcional)

    Define umbrales personalizados para la tasa de SERVFAIL, el ratio de aciertos de caché o la latencia de resolución para recibir notificaciones en cuanto la fiabilidad o el rendimiento del DNS se degraden.

    5

    Verifica que funciona

    Ejecuta este comando en el servidor para confirmar que Xitogent ha detectado la integración. En unos 30 segundos comenzarán a llegar métricas nuevas a tu panel.

    sudo xitogent status

    Con frecuencia preguntas formuladas

    ¿CoreDNS de Kubernetes?
    Sí, CoreDNS es totalmente compatible con Kubernetes.
    ¿Métricas de Prometheus?
    Xitogent lee el punto final de métricas de Prometheus de CoreDNS.
    ¿Qué hace el plugin kubernetes?
    El plugin `kubernetes` observa la API de Kubernetes en busca de cambios en Service, Endpoint y Pod, y sintetiza registros DNS para ellos: resoluciones `..svc.cluster.local`, registros ESS de servicios headless, IPs de pods. También habilita funciones de descubrimiento de servicios como los registros SRV para puertos con nombre. Monitoréelo junto con `forward` (que gestiona el DNS externo), ya que comparten el pipeline de solicitudes.
    ¿Cómo monitoreo la tasa de aciertos de caché de CoreDNS?
    Calcúlela a partir de Prometheus: `coredns_cache_hits_total / (coredns_cache_hits_total + coredns_cache_misses_total)`; objetivo 80%+ para DNS de clúster, 95%+ para NodeLocal DNSCache. Tasas de aciertos bajas suelen significar que los TTL son demasiado cortos (el TTL del DNS del clúster es de 30s por defecto, ajustable) o que el conjunto de trabajo de consultas únicas supera el tamaño de la caché.
    ¿Qué significa NXDOMAIN en las métricas de CoreDNS?
    `NXDOMAIN` (dominio inexistente) en `coredns_dns_response_rcode_count_total` significa que un nombre consultado no existe. Cierta cantidad de NXDOMAIN es normal (errores tipográficos, escáneres); los picos indican dominios de búsqueda mal configurados, aplicaciones que buscan servicios inexistentes o intentos de amplificación DNS. SERVFAIL es más preocupante: significa que CoreDNS no pudo obtener una respuesta en absoluto (fallo upstream, error de plugin).
    ¿Cómo depuro CoreDNS en Kubernetes?
    Tres capas: (1) revisar los logs del pod (`kubectl logs -n kube-system -l k8s-app=kube-dns`), (2) probar la resolución desde dentro de un pod (`kubectl exec... -- nslookup kubernetes.default`), (3) leer las métricas de Prometheus para ver la tasa de SERVFAIL por plugin. El plugin `log` puede añadirse temporalmente al Corefile para obtener una salida de log por consulta. Use `dnstap` para tracing seguro en producción a alto volumen sin afectar a la latencia de las consultas.
    ¿Cómo monitoreo la latencia del plugin forward de CoreDNS?
    Lea el histograma `coredns_forward_request_duration_seconds`, etiquetado por la dirección del resolver upstream. Rastree p95 y p99 por upstream: los upstreams lentos aparecen aquí, separados de la latencia interna de CoreDNS. El plugin `forward` también expone `coredns_forward_responses_total` por rcode para las tasas de SERVFAIL específicas por upstream. Alerte cuando p99 > 500 ms por upstream.
    ¿Cuándo debo usar NodeLocal DNSCache?
    Clúster de tamaño > ~100 nodos, o cualquier clúster que experimente condiciones de carrera UDP en conntrack (timeouts de DNS intermitentes bajo carga). NodeLocal DNSCache ejecuta un sidecar de caché de CoreDNS en cada nodo enlazando `169.254.20.10:53`, eliminando la entrada de la tabla conntrack por consulta. La carga del CoreDNS del clúster suele caer entre un 70 y un 90%, y la latencia p99 del DNS baja a la velocidad del disco local. Monitoree la tasa de aciertos por nodo (objetivo 95%+).
    ¿Qué versiones de CoreDNS son compatibles?
    CoreDNS 1.11.x, 1.12.x y 1.13.x son totalmente compatibles. La 1.12 añadió el descubrimiento de servicios multiclúster MCS-API, la configuración del timeout de arranque y la gestión de nombres de host IPv6 en el plugin `kubernetes`. La 1.13.2 (diciembre de 2025) es la estable actual. K8s 1.30+ incluye CoreDNS 1.11.x por defecto; las distribuciones más nuevas incluyen 1.12.x. Xitogent detecta automáticamente la versión y se adapta.

    Empieza a seguir a CoreDNS hoy

    Se configura en menos de 60 segundos. No se necesita tarjeta de crédito. Estadísticas completas desde el primer día.

    Empieza tu prueba gratuita

    Sigue explorando

    Relacionado Integraciones