¿Tu DNS está sufriendo duplicación excesiva de consultas? Un análisis con datos duros

Introducción

En el DNS, cada consulta tiene un costo: el de procesarla en el servidor autoritativo. Pero para el cliente que resuelve —el recursive resolver— esa consulta es gratis. Esta asimetría económica es la misma que explica el «tragedy of the commons»: cuando un recurso es de acceso libre, los actores tienden a consumirlo hasta agotarlo, sin internalizar el impacto en los demás.

En el ecosistema DNS, este problema se manifiesta como duplicación de consultas: resolvers que envían la misma pregunta múltiples veces en intervalos breves, ya sea por impaciencia ante posibles pérdidas de paquetes UDP o por comportamientos de caché mal implementados. El resultado es un tráfico innecesario que satura servidores autoritativos, aumenta la latencia percibida por los usuarios y, en entornos como AKS, puede degradar el rendimiento de aplicaciones críticas.

Qué ocurrió

El equipo de APNIC Labs midió durante 24 horas (1 de junio de 2026) el comportamiento de resolución DNS en 35 millones de presentaciones publicitarias distribuidas globalmente. Cada presentación incluía hasta 15 URLs únicas con nombres de dominio distintos, asegurando que no hubiera caché intermedia. Todas las consultas llegaron a servidores autoritativos controlados por APNIC, permitiendo medir con precisión cuántas veces se repetía una misma consulta por nombre y tipo (A o AAAA).

Los resultados son contundentes:

• Promedio global de duplicación: 38% de todas las consultas.
• Regiones con mayor duplicación:

– China/Hong Kong (hk): 47%.

– North America (am): 28%.

– Europe (eu): 27%.

El dato más llamativo no es solo el promedio, sino la distribución:

• 90% de las consultas duplicadas ocurren 3 veces o menos.
• 58% son duplicados únicos (una sola repetición).
• Solo 1% supera las 10 repeticiones en 24 horas.

Pero el análisis temporal revela un patrón aún más preocupante: el 45% de todas las duplicaciones ocurren en los primeros 10 milisegundos después de la consulta original. Esto sugiere un comportamiento de retries agresivos en los resolvers, donde la pérdida de un paquete UDP (esperable en redes con ≤2% de pérdida) dispara una inmediata repetición, sin esperar tiempos de timeout razonables.

Impacto para DevOps, Infraestructura y Cloud

1. Carga en servidores autoritativos y costos ocultos

Cada consulta duplicada genera trabajo en el servidor autoritativo: consultar la base de datos, aplicar políticas de seguridad (como DNSSEC) y responder. En un escenario de AKS con servicios expuestos al público, esto se traduce en:

• Mayor latencia en respuestas para todos los clientes, no solo los afectados por la duplicación.
• Consumo de ancho de banda innecesario en la red del cluster (especialmente en redes con facturación por tráfico, como en proveedores cloud).
• Riesgo de rate limiting en servicios como Azure DNS o AWS Route 53, que pueden bloquear IPs por exceso de consultas.
• Sobrecarga en servicios críticos: si tu cluster depende de servicios externos con APIs públicas (ej: geolocalización, pagos), cada consulta duplicada podría agotar tus rate limits y degradar la experiencia del usuario.

2. Inconsistencias en caché y comportamiento de resolvers

El estudio de APNIC identificó picos de duplicación en intervalos de 6, 12 y 18 horas, así como en 8 y 16 horas. Estos valores no coinciden con los TTL típicos (generalmente en segundos o minutos), sino con comportamientos de cache refresh implementados por algunos resolvers.

En AKS, esto puede manifestarse como:

• Respuestas inconsistentes en aplicaciones que dependen de DNS para balanceo de carga (ej: headless services con ExternalDNS).
• Falsos positivos en monitoreo: métricas como latencia de DNS pueden inflarse sin causa real.
• Problemas de escalabilidad: si tu recursive resolver interno (ej: CoreDNS, kube-dns) está mal configurado, podría estar generando tráfico duplicado hacia los servidores autoritativos de tus dependencias.

3. Riesgos de seguridad indirectos

Aunque la duplicación no es un exploit en sí misma, revela debilidades en la implementación de resolvers que podrían ser explotadas:

• Ataques de amplificación: un atacante podría forzar a un resolver mal configurado a enviar múltiples consultas a un servidor autoritativo, amplificando el tráfico de respuesta.
• Fugas de información: si un resolver duplica consultas a servidores internos (ej: bases de datos con nombres de servicios), podría exponer patrones de acceso antes de que el TTL expire.
• Incompatibilidad con DNSSEC: servidores que no manejan correctamente los duplicados pueden fallar en la verificación de firmas, debilitando la seguridad de tu infraestructura.

Detalles técnicos

Vectores de duplicación identificados

APNIC Labs categorizó los duplicados en tres tipos principales, según el tiempo entre la consulta original y la duplicada:

• Comportamiento de caché: Los picos en 60, 120, 180 y 240 segundos coinciden con TTLs comunes (1 minuto), pero en un entorno donde cada consulta era única (sin caché entre usuarios), esto indica un cache refresh independiente del TTL real. Esto es típico en resolvers como Windows DNS Client o macOS mDNSResponder.
• Comportamiento cronológico: Los picos en 8, 12 y 16 horas sugieren que algunos resolvers (ej: dnsmasq en modo cache-only) realizan cache refreshes programados, ignorando el TTL real de las respuestas.

Componentes afectados

Los resolvers más propensos a generar duplicados incluyen:

1. systemd-resolved (versiones ≤ 252): Usa temporizadores agresivos para UDP y no maneja bien la caché en entornos con TTL bajos.

     [Resolve]
     DNSOverTLS=yes
     DNSSEC=allow-downgrade
     Cache=yes
     

1. dnsmasq (versiones ≤ 2.86): En modo cache-only, realiza refreshes cada 12 horas, independientemente del TTL.
2. Windows DNS Client (versiones ≤ Windows 11 22H2): Duplica consultas en intervalos de 6 horas si el TTL es > 0.
3. CoreDNS (versiones ≤ 1.10.1) con plugins como forward mal configurados: Puede heredar comportamientos agresivos de los resolvers upstream.

Ejemplo práctico en AKS

Si tu cluster usa CoreDNS como recursive resolver interno y apunta a un servidor autoritativo externo (ej: Azure DNS), un comportamiento típico de duplicación podría verse así:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        forward . 10.0.0.10  # Servidor autoritativo interno
        cache 30
        health
    }

Si el servidor 10.0.0.10 responde con TTL=60s, pero CoreDNS está configurado para cache refresh cada 30s, generará duplicados cada 30 segundos para la misma consulta.

Qué deberían hacer los administradores y equipos técnicos

1. Auditar el comportamiento de tu recursive resolver

• Usa eBPF para medir consultas DNS en tiempo real:

  sudo tcpdump -i any -nn -A 'port 53' | grep "duplicate"
  

O, mejor, con herramientas como Cilium o Pixie:

  px get dns --pod <nombre-pod> -n <namespace>
  

• Configura métricas en CoreDNS:

  apiVersion: v1
  kind: ConfigMap
  metadata:
    name: coredns
    namespace: kube-system
  data:
    Corefile: |
      .:53 {
          forward . 8.8.8.8
          prometheus :9153
          cache 30
      }
  

Luego revisa las métricas en Prometheus:

  rate(coredns_dns_requests_total{job="kube-dns"}[5m])
  

• Usa dnscap para capturar y analizar tráfico DNS:

  dnscap -i eth0 -w /tmp/dns.pcap
  

Luego analiza con Wireshark:

  tshark -r /tmp/dns.pcap -Y "dns.flags.response == 0 && dns.id == <id-consulta>"
  

2. Ajustar configuraciones de resolvers

Para CoreDNS/kube-dns:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        forward . /etc/resolv.conf
        cache 60  # Aumentar TTL de caché para reducir refreshes
        loop
        reload
        loadbalance
    }

• cache 60: Aumenta el TTL de la caché interna para reducir los refreshes innecesarios.
• Evita forward . /etc/resolv.conf: Si tu /etc/resolv.conf apunta a un resolver mal configurado, CoreDNS heredará sus malos hábitos.

Para systemd-resolved:

# /etc/systemd/resolved.conf
[Resolve]
DNSSEC=yes
Cache=yes
DNSStubListener=yes

• DNSSEC=yes: Habilita DNSSEC para evitar ataques de cache poisoning.
• Cache=yes: Asegúrate de que la caché esté habilitada (deshabilitada por defecto en algunas distribuciones).

Para dnsmasq:

# /etc/dnsmasq.conf
cache-size=10000
neg-ttl=3600  # Evita negaciones de caché demasiado cortas
no-resolv       # Evita consultar /etc/resolv.conf

• cache-size=10000: Aumenta el tamaño de la caché para reducir consultas a upstream.
• no-resolv: Evita que dnsmasq consulte otros resolvers si ya tiene la respuesta en caché.

3. Implementar rate limiting en servidores autoritativos

Si controlas los servidores autoritativos (ej: en Azure DNS o AWS Route 53):

• Azure DNS:

  az network dns zone update --resource-group mygroup --zone-name example.com --max-record-sets-per-second 1000
  

• AWS Route 53:

Si usas PowerDNS como servidor autoritativo:

# /etc/powerdns/pdns.conf
dnsupdate=yes
max-queue-length=5000
max-tcp-connections=2000

4. Monitorear y alertar

• Prometheus + Grafana:

  - job_name: 'dns-duplication'
    scrape_interval: 30s
    static_configs:
      - targets: ['coredns:9153']
    metrics_path: '/metrics'
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
  

Crea un dashboard con:

– rate(coredns_dns_requests_total{job="kube-dns"}[5m]) (tasa de consultas).

– histogram_quantile(0.95, sum(rate(coredns_dns_request_duration_seconds_bucket[5m])) by (le)) (latencia).

• Alertas en Grafana:

  A: rate(coredns_dns_requests_total{job="kube-dns"}[5m]) > 1000
  B: histogram_quantile(0.95, sum(rate(coredns_dns_request_duration_seconds_bucket[5m])) by (le)) > 0.5
  

Combina con alertas de timeout en tus aplicaciones.

5. Considerar alternativas de transporte

Si el problema es UDP, migra a DNS over TLS (DoT) o DNS over HTTPS (DoH) en tus resolvers:

# Ejemplo para CoreDNS con DoT
.:53 {
    forward . tls://1.1.1.1 {
        tls-servername cloudflare-dns.com
        health_check 5s
    }
    cache 60
}

• Ventajas:

– Reduce la duplicación al 0% en escenarios con pérdida de paquetes UDP.

• Desventajas:

– Requiere configuración de trust anchors para DNSSEC.

Conclusión

La duplicación de consultas DNS no es un problema menor: el 38% del tráfico medido por APNIC Labs es innecesario, con picos del 61% en regiones como el subcontinente indio. En entornos como AKS, donde la latencia y la escalabilidad son críticas, este comportamiento puede traducirse en:

• Degradación de rendimiento en aplicaciones expuestas a tráfico público.
• Costos ocultos por ancho de banda y rate limiting en servicios cloud.
• Riesgos de seguridad indirectos, como amplificación de ataques o fugas de información.

La solución no es culpar al DNS, sino optimizar la configuración de tus resolvers. Desde ajustar TTLs de caché hasta migrar a DoT/DoH, hay acciones concretas que reducen la duplicación sin sacrificar resiliencia. El primer paso es medir: sin datos, cualquier ajuste es solo especulación.