Gobernanza de DNS: las cuatro formas en que fallan los patrimonios de DNS

La mayoría de los patrimonios de DNS no se gestionan. Se acumulan. Se crean registros por buenas razones, los proyectos que los motivaron terminan y nada reconcilia lo que está publicado con lo que sigue siendo cierto. Quien hereda el patrimonio hereda cada decisión tomada por personas que ya se fueron, normalmente sin documentación y sin forma de saber qué registros siguen siendo importantes.

Esa acumulación falla de cuatro formas concretas, cada una con una causa distinta, un coste diferente y una manera particular de ser detectada.

Cada uno de estos casos empieza igual. Alguien crea un registro por un buen motivo, el proyecto que lo sustentaba termina y nadie reconcilia después el registro con la realidad.

La mayoría de los patrimonios de DNS funcionan como un armario que nadie abre. Todo está ahí dentro, se cierra la puerta y, mientras el correo fluya y el sitio web cargue, nadie tiene motivos para mirar. Entonces alguien necesita algo concreto, abre la puerta y descubre lo que de verdad se ha ido acumulando.

Durante años eso era tolerable, porque nada te indicaba lo contrario. Los marcos con los que los equipos de seguridad se miden estaban orientados a resultados y no a mecanismos. NIST CSF pregunta si gestionas activos. NCSC CAF pregunta si comprendes tus sistemas. Ninguno menciona los registros DNS como una clase de activo con requisitos específicos de higiene, así que la gobernanza de DNS permaneció como una disciplina no escrita que los equipos buenos aplicaban y los demás aplazaban.

Eso cambió a lo largo de tres años y cuatro documentos, la mayoría europeos. La UE redactó requisitos técnicos detallados para las organizaciones que gestionan infraestructuras de DNS, ENISA convirtió esos requisitos en guías implemetables con ejemplos de evidencias, y NIST revisó su guía de despliegue de DNS por primera vez desde 2013. Entre todos ellos movieron la higiene DNS de buena práctica no escrita a algo que pueden pedirte como evidencia.

Esta guía cubre lo que esos documentos realmente requieren, a quién obligan, las cuatro formas en que fallan los patrimonios de DNS en la práctica y un marco de cinco etapas para gobernar un patrimonio que no puedes ver completamente. Está dirigido a equipos que heredan grandes carteras de dominios a través de múltiples registradores y proveedores, donde nadie construyó el patrimonio del que ahora son responsables.

Dos de los cuatro modos de fallo ya se han tratado en profundidad; esta guía enlaza a ambos en lugar de repetirlos. Comienza con dangling DNS: cómo detectarlo y arreglarlo antes de que lo tomen para lo que OWASP y AWS dicen sobre registros que siguen apuntando a recursos cloud eliminados, y cómo las transferencias de zona abiertas exponen tu red interna para ver el resultado real de dos zonas entregadas en una sola consulta.

Hay dos aspectos de esa secuencia que merecen destacarse. El primero es la dirección de avance. En 2022 la UE estableció una obligación. En 2024 ya había concretado los requisitos técnicos. En 2025 ENISA había publicado cómo se evidencia el cumplimiento. Los reguladores pasaron de "gestiona tu riesgo" a "aquí tienes el requisito y aquí cómo demuestras que lo cumples". DNS fue nombrado explícitamente en cada paso.

El segundo es que NIST llegó de forma independiente a conclusiones similares. SP 800-81r3 no es una respuesta a NIS2, es el cuerpo de estándares estadounidense revisando una guía de trece años de antigüedad. Que dos procesos en diferentes continentes hayan acabado centrándose en la higiene de DNS en la misma ventana temporal dice más del problema que de los reguladores.

Aquí es donde la mayoría de coberturas sobre NIS2 y DNS se vuelven imprecisas, y la distinción importa si tienes que decidir qué debe hacer tu organización.

NIS2 es una directiva, no un reglamento, por lo que entra en vigor a través de la ley de transposición de cada Estado miembro, y no de forma directa e idéntica para todas las empresas de Europa. Los artículos 2 y 3 recogen los 18 sectores y los criterios de tamaño para entidades "esenciales" e "importantes", pero hay excepciones previstas y los Estados miembros pueden designar entidades concretas dentro del alcance independientemente de su tamaño. Las obligaciones de gestión de riesgos del artículo 21 tienen forma de resultado, y DNS se recoge dentro de ellas como parte de la seguridad de red y gestión de activos, no como elemento explícito. Lo que esto significa en la práctica depende de cómo tu ley nacional la transponga, así que la regla de sectores y tamaños es sólo un primer filtro, no una respuesta final.

El Reglamento de Ejecución 2024/2690 vincula a una lista concreta. Sus requisitos técnicos detallados aplican a proveedores de DNS, registros TLD, proveedores cloud, de centros de datos, CDN, proveedores de servicios gestionados y de seguridad gestionada, plataformas de marketplace online, motores de búsqueda, redes sociales y proveedores de servicios de confianza. Los registradores no figuran como categoría propia en este Anexo (aunque siguen sujetos a NIS2 por transposición nacional, pero es una base legal aparte). Si gestionas tus propios dominios en una empresa, este Reglamento no te impone los requisitos de su anexo directamente. Pero probablemente sí a varios de tus proveedores. La guía de implementación técnica de ENISA es el acompañamiento práctico, incluyendo tablas de relación con los estándares internacionales y europeos.

NIST SP 800-81r3 es una guía voluntaria que aplica a cualquiera. Sin fuerza legal, sin pruebas de alcance. Es una referencia técnica útil para acompañar la legislación, los contratos y los estándares sectoriales, y precisamente por su aplicabilidad general, es probable que la cite un auditor o la encuentres en cuestionarios de seguridad para clientes. NIST publicó posibles actualizaciones y erratas al documento en julio de 2026, así que revisa la página activa y no solo una copia antes de citar detalles. Si quieres recorrer en detalle la revisión, desde DNS protector hasta el endurecimiento de servidores autoritativos, lee Ivan Ristic on NIST's secure DNS deployment guide en vez de basarte en este resumen.

En la práctica, para la mayoría de empresas: no estás sujeto directamente a los requisitos técnicos de CIR 2024/2690 mientras que NIS2 puede o no aplicar en función de la transposición nacional. NIST SP 800-81r3 es el único documento de esta lista sobre el que puedes empezar a actuar hoy sin esperar una determinación de alcance o un plazo de transposición.

El fallo más habitual y el menos dramático. DNS deja de resolver correctamente y, como suele dejar de hacerlo sólo a veces, nadie lo detecta.

• Delegaciones lamas ocurren cuando los registros NS de una zona padre apuntan a un servidor de nombres que no es autoritativo para la zona hija, o no responde por ella. La delegación está escrita; el servidor detrás no cumple su función. Entonces, la resolución depende de a qué servidor acuda un resolutor, así que el dominio funciona para unos y devuelve SERVFAIL para otros. Ambos resultados son comportamientos correctos. Solo uno es visible para quien hace la prueba.
• Registros huérfanos apuntan a infraestructuras que ya no existen. Un servidor fue retirado, un balanceador reemplazado, un servicio migrado y el registro A o CNAME quedó allí. A veces el registro simplemente falla. A veces la dirección se reasigna a otro tenant y el registro apunta ahora a infraestructura ajena.
• Fallas de resolución parcial son las más difíciles de detectar porque burlan los sistemas habituales de monitorización. Un chequeo pregunta "¿resuelve este dominio?" desde un sitio y un resolutor: respuesta correcta. Mientras, un subconjunto de usuarios accede a un nameserver con información caduca, o un resolutor valida DNSSEC cuando el tuyo no, o una ruta en la que algún NS está muerto. El fallo es real y reproducible, pero no desde donde alguien esté mirando.

La razón de que esta categoría persista es que DNS está diseñado para ser resiliente. La redundancia implica que si sólo uno de cuatro servidores falla, normalmente no provoca corte visible. Solo un servicio un poco más lento o menos fiable, que degrada en silencio y nunca genera una señal clara para investigar.

Una transferencia de zona, o AXFR, es como un servidor maestro replica toda la zona a un secundario. Necesario, normal y peligroso si no está restringido, porque un nameserver que no limite las transferencias a IPs de confianza entregará toda la zona a cualquiera que la solicite.

Una sola consulta devuelve todos los nombres de host de la zona y sus direcciones. Sin escaneos, sin fuerza bruta de subdominios, sin adivinar. En patrimonios que hemos revisado, eso ha significado convenciones internas de nomenclatura, infraestructura de voz, entornos de desarrollo mezclados en zonas de producción, y mapas de red prácticamente completos devueltos al instante.

El patrón a conocer: las zonas raíz suelen estar protegidas, porque son las que todos recuerdan auditar. Los subdominios delegados, gestionados por otro equipo o para un producto concreto, configuran por su cuenta y nadie los revisa. Lo explicamos en detalle, incluidos ejemplos reales, en cómo las transferencias de zona abiertas exponen tu red interna.

Un registro colgante apunta a un servicio de terceros una vez que se ha dado de baja. Si el nombre tras ese registro puede volver a ser reclamado por otra persona, el dominio se va con él.

La mecánica es simple hasta resultar poco espectacular. Un equipo prepara un site de campaña en un constructor web, un bucket de almacenamiento o un servicio en la nube, apunta un registro DNS a él y el proyecto termina. El servicio desaparece. El registro no, porque crearlo es un acto planificado y eliminarlo nunca es responsabilidad de nadie en concreto.

Lo que convierte un registro colgante en una toma es la plataforma al otro lado.

Durante un servicio a un cliente ejecutamos reporting DNS sobre su patrimonio, comparando a qué apuntaban los registros realmente respecto a lo que creía el personal aún activo. Había un dominio montado años antes para una campaña de marketing, con un registro A apuntando a un constructor web de terceros. La campaña había terminado y el sitio ya no existía, pero el registro seguía allí, operativo, aparentemente intacto desde entonces.

Probamos si la plataforma permitía que otra persona lo reclamara. Sí. Sin desafío TXT para demostrar control del dominio, sin archivo que subir, sin comprobación de que alguien lo hubiera configurado antes ni aviso al dueño original. La plataforma trató sólo el registro DNS como prueba suficiente de intención, que es el supuesto donde descansa todo el fallo. Un registro que apunta a un servicio no dice nada sobre quién puede reclamar lo que hay detrás.

Esa misma tarde, el dominio quedó ligado a una cuenta que controlábamos y sirviendo una página escrita por nosotros, en el nombre real del cliente, bajo su dominio real, sin advertencias de certificado ni señales extrañas. Un usuario metiendo esa dirección, o siguiendo un enlace antiguo, no tenía motivo para sospechar nada.

Lo reportamos el mismo día. Cuando confirmaron internamente el hallazgo, el registro DNS se eliminó esa noche y la exposición quedó cerrada. La vulnerabilidad había existido tanto como el registro, seguramente años. Detectarlo, probarlo y solventarlo, todo en una tarde. Lo difícil nunca fue la solución.

Eso es lo que hace que una toma sea más grave que otros fallos. Una fuga da información al atacante. Una toma le da un canal confiable para entregar algo. El contenido servido desde un dominio conocido no despierta las sospechas que genera un dominio falsificado, lo que hace trivial robar credenciales, distribuir malware y secuestrar tráfico de búsqueda.

Los proveedores cloud reconocen abiertamente que no cierran este hueco por ti. AWS documenta que muchos servicios permiten a un nuevo cliente reclamar un nombre previamente usado, que no existe un mecanismo universal de verificación de dominio entre servicios y que su equipo de incidentes ve atacantes escaneando DNS públicos en busca de registros apuntando a recursos ya eliminados [5]. OWASP lo trata como un problema operativo y recomienda inventario, eliminar registros antes que los recursos de los que dependen y vigilar los mensajes de error de proveedor tras recursos borrados [6]. Ambos aciertan y ambos dejan el trabajo a tu cargo. Los detalles de cómo detectar y corregir estos registros están en dangling DNS: cómo detectarlo y arreglarlo antes de que lo tomen.

El fallo que sobrevive a las auditorías, porque todo marca en verde.

DNSSEC roto es lo más claro y el fallo es asimétrico. Una zona firmada con firmas caducadas o un registro DS que ya no coincide con la clave actual falla la validación de manera notoria, que es DNSSEC actuando como debe aunque aparentemente sea una caída sin explicación para usuarios. Más sutil es la zona que parece firmada pero donde nunca se valida en ningún punto: tienes la apariencia de DNSSEC y ninguna protección real. Nuestra guía sobre NIST's DNS deployment guidance cubre cómo desplegar DNSSEC correctamente.

Un registro TLSA publicado no equivale por sí mismo a un despliegue DANE: sólo es útil para DANE cuando la cadena DNSSEC valida de forma segura. En SMTP, un TLSA inseguro se trata igual que el pre-DANE TLS oportunista, no como DANE autenticado.

Registros NS y SOA inconsistentes significan que tus servidores difieren sobre lo que contiene la zona. Si el conjunto NS en la raíz y el interior no coinciden, los resolutores pueden llegar a servidores que ya no consideras autoritativos. Si los números de serie SOA difieren entre servidores pueden estar sirviendo datos distintos y el usuario dependerá de cuál reciba. Ambas situaciones son invisibles si sólo preguntas a un nameserver y obtienes una respuesta válida.

Lo que une esta categoría es que los controles informan de éxito. Puedes tener un escaneo limpio, zona firmada y registro DANE y carecer totalmente de la protección que deberían implicar.

Dos puntos a destacar de ese mapeo.

La delegación lama aparece dos veces, en dos modos de fallo distintos, y es el mejor ejemplo de por qué la taxonomía es útil. La sección 3.2.1 la trata como un problema de disponibilidad, donde una delegación que apunta a un servidor inexistente vuelve inalcanzable una zona hija o la hace accesible sólo a ratos. La sección 3.6.2 trata la misma mala configuración como vía de hijacking: una subzona delegada a un proveedor de DNS cuyo contrato ha caducado puede ser tomada por un actor que contrate con ese proveedor. Un error, dos consecuencias y la mayoría de equipos sólo busca la primera.

Zone drift y zone thrash, en la sección 3.2.2, son las formas nominadas del problema de inconsistencia. Si pones Refresh y Retry del SOA muy alto en una zona que cambia mucho, los secundarios sirven datos caducos. Si lo pones muy bajo, generas demasiado tráfico de transferencia. Ambas degradan el servicio sin provocar un corte visible.

Todo lo que sigue depende de esto, y aquí es donde la mayoría de programas fallan silenciosamente. El objetivo es la cobertura total: cada dominio, zona y registro, en cada registrador, proveedor de DNS, cuenta cloud y entidad certificadora, aunque ya no exista el equipo que lo creó. El riesgo: basar la lista en la memoria institucional, porque precisamente los registros que causan incidentes son los que nadie recuerda. Dominios heredados en una adquisición y nunca migrados. Subdominios delegados a equipos ya reorganizados. Sitios de campaña montados por marketing sin ticket. Una lista hecha preguntando "¿qué tienes?" será incorrecta, y lo será justo donde más importa. Nuestro blog sobre dangling DNS explica el destino de los registros que nunca acaban en ninguna lista.

Cuando sabes lo que existe, define cómo es el estado bueno para que las desviaciones sean visibles. Eso implica registrar qué registradores y DNS están permitidos, qué rangos de IP y CAs cloud esperas ver, cómo debería configurarse la autenticación de correo en cada dominio emisor y qué zonas llevan DNSSEC. Todo para poder comparar: un cambio de nameserver no autorizado y una migración planificada producen idénticos eventos DNS; solo la línea base te dice cuál es cuál. Sin una, no eres ciego al cambio sino a su significado.

Compara constantemente el patrimonio en vivo con la línea base y clasifica lo que surja. Aproximadamente el 1% de los nombres en un gran patrimonio cambian cada día; en uno de 37.500 registros, son 375 diarios. Flujos de cambios en bruto a ese volumen acaban siendo ignorados en dos semanas, lo que es peor que no tener ningún flujo porque aparentas monitorización. La clasificación lo vuelve operable: separar el bullicio rutinario de proveedor de un registro que empieza a apuntar donde no debe, suprimiendo lo esperado para que sobresalga lo inesperado.

Mide el patrimonio con NIST SP 800-81r3, usando el mapeo anterior para convertir cada modo de fallo en un conjunto de chequeos. Revisa a diario en vez de de forma periódica y sigue la tasa de éxito a lo largo del tiempo, no tratándolo como simple resultado puntual. Un escaneo limpio dice el estado en un momento. Una tasa bajando durante seis semanas dice que el patrimonio deriva, y eso es justo el aviso que quieres y que llega antes de que se rompa nada.

Segmenta el patrimonio para que el modelo sea sostenible y hazlo tanto para los cambios como para los activos. Un cambio de nameserver en un dominio que gestiona acceso de clientes no es igual que el mismo cambio en un dominio aparcado; tratarlos igual garantiza que lo importante se pierda. Cruza los cambios con los problemas abiertos, para que un registro que cambia con un hallazgo sin cerrar se escale y no entre al montón. Los programas que lo marcan todo igual de crítico colapsan por volumen de alertas en un trimestre.

El salto más importante es del nivel 2 al nivel 3, porque ahí es donde la detección deja de depender de que alguien decida mirar.

Repasa esto con tu propio patrimonio de dominios. Cualquier cosa que no puedas responder con confianza ya es en sí misma un hallazgo.

• Puedes generar una lista de todos los dominios que posee tu organización, en todos los registradores
• Esa lista incluye dominios adquiridos por fusiones y adquisiciones
• Sabes qué proveedor de DNS aloja cada zona
• Puedes enumerar todos los subdominios delegados a un nameserver que no controlas
• Cada zona tiene un propietario asignado que sigue trabajando en la organización

• Cada registro NS en cada zona padre apunta a un nameserver que es autoritativo para la zona hija
• Los números de serie SOA coinciden en todos los nameservers de cada zona
• El conjunto de NS en el padre coincide con el conjunto publicado dentro de la zona hija
• Pruebas la resolución desde múltiples resolutores y geografías, no solo uno

• Las transferencias de zona están restringidas a IPs secundarias nominadas en cada nameserver
• Has probado AXFR en cada subdominio delegado, no solo en el padre
• Ninguna zona contiene nombres de host que revelen convenciones internas de nomenclatura o infraestructura no pública
• Los entornos de desarrollo y pruebas no se encuentran en zonas de producción

• Puedes enumerar cada registro DNS que apunte a una plataforma SaaS de terceros, servicio en la nube o bucket de almacenamiento
• Eliminar el registro DNS es un paso obligatorio al dar de baja cualquier servicio de terceros
• Sabes cuáles de esas plataformas verifican la propiedad del dominio antes de permitir asociarlo
• Alguien revisa estos registros de forma programada en lugar de solo cuando hay incidencias

• Sabes qué zonas están firmadas con DNSSEC y cuáles no
• El vencimiento de las firmas es monitorizado, no solo asumido
• Cualquier zona que publique registros TLSA para DANE está firmada con DNSSEC
• Los registros DS en el padre coinciden con las claves actuales en la zona hija
• Has probado que la validación realmente falla cuando debe hacerlo

• Existe una línea base que define registradores permitidos, proveedores, rangos de nube y autoridades certificadoras
• Los cambios en registros NS, MX y TXT generan una alerta
• El patrimonio se clasifica por importancia y no se trata de forma uniforme
• Alguien es responsable explícito del saneamiento DNS, no solo de forma implícita

La etapa que detiene la mayoría de los programas es la primera, porque todo lo demás depende de saber lo que existe. Las comprobaciones de configuración cloud-native son útiles y están pensadas para una sola cuenta. Los escáneres de código abierto cubren más, pero solo se ejecutan cuando alguien se acuerda de hacerlo. Ninguno cubre un patrimonio repartido en varios registradores, múltiples proveedores de DNS y cuentas cloud pertenecientes a equipos que no reportan a seguridad.

Red Sift ASM construye ese inventario conectando directamente a tus registradores, proveedores DNS y cuentas en la nube, en lugar de depender de una lista que mantiene alguien. Supervisa la configuración DNS y DNSSEC de todo el patrimonio de forma continua, señala los registros colgantes y recursos reclamables cuando aparecen, y valida la configuración DANE, lo que significa que los fallos de esta guía aparecen como hallazgos y no como incidentes.

• [1] Directiva (UE) 2022/2555 del Parlamento Europeo y del Consejo de 14 de diciembre de 2022 sobre medidas para un nivel elevado común de ciberseguridad en la Unión
• [2] Reglamento de Ejecución (UE) 2024/2690 de la Comisión, de 17 de octubre de 2024
• [3] Guía Técnica de Implementación NIS2
• [4] Guía de Implementación Segura del Sistema de Nombres de Dominio (DNS), NIST SP 800-81r3
• [5] Threat Tactic Spotlight: Subdomain Takeover
• [6] Subdomain Takeover Prevention Cheat Sheet