DNS: NXDOMAIN vs SERVFAIL — cómo identificar rápido qué está roto (y arreglarlo)

diciembre 28, 2025 • febrero 3, 2026 • Lectura: 25 min • Views: 11

¿Te fue útil?

Cuando DNS se rompe, nunca lo hace con educación. Se rompe mientras tu CEO está haciendo una demo, tu pipeline de CI está “sólo haciendo un despliegue rápido”, y la mitad de la compañía de repente no puede acceder a “internet” (que, para ellos, es una página de inicio de sesión de un SaaS).

La forma más rápida de recuperar tu tiempo es dejar de tratar cada error de DNS como si fuera un presentimiento. NXDOMAIN y SERVFAIL no son el mismo tipo de fallo. Señalan cosas rotas diferentes, pertenecientes a equipos distintos, y se arreglan con movimientos distintos.

NXDOMAIN vs SERVFAIL: dos códigos, dos mundos de fallo

NXDOMAIN en una frase

NXDOMAIN significa: “El nombre de dominio que solicitaste no existe” (específicamente: el servidor cree que ese nombre no existe en DNS). Es una respuesta, no un colapso.

SERVFAIL en una frase

SERVFAIL significa: “No puedo responder esto ahora.” Es una falla para producir una respuesta: a menudo debido a problemas ascendentes, fallos de validación DNSSEC, delegaciones lame, recursión rota o problemas internos del resolver.

El atajo en producción: lo que suele implicar cada uno

NXDOMAIN: con mayor frecuencia un problema de datos/configuración (nombre equivocado, registro faltante, zona incorrecta, desajuste split-horizon, caché negativa obsoleta). El sistema está funcionando; te está diciendo “no”.
SERVFAIL: con mayor frecuencia un problema de ruta/validación/disponibilidad (el resolver no puede alcanzar la autoridad, la autoridad se comporta mal, la cadena DNSSEC está rota, la recursión está bloqueada, MTU/fragmentación, problemas EDNS, timeouts). El sistema no está respondiendo correctamente.

Ese es todo el juego. NXDOMAIN te empuja hacia “¿existe este nombre donde creo que existe?” SERVFAIL te empuja hacia “¿por qué no puede el resolver completar la resolución de forma segura?”

Broma #1: DNS es como una guía telefónica que puede devolver “no existe tal persona” o “estoy teniendo un mal día”—y ambas arruinan tu fin de semana por igual.

Qué hacer inmediatamente cuando ves cada uno

Si es NXDOMAIN:

Confirma ortografía y FQDN. No te rías; hazlo.
Comprueba si el registro existe en la zona autorizada (no sólo en tu repo de IaC).
Comprueba si estás consultando la vista correcta (pública vs interna / split-horizon).
Revisa el caché negativo (SOA minimum / negative TTL) si acabas de crear el registro.

Si es SERVFAIL:

Comprueba si el resolver está fallando para todo el mundo o sólo para ti (stub local vs recursivo corporativo vs resolvers públicos).
Comprueba la validación DNSSEC: prueba con y sin validación para aislar.
Comprueba la salud de la delegación: registros NS, glue, accesibilidad y si las autoridades son “lame”.
Comprueba rarezas de transporte: fragmentación UDP, tamaño EDNS, reglas de firewall y limitación de tasa.

Manual rápido de diagnóstico (qué comprobar primero)

Este es el “tengo cinco minutos antes de que el canal de incidentes se convierta en arte performativo” playbook. Síguelo en orden. Para cuando encuentres el cuello de botella, deja de avanzar.

Paso 1: Reproducir con `dig` y capturar el error exacto

Usa dig con +norecurse y con recursión normal, y anota status:, flags: y SERVER:.
Decisión: Si el status es NXDOMAIN, pivotar a “datos y zona”. Si es SERVFAIL, pivotar a “ruta y validación”.

Paso 2: Cambiar el resolver para aislar dónde falla

Consulta tu resolver habitual, luego un resolver público conocido y luego el nameserver autoritativo directamente.
Decisión: Si el público funciona pero el corporativo falla, es tu recursión/egress/política DNSSEC. Si la autoridad falla, es la zona/autoridad en sí.

Paso 3: Identificar servidores autoritativos y probarlos individualmente

Usa dig NS y consulta cada NS por el registro exacto.
Decisión: Si un NS difiere, tienes problemas de propagación o master oculto/transferencia. Si todos fallan, es un problema global de la zona.

Paso 4: Si es SERVFAIL, hacer la prueba de división DNSSEC

Usa +dnssec y también intenta desactivar la validación en un resolver que valide (o usa un resolver no validante que controles).
Decisión: Si deshabilitar la validación hace que funcione, tienes un problema de cadena DNSSEC (DS desajustado, firmas expiradas, DNSKEY faltante, NSEC/NSEC3 incorrectos, etc.).

Paso 5: Comprobar comportamiento de caché y TTL

Si lo acabas de arreglar y sigue fallando, vacía caches donde puedas (stub local, resolver recursivo) o espera a que expiren los negative TTL.
Decisión: Si la autoridad es correcta pero los clientes aún ven NXDOMAIN/SERVFAIL, estás en zona de caché.

Paso 6: Buscar restricciones de red que parezcan “DNS caído”

Prueba la accesibilidad de UDP/53 y TCP/53. Observa ICMP frag-needed. Revisa logs de firewall, timeouts de NAT y listas de permitidos de egress.
Decisión: Si TCP funciona pero UDP falla (o viceversa), arregla la red. DNS solo es el mensajero.

Cómo DNS llega a NXDOMAIN o SERVFAIL (sin cuentos)

La resolución DNS es una cadena de responsabilidad. Tu aplicación suele preguntar a un stub resolver (a menudo en el host), que pregunta a un resolver recursivo (DNS corporativo, ISP o un resolver público), que recorre el árbol consultando servidores autoritativos.

NXDOMAIN: un “no” autoritativo (o uno creíble)

NXDOMAIN se devuelve cuando el respondedor cree que el nombre no existe. En un mundo limpio, eso viene del servidor autoritativo para la zona, respaldado por prueba (SOA en la sección de autoridad, posiblemente NSEC/NSEC3 con DNSSEC).

Pero en producción, NXDOMAIN también puede ser:

Desajuste split-horizon: la vista interna dice “no existe tal nombre”, la vista pública lo tiene (o al revés).
Accidentes de sufijo de búsqueda: el cliente pidió api y el resolver intentó api.corp.example, obtuvo NXDOMAIN, y tu app registra “api no existe”.
Caché negativo: un resolver almacenó NXDOMAIN; creaste el registro; todos siguen viendo NXDOMAIN hasta que expira el TTL negativo.
Interacciones con comodines: pensaste que un wildcard lo cubre; no cubre todos los tipos o todas las etiquetas como asumiste.

SERVFAIL: un resolver negándose a mentir

SERVFAIL es el resolver diciendo: “No obtuve una respuesta fiable.” Eso puede ocurrir por muchas razones, y un buen resolver es conservador: prefiere fallar antes que entregar una respuesta que no pueda validar o completar.

Rutas comunes de SERVFAIL:

Fallo de validación DNSSEC: el resolver recibió una respuesta, pero las firmas no validaron. Devuelve SERVFAIL al cliente.
Timeouts y autoridades inalcanzables: la recursión no puede alcanzar los servidores autoritativos, a menudo por reglas de firewall, mitigación DDoS, rutas anycast rotas o servidores muertos.
Delegación lame: los registros NS apuntan a servidores que no son autoritativos para la zona. Los resolvers pierden tiempo; algunos devuelven SERVFAIL.
Truncamiento y problemas TCP: respuestas DNS grandes (DNSSEC las hace más grandes) se truncarán por UDP, y luego TCP/53 esté bloqueado, causando fallos.
Problemas EDNS/fragmentación: tamaños de buffer EDNS, PMTU blackholes o middleboxes que “amablemente” descartan UDP fragmentado.

Broma #2: SERVFAIL es DNS diciendo “Te lo diría, pero entonces tendría que validarte.”

Un modelo mental útil: “¿Dónde se almacena la verdad y quién falla al obtenerla?”

Los servidores autoritativos almacenan la verdad. Los resolvers recursivos la obtienen, validan y cachean. NXDOMAIN suele ser un problema de verdad. SERVFAIL suele ser un problema al obtener/validar la verdad.

Hechos e historia que realmente ayudan en incidentes

Estos no son datos para un trivial. Cambian cómo depuras.

NXDOMAIN está definido como RCODE 3. No es “sin datos”. “Sin datos” es una respuesta NOERROR con la sección de respuesta vacía (a menudo llamada NODATA).
SERVFAIL es RCODE 2. Es intencionalmente vago: cubre muchas fallas internas, incluidos timeouts ascendentes y fallos de validación DNSSEC.
El caché negativo está estandarizado. Los resolvers almacenan NXDOMAIN y NODATA usando los valores SOA de la zona (comúnmente el campo minimum/negative TTL), por eso “acabo de añadir el registro” puede seguir viéndose roto.
DNS fue diseñado pensando primero en UDP. TCP existe para transferencias de zona y respuestas truncadas, pero las redes reales a menudo tratan TCP/53 como sospechoso. Eso es una receta para SERVFAIL cuando las respuestas se hacen grandes.
DNSSEC hizo las respuestas más grandes y el debug más agudo. Los fallos de validación suelen aparecer como SERVFAIL en el resolver, incluso cuando los servidores autoritativos sirven datos correctamente.
La “delegación lame” es un modo de fallo clásico. Delegar a nameservers que realmente no sirven la zona consume tiempo de los resolvers y aumenta la latencia de cola—a veces hasta SERVFAIL.
EDNS(0) se introdujo para extender DNS sin romperlo. Los middleboxes a veces rompen EDNS, llevando a comportamientos raros: timeouts, bucles de truncamiento o SERVFAIL según la lógica del resolver.
La infraestructura raíz y de TLD evolucionó para reducir fragilidad. Despliegues anycast y múltiples registros NS están destinados a mejorar disponibilidad, pero también pueden enmascarar fallos parciales hasta que un cambio de ruta los exponga.
Los dominios de búsqueda (resolv.conf) son una trampa corporativa. Generan consultas que no pretendías. El debug necesita nombres totalmente calificados para evitar NXDOMAIN fantasma.

Una idea de fiabilidad para llevar en el bolsillo: si diseñas pensando que la falla es normal, pasarás menos tiempo fingiendo que es excepcional (parafraseado de Werner Vogels, CTO de Amazon).

Tareas prácticas: comandos, salidas, decisiones (12+)

Esto es lo que realmente ejecutas a las 02:00. Cada tarea incluye: el comando, un ejemplo de lo que podrías ver, qué significa y qué haces después.

Task 1: Get the basic status and confirm which resolver answered

cr0x@server:~$ dig api.example.com A

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

;; QUESTION SECTION:
;api.example.com.            IN      A

;; AUTHORITY SECTION:
example.com.         300     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

;; Query time: 21 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)
;; WHEN: Wed Dec 31 10:12:01 UTC 2025
;; MSG SIZE  rcvd: 115

Meaning: Your recursive resolver at 10.10.0.53 is returning NXDOMAIN. It also shows an SOA, suggesting the resolver believes it has authoritative proof of non-existence (or cached proof).

Decision: Don’t chase network yet. Verify whether api.example.com exists in the authoritative zone and whether you’re querying the right DNS view.

Task 2: Compare against a different recursive resolver

cr0x@server:~$ dig @1.1.1.1 api.example.com A

; <<>> DiG 9.18.24 <<>> @1.1.1.1 api.example.com A
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5329
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.example.com.     60      IN      A       203.0.113.10

;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; Query time: 18 msec

Meaning: Public recursion returns a valid A record; your corporate resolver returns NXDOMAIN. That’s not “DNS is down.” That’s a policy/view/caching issue on your side.

Decision: Check split-horizon configuration, forwarding rules, RPZ/blocklists, or stale negative cache on the corporate resolver.

Task 3: Force a fully qualified name to avoid search-domain lies

cr0x@server:~$ dig api A

; <<>> DiG 9.18.24 <<>> api A
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1204
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;api.                          IN      A

;; AUTHORITY SECTION:
.                       86400   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2025123100 1800 900 604800 86400

Meaning: You asked for api. (the literal top-level name), not api.example.com. Apps and humans do this accidentally through search suffixes and missing dots.

Decision: Use FQDNs in configs. In incident debugging, always query the full name ending with a dot if you want to be pedantic: api.example.com.

Task 4: Check if it’s NXDOMAIN vs NODATA (NOERROR, empty answer)

cr0x@server:~$ dig www.example.com AAAA

; <<>> DiG 9.18.24 <<>> www.example.com AAAA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64430
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.         300     IN      SOA     ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

Meaning: The name exists, but there is no AAAA record. That’s not NXDOMAIN, and your fix is different.

Decision: If your app requires IPv6, add AAAA or fix client behavior. If not, ignore and stop paging yourself.

Task 5: Find the authoritative nameservers (and whether delegation looks sane)

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

example.com.     172800  IN  NS  ns1.example.net.
example.com.     172800  IN  NS  ns2.example.net.

Meaning: These are the servers the world will ask for example.com.

Decision: Query each NS directly for the record. If answers differ, you likely have zone propagation problems.

Task 6: Query the authoritative server directly to confirm reality

cr0x@server:~$ dig @ns1.example.net api.example.com A +norecurse

; <<>> DiG 9.18.24 <<>> @ns1.example.net api.example.com A +norecurse
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33201
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
api.example.com.     60      IN      A       203.0.113.10

Meaning: The authority says it exists and marks the answer authoritative (aa flag). If your recursive resolver gives NXDOMAIN, the issue is caching, filtering, split-horizon, or a broken forwarder chain.

Decision: Investigate the recursive resolver: cache state, RPZ, views, forwarding, and DNSSEC behavior.

Task 7: Check for lame delegation

cr0x@server:~$ dig @ns2.example.net example.com SOA +norecurse

; <<>> DiG 9.18.24 <<>> @ns2.example.net example.com SOA +norecurse
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9012
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

Meaning: The server listed as an NS refuses to answer authoritatively. That’s a delegation problem (or ACL problem), and resolvers may end up SERVFAIL-ing under load or on unlucky selection.

Decision: Fix NS records to point to actual authoritative servers, or fix the server ACLs so it answers authoritatively for the zone.

Task 8: Check DNSSEC at the resolver boundary

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

; <<>> DiG 9.18.24 <<>> secure.example.com A +dnssec
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4411
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)

Meaning: SERVFAIL with DNSSEC in play often signals validation failure, especially if other resolvers behave differently.

Decision: Compare with a resolver known to validate correctly, and inspect DS/DNSKEY/RRSIG chain for the zone.

Task 9: Use `+trace` to watch delegation step-by-step

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

; <<>> DiG 9.18.24 <<>> secure.example.com A +trace
.                       518400  IN  NS  a.root-servers.net.
...
com.                    172800  IN  NS  a.gtld-servers.net.
...
example.com.             172800  IN  NS  ns1.example.net.
example.com.             172800  IN  NS  ns2.example.net.
secure.example.com.      60      IN  A   203.0.113.20

Meaning: Trace shows the chain: root → TLD → your authoritative servers → final record. If it breaks mid-chain, you know which delegation layer is wrong.

Decision: If trace fails at the TLD delegation, check registrar-side NS/DS settings. If it fails at your NS, fix your authoritative infrastructure.

Task 10: Check TCP fallback (truncation problems)

cr0x@server:~$ dig dnssec-heavy.example.com DNSKEY +dnssec +ignore +bufsize=4096

; <<>> DiG 9.18.24 <<>> dnssec-heavy.example.com DNSKEY +dnssec +ignore +bufsize=4096
;; Truncated, retrying in TCP mode.
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20031
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

Meaning: The answer didn’t fit in UDP, so the resolver retried over TCP. If TCP/53 is blocked somewhere, clients may see SERVFAIL or timeouts.

Decision: Ensure TCP/53 is allowed between recursive resolvers and authoritative servers (and sometimes between clients and resolvers, depending on architecture).

Task 11: Confirm what your host is actually using for DNS

cr0x@server:~$ resolvectl status

Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute
Current DNS Server: 10.10.0.53
       DNS Servers: 10.10.0.53 10.10.0.54
        DNS Domain: corp.example

Meaning: Your systemd-resolved stub is forwarding to corporate resolvers and appending corp.example as a search domain.

Decision: If you see surprising queries, disable or constrain search domains for critical services. Also verify both listed DNS servers behave the same.

Task 12: Detect “one resolver is sick” by querying both explicitly

cr0x@server:~$ dig @10.10.0.53 api.example.com A +time=1 +tries=1

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 31990
;; Query time: 1001 msec
;; SERVER: 10.10.0.53#53(10.10.0.53) (UDP)

cr0x@server:~$ dig @10.10.0.54 api.example.com A +time=1 +tries=1

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31991
;; ANSWER SECTION:
api.example.com. 60 IN A 203.0.113.10

Meaning: One recursive resolver is failing; the other works. This is more common than anyone wants to admit: bad cache, stuck upstream, CPU thrash, broken DNSSEC state.

Decision: Pull the bad resolver from rotation (DHCP option, load balancer, Anycast withdrawal), then debug it offline.

Task 13: Check BIND/unbound logs for validation and upstream errors

cr0x@server:~$ sudo journalctl -u unbound --since "10 minutes ago" | tail -n 10

Dec 31 10:05:22 resolver1 unbound[1321]: info: validation failure <secure.example.com. A>: signature expired
Dec 31 10:05:22 resolver1 unbound[1321]: info: resolving secure.example.com. A
Dec 31 10:05:22 resolver1 unbound[1321]: info: error: SERVFAIL secure.example.com. A IN

Meaning: The resolver is explicitly telling you the DNSSEC signature is expired. This is one of the cleanest SERVFAIL root causes you can get.

Decision: Fix DNSSEC signing for the zone (re-sign, correct time sync on signer, ensure automated rollovers). Temporary mitigation: route critical clients to a resolver policy that doesn’t validate (carefully), but treat that as an emergency bandage, not a lifestyle.

Task 14: Confirm authoritative server health and zone loading

cr0x@server:~$ sudo rndc status

version: BIND 9.18.24 (Stable Release)
running on ns1: Linux x86_64 6.5.0
boot time: Wed, 31 Dec 2025 08:12:07 GMT
last configured: Wed, 31 Dec 2025 09:58:41 GMT
number of zones: 128
debug level: 0
xfers running: 0
up time: 1h 59m

Meaning: BIND is up and not obviously overloaded. This doesn’t prove your zone is correct, but it rules out “named is dead.”

Decision: If you suspect zone load failures, inspect logs and confirm the zone serial and records.

Task 15: Verify the zone serial and whether secondaries are in sync

cr0x@server:~$ dig @ns1.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123101 7200 3600 1209600 300

cr0x@server:~$ dig @ns2.example.net example.com SOA +noall +answer
example.com. 300 IN SOA ns1.example.net. hostmaster.example.com. 2025123009 7200 3600 1209600 300

Meaning: The serials differ. One nameserver is serving an older zone. That can manifest as intermittent NXDOMAIN (depending on which NS the resolver picks).

Decision: Fix zone transfers (TSIG keys, allow-transfer ACLs, notify configuration, network reachability). Don’t ship “eventual consistency DNS” unless you like mystery outages.

Tres mini-historias corporativas (y lo que enseñan)

Incidente 1: La caída causada por una suposición equivocada (NXDOMAIN fingiendo ser “red”)

En una compañía mediana con una arquitectura híbrida, un equipo migró un servicio interno de api.int.corp a api.internal.corp. Hicieron lo correcto: actualizaron discovery, cambiaron algunas configuraciones, mergearon el PR y siguieron.

Entonces un on-call recibió una alerta: “Servicio inaccesible.” Los logs de la aplicación mostraban NXDOMAIN repetidos para api.int.corp. El on-call asumió que era una caída del resolver porque “NXDOMAIN significa que DNS no puede encontrarlo, así que DNS debe estar caído.” Esa suposición cuesta una hora.

El problema real fue aburrido. Un job legacy tenía el hostname antiguo hardcodeado. Corría una vez por hora, disparaba reintentos y generó suficiente ruido para parecer un problema de plataforma. DNS estaba funcionando perfectamente y diciendo la verdad: ese nombre ya no existía.

Lo que lo arregló no fue heroico. Buscaron en el repo de config el string, encontraron el job, desplegaron el nombre nuevo y añadieron un CNAME temporal del nombre viejo al nuevo por una semana. También afinaron el monitoreo para diferenciar picos de NXDOMAIN por nombre, no sólo “errores DNS”.

Lección: NXDOMAIN suele ser DNS haciendo su trabajo. Cuando ves NXDOMAIN, sospecha primero de tus entradas: nombres, zonas, vistas y caches. No “reinicies DNS” para arreglar una falta de ortografía embebida en 200 nodos.

Incidente 2: La optimización que salió mal (SERVFAIL por DNSSEC + lore de “paquetes más pequeños”)

Un equipo de plataforma quería DNS más rápido. Ajustaron sus resolvers recursivos: tamaños UDP más pequeños, timeouts agresivos y un par de tweaks EDNS de “no necesitamos eso” copiados de un hilo viejo. Los gráficos se veían bien durante un mes. Latencia reducida, dashboards verdes. Todos asintieron sabiamente.

Entonces un partner activó DNSSEC en una zona de la que dependía la compañía. De repente, un subconjunto de consultas empezó a devolver SERVFAIL. No todas. Suficientes para arruinar logins de clientes en una geografía y hacer que el incidente commander cuestione la realidad.

La raíz no fue el partner. Fue la “optimización”: reducir el tamaño EDNS provocó más truncamiento, lo que forzó el fallback a TCP. Pero el egress TCP/53 desde esos resolvers estaba permitido de forma inconsistente a través de pasarelas NAT. A veces funcionaba; a veces no. Los resolvers que no podían completar la validación devolvían SERVFAIL. El DNSSEC del partner simplemente hizo los paquetes lo suficientemente grandes para caer en la trampa.

La solución fue poco glamorosa: revertir los tweaks EDNS, estandarizar la política de firewall para permitir TCP/53 desde resolvers recursivos y ajustar timeouts según el comportamiento real de upstream en lugar de ideología. También añadieron una comprobación canaria que consulta deliberadamente un registro pesado en DNSSEC para asegurar que el fallback TCP funciona.

Lección: Las “optimizaciones” de DNS que ignoran el protocolo completo (UDP y TCP, EDNS, DNSSEC) son bombas de tiempo con mejores métricas.

Incidente 3: La práctica aburrida que salvó el día (comprobaciones de delegación consistentes)

Una gran empresa operaba su propio DNS autoritativo más un proveedor secundario gestionado. Cada cambio pasaba por una checklist: actualizar zona, incrementar serial, validar sintaxis, empujar al hidden master, confirmar que los secundarios recibieron el nuevo serial y luego ejecutar una comprobación de delegación externa desde al menos dos redes.

Un día, un cambio en el lado del registrador ocurrió durante un proyecto de consolidación de dominios. Se actualizaron los registros NS. Un cambio razonable—excepto que uno de los nameservers recién listados aún no servía la zona. Delegación lame: libro de texto.

La diferencia fue que su chequeo post-cambio lo detectó en minutos. Consultaron el conjunto de NS listados individualmente, vieron uno devolviendo REFUSED y revertieron la delegación antes de que las caches de internet absorbieran el estado malo. Los usuarios no notaron nada. El project manager aún consiguió su consolidación.

Lección: La validación de delegación es aburrida como los cinturones de seguridad. No sientes que funciona. Sólo notas cuando falta.

Errores comunes: síntoma → causa raíz → arreglo

1) “NXDOMAIN para un registro que acabamos de crear”

Síntoma: dig devuelve NXDOMAIN para un nombre que añadiste hace minutos.

Causa raíz: Caché negativo en resolvers recursivos (NXDOMAIN cacheado), o actualizaste sólo una vista/zona (interna vs pública), o secundarios no están sincronizados.

Arreglo: Consulta el autoritativo directamente para confirmar que el registro existe. Revisa el SOA serial en cada NS. Si la autoridad es correcta, espera el TTL negativo o limpia caches en resolvers que controles.

2) “NXDOMAIN intermitente”

Síntoma: A veces resuelve, a veces NXDOMAIN.

Causa raíz: Conjunto autoritativo con split-brain (algunos NS tienen el registro, otros no), o nodos anycast sirviendo versiones diferentes de la zona.

Arreglo: Consulta cada NS autoritativo directamente. Compara SOA serials. Arregla transferencias/notify y asegura despliegue atómico en nodos autoritativos.

3) “SERVFAIL desde DNS corporativo, pero resolvers públicos funcionan”

Síntoma: dig @10.10.0.53 devuelve SERVFAIL; dig @1.1.1.1 funciona.

Causa raíz: Fallo de validación DNSSEC por trust anchors obsoletos, desincronización de tiempo en resolvers, filtrado por políticas (RPZ) o TCP/53 bloqueado impidiendo completar la validación.

Arreglo: Revisa logs del resolver por errores de validación. Asegura NTP correcto. Verifica egress TCP/53. Revisa hits de RPZ y excepciones.

4) “SERVFAIL sólo para dominios con DNSSEC”

Síntoma: Algunas zonas siempre dan SERVFAIL, otras bien.

Causa raíz: Problemas en la cadena DNSSEC (RRSIG expirado, DS desajustado tras rollover de claves, DNSKEY incorrecto).

Arreglo: Usa dig +trace +dnssec y comprueba DS en el padre vs DNSKEY en el hijo. Re-firma la zona o corrige DS en el registrador/padre.

5) “Todo falla en Kubernetes, pero los nodos pueden resolver”

Síntoma: Los pods ven SERVFAIL/NXDOMAIN; el host resuelve bien.

Causa raíz: Upstream de CoreDNS mal configurado, NodeLocal DNSCache con problemas, reglas iptables o diferencias en el stub resolver.

Arreglo: Consulta desde dentro del pod al servicio CoreDNS y al upstream. Revisa logs de CoreDNS, configmap y políticas de red para UDP/TCP 53.

6) “NOERROR pero la app dice ‘host not found’”

Síntoma: DNS devuelve NOERROR sin respuestas; la app falla.

Causa raíz: Consultaste un tipo de registro que no existe (AAAA vs A), o la app requiere SRV/TXT y sólo comprobaste A.

Arreglo: Consulta los tipos de registro exactos que usa la app. Para discovery moderno, revisa SRV/TXT y el comportamiento de la librería.

7) “Picos de SERVFAIL después de habilitar protección DDoS”

Síntoma: SERVFAIL súbito bajo carga o tras cambios de seguridad.

Causa raíz: Rate limiting o reglas de firewall que descartan fragmentos, bloqueo de TCP/53 o descartar tráfico EDNS.

Arreglo: Valida rutas UDP y TCP. Ajusta límites de tasa. Si debes filtrar, hazlo conscientemente y prueba respuestas pesadas en DNSSEC.

8) “NXDOMAIN para nombre interno desde portátiles en VPN”

Síntoma: En VPN falla; fuera de VPN funciona (o viceversa).

Causa raíz: DNS dividido no se empuja correctamente por la VPN, o las vistas del resolver corporativo dependen de rangos de IP origen.

Arreglo: Verifica qué resolvers usan los clientes en VPN. Confirma ACLs de vista e incluye los pools de direcciones de VPN.

Listas de verificación / plan paso a paso

Checklist A: Cuando ves NXDOMAIN

Confirma el FQDN exacto que se consulta (incluyendo comportamiento del punto final y sufijos de búsqueda).
Consulta el autoritativo directamente para el tipo de registro en cuestión (A, AAAA, CNAME, SRV).
Comprueba split-horizon: consulta desde redes internas y externas; consulta autoridades internas y públicas.
Comprueba SOA serial en cada NS autoritativo; confirma que coincidan.
Si fue creado/cambiado recientemente, ten en cuenta el caché negativo: espera o limpia caches que controles.
Confirma que no publicaste sólo un CNAME sin su objetivo, o que publicaste un registro en la zona equivocada.
Arregla en la fuente de la verdad (archivo de zona / proveedor DNS), no en resolvers al azar.

Checklist B: Cuando ves SERVFAIL

Identifica qué resolver devuelve SERVFAIL (stub local, recursivo corporativo, público).
Consulta el mismo nombre vía múltiples resolvers para aislar alcance.
Ejecuta dig +trace para ver dónde se rompe la cadena.
Prueba servidores autoritativos individualmente; busca timeouts, REFUSED o respuestas inconsistentes.
Investiga DNSSEC: compara DS y DNSKEY, busca firmas expiradas, confirma sincronización de tiempo en signers y resolvers.
Prueba comportamiento UDP y TCP (truncamiento y fallback). Asegura que TCP/53 no esté bloqueado.
Revisa logs del resolver por fallos de validación, timeouts upstream o advertencias de “lame delegation”.
Mitiga: mueve clientes a resolvers saludables, retira nodos anycast rotos o desactiva validación temporalmente sólo si el riesgo está entendido.

Paso a paso: el flujo “restaurar servicio primero, luego arreglar la causa”

Estabilizar: Si un resolver falla, retíralo de rotación. Si un autoritativo está roto, quítalo del conjunto de NS (con cuidado) o arréglalo rápido.
Confirmar la verdad: Consulta fuentes autoritativas directamente. Determina si el registro existe y es consistente entre NS.
Arreglar la corrección: Para NXDOMAIN, corrige datos de zona. Para SERVFAIL, arregla accesibilidad/validación/delegación.
Arreglar la propagación: Asegura que las transferencias de zona se completen, que el serial aumente y que las caches expiren o se vacíen.
Prevenir recurrencia: Añade comprobaciones de delegación, monitoreo de expiración DNSSEC, pruebas de accesibilidad TCP/53 y canarios desde múltiples redes.

Preguntas frecuentes

1) ¿NXDOMAIN es siempre una respuesta autoritativa?

No. Se supone que refleja no-existencia autoritativa, pero puedes ver NXDOMAIN desde caches recursivos, políticas RPZ o la vista equivocada. Siempre verifica consultando el NS autoritativo directamente.

2) ¿Cuál es la diferencia entre NXDOMAIN y “sin respuesta”?

NXDOMAIN significa que el nombre no existe. “Sin respuesta” suele ser NOERROR con la sección de respuesta vacía (NODATA): el nombre existe, pero no ese tipo de registro.

3) ¿Por qué ocurre SERVFAIL cuando el servidor autoritativo parece estar bien?

Porque los resolvers validan y aplican políticas. Fallos de validación DNSSEC, fallback TCP bloqueado o timeouts upstream pueden causar SERVFAIL incluso si la autoridad sirve datos.

4) ¿Puede un firewall causar NXDOMAIN?

Los firewalls más comúnmente causan timeouts o SERVFAIL, pero pueden contribuir indirectamente a NXDOMAIN si tu resolver cambia a otra vista o cadena de forwarders que devuelva NXDOMAIN. Trátalo como “poco probable pero posible” y aísla consultando la autoridad directamente.

5) ¿Por qué SERVFAIL a veces es intermitente?

Los resolvers pueden elegir distintos servidores autoritativos cada vez. Si un NS es inaccesible, lame o sirve DNSSEC roto, algunas rutas tienen éxito y otras fallan. Por eso las consultas directas por NS son imprescindibles.

6) ¿Cómo sé si DNSSEC es el problema sin hacerme criptoanalista?

Haz una prueba comparativa: consulta un resolver validador y uno no validador que controles, y luego usa dig +trace +dnssec. Los logs del resolver suelen indicarlo claramente (firmas expiradas, DS desajustado).

7) ¿Debo desactivar la validación DNSSEC para “arreglar SERVFAIL”?

Sólo como mitigación temporal, con aceptación explícita del riesgo y si controlas la política del resolver. La solución real es reparar la cadena DNSSEC o los problemas de transporte.

8) ¿Por qué cambiar a TCP arregla algunos problemas de DNS?

Las respuestas grandes (especialmente con DNSSEC) pueden no caber en UDP. DNS usa truncamiento para indicar “reintentar por TCP”. Si la fragmentación UDP o EDNS está rota, TCP puede ser más fiable—si TCP/53 está permitido.

9) ¿Cuál es la forma más rápida de probar si es split-horizon?

Consulta el mismo FQDN contra resolvers internos y externos, y compara. Si el público devuelve NOERROR y el interno NXDOMAIN (o IPs diferentes), tienes comportamiento split-horizon por diseño o por accidente.

10) ¿Cómo evito que me engañe un fallo cacheado?

Incluye siempre una consulta directa al autoritativo en tu flujo. Si la autoridad es correcta y la recursión está mal, estás tratando con caché, políticas o salud del resolver—no con registros faltantes.

Conclusión: qué hacer la próxima vez

NXDOMAIN y SERVFAIL no son sólo dos sabores de “DNS enfadado”. Son señales diferentes.

NXDOMAIN: asume que el sistema está respondiendo. Verifica el nombre, la zona, la vista y las caches.
SERVFAIL: asume que el resolver no pudo completar la resolución de forma segura. Investiga DNSSEC, salud de delegación, accesibilidad y comportamiento UDP/TCP.

Pasos prácticos que puedes hacer esta semana:

Construye una pequeña página de runbook que empiece con “NXDOMAIN vs SERVFAIL” e incluya los comandos Paso 1–4 arriba.
Añade una comprobación periódica de consistencia de delegación/autoridad (consulta cada NS y compara SOA serials).
Añade un canario con una consulta pesada en DNSSEC que valide que el fallback TCP funciona end-to-end.
Enseña a tu proceso de incidentes a capturar la salida de dig incluyendo status, SERVER y flags. Las capturas de pantalla no son telemetría.

DNS seguirá rompiéndose. Pero no te hará perder tanto tiempo por ser misterioso sobre ello.