Registros DNS «colgantes»: qué son y cómo evitar la apropiación de subdominios

Un registro DNS «colgante» es una entrada DNS que sigue apuntando a un recurso que ya no existe, como un servicio en la nube eliminado, un servidor fuera de servicio o una plataforma de terceros inactiva. El registro sigue resolviéndose aunque el destino al que apunta ya no exista, y esa discrepancia es precisamente lo que buscan los atacantes.

Para los equipos de TI y seguridad, la dificultad rara vez radica en encontrar un único registro erróneo. Se trata más bien de mantener una visibilidad continua de los dominios, subdominios y registros de autenticación a medida que cambia la infraestructura subyacente. Cada migración, cambio de proveedor y servicio dado de baja deja tras de sí elementos que pueden ser objeto de revisión.

¿Qué son los registros DNS colgantes?

Un registro DNS «colgante» es una entrada DNS que apunta a un recurso que ya no existe o al que no se puede acceder. Los ciberdelincuentes de Internet siempre están al acecho de este tipo de entradas DNS, ya que son propensas a la filtración de información. Algunas de estas entradas pueden contener información confidencial sobre un dominio, lo que las convierte en una mina de oro de datos de la que pueden beneficiarse los autores de amenazas.

Situaciones habituales que provocan un DNS «colgado»

Errores de configuración del DNS. El Sistema de Nombres de Dominio (DNS) se configura por separado del recurso de Internet con el que queremos interactuar. Los registros DNS añadidos al DNS apuntan a estos recursos, lo que nos ayuda a acceder a ellos. En determinados casos, un recurso configurado previamente puede quedar desconfigurado por su proveedor de alojamiento. Por ejemplo, el propietario de un dominio configuró un registro DNS para que apuntara a la dirección IP de un servidor. Este servidor ya no está en uso. El registro DNS apunta ahora a un recurso que ya no existe y, por lo tanto, puede denominarse una entrada «DNS colgante».

Recursos en la nube caducados o eliminados. Si un servicio en la nube utilizado por el propietario de un dominio caduca o se elimina, cualquier registro DNS que apunte a dicho servicio se convierte en un registro DNS «colgante» . Este registro DNS sigue activo, y cualquier atacante puede utilizar el recurso para servir contenido malicioso.

Direcciones IP obsoletas. Una empresa puede migrar sus servicios a un nuevo proveedor, mientras que las direcciones IP anteriores quedan en desuso. Si el equipo se olvida de actualizar o eliminar los antiguos registros DNS, dichos registros quedan expuestos a la apropiación de subdominios y pueden ser objeto de ataques con facilidad.

Desactivación o interrupción de un servicio. Un servidor de correo electrónico, una cuenta de alojamiento o un proveedor de servicios externo se suspende o se retira del servicio; sin embargo, los registros DNS, como los registros MX, A y CNAME, siguen activos y configurados. Los atacantes pueden aprovechar estos registros DNS activos y «suspensos» para suplantar al servicio suspendido.

¿Qué registros DNS quedan «en el aire» y qué riesgos conlleva cada uno de ellos?

La vulnerabilidad se encuentra en la brecha entre la capa DNS y la capa de recursos. Un registro puede ser sintácticamente perfecto y, aun así, resultar peligroso cuando el destino al que hace referencia ya no es propiedad de nadie ni está operativo. La tabla siguiente muestra esa brecha por tipo de registro.

Error habitual

Considerar que una consulta de DNS satisfactoria es prueba de que el registro está en buen estado. Un registro «colgante» se resuelve con normalidad, ya que la propia entrada es válida. Lo que importa es si tu organización sigue siendo propietaria y controlando el destino. Comprobar la resolución sin verificar la propiedad es la razón por la que estos registros superan las auditorías.

Dónde suelen aparecer con mayor frecuencia los registros «pendientes»

Algunas partes de una finca generan estos registros de forma mucho más fiable que otras. Saber cuáles son te permite realizar la auditoría en función de la probabilidad, en lugar de tener que revisar toda la zona cada vez.

• Depósitos de almacenamiento en la nube y servidores de sitios web estáticos: los nombres de los depósitos son únicos a nivel global y se pueden volver a registrar libremente, por lo que un depósito eliminado con un CNAME activo es uno de los objetivos más fáciles de reclamar
• Subdominios personalizados de CDN y SaaS: help.example.com, status.example.com y careers.example.com suelen apuntar a plataformas de terceros que liberan el nombre de host en el momento en que caduca la suscripción
• Herramientas de marketing y páginas de destino: los subdominios de las campañas son configurados rápidamente por equipos ajenos al departamento de TI y rara vez están sujetos a un proceso de desactivación
• Entornos de prueba y de desarrollo: los registros de los entornos de desarrollo (dev), de pruebas de aceptación de usuarios (uat) y de puesta en marcha perduran más allá de los proyectos que los crearon, y nadie se da cuenta porque ningún tráfico real depende de ellos
• Dominios adquiridos o subsidiarios: las zonas heredadas vienen con registros cuyos propietarios originales ya no están, y rara vez se incluye documentación con ellas
• Proveedores de correo electrónico y asistencia técnica que han dejado de prestar servicio: Entradas MX, CNAME de DKIM e inclusiones SPF para una plataforma por la que dejaste de pagar el año pasado

El patrón que los une es la deriva de la propiedad. Cada registro fue creado correctamente por alguien que tenía la autoridad para hacerlo, pero luego la relación que lo justificaba dejó de existir. Por eso, la limpieza es responsabilidad de quien retira un servicio, y no de quien administra el DNS.

Registros TXT de DMARC

Los registros DMARC se publican como registros TXT y suelen incluir destinos de notificación mediante las etiquetas «rua» y «ruf». Si esos destinos apuntan a buzones inactivos o sin supervisar, los equipos pierden visibilidad sobre los fallos de autenticación y los intentos de suplantación de identidad, sin que se muestre ningún error. Revisa cómo publicas un registro DMARC cada vez que cambien las direcciones de notificación o los titulares.

Registros SPF y TXT

Los registros SPF enumeran los servicios de envío autorizados mediante direcciones IP e incluyen mecanismos de autenticación. Si un registro SPF hace referencia a un servicio de terceros obsoleto o a un dominio abandonado, la autenticación deja de ser fiable, y un atacante que registre ese dominio abandonado del proveedor hereda la autorización de envío. Además, a medida que se acumulan los remitentes SaaS, los registros superan el límite de 10 consultas DNS, por lo que el «aplanamiento» de SPF los mantiene dentro del límite máximo. Más información sobre SPF.

Registros TLS-RPT

Los registros TLS-RPT definen dónde se utiliza SMTP TLS deben enviarse. Si el destino de los informes está inactivo, mal configurado o ya no se supervisa, los equipos pasan por alto los fallos de seguridad en el transporte que afectan al envío de correo cifrado. Más información sobre TLS-RPT y MTA-STS.

Registros DKIM CNAME

Los registros DKIM pueden publicarse como registros CNAME que apunten al host DKIM de un proveedor de envío. Si se elimina la cuenta del proveedor o el dominio de destino queda inactivo, la firma y la verificación DKIM dejan de funcionar sin que se note. Por ejemplo, el subdominio mail.domain.com es un alias del CNAME info.domain.com. Por lo tanto, cuando un servidor consulta mail.domain.com, se le redirige a info.domain.com. Tu sistema de autenticación DKIM se suele añadir al DNS como un registro CNAME.

Nota: Los registros MX, NS, A, AAAA, CNAME y TXT pueden quedar «en el aire» cuando hacen referencia a infraestructura inactiva, servicios retirados o proveedores externos abandonados. Este artículo se centra en los registros de autenticación de correo electrónico, ya que esos fallos son los que permanecen ocultos durante más tiempo.

Cómo el DNS «colgante» da lugar a la apropiación de subdominios

Ocultas Las vulnerabilidades del DNS , como los DNS «colgantes», pueden dar lugar a la explotación de dominios y a amenazas cibernéticas. En sectores regulados como el financiero, el sanitario, el educativo, el minorista y el sector público, los problemas no resueltos relacionados con el DNS y la autenticación también complican las revisiones de seguridad y la preparación para las auditorías.

El ataque en sí sigue una secuencia predecible, lo cual resulta útil porque muestra exactamente en qué punto un control rompe la cadena.

1. Enumeración de subdominios. El atacante analiza tu dominio en busca de subdominios utilizando herramientas DNS públicas, registros de transparencia de certificados o enumeración por fuerza bruta.
2. Identificación de registros sin asignar. El atacante encuentra un registro CNAME, A o MX que apunta a un servicio externo que devuelve una respuesta del tipo «cuenta inexistente» o «sin reclamar».
3. Reclamación de recursos. El atacante registra esa misma cuenta, depósito o nombre de host en la plataforma externa, ya sea un depósito de almacenamiento en la nube, un punto final de CDN o un subdominio SaaS.
4. Secuestro de tráfico. Dado que tu registro DNS sigue apuntando allí, todas las solicitudes dirigidas a ese subdominio pasan ahora por la infraestructura que controla el atacante.
5. Abuso de la confianza heredada. A continuación, el subdominio de confianza muestra páginas de phishing, aloja malware, roba cookies de sesión, envía correos electrónicos suplantados o recopila credenciales, todo ello bajo el nombre de dominio de tu organización.

¿Qué es un ataque de apropiación de subdominio?

Cuando un atacante detecta una entrada DNS «suspensa» que apunta a un recurso desconfigurado, puede apropiarse del recurso abandonado y redirigir el tráfico a través de la infraestructura que controla. El atacante se hace con el control del (sub)dominio al que apunta el registro DNS «colgante», desviando así todo el tráfico hacia un dominio controlado por él, con acceso completo al contenido y a los recursos de dicho dominio.

El daño va más allá de una página alterada. Las acciones de los atacantes incluyen el robo de credenciales a través de páginas de inicio de sesión falsas, malware alojado en un subdominio de confianza, suplantación de marca en el correo electrónico y en la web, interceptación de cookies de sesión, abuso de SEO aprovechando la autoridad de tu dominio, abuso en el envío de correos electrónicos debido a registros MX o SPF mal configurados, y daño a la reputación que sale a la luz más adelante en las revisiones de cumplimiento normativo.

Nombre de host «colgante» frente a registro DNS «colgante»

Ambos términos están estrechamente relacionados y se utilizan indistintamente, aunque describen conceptos diferentes. Un registro DNS «colgante» es la propia entrada —un registro CNAME o A— que sigue existiendo en el archivo de zona, pero que apunta a un recurso eliminado o sin propietario. Un nombre de host «colgante» es el subdominio que se resuelve a un destino que ya nadie de tu organización controla.

En la práctica, el registro crea el nombre de host. Si dev.example.com tiene un CNAME que apunta a una cuenta de alojamiento desactivada, entonces dev.example.com es un nombre de host «colgante» y el CNAME es el registro «colgante» que hay detrás. La distinción es importante porque los escáneres señalan uno u otro, aunque ambos requieren la misma solución: verificar la propiedad del destino y, a continuación, eliminar o redirigir el registro.

Cómo detectar registros DNS sin asignar

Detectar en una fase temprana los registros DNS que apuntan a recursos no habilitados puede ayudarte a proteger tu marca. Puedes hacerlo de dos maneras: de forma manual y de forma automatizada.

Detección manual

Aunque requiere mucho tiempo, una auditoría manual puede ayudar a detectar registros DNS obsoletos, sobre todo tras migraciones a la nube, cambios de proveedor, la retirada de servicios o la incorporación de nuevos remitentes.

• Revisa tus entradas DNS: Compara todos los registros DNS de tu sistema de gestión de DNS con los recursos activos de tu entorno. Busca entradas que apunten a servicios o direcciones IP que no existan.
• Comprueba las configuraciones de DNS: Utilice herramientas como nslookup o dig para consultar cada registro y comprobar que el recurso correspondiente esté habilitado y activo. Una respuesta DNS por sí sola no es garantía de seguridad, por lo que debe confirmar que el destino es propiedad de su organización y que esta lo gestiona de forma activa.
• Comprueba si hay servicios huérfanos: Investigue servicios como el alojamiento de terceros, las plataformas en la nube o los proveedores de CDN que puedan haber sido cancelados sin que se hayan eliminado las entradas DNS asociadas.

Para la validación registro por registro, también puedes comprobar cada entrada mediante un comprobador de registros DNS para comprobar a qué se resuelve actualmente antes de decidir si la mantienes.

Por qué la detección manual falla a gran escala

Aunque los métodos manuales son exhaustivos, son propensos a errores humanos y pueden resultar inmanejables en el caso de dominios con configuraciones de DNS grandes o complejas. Hay varios factores que hacen que estos métodos no sean fiables mucho antes de que una zona alcance un tamaño considerable.

• Propiedad descentralizada del DNS entre equipos y departamentos
• Entornos de pruebas y de desarrollo olvidados que aún contienen registros DNS activos
• Tecnología de la información «en la sombra» e integraciones de SaaS de terceros no registradas
• Recursos en la nube caducados que nunca se han sometido a un proceso formal de desmantelamiento
• Varias zonas DNS heredadas a través de adquisiciones o dominios de filiales
• Escasa documentación sobre una infraestructura heredada de la que actualmente nadie es responsable

Detección automática

La supervisión automatizada resulta necesaria cuando los dominios, subdominios, remitentes y servicios en la nube cambian a un ritmo más rápido que el ciclo de auditoría. En lugar de comprobaciones periódicas, una plataforma centralizada detecta de forma continua los registros inactivos, las configuraciones de autenticación erróneas y los cambios sospechosos en toda la cartera.

La ventaja práctica radica más en la rapidez que en la exhaustividad. Una auditoría trimestral acabará por detectar el mismo registro, pero lo hará tras un trimestre de exposición. La supervisión continua elimina ese intervalo de tiempo entre la retirada del servicio y la siguiente comprobación, que es precisamente donde reside el riesgo de apropiación.

Cómo solucionar los registros DNS «suspensos»

Una vez identificado un registro pendiente, el orden es importante. Si se elimina el registro antes de recuperar el recurso, puede quedar una ventana abierta, y si se omite el paso del TTL, la corrección tardará horas en propagarse, en lugar de minutos.

1. Identifica el registro y su destino. Utiliza herramientas de DNS o una plataforma de monitorización para localizar la entrada específica y a qué apunta actualmente.
2. Comprueba quién es el propietario del destino. Comprueba si tu organización sigue controlando el destino consultando al proveedor o al registro de cuentas.
3. Primero, reduce el TTL. Ajústalo a un valor comprendido entre 60 y 300 segundos antes de realizar cambios, para que las actualizaciones se propaguen rápidamente una vez que actúes.
4. Recupera el recurso si es posible reclamarlo. Si el objetivo es un depósito en la nube o un punto final de CDN sin reclamar, reclámalo antes de modificar el DNS para cerrar la ventana de apropiación.
5. Elimina el registro o cambia su destino. Elimínalo si el servicio se ha retirado. Si debe permanecer activo, redirígelo a un recurso que poseas actualmente y que hayas aprovisionado.
6. Comprueba la propagación. Utiliza «dig» o «nslookup» para confirmar que el registro se resuelve correctamente y que el destino anterior ya no responde.
7. Documenta el cambio. Anota qué ha cambiado, por qué, cuándo y quién lo ha hecho; a continuación, actualiza el inventario de DNS y asigna la responsabilidad de su mantenimiento.

Cómo evitar la apropiación de subdominios debido a registros DNS sin asignar

La prevención combina la higiene del DNS con la supervisión continua. Las medidas que se indican a continuación son las más importantes para los equipos de TI, los equipos de seguridad y los proveedores de servicios gestionados (MSP) que gestionan varios dominios.

• Elimina inmediatamente los registros DNS que no se utilicen: elimina los registros CNAME, A, AAAA, MX y TXT cuando los servicios dejen de estar en uso, en lugar de dejarlos ahí «por si acaso».
• Comprueba los destinos de terceros antes de enlazar a ellos: comprueba primero que los recursos en la nube, CDN, de correo electrónico y de alojamiento estén activos y sean propiedad de tu organización
• Supervisa los registros de autenticación del correo electrónico: revisa periódicamente DMARC, SPF, DKIM, MTA-STS, TLS-RPT y BIMI para detectar referencias inactivas o incorrectas
• Titularidad de los documentos: mantener un inventario de dominios, subdominios, remitentes y propietarios de servicios, indicando el nombre del propietario en cada registro
• Incorporar la limpieza del DNS al proceso de retirada del servicio: hacer que la eliminación de registros sea un paso obligatorio cada vez que se retire un servicio en la nube, una plataforma SaaS o una cuenta de alojamiento
• Configura alertas automáticas: vigila los servicios huérfanos, las desviaciones de DNS y la aparición de nuevos subdominios en tu zona
• Realizar auditorías de seguridad periódicas: mensuales o trimestrales, dependiendo de la complejidad, e inmediatamente después de cualquier migración, cambio de proveedor o adquisición de dominio

Qué hacer con los subdominios antiguos o que no se utilizan

Cuando ya no se necesita un subdominio, la decisión suele dar lugar a uno de estos cinco resultados.

• Eliminar el registro cuando el subdominio ya no tenga justificación comercial
• Recuperar el recurso externo abandonado cuando el subdominio deba permanecer activo y la cuenta aún pueda reclamarse
• Aparca de forma segura dirigiéndolo a un recurso interno controlado, nunca a una plataforma externa, cuando tenga que resolver la dirección pero no servir nada
• Redirigir solo cuando exista una razón comercial para ello, y confirma que el destino es de tu propiedad y está activo
• Documentar documenta cada decisión y asigna la responsabilidad antes de dar de baja cualquier elemento

Cómo ayuda PowerDMARC

PowerDMARC centraliza la supervisión de la autenticación de dominios y correo electrónico para que los equipos puedan detectar problemas en DMARC, SPF, DKIM, MTA-STS, TLS-RPT y BIMI sin tener que revisar manualmente cada registro DNS. El objetivo no es encontrar un único registro erróneo, sino mantener una visibilidad continua sobre todos los dominios, subdominios y registros de autenticación que afectan a tu nivel de seguridad.

• Panel de control centralizado: dominio, subdominio y estado de autenticación visibles desde un único lugar
• Detección rápida de problemas: las configuraciones erróneas se detectan antes de que afecten a la seguridad o a la capacidad de entrega
• Gestión automatizada de SPF: menos errores de consulta y fuentes de envío más limpias a medida que cambian las plataformas SaaS
• Preparación para el cumplimiento normativo: apoyo en la preparación de auditorías para equipos de los sectores financiero, sanitario, educativo, minorista y público
• Asistencia especializada: asistencia global para ayudar a investigar, validar y corregir rápidamente un registro de riesgo

Para los proveedores de servicios, la agrupación centralizada de dominios y el acceso basado en roles facilitan la supervisión simultánea de numerosos entornos de clientes. Los programas MSP y MSSP se ha diseñado en torno a ese flujo de trabajo.

Si quieres hacerte una idea rápida de tu postura actual, comprueba tu dominio con el analizador gratuito. Introduce tu dominio, haz clic en «Comprobar ahora» y podrás ver la configuración de tus registros DNS, los errores de configuración detectados y consejos prácticos para solucionarlos.

Preguntas frecuentes

En ellas se abordan las cuestiones operativas que surgen una vez que el concepto está claro.

¿Cómo se solucionan los registros DNS «suspensos»?

Identifica el registro obsoleto, comprueba si tu organización sigue siendo la titular del dominio en cuestión y, a continuación, reduce el TTL. Si el recurso es reclamable, reclámalo primero; a continuación, elimina el registro o cambia su puntero, comprueba la propagación con el comando «dig» y documenta el cambio.

¿Qué es un nombre de host «pendiente»?

Un subdominio que apunta a un destino que ya no está bajo el control del propietario del dominio. Se crea a raíz de un registro DNS «colgante». Si dev.example.com apunta a una cuenta en la nube a la que se le han retirado los servicios, se trata de un nombre de host «colgante».

¿Pueden los registros DNS pendientes afectar a la seguridad del correo electrónico?

Sí. Los registros DMARC, SPF, DKIM, MTA-STS y TLS-RPT quedan sin asignar cuando hacen referencia a dominios inactivos, remitentes obsoletos o buzones de informes no supervisados. El resultado son errores de autenticación y lagunas de visibilidad silenciosas.

¿Con qué frecuencia deberían las organizaciones auditar los registros DNS?

Tras cada baja de un servicio, migración de proveedor, adquisición de dominio o cambio de remitente. Añade auditorías periódicas mensuales o trimestrales, en función de la complejidad, y una supervisión continua para detectar desviaciones entre ellas.

¿Un registro sin asignar implica siempre que se puede tomar el control de un subdominio?

No. Para que se produzca una apropiación, es necesario que el recurso objetivo pueda ser reclamado por otra persona, algo habitual en los depósitos en la nube, los puntos finales de CDN y los subdominios de SaaS. Un registro que apunte a una IP inactiva sigue provocando interrupciones del servicio y riesgo de interceptación.

¿Quién debería encargarse internamente de la limpieza de los registros DNS?

La responsabilidad de la retirada de un servicio recae en quien sea el responsable de dicha retirada, no solo en el administrador del DNS. Los registros quedan obsoletos en el momento en que se retira un servicio, por lo que su eliminación debe incluirse en la lista de comprobación de la baja del servicio, en lugar de en una revisión independiente del DNS.

• Acerca de
• Últimas publicaciones

Yunes Tarada

Experto en seguridad de dominios y correo electrónico en PowerDMARC

Yunes es jefe de equipo de operaciones en PowerDMARC con conocimientos especializados en autenticación y seguridad del correo electrónico. Yunes es Administrador Asociado de Azure certificado por Microsoft y cuenta con certificaciones de CompTIA A+ y muchas más.

Últimos mensajes de Yunes Tarada (ver todos)

• Guía de configuración de DKIM, DMARC y SPF de TinkMail - 19 de agosto de 2026
• Guía de configuración de DKIM, DMARC y SPF en PandaDoc - 19 de agosto de 2026
• Guía de configuración de DKIM, DMARC y SPF de Moloni - 18 de agosto de 2026