DNS: Movimientos poderosos con dig/drill — comandos que responden al 90% de los misterios DNS

La mentalidad DNS: deja de adivinar, empieza a localizar el salto

DNS es una base de datos distribuida con caché, delegación y fallos parciales como característica de diseño. Si lo tratas como un servidor único (“el DNS está caído”), perderás tiempo. Si lo tratas como una cadena de custodia, arreglarás las cosas más rápido.

La mayoría de los misterios DNS se reducen a uno de estos:

• Preguntaste al lugar equivocado. Diferentes resolutores, diferentes vistas (split-horizon), diferentes contenidos en caché.
• Preguntaste al lugar correcto por el nombre/tipo equivocado. A/AAAA vs CNAME/ALIAS, punto final faltante en archivos de zona, dominios de búsqueda en resolutores.
• La cadena está rota. Desajuste de delegación, glue incorrecto, delegación lame, registrador no actualizado, desajuste de DS.
• Está en caché. TTLs, cache negativa, respuestas obsoletas, prefetch del resolutor, cachés de cliente.
• Es “correcto” pero operativamente incorrecto. Apuntaste al balanceador que no es accesible desde esa red, o devolviste un AAAA IPv6 para un servicio que no escucha en v6.
• Es política. Validación DNSSEC, filtrado, reescritura de NXDOMAIN, proxies empresariales o resolutores internos que hacen cosas “útiles”.

Tu trabajo durante un incidente es responder, con evidencia: quién respondió, qué camino se siguió, y qué cambiará si lo arreglamos ahora (TTL/cachés). dig y drill son tu navaja multiusos y tu linterna.

Una cita para tener en mente, porque la depuración DNS es un problema de fiabilidad disfrazado de consulta:

Idea parafraseada (John Allspaw): “No resuelves incidentes culpando a las personas; los resuelves mejorando sistemas y entendiendo cómo ocurre realmente el trabajo.”

Broma #1: DNS es el único sistema donde “está en caché” es tanto una excusa como una ley de la física.

Datos interesantes sobre DNS (útiles en incidentes)

1. DNS es anterior a la Internet moderna tal como la experimentas. Reemplazó el modelo centralizado HOSTS.TXT a principios de los 80, cuando “todos editan el mismo archivo” dejó de escalar.
2. “Recursivo” y “autoritativo” son trabajos distintos. Los servidores autoritativos publican la verdad de las zonas; los resolutores recursivos obtienen la verdad y la cachean para los clientes.
3. El caché negativo existe. Un NXDOMAIN (o NODATA) puede ser cacheado, guiado por las reglas SOA “minimum”/TTL negativo—así que un registro fijo aún puede “no existir” por un tiempo.
4. Los glue records existen porque el dilema huevo-gallina es real. Si el nameserver tiene un nombre dentro de la zona que sirve, el padre debe proporcionar glue A/AAAA para arrancar la resolución.
5. El aplanamiento de CNAME fue una solución operativa. La especificación DNS prohíbe CNAME en el apex de zona, pero la gente quiere comportamiento apex→CDN—de ahí ALIAS/ANAME o aplanamiento del proveedor.
6. EDNS0 se añadió porque los mensajes DNS crecieron. El DNS clásico sobre UDP tenía límites de tamaño; EDNS0 lo extiende para que los registros modernos (especialmente DNSSEC) quepan sin recurrir inmediatamente a TCP.
7. Los fallos de DNSSEC parecen “SERVFAIL aleatorio”. Muchos resolutores ocultan los detalles a menos que preguntes correctamente; los errores de validación a menudo parecen inicialmente una caída.
8. Los resolutores no están obligados a comportarse igual. Algoritmos de caché, prefetch, “serve stale”, caching agresivo de NSEC y estrategias de timeout varían—así que “funciona en 8.8.8.8” es evidencia, no veredicto.

Guía de diagnóstico rápido (primero/segundo/tercero)

Primero: confirma qué está haciendo realmente el cliente

• ¿Qué resolutor está usando el cliente? VPN corporativa, router local, stub de systemd-resolved, DoH en el navegador?
• ¿Qué nombre y tipo? A vs AAAA, expansión de sufijos de búsqueda, punto final faltante, el uso de mayúsculas no importa (DNS es insensible a mayúsculas en etiquetas).
• ¿Cuál es exactamente el síntoma? NXDOMAIN, SERVFAIL, timeout, IP equivocada, intermitente?

Segundo: compara recursivo vs autoritativo

• Pregunta a un resolutor recursivo público conocido (o a dos) y compara: ¿están de acuerdo?
• Pregunta directamente a los servidores autoritativos. Si los autoritativos son correctos pero el recursivo está equivocado, estás en terreno de caché/propagación/validación.
• Traza la delegación. Si la cadena se rompe en el padre, arregla registrador/NS/glue/DS—no el archivo de zona.

Tercero: decide si estás combatiendo caché, delegación, alcanzabilidad o política

• Caché: TTLs, TTL negativo, cachés clientes, resolutor serve-stale, NS obsoletos en cachés.
• Delegación: NS desajustados en padre vs hijo, glue incorrecto, delegación lame.
• Alcanzabilidad: UDP/53 bloqueado, TCP/53 bloqueado (importante para DNSSEC/respuestas grandes), problemas en rutas anycast.
• Política: Validación DNSSEC, filtrado RPZ, reescritura de NXDOMAIN, discrepancias de vista split-horizon.

Si haces esos tres pasos, tendrás la afirmación del problema correcta rápido: “El autoritativo es correcto pero el Resolutor X cacheó NXDOMAIN por 10 minutos debido al SOA minimum,” es mejor que “DNS es raro”.

Movimientos con Dig/drill: tareas reales, comandos, salidas, decisiones

A continuación hay tareas prácticas que harás en incidentes reales. Cada una incluye: un comando, qué significa la salida y qué decisión tomas después. Usa dig si lo tienes; usa drill cuando quieras trazado incorporado y una perspectiva algo distinta. Uso ambos porque los sistemas en producción no se preocupan por tus preferencias.

Tarea 1: Identificar el resolutor que realmente responde (la comprobación “quién respondió”)

cr0x@server:~$ dig example.com A +comments

; <<>> DiG 9.18.24 <>> example.com A +comments
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14067
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;example.com.                   IN      A

;; ANSWER SECTION:
example.com.            300     IN      A       93.184.216.34

;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Wed Dec 31 10:12:44 UTC 2025
;; MSG SIZE  rcvd: 56

Significado: La línea SERVER te dice quién respondió. Aquí es 127.0.0.53, el stub de systemd-resolved, no tu resolutor corporativo ni uno público.

Decisión: Si depuras “por qué mi portátil se comporta distinto”, consulta el resolutor ascendente real directamente (tarea siguiente) e inspecciona la configuración del resolutor local por separado.

Tarea 2: Consultar un resolutor recursivo específico para comparar comportamiento

cr0x@server:~$ dig @1.1.1.1 example.com A +noall +answer +comments

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50289
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
example.com.            300     IN      A       93.184.216.34

Significado: Preguntaste directamente al resolutor de Cloudflare. Si esto difiere de tu respuesta local, probablemente estás ante split-horizon, filtrado o distinto estado de caché.

Decisión: Compara 2–3 resolutores (el corporativo, uno público). El acuerdo entre ellos sugiere que la verdad autoritativa es consistente; el desacuerdo sugiere diferencia de vista/política/caché.

Tarea 3: Comprobar TTLs para predecir “cuándo verán los usuarios la corrección”

cr0x@server:~$ dig @8.8.8.8 api.corp.example A +noall +answer

api.corp.example.       17      IN      A       203.0.113.10

Significado: El TTL es 17 segundos. Es el tiempo restante de caché en este resolutor en este momento, no necesariamente el TTL configurado en la zona.

Decisión: Si el TTL es bajo, las correcciones se propagarán rápido. Si es alto, esperas, o sorteas el problema (lista de IPs temporales, registro paralelo, cambiar resolutor cliente si es imprescindible). No prometas recuperación instantánea con un TTL de 12 horas a menos que disfrutes llamadas incómodas.

Tarea 4: Preguntar directamente a servidores autoritativos para evitar la caché recursiva

cr0x@server:~$ dig ns1.dns-provider.example api.corp.example A +norecurse +noall +answer +comments

api.corp.example.       300     IN      A       203.0.113.10

Significado: +norecurse indica al servidor no hacer recursión. Si aún responde, estás golpeando un servidor autoritativo para esa zona (o un resolutor que te ignora, pero los servidores autoritativos reputables cumplen).

Decisión: Si los autoritativos responden correctamente pero los resolutores están equivocados, deja de editar archivos de zona y piensa en cachés, DNSSEC o desajuste de delegación.

Tarea 5: Trazar la ruta de delegación de extremo a extremo (encontrar dónde se rompe la cadena)

cr0x@server:~$ dig +trace www.example.org A

; <<>> DiG 9.18.24 <<>> +trace www.example.org A
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 1 ms

org.                    86400   IN      NS      a0.org.afilias-nst.info.
org.                    86400   IN      NS      a2.org.afilias-nst.info.
...
example.org.            172800  IN      NS      ns1.dns-provider.example.
example.org.            172800  IN      NS      ns2.dns-provider.example.
...
www.example.org.        300     IN      A       198.51.100.44

Significado: +trace recorre root → TLD → autoritativos. Si falla en el paso TLD, la delegación en el registrador/padre está rota. Si falla en el paso autoritativo, tus servidores autoritativos no responden correctamente.

Decisión: Arregla la capa donde la traza se detiene. No toques el código de la aplicación. DNS no se preocupa por tu pipeline de despliegue.

Tarea 6: Usar drill para trazar y ver ayudas DS/DNSSEC más claramente

cr0x@server:~$ drill -TD www.example.org

;; Number of trusted keys: 1
;; Chasing: www.example.org. A
www.example.org.        300     IN      A       198.51.100.44
;; Chase successful

Significado: drill -T traza; -D aporta detalles relacionados con DNSSEC. “Chase successful” es una comprobación rápida de que la cadena se resuelve en principio.

Decisión: Si drill no puede hacer chase por DNSSEC, sospecha desajuste de DS, firmas expiradas o publicación incorrecta de DNSKEY.

Tarea 7: Diagnosticar SERVFAIL comprobando la validación DNSSEC explícitamente

cr0x@server:~$ dig @1.1.1.1 broken-dnssec.example A +dnssec +multi

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 24670
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Significado: Algunos resolutores devuelven SERVFAIL cuando la validación DNSSEC falla (o cuando las búsquedas ascendentes fallan). +dnssec solicita registros DNSSEC; no fuerza validación, pero te ayuda a ver si RRSIGs están presentes al consultar autoritativos.

Decisión: Pregunta directamente a los autoritativos con +dnssec (tarea siguiente). Si el autoritativo sirve firmas rotas o falta DNSKEY, arregla la firma en el proveedor o quita el DS en el padre temporalmente (con cuidado).

Tarea 8: Verificar que el material DNSSEC autoritativo existe (DNSKEY, RRSIG)

cr0x@server:~$ dig ns1.dns-provider.example broken-dnssec.example DNSKEY +norecurse +dnssec +noall +answer

broken-dnssec.example.  3600    IN      DNSKEY  257 3 13 ( ... )
broken-dnssec.example.  3600    IN      RRSIG   DNSKEY 13 2 3600 ( ... )

Significado: Estás comprobando que la zona publica DNSKEY y está firmada (RRSIG). Si DNSKEY existe pero los resolutores devuelven SERVFAIL, el DS en el padre puede no coincidir, o las firmas pueden estar expiradas.

Decisión: Si DNSKEY/RRSIG faltan o están mal, arregla la firma de la zona. Si parecen presentes, comprueba el DS en el padre (Tarea 9).

Tarea 9: Comprobar el registro DS en el padre (¿está intacta la cadena de confianza?)

cr0x@server:~$ dig +trace broken-dnssec.example DS

; <<>> DiG 9.18.24 <<>> +trace broken-dnssec.example DS
...
example.                86400   IN      NS      a.iana-servers.net.
...
broken-dnssec.example.  86400   IN      DS      12345 13 2 ( ... )

Significado: El DS en el padre apunta al DNSKEY de la zona hija. Si rotaste claves y no actualizaste el DS (o quitaste la firma pero dejaste DS), los resolutores que validan fallan.

Decisión: Alinea DS y DNSKEY. Si estás en medio de un incidente y el negocio necesita disponibilidad ahora, quitar el DS en el padre puede restaurarla (pero trátalo como una reversión controlada y con seguimiento).

Tarea 10: Detectar cadenas CNAME y dónde se rompen

cr0x@server:~$ dig cdn.example.net A +noall +answer

cdn.example.net.        60      IN      CNAME   cdn.vendor.example.
cdn.vendor.example.     60      IN      CNAME   edge123.vendor.example.
edge123.vendor.example. 20      IN      A       192.0.2.80

Significado: No tienes “un problema con el registro A”, tienes una cadena. Una ruptura en cualquier punto devuelve NXDOMAIN o SERVFAIL según las circunstancias.

Decisión: Si hay cadena, consulta cada salto directamente. Cuando algo desaparece, arregla esa zona/proveedor específico. Considera reducir la profundidad de cadenas; las cadenas largas amplifican TTL y modos de fallo.

Tarea 11: Diferenciar NXDOMAIN vs NODATA (mismo nombre, fallo distinto)

cr0x@server:~$ dig nonexistent.example.com A +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10832
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

cr0x@server:~$ dig www.example.com TXT +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40420
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Significado: NXDOMAIN significa que el nombre no existe. NOERROR con cero respuestas a menudo significa que el nombre existe, pero no el tipo de registro pedido (NODATA). Se cachean de forma diferente e implican distintas malas configuraciones.

Decisión: Si NXDOMAIN, revisa el contenido de la zona y la delegación. Si NODATA, probablemente olvidaste publicar ese tipo de registro (por ejemplo, TXT para verificación) o lo publicaste en otra vista.

Tarea 12: Inspeccionar el TTL de caché negativo vía SOA (por qué persiste NXDOMAIN)

cr0x@server:~$ dig example.com SOA +noall +answer

example.com.            300     IN      SOA     ns1.dns-provider.example. hostmaster.example.com. 2025123101 7200 900 1209600 600

Significado: El último campo SOA (aquí 600) se usa comúnmente como TTL de caché negativo en la práctica. Si eliminaste un registro por error y lo restauraste, los resolutores pueden mantener “no existe” durante ese tiempo.

Decisión: Si el TTL negativo es alto, planifica una recuperación retardada tras arreglar NXDOMAIN. En emergencias puedes mitigar respondiendo con un nombre distinto (etiqueta nueva) que no esté en caché negativo.

Tarea 13: Validar delegación: comparar NS en el padre vs NS en el hijo

cr0x@server:~$ dig example.org NS +noall +answer

example.org.            172800  IN      NS      ns1.dns-provider.example.
example.org.            172800  IN      NS      ns2.dns-provider.example.

cr0x@server:~$ dig @ns1.dns-provider.example example.org NS +norecurse +noall +answer

example.org.            3600    IN      NS      ns1.dns-provider.example.
example.org.            3600    IN      NS      ns2.dns-provider.example.
example.org.            3600    IN      NS      ns3.dns-provider.example.

Significado: El padre dice ns1+ns2; la zona hija dice ns1+ns2+ns3. Ese desajuste no siempre es fatal, pero es fuente clásica de comportamiento inconsistente y “algunos resolutores preguntan al servidor equivocado”.

Decisión: Alinea los conjuntos NS entre padre e hijo. Durante incidentes, elimina NS muertos o incorrectos de ambos lados; los servidores lame aumentan timeouts y pueden provocar tormentas de reintentos en resolutores.

Tarea 14: Detectar delegación lame (NS listado pero no autoritativo)

cr0x@server:~$ dig @ns3.dns-provider.example example.org SOA +norecurse +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 61120
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

Significado: Si un NS está listado pero se niega o devuelve SERVFAIL/REFUSED a consultas autoritativas, algunos resolutores perderán tiempo en él. Eso es “delegación lame” en la práctica.

Decisión: Elimina ese NS de la delegación (y/o corrige su configuración). Los timeouts aquí aparecen como cargas lentas de páginas y fallos intermitentes.

Tarea 15: Comprobar si el fallback a TCP funciona (respuestas grandes, DNSSEC, UDP truncado)

cr0x@server:~$ dig @8.8.8.8 dnssec-large.example TXT +dnssec +noall +comments

;; Truncated, retrying in TCP mode.

cr0x@server:~$ dig @8.8.8.8 dnssec-large.example TXT +dnssec +tcp +noall +answer

dnssec-large.example.   300     IN      TXT     "v=some-long-value..."

Significado: Si UDP se trunca, los resolutores reintentan con TCP. Si TCP/53 está bloqueado en algún punto (firewall, security group, proxy corporativo), obtienes fallos misteriosos que se correlacionan con el tamaño del registro.

Decisión: Asegura que TCP/53 esté permitido entre resolutores y servidores autoritativos (y desde clientes a resolutores si aplica). No “optimices la seguridad” bloqueando TCP/53 sin entender DNSSEC y los tamaños de respuesta modernos.

Tarea 16: Probar DNS split-horizon consultando resolutores internos vs externos

cr0x@server:~$ dig @10.0.0.53 app.internal.example A +noall +answer

app.internal.example.   30      IN      A       10.10.20.15

cr0x@server:~$ dig @1.1.1.1 app.internal.example A +noall +comments

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5904
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Significado: El resolutor interno responde con una dirección RFC1918; el resolutor público dice NXDOMAIN. Eso es split-horizon intencional—hasta que deja de serlo. Si clientes VPN usan DoH pública, no verán registros internos.

Decisión: Decide la política: fuerza el uso de resolutor interno en dispositivos gestionados (y deshabilita DoH no gestionado), o publica equivalentes públicos. No ignores que el split-horizon se filtra en el comportamiento de las apps.

Tarea 17: Verificar DNS inverso (PTR) para correo, registro y “por qué este proveedor nos bloquea”

cr0x@server:~$ dig -x 203.0.113.10 +noall +answer

10.113.0.203.in-addr.arpa. 3600 IN PTR mailout.example.com.

Significado: Existe DNS inverso y apunta a un hostname. Muchos sistemas (especialmente correo) lo usan como una señal débil de identidad.

Decisión: Si falta o está mal, arréglalo con el propietario de la IP (a menudo el proveedor cloud). También asegúrate de forward-confirmed reverse DNS donde importe (PTR apunta a nombre y ese nombre resuelve de vuelta a la misma IP).

Tarea 18: Medir latencia y detectar timeouts rápidamente

cr0x@server:~$ dig @9.9.9.9 www.example.com A +stats +tries=1 +time=2

; <<>> DiG 9.18.24 <<>> @9.9.9.9 www.example.com A +stats +tries=1 +time=2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31869
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
www.example.com.        60      IN      A       198.51.100.44
;; Query time: 187 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (UDP)
;; WHEN: Wed Dec 31 10:20:12 UTC 2025
;; MSG SIZE  rcvd: 59

Significado: Obtienes el tiempo de consulta en milisegundos. Un pico aquí puede ser ruta de red, sobrecarga del resolutor, timeouts ascendentes por delegación lame, o filtrado de paquetes.

Decisión: Si los tiempos de consulta son altos, compara resolutores y consulta autoritativos directamente. Si el autoritativo es rápido pero el recursivo lento, el cuello de botella es el resolutor. Si el autoritativo es lento/inaccesible, arregla esa capa.

Broma #2: Si haces DNS a las 3 a.m., recuerda: los registros son inmutables hasta que dejas de teclear.

Tres mini-historias corporativas desde las trincheras DNS

Incidente #1: La caída causada por una suposición errónea

Empresa: SaaS mediana, clientes globales, dos regiones cloud. Lanzaron un nuevo endpoint de servicio detrás de un CDN. El equipo añadió un CNAME y siguió adelante. Todos probaron desde sus portátiles. Todo funcionó.

El incidente empezó con “algunos clientes no pueden alcanzar la API”. Los síntomas estaban claramente divididos por geografía. En una región estaba bien; en otra hacía timeout. Las métricas de aplicación parecían normales, porque el tráfico nunca llegó.

La suposición errónea: “Si DNS público resuelve, resuelve en todas partes”. En realidad, un subconjunto de clientes empresariales usaba resolutores recursivos que aún consultaban un nameserver autoritativo antiguo del proveedor previo—porque la delegación en el padre se había actualizado, pero un NS viejo permaneció listado semanas durante una migración parcial. Algunos resolutores cachearon la delegación anterior y siguieron intentando el servidor muerto. A veces conseguían éxito tras reintentos… a veces no. Intermitente, lento y enloquecedor.

La depuración fue cuestión de trazar desde la red afectada. dig +trace mostró que el padre anunciaba un conjunto NS que incluía un servidor que ya no servía la zona. Consultar ese servidor directamente devolvía REFUSED. El grupo de “funciona para mí” tenía resolutores que por casualidad no consultaron el NS lame.

La reparación fue aburrida: alinear registros NS en padre e hijo; eliminar el NS muerto; bajar TTLs de NS durante la ventana de migración; y validar desde varios resolutores antes de declarar victoria. El postmortem fue más sobre proceso: las migraciones necesitan una checklist y una puerta “hecho cuando la delegación coincide”.

Incidente #2: La optimización que salió mal

Otra empresa, mayor postura de seguridad. Decidieron que DNS debía ser “rápido” y redujeron TTLs agresivamente para la mayoría de registros—30 segundos en todo. La lógica: conmutación más rápida, reversión más rápida, menor riesgo.

Luego introdujeron una dependencia en un proveedor de autenticación externo con una larga cadena CNAME y DNSSEC. En un día normal, bien. En un mal día, sus resolutores recursivos se vieron colapsados. TTL bajos significaban fallos constantes de caché. Los resolutores se vieron forzados a rehacer la cadena repetidamente, tirando sobrecarga de DNSKEY/RRSIG y ocasionalmente cayendo a TCP cuando las respuestas eran grandes.

El primer síntoma fue latencia elevada en los inicios de sesión, no una caída total. El segundo síntoma fueron SERVFAIL “aleatorios”, porque los resolutores estaban sobrecargados y agotaban timeouts ascendentes. El tercer síntoma fue un equipo de infraestructura convencido de que “era el proveedor de autenticación” mientras el proveedor señalaba que estaban sanos y que eran tus resolutores los que luchaban.

La solución eventual: dejar de tratar TTL como una perilla de rendimiento que puedes bajar sin consecuencias. Aumentaron TTLs para registros estables, mantuvieron TTL bajos solo para nombres que realmente necesitaban steering rápido, y añadieron capacidad a los resolutores. También dejaron de bloquear TCP/53 en egress “porque UDP es suficiente”. No lo era.

Lección: TTL bajo no es un almuerzo gratis. Es una factura recurrente que pagas en carga de resolutores y amplificación de dependencias upstream, especialmente con DNSSEC y cadenas.

Incidente #3: La práctica aburrida pero correcta que salvó el día

Otra organización, otro día. Ejecutaban su propio DNS autoritativo con un proveedor gestionado y tenían la costumbre que parecía papeleo: antes de cualquier cambio, capturaban salidas “antes” de SOA, NS y los registros afectados desde ambos servidores autoritativos y dos resolutores públicos. Guardaban los fragmentos en el ticket de cambio.

Un cambio del viernes introdujo un problema sutil: un ingeniero añadió un registro AAAA apuntando a una nueva dirección IPv6 para un servicio que en realidad no era alcanzable desde todas las redes. El servicio era dual-stack en una región y solo v4 en otra. Usuarios en redes que preferían IPv6 tuvieron timeouts. Usuarios solo IPv4 estaban bien. El monitoreo, mayoritariamente v4, permaneció en verde.

Porque tenían instantáneas “antes”, demostraron rápidamente que el único cambio DNS fue AAAA. Luego reprodujeron consultando A y AAAA por separado y probando conectividad. El DNS estaba “correcto”, pero el despliegue no lo estaba. La mitigación más rápida fue quitar AAAA (o enrutar IPv6 adecuadamente), no pelear con los resolutores.

La práctica aburrida—capturar salidas base con dig y comprobar A/AAAA por separado—convirtió una espiral de culpas entre equipos en una solución de 30 minutos. El informe del incidente fue corto. Ese es el sueño.

Errores comunes: síntoma → causa raíz → corrección

• Síntoma: “Algunos usuarios obtienen NXDOMAIN para un registro que ahora existe.”

  Causa raíz: Caché negativo tras una eliminación o error reciente; SOA negative TTL alto; algunos resolutores cachearon NXDOMAIN.

  Corrección: Comprueba SOA (TTL negativo), espera o cambia la etiqueta temporalmente; mantén el TTL negativo razonable para zonas que cambian a menudo.

• Síntoma: “Funciona en DNS público, falla en VPN corporativa.”

  Causa raíz: Vistas split-horizon, filtrado RPZ, o resolutor interno que devuelve IPs privadas no alcanzables desde la red cliente.

  Corrección: Consulta ambos resolutores directamente; alinea vistas o fuerza el uso del resolutor correcto; evita devolver direcciones no enrutable a clientes itinerantes.

• Síntoma: “SERVFAIL en resolutores que validan, NOERROR en los que no validan.”

  Causa raíz: Desajuste DS/DNSKEY de DNSSEC, firmas expiradas, falta DNSKEY en algunos nodos autoritativos.

  Corrección: Valida DS mediante trace; arregla firma o DS; asegura que todos los nodos autoritativos sirvan material DNSSEC consistente.

• Síntoma: “DNS intermitente y lento; a veces 2–5 segundos.”

  Causa raíz: Delegación lame o NS muertos en conjuntos padre/hijo provocando reintentos; resolutor ciclando la lista NS.

  Corrección: Compara NS en padre e hijo; consulta cada NS para SOA con +norecurse; elimina NS muertos; baja TTL de NS durante la transición.

• Síntoma: “Registro A parece correcto, pero los clientes aún reciben la IP vieja.”

  Causa raíz: TTL aún alto en cachés; caches stub locales; navegadores con DoH; caché a nivel de aplicación.

  Corrección: Comprueba TTL desde el resolutor afectado; consulta autoritativo; vacía la caché correcta (systemd-resolved, nscd, unbound) si la controlas; si no, espera o realiza un avance con solapamiento.

• Síntoma: “Solo fallan TXT grandes; búsquedas pequeñas bien.”

  Causa raíz: Problemas de fragmentación UDP, MTU en el camino EDNS, o TCP/53 bloqueado para fallback.

  Corrección: Prueba con dig +tcp; permite TCP/53; considera bajar el tamaño UDP EDNS en resolutores; evita registros gigantes cuando sea posible.

• Síntoma: “El cambio a CDN no funcionó; parte del tráfico aún va al origen.”

  Causa raíz: Cadena CNAME cacheada en distintos estados; registros obsoletos en resolutores; múltiples vistas o múltiples proveedores autoritativos durante la migración.

  Corrección: Mapea la cadena y TTLs en cada salto; minimiza la profundidad de cadena; asegura una única fuente autoritativa de verdad; planifica cortes con reducción de TTL por etapas.

• Síntoma: “El proveedor de correo dice que nuestro DNS inverso está mal.”

  Causa raíz: PTR faltante, PTR apunta a un nombre que no resuelve de vuelta, o cambiaste la IP saliente sin actualizar rDNS.

  Corrección: Verifica con dig -x y la búsqueda directa; actualiza PTR con el propietario de la IP; mantén rDNS alineado con la identidad de envío.

Listas de verificación / plan paso a paso

Checklist: triage “DNS está roto” en 10 minutos

1. Anota el nombre y tipo exacto. Ejemplo: api.example.com AAAA, no “el DNS de la API”.
2. Consulta el resolutor configurado del cliente. Confirma la línea SERVER y el estado (NOERROR/NXDOMAIN/SERVFAIL/timeout).
3. Consulta dos resolutores recursivos conocidos. Si discrepan, tienes diferencias de vista/política/caché.
4. Consulta directamente a los servidores autoritativos. Si el autoritativo está correcto pero los recursivos no, deja de cambiar datos de zona a ciegas.
5. Ejecuta +trace sobre el nombre problemático. Anota exactamente qué paso falla.
6. Comprueba TTLs (positivo y negativo). Decide si puedes esperar o necesitas una solución alternativa.
7. Comprueba A y AAAA por separado. Las sorpresas dual-stack son comunes y dolorosas.
8. Si hay SERVFAIL, sospecha DNSSEC pronto. Valida la cadena DS/DNSKEY en lugar de discutir con equipos de aplicación.
9. Si es lento/intermitente, sospecha salud de delegación/NS. Prueba cada NS con consultas SOA.
10. Registra evidencia. Pega salidas de dig en el documento del incidente. Las discusiones DNS mueren rápido cuando muestras la cadena.

Checklist: cambio DNS planificado (para no crear la caída de la próxima semana)

1. Decide el modelo de propagación. Reducción de TTL 24–48 horas antes del corte para nombres de alto tráfico es normal. Hazlo deliberadamente.
2. Captura instantáneas “antes”: SOA, NS, registros objetivo y cualquier salida de cadenas CNAME desde autoritativos y al menos un resolutor recursivo.
3. Haz un cambio a la vez. Agrupar NS + DNSSEC + corte de servicio es cómo te ganas un fin de semana.
4. Valida desde múltiples redes/resolutores. Especialmente si ejecutas split-horizon o tienes clientes empresariales.
5. Mantén la reversión simple. Sabe a qué valores volverás y entiende que las cachés aún existirán.
6. Tras el cambio, verifica consistencia de delegación. NS del padre vs NS del hijo deben coincidir, y todos los NS deben responder autoritativamente.

Vaciar caché (solo cuando controlas la máquina)

cr0x@server:~$ resolvectl status
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
 resolv.conf mode: stub
Current DNS Server: 10.0.0.53
       DNS Servers: 10.0.0.53 10.0.0.54

cr0x@server:~$ sudo resolvectl flush-caches

Significado: En sistemas systemd-resolved, esto limpia la caché local. No arreglará cachés ascendentes en resolutores que no controlas.

Decisión: Vacía cachés locales solo para demostrar una hipótesis o durante pruebas controladas. En producción, normalmente diseñas alrededor de las cachés en lugar de pelear contra ellas.

Preguntas frecuentes

1) ¿Cuál es la diferencia práctica entre dig y drill?

dig (herramientas BIND) es ubicuo y amigable para scripts. drill (de ldns) tiene un buen comportamiento de trazado y funciones de chase DNSSEC. En incidentes, usa el que esté instalado primero—y ten el otro a mano cuando necesites una segunda opinión.

2) ¿Cuándo debo usar +trace?

Cuando sospechas problemas de delegación, errores del registrador, NS/glue equivocados, o necesitas probar dónde se rompe la cadena. También es la forma más rápida de detener discusiones sobre “nuestro proveedor DNS está caído” cuando la delegación padre es el problema real.

3) ¿Por qué un resolutor devuelve una IP y otro devuelve NXDOMAIN?

Causas comunes: vistas split-horizon, filtrado RPZ, cachés obsoletos (incluyendo caché negativa), o consultar nombres distintos por sufijos de búsqueda. Consulta ambos resolutores directamente y compara status, ANSWER y AUTHORITY.

4) ¿Qué significa realmente SERVFAIL?

Significa “el resolutor no pudo completar la consulta correctamente”. Puede ser timeouts upstream, fallo de validación DNSSEC, delegación lame, o sobrecarga del resolutor. SERVFAIL es un síntoma, no un diagnóstico—así que traza y consulta autoritativos directamente.

5) ¿Por qué veo registros correctos en el autoritativo pero los clientes aún obtienen la respuesta antigua?

Por cachés. Los resolutores recursivos cachean respuestas hasta que el TTL expira. Los clientes también pueden cachear. Tu “arreglo” es correcto pero aún no observado. Lee TTLs desde el resolutor que usan tus clientes y planifica cambios con ventanas de TTL.

6) ¿Cómo demuestro que DNSSEC es el problema sin herramientas especializadas?

Comprueba si resolutores que validan devuelven SERVFAIL mientras resolutores no validantes (o consultas directas a autoritativos) devuelven datos. Luego inspecciona DNSKEY/RRSIG en los autoritativos y DS en el padre con dig +trace DS. Esa combinación suele ser suficiente para probarlo.

7) ¿Debería publicar siempre registros AAAA si tengo IPv6 en algún lado?

No. Publica AAAA cuando el servicio sea alcanzable de forma fiable por IPv6 para los usuarios que lo recibirán. Despliegues IPv6 parciales crean fallos lentos que parecen “la app es inestable” porque los clientes suelen intentar v6 primero.

8) ¿Qué es una “delegación lame” en términos prácticos?

Un NS listado para tu zona que no la sirve autoritativamente (o se niega/da SERVFAIL). Los resolutores pierden tiempo en él. Obtienes lentitud intermitente, reintentos y a veces fallos. Arregla quitando/reparando ese servidor y alineando NS padre/hijo.

9) ¿Por qué yo veo un registro TXT de verificación y el proveedor no?

O estás consultando distintos resolutores con caches distintas, lo publicaste en la zona/vista equivocada, o creaste NODATA (el nombre existe pero no TXT) en vez del registro previsto. Pregunta al proveedor qué resolutor usan y luego consulta ese resolutor directamente.

10) ¿Vaciar cachés es una buena respuesta a incidentes?

Solo si controlas la caché y lo haces para validar una hipótesis. No puedes vaciar los resolutores del mundo. La habilidad real es entender TTLs y planificar cortes seguros con solapamiento.

Siguientes pasos que puedes hacer hoy

1. Construye el hábito de “evidencia DNS”. Durante incidentes, pega salidas de dig/drill mostrando SERVER, estado, TTL y respuestas autoritativas. Acorta las reuniones.
2. Estandariza una comparación de resolutores. Elige dos resolutores públicos y tu resolutor corporativo, y guarda un conjunto corto de comandos para compararlos rápido.
3. Conoce tu delegación. Para zonas críticas, verifica periódicamente que NS del padre coincidan con NS del hijo y que cada NS responda autoritativamente.
4. Revisa la estrategia de TTL. TTL bajo solo donde necesitas steering rápido; TTL razonable en otros casos para reducir carga de dependencias.
5. Haz que TCP/53 sea innegociable para la infraestructura DNS. El DNS moderno (especialmente con DNSSEC) lo necesita cuando UDP se trunca.
6. Practica una reversión controlada de DNSSEC. No durante un incidente. Sabe cómo quitar DS si hace falta y cómo reactivar de forma segura.

DNS no es magia. Es papeleo con pérdida de paquetes. Usa los comandos arriba, localiza dónde diverge la verdad y tu “misterio” se convierte en una corrección.