Desmitificando las zonas DNS y las transferencias de zona

El DNS suele parecer una única base de datos global, pero entre bastidores es un sistema cuidadosamente dividido. La responsabilidad se reparte en zonas, cada zona la sirven varios servidores autoritativos y esos servidores se mantienen sincronizados mediante un mecanismo llamado transferencia de zona. Entender estas piezas le ayuda a diagnosticar retrasos de propagación, elegir una configuración DNS fiable y evitar una de las fugas de información más habituales en internet: una transferencia de zona sin restricciones. Este artículo recorre los conceptos y termina con ejemplos prácticos de configuración y de pruebas.

Zonas y dominios: no son lo mismo

Un dominio es un nodo del árbol DNS junto con todo lo que cuelga de él. example.com es un dominio, y shop.example.com también. Una zona es una frontera administrativa: la parte del espacio de nombres que se gestiona como una unidad y que publica un mismo conjunto de servidores de nombres autoritativos.

A menudo un dominio y su zona parecen idénticos. Una pequeña empresa puede guardar todos los registros de example.com en un único archivo de zona. Pero cuando una parte del árbol se delega, las fronteras se separan. Si eu.example.com se cede a otro equipo con sus propios servidores de nombres, la zona padre conserva solo los registros NS (y quizá direcciones glue) que apuntan a ellos, y eu.example.com pasa a ser una zona independiente. El dominio example.com sigue incluyendo eu.example.com, pero la zona no.

La misma lógica se aplica en la cima: la zona raíz delega .com, la zona .com delega example.com en los servidores de nombres que registró su propietario, y así sucesivamente. Cuando consulta un dominio con la consulta WHOIS y RDAP de TLDix, los servidores de nombres que aparecen son exactamente esa delegación procedente del registro del TLD.

Qué contiene una zona

Una zona es un conjunto de registros de recursos. Los más habituales son los siguientes.

Toda zona tiene exactamente un registro SOA en su ápice y al menos uno, normalmente dos o más, registros NS.

El registro SOA y su número de serie

El registro Start of Authority describe cómo debe mantenerse la zona. Un SOA típico tiene este aspecto en un archivo de zona:

example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. (
              2026100701 ; serial
              7200       ; refresh
              900        ; retry
              1209600    ; expire
              300 )      ; negative caching TTL

• MNAME (ns1.example.com.) indica el servidor primario.
• RNAME (hostmaster.example.com.) es el buzón del administrador, donde el primer punto sustituye a la arroba.
• Serial es un número de versión de la zona. Los secundarios lo comparan con el de su copia; si el primario tiene un serial mayor, transfieren la zona.
• Refresh indica cada cuánto comprueban los secundarios el serial.
• Retry es cuánto esperan antes de volver a intentarlo tras una comprobación fallida.
• Expire es cuánto tiempo sigue respondiendo un secundario si no consigue contactar en absoluto con el primario. Pasado ese plazo deja de servir la zona en lugar de dar respuestas obsoletas.
• Minimum se usa hoy como TTL de las respuestas negativas, como NXDOMAIN (RFC 2308).

Una convención muy extendida es el serial basado en la fecha con el formato AAAAMMDDnn, por ejemplo 2026100701 para el primer cambio del 7 de octubre de 2026. El error más común en las zonas editadas a mano es olvidarse de aumentar el serial: el primario sirve los datos nuevos, pero los secundarios nunca los descargan, de modo que los usuarios obtienen respuestas distintas según el servidor al que lleguen. Los números de serie usan aritmética de espacio de secuencia (RFC 1982), así que si alguna vez necesita reducir uno, debe hacerlo en pasos planificados y no simplemente escribiendo un número menor.

Servidores primarios y secundarios

La mayoría de las zonas las publican varios servidores autoritativos, por resiliencia y por rendimiento. Uno es el primario (antes llamado maestro), donde se edita o genera la zona, por ejemplo a partir de una base de datos o de la API de un proveedor. Los demás son secundarios (antes llamados esclavos), que guardan copias de solo lectura obtenidas del primario.

Desde el punto de vista de un resolutor, todos los servidores autoritativos que figuran en los registros NS son iguales y puede preguntar a cualquiera. Por eso importa la coherencia: si un secundario se queda atrás, parte de su tráfico verá registros desactualizados. Muchas organizaciones usan un primario oculto, un servidor que no aparece en los registros NS públicos y solo alimenta a los secundarios, lo que reduce su exposición a ataques.

Usar secundarios de otro proveedor o de otra red es también una forma clásica de sobrevivir a las caídas, porque un fallo en un proveedor ya no deja fuera de línea toda la zona.

Transferencias completas (AXFR) e incrementales (IXFR)

Cuando un secundario necesita datos, solicita una transferencia de zona por TCP.

AXFR: la zona entera

AXFR, estandarizado en la RFC 5936, envía todos los registros de la zona, empezando y terminando por el registro SOA. Es sencillo y robusto, y se usa siempre que un secundario aún no tiene ninguna copia. Sin embargo, en zonas grandes, repetir una copia completa tras cada pequeño cambio desperdicia ancho de banda y tiempo.

IXFR: solo lo que ha cambiado

IXFR, definido en la RFC 1995, permite al secundario enviar su serial actual y recibir solo las diferencias: los registros eliminados y añadidos entre versiones. Para ello, el primario necesita mantener un diario de los cambios recientes. Si no puede generar las diferencias, por ejemplo porque se ha vaciado el diario, recurre a enviar la zona completa.

NOTIFY: se acabó esperar al temporizador de refresco

Depender solo del intervalo de refresco significaría que los cambios podrían tardar horas en llegar a los secundarios. El mecanismo DNS NOTIFY, descrito en la RFC 1996, lo resuelve. Cuando la zona cambia, el primario envía un mensaje NOTIFY a sus secundarios. Cada secundario consulta entonces el SOA, ve el serial más alto e inicia de inmediato un IXFR o un AXFR. En la práctica, esto reduce la actualización de los secundarios a segundos. El refresco sigue funcionando como red de seguridad por si se pierde algún NOTIFY.

Tenga en cuenta que esto es distinto de lo que se suele llamar propagación. Cuando todos los servidores autoritativos están sincronizados, el retraso restante se debe a los resolutores de todo el mundo que guardan registros antiguos en caché hasta que caduca su TTL.

Por qué las transferencias de zona abiertas son un problema

Si un servidor permite AXFR a cualquiera, cualquiera puede descargar el contenido completo de la zona. Eso puede revelar nombres de host internos, sistemas de preproducción, puntos de acceso VPN, infraestructura de correo y patrones de nomenclatura: información que convierte el reconocimiento en un juego de niños. Esta mala configuración sigue apareciendo en internet, a menudo como resto de valores por defecto o de configuraciones antiguas. La regla es sencilla: solo sus propios secundarios deberían poder transferir la zona.

Las restricciones por IP son un buen primer paso, pero las direcciones IP pueden cambiar o compartirse. TSIG añade autenticación por encima.

Proteger las transferencias con ACL y TSIG

TSIG (Transaction Signature, RFC 8945) usa una clave secreta compartida y un algoritmo HMAC, como HMAC-SHA256, para firmar los mensajes DNS. El primario solo responde a solicitudes de transferencia firmadas con la clave correcta, y el secundario puede verificar que los datos proceden realmente del primario y no se alteraron por el camino. TSIG no cifra la zona; si necesita confidencialidad, puede usar estándares más recientes como XoT (transferencia de zona sobre TLS, RFC 9103) donde estén disponibles.

La clave se genera normalmente con tsig-keygen en BIND. La configuración resultante en el primario podría ser esta:

key "xfer-key" {
    algorithm hmac-sha256;
    secret "REPLACE-WITH-GENERATED-SECRET";
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.db";
    allow-transfer { key "xfer-key"; };
    also-notify { 198.51.100.20; };
    notify yes;
};

Y en el secundario:

key "xfer-key" {
    algorithm hmac-sha256;
    secret "REPLACE-WITH-GENERATED-SECRET";
};

server 192.0.2.10 { keys { "xfer-key"; }; };

zone "example.com" {
    type secondary;
    primaries { 192.0.2.10; };
    file "/var/cache/bind/example.com.db";
};

Guarde el secreto de forma segura, rótelo cuando cambie el personal o los proveedores y, cuando sea práctico, use una clave distinta para cada relación con un secundario. Las versiones antiguas de BIND usan las palabras clave master y slave en lugar de primary y secondary; las versiones actuales aceptan ambas.

Cómo probar las transferencias de zona con dig

Tras configurar las restricciones, verifíquelas desde una máquina que no debería tener acceso:

dig @ns1.example.com example.com AXFR

Un servidor bien cerrado responde con Transfer failed o con el estado REFUSED. Desde un secundario autorizado, pruebe con la clave:

dig @192.0.2.10 example.com AXFR -y hmac-sha256:xfer-key:REPLACE-WITH-SECRET
dig @192.0.2.10 example.com IXFR=2026100701

Para confirmar que todos los servidores autoritativos están sincronizados, compare los seriales:

dig +nssearch example.com
dig @ns2.example.com example.com SOA +short

Si un servidor muestra un serial más antiguo, revise la entrega de NOTIFY, las reglas del cortafuegos para el puerto TCP 53 y los registros de ambos lados. Pruebe las transferencias únicamente contra servidores que gestione usted o para los que tenga permiso.

Mantener sano el conjunto

Las zonas y las transferencias son solo una parte de mantener accesible un dominio. La delegación en el registro del TLD debe apuntar a los servidores de nombres correctos, las firmas DNSSEC deben seguir siendo válidas (los secundarios pueden servir zonas firmadas, pero las claves y el registro DS deben coincidir, como se explica en por qué DNSSEC es esencial para la seguridad de un dominio) y el propio dominio no debe caducar. Tener sus dominios y sus fechas de renovación en el panel de dominios de TLDix facilita detectar los problemas antes que los usuarios. Con una estrategia clara para el SOA, NOTIFY activado, transferencias restringidas con TSIG y comprobaciones periódicas con dig, su DNS será coherente y mucho más difícil de cartografiar desde fuera.