¿Qué es la transferencia de zona DNS y por qué supone un riesgo de seguridad?

La redundancia es la columna vertebral del Sistema de Nombres de Dominio (DNS). Si un servidor de nombres autoritativo deja de estar operativo o resulta inaccesible, los servidores de respaldo deben estar preparados para resolver las consultas relacionadas con tu dominio sin interrupciones. Para mantener sincronizados estos servidores secundarios, el DNS se basa en las transferencias de zona para replicar los registros automáticamente.

Cuando se configuran correctamente, las transferencias de zona se realizan de forma discreta entre servidores de confianza. Sin embargo, un solo ajuste predeterminado o un descuido en el control de acceso puede dejar este canal de replicación abierto a toda la red de Internet. Cuando eso ocurre, una medida administrativa habitual que facilita el trabajo se convierte en una fuga de información abierta.

Esta guía analiza qué son las transferencias de zona DNS, las diferencias operativas entre AXFR e IXFR, por qué las transferencias abiertas suponen un grave riesgo para la seguridad y cómo proteger tus servidores de nombres frente a actividades de reconocimiento no autorizadas.

¿Qué es una transferencia de zona DNS?

Una transferencia de zona DNS consiste en la replicación de un archivo de zona desde un servidor de nombres primario y autoritativo a uno o varios servidores de nombres secundarios a través del puerto TCP 53. De este modo se garantiza que los servidores de nombres secundarios dispongan de copias idénticas de todos los registros de recursos necesarios para responder de forma autoritativa a las consultas de los clientes.

Para comprender por qué existe esta replicación, hay que tener en cuenta cómo funciona el DNS oficial. Una zona DNS representa un espacio administrativo diferenciado dentro de la jerarquía global de dominios. El archivo de zona contiene el catálogo completo de registros de recursos que definen ese espacio, incluyendo las asignaciones de direcciones (registros A y AAAA), los servidores de correo (registros MX), las ubicaciones de servicios (registros SRV) y las cadenas de validación (registros TXT).

Depender de un único servidor de nombres crea un punto único de fallo inaceptable. Si ese servidor sufre un fallo de hardware, una congestión de la red o interrupciones debidas a un ataque de denegación de servicio distribuido (DDoS), los visitantes no podrán resolver tu dominio.

Para evitar tiempos de inactividad, las organizaciones implementan servidores de nombres secundarios. Gestionar estos servidores manualmente resultaría ineficaz y propenso a errores, ya que los administradores tendrían que duplicar cada cambio en los registros en varios hosts. Las transferencias de zona DNS automatizan este proceso, lo que permite a los servidores secundarios obtener los datos actualizados de la zona directamente del host maestro. Esto garantiza una alta disponibilidad y equilibra el volumen de consultas entre servidores de nombres dispersos geográficamente.

Cómo funcionan las transferencias de zonas DNS

Las transferencias de zonas DNS siguen una arquitectura cliente-servidor en la que el servidor de nombres secundario actúa como cliente que solicita los datos, y el servidor de nombres primario actúa como servidor que los proporciona.

Las consultas DNS estándar de los navegadores web suelen realizarse a través del puerto 53 del Protocolo de Datagramas de Usuario (UDP), lo que garantiza rapidez y una baja sobrecarga. Por el contrario, las transferencias de zona se realizan a través del puerto 53 del Protocolo de Control de Transmisión (TCP). El TCP proporciona la conexión fiable y con estado, así como la comprobación de errores, necesarias para transmitir grandes volúmenes de datos estructurados sin pérdida de paquetes.

El proceso de sincronización se basa en el registro «Start of Authority» (SOA), concretamente en su campo de número de serie:

1. Comparación de números de serie: El servidor de nombres secundario consulta periódicamente al servidor primario para obtener su registro SOA. Por otra parte, cuando un administrador actualiza una zona, el servidor de nombres primario puede enviar un mensaje DNS NOTIFY no solicitado (RFC 1996) para notificar a los servidores secundarios que se ha producido una actualización.
2. Decisión de transferencia: El servidor secundario compara el número de serie del servidor principal con su propia copia local. Si el número de serie del servidor principal es mayor, el servidor secundario sabe que los registros han cambiado e inicia una solicitud de transferencia.
3. Transmisión de datos: El servidor principal valida la solicitud y transmite los registros actualizados a través de la conexión TCP establecida.

En función de la configuración y el volumen de los cambios, los servidores llevan a cabo esta sincronización mediante uno de estos dos métodos: AXFR o IXFR.

AXFR (Transferencia de zona completa)

La transferencia autoritativa (AXFR), definida en el RFC 1035 y actualizada en el RFC 5936, constituye el mecanismo de transferencia original. Cuando se ejecuta una solicitud AXFR, el servidor de nombres principal envía el archivo de zona completo de principio a fin, comenzando y terminando con el registro SOA.

Aunque es sencillo y fiable, el protocolo AXFR resulta ineficaz para zonas de gran tamaño. Si una empresa gestiona una zona que contiene 50 000 registros de recursos y modifica una sola dirección IP, una transferencia AXFR retransmite los 50 000 registros. En redes con un gran volumen de tráfico, las transferencias completas repetidas consumen ancho de banda de red y ciclos de procesamiento innecesarios.

IXFR (Transferencia incremental por zonas)

Para eliminar la sobrecarga que suponen las transferencias completas, el RFC 1995 introdujo la transferencia incremental de zonas (IXFR). En lugar de copiar toda la base de datos, IXFR envía únicamente las diferencias específicas entre la versión actual del servidor secundario y la versión actualizada del servidor primario.

Durante un intercambio IXFR, el servidor secundario envía su número de serie SOA actual en su solicitud. El servidor primario evalúa su registro de cambios, determina qué registros se han eliminado y añadido en las versiones intermedias, y transmite únicamente esas diferencias. Esto reduce drásticamente el consumo de ancho de banda y acelera la sincronización en arquitecturas distribuidas.

Comparación entre AXFR e IXFR

Si un servidor secundario ha estado desconectado durante un periodo prolongado y su número de serie no figura en el historial de transacciones del servidor primario, IXFR no puede subsanar esa laguna. En ese caso, el sistema recurre de forma controlada a una transferencia AXFR completa para reconstruir la zona.

Por qué las transferencias de zona abierta suponen una vulnerabilidad de seguridad

Las transferencias de zona son esenciales para la sincronización administrativa, pero se diseñaron teniendo en cuenta la disponibilidad más que la confidencialidad. Por defecto, las configuraciones de los servidores de nombres heredados solían considerar legítima cualquier consulta AXFR entrante.

Se produce una transferencia de zona abierta cuando un servidor de nombres autoritativo responde a solicitudes AXFR procedentes de direcciones IP no autorizadas. Cuando existe esta configuración errónea, cualquier persona conectada a Internet puede consultar el servidor de nombres y recibir una copia completa del archivo de zona.

Esta exposición supone una vulnerabilidad crítica de divulgación de información. En lugar de recurrir a ataques de fuerza bruta basados en el método de prueba y error, un atacante obtiene un inventario autorizado y estructurado de la huella digital de una organización. Esto convierte una fase de reconocimiento manual en un descubrimiento instantáneo y exhaustivo del sistema. Las transferencias de zona abiertas siguen siendo una de las vulnerabilidades de DNS más documentadas vulnerabilidades comunes del DNS , ya que exponen los planes operativos internos a la inspección pública.

Lo que los atacantes averiguan gracias a una transferencia de zona

Cuando un actor malintencionado obtiene un archivo de zona a través de una consulta AXFR abierta, consigue acceso a datos que rara vez son visibles mediante consultas DNS estándar:

• Directorios completos de subdominios: Los atacantes descubren todos los subdominios registrados, incluidos los hosts que llevan el nombre de funciones internas, departamentos o tecnologías propias.
• Servidores de desarrollo y de pruebas: Los subdominios como dev.example.com, test-api.example.com o qa-vpn.example.com suelen ejecutar software en fase de pre-lanzamiento que carece de cortafuegos de nivel de producción, parches de seguridad actualizados o controles de acceso estrictos.
• Portales administrativos y remotos: Los enlaces a la intranet, los portales de empleados, los puntos de conexión a la VPN y las interfaces de gestión de bases de datos suelen aparecer directamente en la lista de registros.
• Arquitectura de correo y enrutamiento: Los registros MX y las direcciones IP de los servidores de correo correspondientes revelan la topología de filtrado del correo electrónico de una organización, los saltos de enrutamiento y los servicios de entrega de terceros.
• Datos de verificación de terceros: Los registros TXT no auditados suelen contener tokens de verificación para plataformas en la nube, integraciones SaaS, herramientas de análisis y cadenas de verificación históricas que dan pistas sobre las dependencias de la infraestructura interna.

Cómo una fuga en la transferencia de zonas da pie a otros ataques

La información obtenida mediante una transferencia de zona abierta sirve de punto de partida operativo para sofisticados ataques posteriores:

• Apropiación de subdominios: Los archivos de zona suelen contener registros CNAME huérfanos que apuntan a recursos en la nube fuera de servicio, como buckets de Amazon S3 abandonados, páginas de GitHub o instancias de Microsoft Azure. Con una lista completa de registros CNAME, los atacantes pueden apropiarse del recurso huérfano en el proveedor externo y publicar contenido no autorizado bajo el dominio verificado de la víctima.
• Spear phishing e ingeniería social: Descubrir las convenciones de nomenclatura de los servidores internos, las direcciones de los portales de empleados y las relaciones con los proveedores permite a los atacantes crear señuelos de ingeniería social muy creíbles. Cuando los autores de las amenazas hacen referencia a nombres de host internos reales en un correo electrónico dirigido a una víctima concreta, los destinatarios son mucho más propensos a confiar en el mensaje. Para ver cómo los adversarios aprovechan la inteligencia sobre la infraestructura para la recopilación selectiva de credenciales, lee nuestro análisis sobre spear phishing.
• Superficies de ataque ampliadas: Las transferencias de zona suelen dejar al descubierto los esquemas de direccionamiento IP internos cuando las redes privadas se fusionan accidentalmente con zonas públicas. Esto proporciona a los atacantes los detalles de enrutamiento necesarios para sondear los cortafuegos perimetrales y atacar las interfaces administrativas internas.

Además, aunque las transferencias de zona en sí mismas no manipulan el tráfico, conocer la topología de almacenamiento en caché y enrutamiento de una empresa puede facilitar ataques secundarios como el envenenamiento de la caché DNS.

Cómo comprobar si tu dominio permite las transferencias de zona

Los administradores de seguridad deben comprobar si los servidores de nombres autoritativos permiten transferencias de zona no autorizadas. El objetivo es confirmar que las consultas externas que solicitan copias completas de la zona reciban una denegación explícita en lugar de los registros completos.

Los administradores evalúan esta configuración lanzando una consulta AXFR desde una ubicación de red externa no fiable dirigida a cada servidor de nombres autoritativo que figure en los registros NS del dominio:

• Comportamiento seguro: El servidor de nombres rechaza la consulta inmediatamente, devolviendo un estado de REFUSED o SERVFAIL. No se transmiten registros de zona.
• Comportamiento vulnerable: El servidor de nombres acepta la conexión, confirma la solicitud AXFR y devuelve la lista completa de registros de recursos del dominio.

Más allá de las comprobaciones puntuales periódicas, los entornos empresariales se benefician de la vigilancia automatizada. Las comprobaciones automatizadas de la configuración detectan cuándo las actualizaciones de los servidores de nombres eliminan inadvertidamente las restricciones de transferencia. 

PowerDMARC incluye comprobaciones automatizadas de exposición AXFR dentro de su paquete de supervisión de seguridad DNS , y avisa a los administradores en el momento en que un servidor autoritativo comienza a responder a solicitudes públicas de transferencia de zona.

Cómo proteger las transferencias de zonas DNS

Para proteger tu dominio frente a transferencias de zona no autorizadas, es necesario aplicar restricciones de acceso estrictas y controles criptográficos modernos. Siguiendo las directrices de seguridad del DNS del NIST establece una base de referencia fiable para la integridad del dominio.

Aplica los siguientes controles de seguridad en toda tu infraestructura de DNS:

1. Restringir las transferencias por dirección IP: No permita nunca consultas AXFR o IXFR sin restricciones. Declare explícitamente las direcciones IP de los servidores de nombres secundarios autorizados en los bloques de configuración de su servidor de nombres (como la directiva «allow-transfer» de BIND) y rechace todas las solicitudes que no figuren en esa lista blanca.
2. Autenticación mediante TSIG: Limitar el acceso únicamente mediante la dirección IP ofrece una protección básica, pero las direcciones IP pueden falsificarse en determinadas topologías de red. Implemente las firmas de transacción (TSIG) para autenticar la comunicación entre servidores de nombres mediante secretos criptográficos compartidos.
3. Desactivar las transferencias en sistemas independientes: Si tu dominio depende de un único servidor de nombres o utiliza un proveedor moderno de DNS gestionado que se sincroniza a través de interfaces API propias, desactiva por completo las transferencias de zona.
4. Implementar el DNS de horizonte dividido: Mantén archivos de zona separados para las redes corporativas internas y los servicios públicos externos. Los nombres de host internos, los entornos de prueba y los subdominios de prueba nunca deben figurar en un archivo de zona de acceso público.
5. Mantén actualizados los demonios de los servidores de nombres: Las vulnerabilidades en el software DNS pueden permitir a los atacantes eludir las reglas de ACL o provocar el agotamiento de recursos. Utiliza versiones actualizadas y parcheadas de software de servidor como BIND, PowerDNS, Knot DNS o NSD para minimizar la exposición a vulnerabilidades de día cero y ataques de amplificación de DNS.
6. Registro y alertas sobre solicitudes de transferencia: Supervisa los registros de consultas del servidor de nombres en busca de solicitudes AXFR o IXFR no solicitadas. Los intentos repetidos de transferencia desde direcciones IP desconocidas suelen indicar un reconocimiento activo por parte de un adversario.
7. Revisa periódicamente los registros de zona: Revisa periódicamente tus archivos de zona para identificar y eliminar registros obsoletos, especialmente las entradas CNAME desactualizadas que apuntan a recursos de alojamiento en la nube de terceros que han caducado.

Autenticación de transferencias con TSIG y cifrado con XoT

Las firmas de transacción (TSIG), normalizadas en el RFC 2845 y revisadas en el RFC 8945, añaden autenticación criptográfica a los mensajes del DNS. El TSIG se basa en secretos compartidos simétricos establecidos entre los servidores de nombres primario y secundario.

Una vez configurado, el servidor de nombres secundario firma su solicitud AXFR o IXFR con un hash criptográfico derivado de la clave compartida y la marca de tiempo actual. El servidor de nombres primario valida la firma con su propia clave. Si la firma coincide y se encuentra dentro de un intervalo de tiempo aceptable, la transferencia continúa; si falta la clave o no es válida, el servidor primario rechaza la conexión.

Aunque el TSIG verifica la identidad y garantiza la integridad de los datos, no cifra el contenido de la zona en sí durante la transmisión. Para subsanar esta carencia en materia de confidencialidad, el Grupo de Trabajo de Ingeniería de Internet (IETF) publicó el RFC 9103, que especifica la transferencia de zonas DNS sobre TLS (XoT). XoT envuelve las sesiones AXFR e IXFR dentro de un túnel cifrado de Seguridad de la Capa de Transporte (TLS), lo que impide las escuchas, la inspección de tipo «hombre en el medio» y la manipulación a lo largo de las redes de tránsito.

Supervisión de la exposición a las transferencias de zona con PowerDMARC

Para garantizar la seguridad de la infraestructura de servidores de nombres se requieren tanto configuraciones defensivas de los servidores como una observabilidad externa continua. Aunque los equipos de infraestructura gestionan las listas de acceso a las zonas, los analistas de seguridad necesitan una visibilidad continua para garantizar que los errores administrativos o las migraciones a la nube no expongan los registros de forma inadvertida.

PowerDMARC incorpora una función específica de detección de vulnerabilidades AXFR en sus completas soluciones de seguridad DNS de primera línea .

Posicionado como una plataforma de supervisión de registros DNS externos y de cumplimiento normativo en materia de seguridad, en lugar de como un proxy de filtrado en línea o un cortafuegos, el servicio de supervisión de seguridad y cumplimiento normativo de DNS de PowerDMARC realiza comprobaciones automatizadas en todos tus servidores de nombres autoritativos:

• Comprobaciones de exposición AXFR: Comprueba continuamente los servidores de nombres autoritativos desde ubicaciones externas para confirmar que se deniegan las transferencias de zona no autorizadas.
• Registro de auditoría de fugas de zona: Sepa y registre al instante los casos en los que un servidor de nombres secundario o primario permita por error la descarga de datos AXFR.
• Detección de cambios en los registros: Supervisa los movimientos en serie de la SOA y realiza un seguimiento de las adiciones, modificaciones o eliminaciones en los registros de recursos públicos.
• Verificación de la sincronización de los servidores de nombres: Comprueba que los servidores de nombres secundarios contengan registros idénticos y sincronizados con respecto a las autoridades primarias.
• DNSSEC y descuido en los registros CNAME «colgantes»: Avisa a los administradores de cadenas DNSSEC rotas e identifica registros CNAME obsoletos antes de que puedan ser aprovechados para la apropiación de subdominios.

La combinación de estrictos controles de acceso a los servidores de nombres con una supervisión automatizada y continua de los registros garantiza que tu topología DNS se mantenga privada, resistente y conforme a las normas de seguridad empresariales.

Preguntas frecuentes

¿Cuál es el objetivo de una transferencia de zona DNS?

Una transferencia de zona DNS replica los datos de la zona desde un servidor de nombres autoritativo primario a servidores de nombres secundarios a través del puerto TCP 53. Esta replicación garantiza una alta disponibilidad, el equilibrio de carga y la tolerancia a fallos en redes distribuidas, lo que evita fallos en la resolución de dominios en caso de que el servidor primario deje de estar disponible.

¿Cuál es la diferencia entre AXFR e IXFR?

AXFR realiza una transferencia completa de la zona, transmitiendo todo el archivo de zona y todos los registros de recursos asociados, independientemente de si se han producido cambios. IXFR realiza una transferencia incremental, transmitiendo únicamente las adiciones y eliminaciones específicas de registros que han tenido lugar desde el último número de serie sincronizado del servidor secundario.

¿Se considera un ataque una transferencia de zona DNS?

No, una transferencia de zona es un mecanismo administrativo estándar definido por las normas de Internet. Solo se convierte en un incidente de seguridad cuando un servidor de nombres autoritativo está mal configurado y permite transferencias AXFR abiertas y sin restricciones a clientes públicos no autorizados, lo que permite a los atacantes descargar el mapa completo de la infraestructura de dominios de una organización.

¿Qué puerto utiliza una transferencia de zona?

Las transferencias de zona utilizan el puerto TCP 53. Mientras que las consultas DNS recursivas estándar utilizan el puerto UDP 53 para ganar en velocidad, las transferencias de zona requieren el protocolo TCP para establecer una conexión fiable capaz de transmitir registros de zona de gran tamaño, compuestos por varios paquetes, sin truncamiento de datos ni pérdida de paquetes.

¿Qué es TSIG y cómo garantiza la seguridad de las transferencias de zona?

TSIG (Transaction Signatures) es un mecanismo de autenticación del DNS definido en el RFC 8945. Utiliza claves criptográficas simétricas compartidas para firmar las solicitudes y respuestas de transferencia de zona, lo que garantiza que los servidores de nombres primario y secundario se autentiquen mutuamente y verifiquen la integridad de los datos antes de transmitir los registros de zona.

¿Permiten los proveedores de DNS gestionado las transferencias de zona?

La mayoría de los proveedores modernos de DNS gestionado en la nube desactivan por defecto las transferencias AXFR públicas tradicionales y utilizan API propias y redes anycast internas para replicar los registros. Sin embargo, algunos proveedores de servicios en la nube ofrecen configuraciones AXFR opcionales y seguras para dar soporte a entornos híbridos a la hora de conectar servidores de nombres secundarios externos personalizados.

Palabras finales

Las transferencias de zonas DNS son fundamentales para mantener la disponibilidad continua de la red y una resolución de dominios fiable. Sin embargo, si no se controlan, se convierten en una puerta abierta a tu red corporativa, proporcionando a los atacantes un inventario detallado de subdominios, portales administrativos y entornos de pruebas olvidados.

Proteger las transferencias de zona no implica renunciar a la redundancia. Al restringir las transferencias a direcciones IP secundarias autorizadas, autenticar los intercambios con claves TSIG, cifrar las sesiones con XoT y mantener una higiene estricta de las zonas, puedes proteger tus activos de nomenclatura sin sacrificar la disponibilidad.

Da hoy mismo el primer paso para proteger tu infraestructura de dominios: utiliza nuestro analizador de dominios gratuito para comprobar el estado de tu DNS público, o implementa la supervisión de seguridad DNS de PowerDMARC para proteger tu infraestructura frente a la exposición no autorizada.