DNS: Tu dominio funciona… hasta que deja de hacerlo — La trampa de la delegación explicada

Delegación: lo que realmente significa en la red

La gente habla del DNS como si fuera una base de datos que actualizas y todos mágicamente ven la nueva verdad.
En la práctica es una búsqueda de pistas. Un resolutor recursivo empieza en la raíz, camina hasta el TLD,
luego hasta la zona padre de tu dominio, y sólo entonces aprende dónde viven tus servidores autoritativos.
Ese paso de “aprender adónde ir” es la delegación.

La delegación no es tu archivo de zona. La delegación es el conjunto de NS publicado por la zona padre para tu dominio,
más cualquier registro glue (A/AAAA en la zona padre) necesario para alcanzar esos servidores de nombres.
Tu archivo de zona puede estar impecable y aun así internet puede estar dirigiéndose a la puerta equivocada.

El padre y el hijo: dos fuentes de verdad que deben coincidir

Para example.com, el padre es .com. El padre publica:

• Registros NS en el punto de delegación: qué servidores autoritativos deben ser consultados.
• Registros glue (a veces): direcciones IP para servidores de nombres que están dentro de la zona delegada (in-bailiwick).
• Registro DS (si hay DNSSEC): el enlace de la cadena de confianza hacia el DNSKEY de la zona hija.

La zona hija (tu archivo de zona en tus servidores autoritativos) publica:

• Su propio conjunto NS: lo que declara como sus servidores autoritativos.
• Todo lo demás: A/AAAA, MX, TXT, CNAME, etc.
• Registros DNSKEY (si hay DNSSEC), y firmas (RRSIG).

Si el conjunto NS del padre y el del hijo no coinciden, puedes acabar en una “delegación dividida”:
algunos resolutores siguen un camino, otros otro, y las cachés congelan la divergencia.
Si el glue está mal, puedes tener un nombre NS correcto apuntando a una IP inalcanzable. Si el DS está mal,
puedes obtener fallos duros (SERVFAIL) aunque los registros estén presentes.

Verdad seca: la delegación es un sistema distribuido. Los sistemas distribuidos no “propagan”, convergen—
a veces despacio, a veces nunca, a menos que arregles la inconsistencia.

Por qué la delegación falla en producción (aunque tu zona sea perfecta)

1) La interfaz del registrador no es el DNS

La interfaz del registrador es un plano de control. La delegación real vive en la zona padre del registro.
Muchos registradores hacen lo correcto. Algunos lo hacen eventualmente. Algunos lo hacen después de que hagas clic en “guardar” dos veces
y esperes un trabajo en segundo plano que está corriendo en un servidor reiniciado por última vez durante una reunión presupuestaria.

Peor: los registradores a veces aceptan estados inválidos (como glue faltante para nombres NS in-bailiwick),
o normalizan y reordenan registros de formas que sorprenden a la automatización.

2) Registros glue: la “agenda” justa que puede quedar obsoleta

El glue existe para romper dependencias circulares. Si tu dominio es example.com y uno de tus servidores
de nombres es ns1.example.com, un resolutor no puede buscar ns1.example.com
sin primero poder resolver example.com. Eso es la recursión comiéndose la propia cola.
El glue es la zona padre proporcionando la IP directamente.

El glue también es una trampa: la gente cambia IPs de servidores de nombres y olvida el glue en el padre. La zona hija se actualiza,
pero los resolutores siguen usando el glue antiguo. O peor, sólo algunos resolutores lo hacen—porque las cachés difieren, y
algunos resolutores son más agresivos con búsquedas “útiles” adicionales.

3) DNSSEC: la delegación falla en cerrado

DNSSEC añade integridad, y vale la pena. Pero DNSSEC hace los errores más ruidosos. Un DS obsoleto en el
padre que ya no coincide con la KSK del hijo significa que los validadores rechazan tus respuestas. Los resolutores no validadores pueden seguir funcionando.
Ese es tu clásico incidente de “me funciona a mí” con un remate criptográfico.

4) Caché negativa: tu arreglo es correcto, pero internet sigue enfadada

Los resolutores almacenan en caché el no con tanto entusiasmo como el sí. Si un resolutor pidió
A www.example.com y obtuvo NXDOMAIN, puede cachear ese resultado por el TTL negativo (del SOA).
Eso significa que puedes arreglar un registro y aun así tener clientes jurando que está roto durante minutos o horas.

5) Anycast, balanceadores y topologías “inteligentes” de NS

Muchos proveedores autoritativos usan anycast, lo cual es excelente cuando se hace correctamente. Pero si montas
tu propio NS y lo pones detrás de un balanceador que hace health checks en TCP/53 mientras tus clientes
usan mayormente UDP/53, estás buscando un informe de incidente.

6) Inconsistencias en la zona hija: seriales, NOTIFY y masters ocultos

La delegación puede ser correcta, pero tus servidores autoritativos discrepan. Actualizaste el primario, un secundario está desactualizado,
y tu conjunto NS envía resolutores a ambos. Algunos usuarios obtienen la nueva respuesta, otros la vieja, y todos culpan a la “propagación”.
El término correcto es “tienes autoridad inconsistente”.

Broma #1: La propagación del DNS es como el cotilleo de oficina—todo el mundo lo oye eventualmente, pero no en el mismo orden, y rara vez con el significado original intacto.

Hechos e historia que explican las rarezas actuales

• 1983: El DNS (RFC 882/883, luego reemplazados) se diseñó para reemplazar un único archivo HOSTS.TXT—la delegación fue la característica de escalabilidad.
• Los servidores raíz no son “un solo servidor”: hay 13 letras lógicas de raíz, pero cada una está anycasteada a muchos sitios en todo el mundo.
• El glue es intencionalmente limitado: las zonas padre proporcionan glue sólo para servidores de nombres in-bailiwick para evitar convertirse en una directorio general de direcciones.
• Existe la comprobación de bailiwick por seguridad: los resolutores tratan el glue de forma diferente según si está dentro de la autoridad que consultan.
• El DNS se construyó para UDP: existe fallback a TCP, pero muchas redes aún manejan mal TCP/53, haciendo frágiles las respuestas grandes (¡DNSSEC!).
• EDNS(0) cambió el juego: permite cargas UDP más grandes, pero los middleboxes a veces descartan UDP fragmentado, causando fallos “aleatorios”.
• DNSSEC (1990s–2000s): añade firmas y claves; el punto de delegación usa DS para conectar padre e hijo en la confianza.
• TTL no es una promesa: es una pista; algunos resolutores limitan TTLs o aplican políticas locales, así que la convergencia es más enmarañada que tu hoja de cálculo.
• NXDOMAIN puede ser “reescrito” de forma “útil”: algunos proveedores usaron históricamente wildcarding en el TLD o a nivel de resolutor; tu depuración puede enfrentar mentiras.

Una verdad operativa ha sobrevivido a cada evolución del DNS: el camino importa tanto como los datos.
La delegación es el camino.

Guion rápido de diagnóstico (primero/segundo/tercero)

Cuando un dominio “más o menos funciona”, tu trabajo es encontrar dónde diverge la resolución. No empieces mirando tu archivo de zona.
Empieza por probar qué se le está contando al mundo.

Primero: determina si es delegación, autoridad o validación

1. Comprobar con trace: ¿El resolutor encuentra el conjunto NS correcto desde el padre?
   Si no, es delegación (registrador/registro/glue/DS).
2. Interrogar cada autoritativo directamente: ¿Responden todos los servidores autoritativos igual?
   Si no, es consistencia de zona/transferencia/despliegue.
3. Comprobar DNSSEC y códigos de respuesta: SERVFAIL en resolutores validadores pero éxito en no validadores sugiere problemas con la cadena DNSSEC.

Segundo: busca patrones “sólo en algunas redes”

• Funciona en un ISP, falla en otro: probablemente diferencias de caché o diferencias en validación DNSSEC.
• Funciona en IPv4 pero no en IPv6: problemas con AAAA, glue v6 roto o autoritativos v6 inalcanzables.
• Funciona desde tu portátil, falla desde una región de monitorización: diferencias de ruteo anycast o reglas de firewall por geolocalización.

Tercero: decide si puedes mitigar rápidamente

• Mitigación temporal: añade un NS que funcione de vuelta en la delegación del padre; reduce el radio de impacto.
• Arreglo definitivo: corrige glue/DS/NS y espera a que caduquen las cachés; comunica la ventana esperada de recuperación.
• Si DNSSEC está roto: repara DS/claves rápido o elimina DS (coordinado), pero no lo hagas a medias.

Idea parafraseada (atribuida): Werner Vogels lleva tiempo insistiendo en que debes “diseñar para el fallo” como un estado normal, no como una excepción.

Tareas prácticas: comandos, salida esperada y lo que decides

A continuación hay tareas prácticas que puedes ejecutar desde una máquina Linux. Cada una incluye lo que la salida te dice
y la decisión que tomas a partir de ello. No son comandos de juguete; son los que usas a las 2 a.m.
cuando Slack está en llamas.

Task 1: Confirmar el conjunto NS de la delegación padre (con trace)

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

; <<>> DiG 9.18.24 <<>> +trace example.com NS
.			518400	IN	NS	a.root-servers.net.
.			518400	IN	NS	b.root-servers.net.
;; Received 811 bytes from 127.0.0.53#53(127.0.0.53) in 1 ms

com.			172800	IN	NS	a.gtld-servers.net.
com.			172800	IN	NS	b.gtld-servers.net.
;; Received 1171 bytes from 198.41.0.4#53(a.root-servers.net) in 18 ms

example.com.		172800	IN	NS	ns1.dns-host.net.
example.com.		172800	IN	NS	ns2.dns-host.net.
;; Received 212 bytes from 192.5.6.30#53(a.gtld-servers.net) in 22 ms

Qué significa: Esto muestra lo que la zona padre publica como el conjunto NS de delegación.
El TTL aquí es el TTL del padre, no el de tu zona.

Decisión: Si estos nombres NS no son los que esperas, deja de culpar a tus servidores autoritativos.
Arregla la delegación en el registrador/registro. Si son correctos, pasa a comprobar glue y la consistencia de la zona hija.

Task 2: Comprobar glue en el padre (caso in-bailiwick)

cr0x@server:~$ dig @a.gtld-servers.net example.com NS +norecurse +authority +additional

; <<>> DiG 9.18.24 <<>> @a.gtld-servers.net example.com NS +norecurse +authority +additional
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; AUTHORITY SECTION:
example.com.	172800	IN	NS	ns1.example.com.
example.com.	172800	IN	NS	ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.	172800	IN	A	203.0.113.10
ns2.example.com.	172800	IN	A	203.0.113.11

Qué significa: El padre está proporcionando registros A glue para ns1.example.com/ns2.example.com.
Si las IPs están mal, los resolutores pueden nunca alcanzar tus servidores autoritativos.

Decisión: Si el glue está mal, actualiza los objetos host / glue en el registrador. Actualizar la zona hija no lo arreglará.

Task 3: Verificar que el conjunto NS del hijo coincide con la delegación del padre

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

example.com.	3600	IN	NS	ns1.example.com.
example.com.	3600	IN	NS	ns2.example.com.

Qué significa: Esto es lo que la zona hija declara como autoritativa. El TTL viene de tu zona.

Decisión: Si el conjunto NS del hijo difiere del del padre, arréglalo. No dejes NS “extra” en el hijo o el padre por costumbre.
La consistencia importa más que el optimismo.

Task 4: Consultar cada servidor autoritativo directamente por el registro problemático

cr0x@server:~$ for ns in ns1.example.com ns2.example.com; do echo "== $ns =="; dig @"$ns" www.example.com A +noall +answer; done
== ns1.example.com ==
www.example.com.	300	IN	A	198.51.100.20
== ns2.example.com ==
www.example.com.	300	IN	A	198.51.100.21

Qué significa: Tus servidores autoritativos discrepan. Eso no es propagación; es inconsistencia.

Decisión: Arregla la distribución de la zona (AXFR/IXFR, push por API, pipeline de master oculto), y luego vuelve a comprobar. No prosigas con “esperar a que pase”.

Task 5: Comprobar seriales SOA entre servidores autoritativos

cr0x@server:~$ for ns in ns1.example.com ns2.example.com; do dig @"$ns" example.com SOA +noall +answer; done
example.com.	3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2026020401 7200 3600 1209600 300
example.com.	3600	IN	SOA	ns1.example.com. hostmaster.example.com. 2026020304 7200 3600 1209600 300

Qué significa: Seriales diferentes indican que no todos los servidores tienen la misma versión de la zona.

Decisión: Investiga transferencias/actualizaciones. Si no puedes reparar rápido el autoritativo obsoleto, quítalo de la delegación hasta que esté sano.

Task 6: Comprobar el registro DS en el padre

cr0x@server:~$ dig @a.gtld-servers.net example.com DS +noall +answer

example.com.	86400	IN	DS	12345 13 2 4C2B9D3C8B4E9B0F0F3E2C2B2D1A9A0D0B2A6F9E6E7C0A1B2C3D4E5F6789

Qué significa: El padre dice que la zona hija debe validar con este digest DS.

Decisión: Si rotaste claves recientemente o cambiaste de proveedor DNS, verifica que el DS coincida con la KSK actual. Si no, corrige el DS o seguirás teniendo fallos de validación.

Task 7: Confirmar DNSKEY en el hijo (y que exista donde crees)

cr0x@server:~$ dig @ns1.example.com example.com DNSKEY +noall +answer | head -n 3
example.com.	3600	IN	DNSKEY	257 3 13 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
example.com.	3600	IN	DNSKEY	256 3 13 yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=

Qué significa: Presencia de KSK (257) y ZSK (256). Esto no prueba corrección, pero la ausencia es un cráter humeante.

Decisión: Si DNSKEY falta pero DS existe en el padre, espera SERVFAIL en validadores. Publica DNSKEY/firma la zona o elimina DS.

Task 8: Validar como lo haría un resolutor (comprobar la bandera AD vía un validador conocido)

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

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40251
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1
www.example.com.	300	IN	A	198.51.100.20

Qué significa: La bandera ad indica que el resolutor considera la respuesta autenticada (validada por DNSSEC).

Decisión: Si obtienes SERVFAIL aquí pero tus respuestas autoritativas parecen correctas, probablemente sea un desajuste DS/DNSKEY/RRSIG o una cadena rota.

Task 9: Comparar comportamiento entre resolutores (detectar “sólo algunas redes”)

cr0x@server:~$ for r in 1.1.1.1 8.8.8.8 9.9.9.9; do echo "== $r =="; dig @"$r" www.example.com A +time=2 +tries=1 +noall +answer +comments; done
== 1.1.1.1 ==
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27364
www.example.com.	300	IN	A	198.51.100.20
== 8.8.8.8 ==
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58312
== 9.9.9.9 ==
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11427
www.example.com.	300	IN	A	198.51.100.20

Qué significa: Resultados divergentes sugieren diferencias de validación, estados de caché o problemas de alcance a un sitio anycast autoritativo.

Decisión: Si sólo algunos resolutores validadores fallan, sospecha casos límite de DNSSEC o tamaño/fragmentación de paquetes. Si sólo uno falla, comprueba la ruta de ese resolutor a tus NS.

Task 10: Comprobar truncamiento UDP (bit TC) y fallback a TCP

cr0x@server:~$ dig @ns1.example.com example.com DNSKEY +noall +comments
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61643
;; flags: qr aa; QUERY: 1, ANSWER: 0
;; WARNING: Message parser reports malformed message packet.

cr0x@server:~$ dig +tcp @ns1.example.com example.com DNSKEY +noall +answer | head -n 2
example.com.	3600	IN	DNSKEY	257 3 13 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
example.com.	3600	IN	DNSKEY	256 3 13 yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy=

Qué significa: Respuestas DNSSEC grandes pueden provocar truncamiento o comportamientos extraños de middleboxes. TCP funcionando mientras UDP falla es una señal clara.

Decisión: Asegura que los autoritativos soporten EDNS correctamente, permite UDP fragmentado si es posible y que TCP/53 sea accesible. Si no puedes garantizar UDP, tu despliegue DNSSEC será frágil.

Task 11: Verificar alcanzabilidad de NS por UDP y TCP desde tu ubicación

cr0x@server:~$ nc -vz -u ns1.example.com 53
Connection to ns1.example.com 53 port [udp/domain] succeeded!

cr0x@server:~$ nc -vz ns1.example.com 53
Connection to ns1.example.com 53 port [tcp/domain] succeeded!

Qué significa: Esto comprueba la alcanzabilidad básica. No confirma comportamiento DNS correcto, pero descarta caídas obvias de firewall.

Decisión: Si UDP falla pero TCP funciona, espera resoluciones intermitentes y timeouts. Arregla ACLs/redes/grupos de seguridad antes de cambiar registros DNS.

Task 12: Encontrar el conjunto autoritativo tal como lo ve un resolutor recursivo

cr0x@server:~$ dig @1.1.1.1 example.com NS +noall +answer
example.com.	172800	IN	NS	ns1.example.com.
example.com.	172800	IN	NS	ns2.example.com.

Qué significa: El recursor te dice qué conjunto NS considera autoritativo (desde delegación cacheada).

Decisión: Si esto difiere de lo que dig +trace muestra ahora, estás viendo una delegación antigua en caché. No puedes purgar el mundo; planifica mitigaciones acorde.

Task 13: Inspeccionar comportamiento de caché negativa (TTL NXDOMAIN vía SOA)

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

Qué significa: El último campo (aquí 300) es el TTL de caché negativa (comportamiento RFC 2308).

Decisión: Si planificas un corte donde registros puedan no existir temporalmente, reduce esto con antelación. Si acabas de arreglar un NXDOMAIN, espera que algunos resolutores mantengan el “no” hasta este valor.

Task 14: Confirmar que no hay CNAME accidental en el apex o combinaciones ilegales

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

cr0x@server:~$ dig @ns1.example.com example.com A +noall +answer
example.com.	300	IN	A	198.51.100.10

Qué significa: El apex de la zona no debería ser un CNAME en el DNS clásico. Si ves CNAME en el apex y también NS/SOA, algunos resolutores se comportarán mal.

Decisión: Arregla la estructura de la zona (usa ALIAS/ANAME a nivel de proveedor si es necesario) y mantén salidas conformes al estándar en los servidores autoritativos.

Tres micro-historias corporativas desde las trincheras de la delegación

Micro-historia 1: El incidente causado por una suposición errónea

Una empresa SaaS de tamaño medio decidió “profesionalizar el DNS” moviendo la autoritatividad a un proveedor gestionado.
El runbook de migración estaba limpio: copiar zona, reducir TTLs, cambiar NS en el registrador, monitorizar.
Funcionó en staging. Funcionó para el ingeniero que hizo el cambio. Incluso funcionó para la mayoría de usuarios.

Entonces empezaron las escalaciones de ventas: un grupo de clientes empresariales no podía iniciar sesión desde una red corporativa particular.
El dominio de login resolvía a la IP antigua para ellos. Para todos los demás, resolvía a la nueva.
El equipo hizo la danza habitual—reiniciar cosas, deshacer despliegues de la app, mirar dashboards que no tenían ni idea de lo que el DNS hacía.

La suposición errónea: “Si el registrador muestra los nuevos nameservers, la delegación padre está actualizada.”
En realidad, la UI del registrador estaba por delante de la publicación en el registro. Algunos resolutores recursivos habían cacheado el conjunto NS antiguo
con un TTL largo del padre, y siguieron preguntando al proveedor autoritativo antiguo—que ahora servía una instantánea vieja de la zona.

La solución no fue heroica. Restauraron temporalmente la zona en el proveedor antiguo para que coincidiera con las respuestas nuevas (así cualquiera de las rutas de delegación funcionaba),
luego esperaron la ventana del TTL del padre. Después de que las cosas se estabilizaron, retiraron los servidores autoritativos antiguos otra vez—esta vez verificando
con dig +trace y comprobaciones cruzadas, no con capturas de pantalla.

Lo que cambiaron culturalmente: dejaron de tratar la “propagación” como una fuerza mística y empezaron a considerarla estado cacheado con TTLs medibles.
También añadieron un requisito estricto: antes de apagar el DNS antiguo, confirmar que varios resolutores en todo el mundo estaban recibiendo la nueva delegación desde el padre.

Micro-historia 2: La optimización que salió mal

Una gran empresa ejecutaba su propio DNS autoritativo en un par de balanceadores regionales. La razón era familiar:
“Podemos mantener el tráfico local, reducir latencia y tener control total.” Además activaron DNSSEC, porque venían auditorías de seguridad.

En una semana tranquila, “optimizaron” reglas de firewall: permitir UDP/53 desde todas partes, permitir TCP/53 sólo desde IPs de resolutores conocidos.
La idea era reducir la exposición. Incluso pasó pruebas iniciales—la mayoría de consultas son UDP.

Entonces una rotación de claves aumentó el tamaño de las respuestas DNS y disparó más truncamientos y fallback a TCP. De repente, un segmento de resolutores empezó a hacer timeouts.
No estaban en la allowlist. Eran recursores legítimos con IPs de salida cambiantes (resolutores basados en la nube, forwarders empresariales,
y algunos ISPs con flotas grandes). Los usuarios vieron fallos intermitentes que no se correlacionaban con nada obvio.

El patrón del síntoma fue clásico y adyacente a la delegación: algunos resolutores funcionaban, otros recibían SERVFAIL o timeouts, y reintentos contra distintos NS
a veces tenían éxito. El equipo perdió horas culpando al proveedor DNS—salvo que el proveedor DNS era ellos mismos.

La solución eventual fue poco glamorosa: permitir TCP/53 ampliamente, limitarlo por tasa sensatamente y monitorizar.
Si publicas DNSSEC, no puedes fingir que TCP es opcional. Puedes reducir riesgo con controles sensatos, pero no puedes negar la realidad del protocolo.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Otra compañía gestionaba múltiples marcas y dominios, y habían pasado por un doloroso incidente de delegación años antes.
Tras eso, implementaron una regla: cada cambio DNS se valida con un trabajo automatizado de “salud de delegación”.
Sin excepciones. El job corría desde varias redes y comprobaba NS padre, glue, DS, consistencia autoritativa y resolución básica.

Un día, llegó una solicitud rutinaria: “Mover ns2 a una nueva IP; se retira la subred antigua.”
El ingeniero actualizó el A del autoritativo para ns2.example.com y el nuevo servidor arrancó.
Todo parecía bien localmente.

La automatización bloqueó el cambio para declararlo completo. Señaló: “El glue padre para ns2.example.com sigue apuntando a la IP antigua.”
El ingeniero suspiró, entró en el registrador y actualizó el objeto host. El TTL del glue era largo, así que mantuvieron la IP antigua activa hasta su expiración.

El resultado fue aburrido, que es lo más agradable que puedes decir sobre DNS. Los clientes no lo notaron. El retiro de la subred se hizo según lo programado.
El equipo no se llevó elogios, pero tampoco un postmortem. Ese es el trato.

Broma #2: El DNS es el único lugar donde “aburrido” es una característica, y “emocionante” es un evento que limita la carrera.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: funciona desde algunas redes, falla desde otras

Causa raíz: Delegación dividida (NS del padre difiere de los NS del hijo), o cachés manteniendo delegación antigua con TTL largo del padre.

Solución: Usa dig +trace para confirmar la delegación actual del padre. Haz que los conjuntos NS del padre y del hijo sean idénticos. Mantén el autoritativo antiguo sirviendo datos correctos hasta que expiren los TTLs del padre.

2) Síntoma: timeouts intermitentes, especialmente en DNSKEY/TXT

Causa raíz: Problemas de fragmentación UDP, EDNS, o TCP/53 bloqueado. DNSSEC y registros TXT grandes lo amplifican.

Solución: Asegura que TCP/53 sea alcanzable. Ajusta el autoritativo para EDNS. Reduce el tamaño de respuestas donde sea posible (evita TXT inflados, usa parámetros/algoritmos DNSSEC sensatos).

3) Síntoma: SERVFAIL en resolutores validadores, pero consultas autoritativas parecen correctas

Causa raíz: Desajuste DS de DNSSEC, DNSKEY faltante, firmas expiradas o cadena NSEC/NSEC3 incorrecta.

Solución: Compara el DS del padre con el DNSKEY del hijo. Repara DS o vuelve a firmar la zona; si es necesario como mitigación de emergencia, elimina DS en el padre (coordinado) para detener fallos de validación.

4) Síntoma: después de cambiar NS, el dominio está “muerto” durante horas

Causa raíz: El TTL del padre es alto; los resolutores cacharon la delegación antigua. O el nuevo autoritativo no es alcanzable globalmente.

Solución: Planifica migraciones: baja TTLs con antelación (cuando aplique), mantén el autoritativo antiguo sirviendo, valida la alcanzabilidad desde múltiples redes y sólo entonces retira.

5) Síntoma: clientes sólo IPv6 fallan, IPv4 funciona

Causa raíz: Glue AAAA roto para NS in-bailiwick, v6 inalcanzable en los autoritativos o enrutamiento dual-stack inconsistente.

Solución: Verifica registros AAAA de NS y alcanzabilidad v6. Si no puedes soportar v6 de forma fiable para autoritativos, no publiques AAAA para NS.

6) Síntoma: respuestas distintas según qué NS se consulte

Causa raíz: Secundario obsoleto, transferencia fallida, o multi-proveedor con split-brain sin pipeline disciplinado.

Solución: Aplica comprobaciones de consistencia de serial SOA. Arregla el pipeline de transferencias. Quita NS no saludables de la delegación hasta que sean consistentes.

7) Síntoma: algunos resolutores obtienen NXDOMAIN incluso después de crear el registro

Causa raíz: TTL de caché negativa manteniendo NXDOMAIN.

Solución: Espera a que expire el TTL negativo, o si necesitas recuperación más rápida la próxima vez, reduce el campo mínimo/SOA negativo antes de los cambios planeados.

8) Síntoma: la delegación parece correcta, pero los resolutores siguen consultando nombres NS antiguos

Causa raíz: Algunos resolutores ignoran hints de TTL o los limitan; otros cachéan agresivamente. Además, forwarders intermedios pueden cachear más tiempo.

Solución: Trátalo como una convergencia faseada. Mantén compatibilidad, monitoriza y comunica cronogramas basados en el comportamiento observado de resolutores, no en deseo optimista.

Listas de verificación / plan paso a paso

Checklist de migración: cambiar proveedor autoritativo sin sufrir

1. Inventario de la delegación actual: captura NS padre, glue, DS y TTLs usando dig +trace y consultas directas al padre.
2. Baja TTLs en la zona hija para registros que esperas cambiar (A/AAAA, CNAME) con suficiente antelación. No finjas que eso cambia TTLs del padre.
3. Prepara el nuevo proveedor: importa la zona, verifica todos los registros, verifica el estado de DNSSEC (activado/desactivado) deliberadamente, no por accidente.
4. Prueba de consulta directa: consulta los nuevos servidores autoritativos directamente por nombres críticos. Confirma respuestas, SOA y DNSSEC si está activado.
5. Prueba de alcanzabilidad: asegúrate de que UDP/53 y TCP/53 sean alcanzables desde Internet público. Confirma v4/v6 según aplique.
6. Cambia la delegación en el registrador y verifica inmediatamente con dig +trace desde varios puntos de vista.
7. Ejecuta una ventana de servicio dual: mantén el autoritativo antiguo sirviendo las mismas respuestas hasta que converjan los TTLs del padre y las cachés observadas.
8. Monitoriza resolución, no sólo disponibilidad: monitoriza desde múltiples regiones y resolutores; alerta sobre picos de NXDOMAIN/SERVFAIL.
9. Sólo entonces retira el autoritativo antiguo y elimina los NS antiguos del hijo y del padre.

Checklist de emergencia: “dominio parcialmente caído” sospecha de falla de delegación

1. Confirma el alcance del síntoma: qué redes/resolutores fallan? captura ejemplos con IPs exactas de resolutores.
2. Ejecuta trace: confirma qué está delegando el padre ahora mismo.
3. Comprueba glue: si NS in-bailiwick, confirma que las direcciones glue del padre son correctas y alcanzables.
4. Comprueba consistencia autoritativa: serial SOA y registros objetivo en todos los NS.
5. Comprueba cadena DNSSEC: DS en el padre vs DNSKEY en el hijo; valida usando al menos un resolutor validador conocido.
6. Mitiga: si un NS está roto, quítalo de la delegación del padre (y del conjunto NS del hijo) o arréglalo rápido; evita dejar un NS muerto en rotación.
7. Comunica con realismo: publica qué cambiaste y la ventana de convergencia esperada basada en TTLs y comportamiento observado.
8. Post-incidente: añade automatización para prevenir recurrencia (comprobaciones de delegación, alcanzabilidad NS, monitorización de caducidad DNSSEC).

Checklist de higiene operativa: controles aburridos que previenen trampas de delegación

• Mantén idénticos los conjuntos NS del padre y del hijo. La deriva no es redundancia; es confusión.
• Mantén al menos dos servidores autoritativos en redes/proveedores independientes cuando sea posible.
• Monitoriza desde fuera de tu red y fuera de tu resolutor—las vistas internas son mentiras reconfortantes.
• Registra cambios de glue como cambios de infraestructura, no como “contenido DNS”.
• Para DNSSEC: monitoriza expiración de firmas, automatiza rollovers con cuidado y trata actualizaciones DS como cambios de producción con rollback.
• Documenta el proceso del registrador (incluyendo quién tiene acceso y cuánto tardan las actualizaciones).

Preguntas frecuentes

1) ¿Qué es exactamente la “delegación” en DNS?

La delegación es la zona padre indicando a los resolutores qué servidores de nombres son autoritativos para tu dominio (registros NS),
más IPs glue cuando son necesarias, y registros DS si DNSSEC está activado.

2) Si arreglé mi archivo de zona, ¿por qué los usuarios siguen viendo el comportamiento antiguo?

Porque puede que no estén alcanzando tu archivo de zona. Pueden estar siguiendo una delegación vieja en caché, usando glue obsoleto
o atrapados por caché negativa. Arreglar la zona hija no corrige automáticamente la ruta hacia ella.

3) ¿Cuál es la diferencia entre NS del padre y NS del hijo?

Los registros NS del padre viven en la zona padre (registro). Los NS del hijo viven en tu zona en los servidores autoritativos.
Deben coincidir. Cuando no lo hacen, obtienes resolución inconsistente según el camino que tome el resolutor.

4) ¿Cuándo necesito registros glue?

Cuando el hostname de tu servidor de nombres está dentro del dominio que sirve (in-bailiwick), como ns1.example.com para example.com.
El padre debe proporcionar A/AAAA glue para que los resolutores alcancen el NS sin ya resolver la zona.

5) ¿Un glue incorrecto puede romper todo aunque los nombres NS sean correctos?

Sí. Los resolutores pueden tener los nombres NS correctos pero ser enviados a la IP equivocada. Verás timeouts o alcanzabilidad inconsistente.
El glue es un punto de fallo común durante renumeraciones IP y migraciones de proveedor.

6) ¿Por qué DNSSEC causa SERVFAIL en lugar de simplemente “respuesta incorrecta”?

Los resolutores validadores fallan en cerrado: si la cadena de confianza se rompe (DS no coincide con DNSKEY, firmas expiradas, etc.),
no devuelven datos potencialmente manipulados. Devuelven SERVFAIL porque no pueden validar.

7) ¿Existe realmente la “propagación DNS”?

No en el sentido que la gente suele decir. No hay un empuje global. Hay caché con TTLs, más políticas de resolutores,
más una ruta de búsqueda en varios pasos. Internet converge hacia tu cambio; no lo recibe instantáneamente.

8) ¿Cómo demuestro rápido si es delegación o mis servidores autoritativos?

Usa dig +trace para ver qué delega el padre, luego consulta cada autoritativo directamente por el nombre que falla.
Si el trace apunta a NS/glue/DS equivocados, es delegación. Si los autoritativos discrepan, es tu distribución.

9) ¿Debería ejecutar mi propio DNS autoritativo?

Puedes, pero hazlo con disciplina de producción: redes diversas, anycast bien hecho (o no lo hagas), TCP/53 permitido,
monitorización del ciclo de vida DNSSEC y monitorización externa real. Si eso suena a trabajo, lo es.

10) ¿Cuántos nameservers debo publicar?

Dos es el mínimo; tres o cuatro pueden ayudar a la resiliencia, pero sólo si son verdaderamente independientes y se actualizan consistentemente.
Publicar cinco NS mediocres es peor que publicar dos excelentes.

Conclusión: pasos siguientes para evitar incidentes recurrentes

Las fallas de delegación se sienten personales porque te hacen parecer incompetente en público mientras tus sistemas están silenciosamente bien.
La solución es tratar la delegación DNS como infraestructura de producción con su propia observabilidad, control de cambios y plan de rollback.
No “configurar y olvidar”. No “el registrador dice que está bien”.

Haz esto, en este orden

1. Construye una comprobación de salud de delegación que ejecute dig +trace, verifique NS/glue/DS del padre y consulte cada autoritativo por SOA y registros críticos.
2. Haz cumplir la consistencia del conjunto NS entre padre e hijo. Que la deriva genere una alerta de página.
3. Haz del TCP/53 algo no negociable si ejecutas DNSSEC o respuestas grandes. Monitoriza tasas de éxito UDP y TCP por separado.
4. Practica migraciones con una ventana de servicio dual: mantén el autoritativo antiguo sirviendo datos correctos hasta que converjan las cachés.
5. Documenta quién controla el registrador y cuán rápido pueden actualizar glue/DS. Cuando lo necesites, no tendrás tiempo para buscar acceso.

La trampa de la delegación es evitable. Pero sólo si dejas de pensar en DNS como “registros” y empiezas a pensar en él como un camino de búsqueda distribuido
con múltiples autoridades, cachés y anclas de confianza. Ese es el sistema que realmente estás operando.