Entender las transferencias de zona AXFR

¿Qué es AXFR?

AXFR (transferencia de zona completa) es un mecanismo del protocolo DNS para replicar una zona entera desde un servidor primario hacia uno secundario. Cuando un servidor secundario necesita una copia de una zona, abre una petición AXFR al primario, que responde con todos los registros de la zona en un único flujo TCP.

AXFR se define en el RFC 5936 y funciona sobre TCP en el puerto 53, no sobre UDP, porque una zona completa suele ser más grande que un solo datagrama UDP. La transferencia incluye todos los registros de la zona: SOA, NS, A, AAAA, MX, CNAME, TXT y los demás. En resumen: AXFR es la forma en que un servidor DNS secundario obtiene y mantiene sincronizada la copia autoritativa de sus datos DNS.

Transferencias de zona DNS completas vs. incrementales

Existen dos tipos de transferencia de zona:

AXFR (transferencia completa): transfiere la zona entera cada vez. Es sencilla y fiable, pero consume más ancho de banda en zonas grandes.

IXFR (transferencia incremental, RFC 1995): transfiere solo los registros que cambiaron desde el último serial del secundario. Resulta mucho más eficiente en zonas grandes con ediciones pequeñas y frecuentes.

La mayoría del software DNS admite ambos. Por lo general, un secundario intenta primero IXFR y usa AXFR como alternativa si el primario no admite transferencias incrementales, si el serial solicitado es demasiado antiguo para calcular un delta o si el diario IXFR del primario se ha truncado. Por eso AXFR es la base fiable que siempre funciona, mientras que IXFR es la optimización que se añade encima.

Cómo funciona la transferencia de zona DNS

Una transferencia de zona sigue estos pasos:

1. El secundario consulta el registro SOA del primario, ya sea según el temporizador de refresco o cuando recibe un mensaje NOTIFY. 2. Si el serial del SOA del primario es mayor que el de la copia local del secundario, hace falta una transferencia. 3. El secundario abre una petición AXFR (o IXFR) al primario en el puerto TCP 53. 4. El primario comprueba si el secundario tiene permiso para transferir (mediante una ACL por IP o TSIG) y, en ese caso, envía los datos de la zona. 5. El secundario reemplaza (AXFR) o aplica los cambios (IXFR) sobre su copia local y empieza a responder con los datos nuevos.

Los temporizadores de refresco, reintento y expiración del registro SOA determinan con qué frecuencia el secundario busca actualizaciones y durante cuánto tiempo sigue respondiendo cuando el primario no está accesible.

Intervalos de actualización y reintento de zona DNS

El registro SOA lleva cuatro parámetros de tiempo que controlan el comportamiento de la transferencia de zona:

Refresco (refresh): con qué frecuencia el secundario consulta al primario en busca de actualizaciones (por ejemplo, 3600 = cada hora).

Reintento (retry): con qué frecuencia el secundario vuelve a intentarlo si el primario no está accesible (por ejemplo, 900 = cada 15 minutos).

Expiración (expire): durante cuánto tiempo el secundario sigue respondiendo por la zona si no consigue comunicarse con el primario (por ejemplo, 604800 = 7 días). Tras la expiración, el secundario deja de responder por la zona, por eso una expiración larga lo protege durante una caída prolongada del primario.

TTL mínimo: el TTL de cacheo negativo, es decir, cuánto tiempo los resolutores guardan en caché una respuesta NXDOMAIN, tomado como el menor entre este campo y el propio TTL del registro SOA, según el RFC 2308.

Para zonas que cambian a menudo, use un refresco más bajo, aunque si tiene NOTIFY configurado, el refresco importa mucho menos, porque los cambios se envían casi al instante. Para zonas estables, los valores más altos reducen el tráfico innecesario.

Sincronización de zona DNS en tiempo real con NOTIFY

En lugar de esperar al temporizador de refresco, el primario envía un mensaje NOTIFY (RFC 1996) a sus secundarios justo después de que la zona cambie. El NOTIFY le indica al secundario 'consulta tu serial ahora', lo que dispara una consulta del SOA y una transferencia si hace falta.

NOTIFY reduce el retraso entre un cambio en el primario y su aparición en los secundarios, que pasa de minutos (el intervalo de refresco) a segundos.

La mayoría del software DNS envía NOTIFY de forma automática a todos los servidores que figuran en los registros NS de la zona. Para un secundario que no aparece en el conjunto NS, algo habitual cuando se usa un secundario oculto o invisible de un proveedor, añádalo como destino explícito de also-notify para que también reciba las actualizaciones enviadas.

Prueba de transferencias de zona DNS con dig

Puede solicitar una AXFR a mano con dig para confirmar que una transferencia funciona, o para comprobar si su zona está peligrosamente expuesta. Pídale a un servidor concreto la zona completa:

dig AXFR example.com @ns1.example.com

Si el servidor permite la transferencia, dig imprime todos los registros de la zona. Si está correctamente restringido, obtiene en cambio:

; Transfer failed.

o una conexión que no devuelve ningún registro. Ese fallo es el resultado deseado para una consulta pública: solo sus secundarios autorizados deberían poder descargar la zona.

Desde el lado del secundario, confirme que los seriales coinciden tras una transferencia:

dig SOA example.com @primary-ip +short
dig SOA example.com @secondary-ip +short

Ambos deberían devolver el mismo serial del SOA. Si el secundario muestra un serial más bajo, la transferencia no se ha completado: revise NOTIFY, la ACL y el puerto TCP 53.

Seguridad en transferencias de zona DNS

Una AXFR expone su zona entera: cada nombre de host, servidor de correo y registro TXT. Una transferencia abierta es un hallazgo clásico de reconocimiento: un atacante que pueda descargar su zona conoce, en una sola petición, su nomenclatura interna, sus hosts de preproducción y la disposición de su infraestructura. Restrinja quién puede transferir:

ACL basadas en IP: permita AXFR solo desde las IP conocidas de sus servidores secundarios. Es el control más habitual y más sencillo.

TSIG (firmas de transacción, RFC 8945): autenticación criptográfica con un secreto compartido. Es más robusta que una ACL por IP, porque no se puede burlar mediante suplantación de IP y funciona incluso cuando cambia la IP del secundario.

Reglas de cortafuegos: mantenga el puerto TCP 53 accesible solo desde los secundarios autorizados.

Nunca use allow-transfer { any; } (ni su equivalente en PowerDNS). Pruebe sus propios dominios con el comando dig AXFR anterior: si una consulta pública devuelve registros, su zona está abierta y debería cerrarla de inmediato.

Proteger las transferencias de zona con TSIG

TSIG añade una firma con secreto compartido a las peticiones de transferencia, de modo que el primario puede autenticar al secundario sin importar su IP. Genere una clave y luego haga referencia a ella en ambos servidores.

Genere una clave (herramientas de BIND):

tsig-keygen -a hmac-sha256 transfer-key

Esto imprime un bloque de clave. En el primario BIND, defina la clave y exijala para las transferencias:

key "transfer-key" {
    algorithm hmac-sha256;
    secret "BASE64_SECRET_HERE";
};

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { key "transfer-key"; };
};

El secundario se configura con el mismo nombre de clave, algoritmo y secreto, y lo presenta al solicitar la transferencia. Use el mismo material de clave en ambos lados y nunca incluya el secreto en el control de versión.

Ejemplos de configuración de transferencia de zona

BIND (primary):

zone "example.com" {
    type primary;
    file "/etc/bind/zones/example.com.zone";
    allow-transfer { 192.0.2.1; };
    also-notify { 192.0.2.1; };
};

PowerDNS (primary):

allow-axfr-ips=192.0.2.1/32
also-notify=192.0.2.1
disable-axfr=no

Reemplace 192.0.2.1 por la dirección IP real de su servidor DNS secundario.

Solución de problemas en transferencias de zona DNS

Transferencia rechazada: revise la configuración de allow-transfer / ACL en el primario y confirme que la IP (o la clave TSIG) del secundario coincide. Pruebe con dig AXFR desde la red del secundario.

Tiempo de conexión agotado: AXFR usa el puerto TCP 53, no UDP. Un cortafuegos que solo abre UDP 53 para las consultas normales deja funcionar la resolución mientras rompe las transferencias sin avisar. Abra el puerto TCP 53 entre el primario y el secundario.

El serial no se incrementa: el primario debe subir el serial del SOA en cada cambio. Con el formato YYYYMMDDNN, asegúrese de incrementar NN cuando haga varias ediciones el mismo día, o el secundario no verá ningún cambio.

El secundario muestra datos obsoletos: confirme que NOTIFY está configurado. Sin él, el secundario solo se actualiza según el intervalo de refresco del SOA.

Falla la transferencia de una zona grande: las zonas muy grandes (millones de registros) pueden alcanzar los límites de tiempo de espera de TCP a mitad de la transferencia. Aumente los ajustes de transferencia y de tiempo de espera en ambos lados, y prefiera IXFR para que solo se muevan los deltas.

¿No quiere gestionar su propio servidor secundario? SecondDNS ofrece DNS secundario gestionado con sincronización AXFR automática — empiece gratis.

Guías relacionadas

Para poner en marcha las transferencias de zona con un servicio de DNS secundario o un panel de hosting, consulte:

- Cómo configurar un servidor DNS secundario - Redundancia DNS: por qué es importante y cómo lograrla - Servidores de nombres personalizados: configuración, glue records y errores comunes - Cómo añadir DNS secundario a cPanel/WHM - Cómo añadir DNS secundario a Plesk - Cómo añadir DNS secundario a DirectAdmin - Cómo añadir DNS secundario a CyberPanel