Cómo monitorizar los cambios de nameservers de tus dominios

Para monitorizar los cambios de nameservers necesitas dos cosas: capturar con regularidad los registros NS del dominio (junto con los nameservers declarados en el registro) y comparar con el estado anterior. Puedes montarlo tú mismo con cron y dig, o dejar que un servicio de monitorización DNS capture el estado, calcule el diff y te envíe un email cuando algo se mueva. Por qué importa: los nameservers deciden qué proveedor de DNS responde por toda la zona. Un cambio de NS que no has planificado es un error o un ataque en curso, y en ambos casos conviene saberlo el mismo día. Aquí tienes por qué este registro merece una alerta propia, cómo interpretar un cambio según el contexto y la configuración paso a paso.

Por qué los nameservers merecen una alerta propia

La mayoría de los registros DNS apuntan a una sola cosa. Un registro A mueve tu web, un registro MX mueve tu correo. El registro NS es distinto: entrega la autoridad sobre toda la zona a un conjunto de servidores. Quien controla esos servidores puede reescribir todos los registros de golpe, en silencio, incluidos los TXT que autentican tu correo y los CNAME de tus herramientas SaaS.

Un cambio legítimo de nameservers es un evento raro. Migras del DNS por defecto de tu registrador a Cloudflare, o de Cloudflare a Route 53, una vez cada varios años, y lo sabes porque has cambiado los nameservers tú mismo. Cualquier cambio fuera de ese escenario es sospechoso por defecto.

Hay un matiz que justifica vigilar los NS desde dos ángulos. El registro almacena los nameservers declarados para el dominio (visibles por RDAP), mientras que los resolvers usan los registros NS que realmente se sirven en DNS. Las dos listas normalmente coinciden. Cuando divergen, algo está a medio migrar, mal configurado o manipulado, y la propia divergencia ya es una señal, incluso antes de que algo falle de forma visible.

Qué significa un cambio de NS según el contexto

Contexto	Significado probable
Tu dominio, migración planificada	Cambio esperado, verifica y sigue con lo tuyo
Tu dominio, nada planificado	Un proveedor actuó sin avisar, o cuenta comprometida
Registro y DNS no coinciden	Migración incompleta o manipulación, investiga hoy mismo
Dominio de terceros que sigues	Nuevo hosting o proveedor DNS, preparación de lanzamiento, o cambio de manos

En tus propios dominios

Si habías planificado una migración, la alerta confirma que el cambio se aplicó. Si no había nada previsto, quedan dos explicaciones. La primera: una agencia, un freelance o un proveedor de hosting con acceso hizo un cambio y no lo comunicó. La segunda es peor: alguien entró en tu cuenta del registrador y redirigió el dominio. Así es exactamente como empieza un secuestro de DNS, y cuanto antes lo detectes, menor será el daño.

Una advertencia honesta: los datos de DNS dicen qué cambió y cuándo se detectó el cambio, no quién lo hizo. Para encontrar al autor, revisa el registro de auditoría de tu cuenta del registrador y pregunta a quienes tienen acceso. El valor de la alerta está en empezar esa conversación el mismo día en lugar de semanas después.

En dominios de terceros que sigues

En un dominio que no controlas, un cambio de nameservers es información. Un competidor que pasa de nameservers de hosting compartido a Cloudflare o AWS está invirtiendo en infraestructura. Un dominio aparcado que salta a nameservers reales suele preceder a un lanzamiento. Y un dominio cuyos NS se van a un proveedor sin relación puede haber cambiado de dueño en la práctica, diga lo que diga todavía el WHOIS. Si sigues dominios de clientes, filiales o competidores, los cambios de NS están entre las señales más potentes que ofrecen los datos públicos.

Configurar la alerta con Domain Sentinel

Todo el proceso lleva un par de minutos por dominio:

1. Añade el dominio a tu watchlist.
2. Abre la página de detalle del dominio y activa la monitorización DNS. Las comprobaciones por defecto incluyen los registros NS del apex de la zona, así que los cambios de nameservers quedan cubiertos sin seleccionar registros a mano.
3. No hay paso tres para la parte del registro: las notificaciones de cambios ya incluyen los nameservers declarados en el registro, extraídos de los datos RDAP del dominio.

Ambos controles son diarios. Los datos del registro se refrescan a las 03:00 y la captura DNS se ejecuta a las 04:00, de modo que un cambio de nameservers se detecta en menos de un día, no en segundos. Para los NS ese compromiso es razonable: los cambios legítimos son eventos planificados, e incluso en un ataque, un email el mismo día es mejor que enterarte por tus clientes.

Cuando algo cambia, el email de alerta muestra el antes y el después del registro, así distingues de un vistazo una migración conocida de un proveedor desconocido.

Comprobar el estado actual a mano

Antes de activar la monitorización, anota cuáles deberían ser tus nameservers. Consulta los NS resueltos:

dig NS example.com

Contrasta con un segundo resolver público para descartar una caché obsoleta:

dig NS example.com @1.1.1.1
dig NS example.com @8.8.8.8

Después compara con los nameservers declarados en el registro, con un lookup RDAP o la herramienta de lookup DNS. Las dos listas deben coincidir exactamente. Si ya difieren antes de empezar, ahí tienes tu primera investigación.

Empieza con una base fiable

Dedica cinco minutos ahora: lista tus dominios críticos, anota los nameservers esperados de cada uno y confirma que registro y resolución coinciden. Luego pon esos dominios en una watchlist con la monitorización DNS activada. A partir de ahí la regla es simple: cualquier alerta de nameservers que no hayas planificado, y cualquier divergencia entre registro y resolución, se investiga el mismo día.