Resumen ejecutivo: Una transferencia de zona DNS (AXFR) debería permanecer únicamente entre el servidor de nombres primario y los secundarios de un dominio. Cuando queda abierta a cualquiera, una sola consulta devuelve una lista completa de cada host en esa zona. En revisiones recientes, Red Sift encontró zonas en múltiples patrimonios que entregaban nombres de host internos, infraestructura de VoIP sin cifrar y mapas completos de red a quien preguntara. Ninguna de estas organizaciones se propuso exponer eso. Simplemente se fue acumulando.
No te pierdas: nuestro primer artículo de esta serie sobre la gestión de un DNS colgante.
Puntos clave
- Una transferencia de zona abierta devuelve todos los nombres de host de una zona en una sola consulta, sin necesidad de escaneo ni de adivinar nada
- Los dominios principales suelen estar protegidos, mientras que un subdominio delegado, con frecuencia propiedad de otro equipo, queda completamente abierto
- Lo que se expone no es algo abstracto. Son endpoints SIP, entornos de desarrollo y convenciones de nomenclatura internas sobre las que un atacante puede actuar de inmediato
- Red Sift ASM descubre y monitoriza estos activos de forma continua, incluidos aquellos que tu equipo ni siquiera sabe que existen
Qué es realmente una transferencia de zona
Una transferencia de zona DNS, o AXFR, es el mecanismo que utiliza un servidor de nombres primario para replicar su archivo de zona completo a un servidor de nombres secundario. Eso es una parte normal y necesaria del funcionamiento del DNS. Dos servidores necesitan tener los mismos registros, así que uno copia toda la zona al otro.
El problema es que AXFR no se diseñó pensando en el internet moderno. A menos que un servidor de nombres esté configurado explícitamente para restringir las transferencias a direcciones IP de confianza, responderá a una solicitud de transferencia de cualquiera. Ejecuta dig axfr @nameserver domain.com contra un servidor mal configurado y obtendrás de vuelta todos los registros de esa zona. Todos los subdominios. Todos los nombres de host internos. Todas las direcciones IP vinculadas a esos hosts.
No necesitas forzar subdominios por fuerza bruta ni escanear rangos de IP para construir un mapa de la infraestructura de alguien. Simplemente lo pides.
La zona principal no es el problema. La delegada sí lo es
La mayoría de los equipos de seguridad que se han planteado esto han restringido las transferencias en su dominio principal. Esa es la zona que todo el mundo recuerda revisar.
Lo que se pasa por alto es la delegación. Cuando un dominio cede un subdominio a un servidor de nombres distinto, quizás para un producto específico, una oficina regional o una plataforma propiedad de otro equipo, esa zona delegada funciona con su propia configuración. Nadie vuelve a comprobarla frente a los estándares del dominio principal, porque nadie la considera una zona separada. Simplemente es "parte del dominio".
La escala es el verdadero problema aquí. Nuestro análisis encontró el mismo patrón de exposición en varias organizaciones. Tomemos el caso de una empresa de telecomunicaciones. Sus servidores de nombres principales estaban limpios: transferencias restringidas, registros actualizados, nada que señalar. Pero un subdominio delegado, configurado años antes para una plataforma de videoconferencia, seguía permitiendo transferencias de zona abiertas en seis nombres de host.
Nadie lo puso ahí a propósito. Se delega un subdominio para un proyecto, el equipo que lo gestionaba avanza hacia otras cosas, y la configuración nunca se vuelve a revisar. Simplemente terminó así.
Lo que devolvió una sola consulta
Un único dig axfr contra esa zona delegada devolvió lo siguiente:
- Los nombres de host internos de Session Border Controllers en funcionamiento en dos ubicaciones distintas, comunicándose mediante SIP sin cifrar
- Un conjunto de nombres de host internos que se correspondían directamente con funciones empresariales específicas, haciendo que la convención de nomenclatura interna fuera inmediatamente legible
- Un entorno de desarrollo ubicado dentro de lo que, por lo demás, era una zona de producción
- Un número de serie SOA que mostraba que la zona no se había modificado desde 2019
Nada de eso requiere que un atacante haga algo ingenioso. Es una lista de objetivos, entregada gratis. El SIP sin cifrar te dice exactamente dónde interceptar una llamada. Un entorno de desarrollo dentro de una zona de producción te dice exactamente dónde probablemente los controles sean más débiles. Un registro actualizado por última vez en 2019 te dice que nadie ha estado revisando nada.
Una segunda zona, un fallo distinto
Otra revisión distinta, esta vez en una empresa de SaaS, mostró una versión diferente de la misma causa raíz. Un ingeniero de redes había asumido recientemente la responsabilidad de una infraestructura que había crecido durante años bajo distintos propietarios. Conocía algunos de los problemas en la parte de la zona que había heredado. No los conocía todos.
Un solo dig axfr devolvió cerca de 55 hosts, cada uno con una dirección IP resoluble, en una única respuesta. Eso no es un panorama parcial. Es un mapa casi completo de una parte significativa del entorno de la empresa, entregado en una sola consulta a cualquiera que pensara en pedirlo.
Ninguno de los dos casos implicó un ataque sofisticado. Ambos implicaron una consulta DNS estándar que debería haberse rechazado y no se rechazó.
Por qué esto importa más que un elemento en una lista de comprobación de configuraciones erróneas
Una transferencia de zona abierta no es un riesgo teórico que aparece en una hoja de cálculo de cumplimiento. Es reconocimiento, realizado para el atacante, sin costo alguno para él.
Una vez que alguien tiene una lista completa de tus nombres de host e IP, no está adivinando dónde buscar. Sabe qué hosts ejecutan qué. Sabe dónde un entorno de desarrollo podría tener parches más débiles. Sabe qué infraestructura gestiona el tráfico de voz y si está cifrado. Cada fallo mencionado en este artículo, una transferencia sin restricciones, una delegación sin monitorizar, un registro obsoleto que nadie ha vuelto a revisar, apunta al atacante hacia el activo exacto que conviene atacar a continuación.
Esta es también la razón por la que las comprobaciones puntuales no funcionan. La zona de telecomunicaciones probablemente había superado una revisión en algún momento. La delegación simplemente nunca volvió a salir a la luz después de eso. Los patrimonios DNS no se quedan quietos. Se delegan nuevos subdominios, nuevos equipos toman el control y las configuraciones se desvían sin que nadie decida que deban hacerlo.
Cómo comprobar tus propias zonas
Prueba cualquier servidor de nombres del que seas responsable con:
dig axfr @nameserver yourdomain.comSi devuelve un listado completo de la zona en lugar de un rechazo, ese servidor permite transferencias sin restricciones. Soluciónalo restringiendo explícitamente las transferencias a una lista definida de direcciones IP secundarias de confianza en la configuración de tu servidor DNS, ya sea BIND, PowerDNS o la opción equivalente de tu proveedor de DNS.
Después, ve más allá del dominio principal. Enumera todos los subdominios que se hayan delegado a un servidor de nombres distinto y prueba cada uno de la misma manera. Si no tienes una lista actualizada de qué se ha delegado y a quién, ese es el verdadero hallazgo. Todavía no tienes un problema de transferencia de zona, tienes un problema de visibilidad, y la transferencia de zona es simplemente el primer lugar donde se manifiesta.
Dónde entra Red Sift ASM
Esto es difícil de detectar revisando tu propio dominio de vez en cuando, porque la exposición normalmente no está en el dominio que tu equipo gestiona activamente. Está en el que se delegó hace tres años y desapareció silenciosamente del radar de todos.
Red Sift ASM descubre e inventaría de forma continua tus activos de cara al exterior, incluidos aquellos que tu equipo aún no sabe que existen, conectándose directamente a tus registradores y proveedores de DNS gestionado en lugar de depender de una lista manual. Monitoriza la configuración DNS en todo tu patrimonio de forma continua, no como una auditoría puntual, de modo que un subdominio delegado que se desvíe de la política quede señalado en lugar de olvidado. Y como te muestra lo que ve un atacante desde el exterior, la infraestructura de terceros y la delegada recibe el mismo escrutinio que los activos que tu equipo configuró directamente.
Si has heredado un patrimonio DNS que no construiste tú, o gestionas uno que ha crecido durante años a través de múltiples equipos, reserva una demo para ver cómo Red Sift ASM mapea lo que realmente hay ahí fuera.
Billy is a solutions engineering leader, technologist, cybersecurity advocate, and researcher. As VP of Customer Engineering at Red Sift, he leads a global team helping security professionals create a safer internet.