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.

Para una explicación del registro SOA campo por campo - incluidos los formatos de serial y los errores que dejan un secundario desactualizado - vea Qué es el registro SOA de DNS.

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 (RFC 8945) añade a cada solicitud de transferencia una firma con un secreto compartido, de modo que el primario autentica al secundario por la clave y no por la dirección IP. Ambos lados usan el mismo nombre de clave, algoritmo y secreto.

En el lado de SecondDNS no tiene que generar la clave usted mismo. En el panel abra Configuración > DNS, cree una clave con una etiqueta y un algoritmo (hmac-sha256 o hmac-sha512) y copie el secreto: solo se muestra una vez. La clave recibe el nombre de su cuenta y la etiqueta, por ejemplo `user_ab12cd34-primary`. Después seleccione la clave al añadir un dominio, o más tarde en el diálogo de edición de la zona. Nuestros servidores firman con ella sus solicitudes AXFR para esa zona (en PowerDNS, el campo `slave_tsig_key_ids` de la zona, guardado como metadato `AXFR-MASTER-TSIG`).

En el primario añada la clave y permita las transferencias firmadas con ella. Para BIND son los mismos bloques que muestra el panel:

key "user_ab12cd34-primary" {
    algorithm hmac-sha256;
    secret "SECRET_FROM_DASHBOARD";
};

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

Con la clave, el primario ya no necesita una entrada IP en allow-transfer. Mantenga also-notify: los mensajes NOTIFY no se firman y se aceptan desde la dirección IP del primario.

Para un primario PowerDNS el equivalente es:

pdnsutil import-tsig-key user_ab12cd34-primary hmac-sha256 SECRET_FROM_DASHBOARD
pdnsutil activate-tsig-key example.com user_ab12cd34-primary primary

Regenerar una clave en el panel sustituye el secreto de inmediato: las zonas que la usan dejan de sincronizarse hasta que el primario tenga el nuevo secreto. Nunca guarde el secreto en el control de versiones.

Configuración para BIND, PowerDNS, NSD y Knot DNS, con comprobación y solución de problemas: Claves TSIG en su servidor DNS primario.

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.

Errores TSIG: el primario registra BADKEY cuando no conoce el nombre de la clave y BADSIG cuando el secreto o el algoritmo no coinciden. Compare el bloque key del primario con la clave seleccionada para la zona; tras regenerar una clave, actualice el secreto en el primario.

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 - Servidor DNS secundario: qué es y cómo funciona - Claves TSIG en su servidor DNS primario