BIND9: Transferencias de zona fuera de control — Protégelas sin romper el DNS secundario

Cómo se rompen las transferencias de zona en la práctica

Las transferencias de zona (AXFR para completas, IXFR para incrementales) deberían ser una replicación de fondo aburrida. Publicas una zona en uno o varios primarios, tus secundarios tiran las actualizaciones, los resolutores consultan el servidor autoritativo que les toque y todos confían en los TTL como adultos.

Luego introduces uno de los acelerantes clásicos:

• ACLs de transferencia demasiado permisivas (“allow-transfer { any; };” el equivalente DNS de dejar el lector de tarjetas en “modo demostración”).
• NAT o cortafuegos con política asimétrica (NOTIFY pasa, la transferencia TCP no; o viceversa).
• Descuidado con el número de serie (ediciones manuales sin incrementar el serial; o DNS dinámico con patrones de master oculto que no coinciden con tus suposiciones).
• Tormentas de transferencia (muchos secundarios, refresco agresivo, masters inestables o un cambio de configuración que fuerza una retransferencia completa).
• Desajustes de view (zonas de split-horizon, pero las credenciales/ACL de transferencia no coinciden, así que los secundarios replican la vista equivocada o ninguna).
• Desincronización de TSIG (clave incorrecta, algoritmo equivocado, asociación equivocada en la declaración “server”, o relojes lo suficientemente desencajados como para fallar mensajes firmados).

Cuando las transferencias se descontrolan, no solo tienes “problemas DNS”. Tienes:

• Riesgo de disponibilidad: secundarios sirviendo datos obsoletos durante incidentes, provocando fallos parciales y difíciles de depurar.
• Riesgo de confidencialidad: AXFR filtra nombres internos, topología de servicios y convenciones de nombres. A los atacantes les encanta eso.
• Riesgo de capacidad: los reintentos de transferencia pueden convertirse en un DDoS autoinfligido, especialmente si tienes muchas zonas o zonas enormes (piensa en registros generados automáticamente).
• Riesgo de control de cambios: un ajuste “inofensivo” de ACL puede romper silenciosamente la replicación y solo aparecer después de que expiren TTL y caches.

Broma #1: DNS es el único sistema donde “gestionar números de serial” es una estrategia de fiabilidad y también un recurso argumental.

Datos y contexto interesantes (por qué llegamos aquí)

El contexto corto y concreto importa porque los comportamientos de BIND están moldeados por décadas de cicatrices operativas.

1. AXFR precede al pensamiento moderno de “mínimo privilegio”. El DNS temprano asumía servidores cooperantes; la idea de escaneo hostil para transferencias apareció después.
2. Las transferencias de zona usan TCP. Las consultas DNS regulares suelen ser UDP, pero AXFR/IXFR son TCP por diseño para mover mucha información de forma fiable.
3. NOTIFY fue un añadido. Originalmente, los secundarios esperaban los timers de refresh; NOTIFY (RFC 1996) aceleró la propagación pero introdujo nuevos modos de fallo cuando UDP 53 se filtra de forma diferente a TCP 53.
4. IXFR existe para evitar transferencias completas. Las transferencias incrementales (RFC 1995) reducen ancho de banda y carga, pero dependen de que los journals/diffs estén disponibles y de que la progresión de seriales sea coherente.
5. TSIG es más antiguo de lo que muchos creen. Transaction SIGnature (RFC 2845) se convirtió en la herramienta para autenticar transferencias sin necesitar la complejidad de DNSSEC.
6. Las “views” de BIND se construyeron para operaciones de split-horizon. Potentes y fáciles de aplicar mal: tu allow-transfer debe alinearse con la vista correcta, o replicarás el conjunto de respuestas equivocado.
7. Los diseños de “hidden master” se volvieron comunes para reducir la superficie de ataque. Exponer solo secundarios a Internet es excelente—hasta que olvidas que los secundarios aún necesitan alcanzar al master por TCP 53.
8. El formato de transferencias y la semántica del SOA siguen siendo centrales. A pesar de la automatización moderna, el serial del SOA, refresh, retry, expire y TTL negativo siguen siendo los mandos que gobiernan el comportamiento.

Un modelo mental útil: AXFR/IXFR/NOTIFY y quién inicia qué

Primario vs secundario: la dirección del viaje

En el DNS clásico primario/secundario, el secundario inicia la transferencia. Se conecta al primario (TCP 53), solicita IXFR o AXFR y almacena una copia local. Eso significa que tu postura de seguridad debe ser: el primario solo permite transferencias a secundarios conocidos, y los secundarios solo hablan con primarios conocidos.

NOTIFY es el “timbre”, no el camión de reparto

NOTIFY es un aviso rápido del primario al secundario: “mi serial cambió; ve a comprobar”. Suele ser UDP. La transferencia real es la carga pesada y ocurre sobre TCP. Así que tu cortafuegos debe permitir ambas direcciones de forma apropiada y tu configuración de BIND debe evitar aceptar NOTIFY de hosts aleatorios.

IXFR no es magia

IXFR solo funciona cuando el primario puede suministrar los cambios incrementales. En BIND, eso suele depender de un journal de zona. Pierdes el journal (o lo deshabilitas) y el secundario a menudo recurrirá a AXFR. Si tu zona es grande, ese fallback es costoso.

Una cita para mantener la honestidad

La esperanza no es una estrategia. — Gene Kranz

Modelo de amenazas: contra qué te estás defendiendo

Asegurar las transferencias no es paranoia; es higiene. Aquí están los problemas realistas:

• Intentos no autorizados de AXFR/IXFR para enumerar nombres y servicios internos.
• Hosts internos mal configurados que actúan accidentalmente como secundarios y golpean al primario con reintentos.
• Secundario comprometido usado como pivote de confianza—seguirá permitido por la ACL del primario.
• Reflejo de errores operativos: alguien abrió transferencias “temporalmente” para arreglar un secundario y lo dejó abierto.
• Agotamiento de recursos: concurrencia de transferencias, sockets TCP, I/O de disco para escrituras de zona, churn de journals y volcado de logs.

El objetivo no es “ninguna transferencia”. El objetivo es solo las transferencias correctas, en el momento correcto, desde los hosts correctos, con autenticación y con límites sensatos.

Guion de diagnóstico rápido

Cuando los secundarios no se actualizan o las transferencias están derritiendo tus servidores, necesitas un orden de operaciones implacable. No empieces editando named.conf en pánico. Empieza por encontrar el cuello de botella.

Primero: prueba la conectividad básica y el protocolo (TCP vs UDP)

• ¿Puede el secundario alcanzar al primario por TCP 53?
• ¿Está llegando NOTIFY (UDP 53)?
• ¿Hay algún middlebox haciendo inspección “útil” de DNS?

Segundo: prueba la autorización y la identidad

• ¿Permite el primario la transferencia al/los IPs del secundario?
• ¿Está TSIG configurado en ambos extremos y realmente lo usas para transferencias?
• ¿Estás tratando con la view correcta?

Tercero: prueba el estado y el movimiento del serial

• ¿Coincide el serial SOA del primario con lo que esperas?
• ¿Está el secundario bloqueado porque no puede IXFR y sigue fallando AXFR?
• ¿Está el secundario sirviendo datos obsoletos porque nunca completó una transferencia?

Cuarto: aísla las limitaciones de capacidad

• ¿CPU al máximo? Probablemente firmado DNSSEC, tormenta de logs o demasiadas transferencias concurrentes.
• ¿I/O de disco al máximo? Escrituras de archivos de zona/journals, o un número patológico de actualizaciones pequeñas.
• ¿Red saturada? Transferencias completas, reintentos y demasiados secundarios refrescando a la vez.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos son movimientos reales de operador: comandos que puedes ejecutar, qué te dice la salida y la siguiente decisión. Ajusta nombres de host y rutas a tu entorno, pero conserva la lógica.

Task 1: Confirmar qué servidor es el primario para una zona (desde cualquier lugar)

cr0x@server:~$ dig +norecurse SOA example.com @ns1.example.net
;; ANSWER SECTION:
example.com.     3600  IN  SOA  ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300

Qué significa: El MNAME del SOA es ns1.example.net. El serial es 2026020401.

Decisión: Esa es la autoridad desde la que deberías transferir (a menos que uses masters ocultos). Si tu “primario” no aparece listado, estás en un diseño multi-master o de master oculto—confirma la lista de masters prevista.

Task 2: Comprobar si AXFR está (accidentalmente) abierto al público

cr0x@server:~$ dig AXFR example.com @ns1.example.net
; Transfer failed.

Qué significa: Buena señal. El servidor rechazó o no te permite.

Decisión: Si AXFR tiene éxito desde un host no confiable, trátalo como un incidente de seguridad: ajusta allow-transfer, añade TSIG y considera si el contenido de la zona es sensible.

Task 3: Probar la transferencia desde un secundario conocido y verificar que TSIG funciona

cr0x@server:~$ dig AXFR example.com @ns1.example.net -y transfer-key:7b3Nq9hR7oR6Zp3kVvQb8w==
; (1 server found)
example.com.     3600 IN SOA ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300
example.com.     3600 IN NS  ns1.example.net.
example.com.     3600 IN NS  ns2.example.net.
www.example.com. 300  IN A   203.0.113.10
example.com.     3600 IN SOA ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300
;; Query time: 45 msec
;; XFR size: 28 records (messages 1, bytes 2150)

Qué significa: La transferencia tuvo éxito con la clave TSIG. Viste SOA de inicio y fin, y el recuento de registros.

Decisión: Si puedes transferir solo con TSIG, vas por buen camino. Si tiene éxito sin TSIG también, aún tienes un problema de ACL.

Task 4: Verificar que TCP 53 es accesible (porque AXFR/IXFR son TCP)

cr0x@server:~$ nc -vz ns1.example.net 53
Connection to ns1.example.net 53 port [tcp/domain] succeeded!

Qué significa: El camino TCP existe.

Decisión: Si esto falla pero las consultas UDP funcionan, arregla el cortafuegos/grupos de seguridad. NOTIFY puede engañarte haciéndote creer que “DNS está abierto” cuando las transferencias no lo están.

Task 5: En el primario, comprobar qué piensa BIND que está pasando con la zona

cr0x@server:~$ sudo rndc zonestatus example.com
name: example.com
type: master
files: /var/cache/bind/db.example.com
serial: 2026020401
nodes: 1421
last loaded: Tue, 04 Feb 2026 08:12:22 GMT
secure: no
dynamic: no

Qué significa: El master tiene el serial 2026020401 cargado desde un archivo específico. No es dinámico.

Decisión: Si esperabas actualizaciones dinámicas, tu modelo de despliegue te está mintiendo. Si el serial no coincide con tu archivo, podrías estar editando el archivo equivocado o usando inline-signing o un master oculto.

Task 6: En el secundario, verificar si realmente está esclavizando al master correcto

cr0x@server:~$ sudo rndc zonestatus example.com
name: example.com
type: slave
masters: 203.0.113.11 port 53
serial: 2026020309
last loaded: Mon, 03 Feb 2026 19:41:03 GMT
next refresh: Tue, 04 Feb 2026 08:01:03 GMT

Qué significa: El secundario está atrasado (serial 2026020309 vs primario 2026020401). Cree que el master es 203.0.113.11.

Decisión: Confirma que esa IP sea correcta (los patrones de master oculto suelen confundir). Si está mal, corrige la lista de masters. Si está correcta, estás solucionando problemas de auth/alcance/fallo de transferencia.

Task 7: Forzar al secundario a volver a comprobar y descargar (empujón controlado)

cr0x@server:~$ sudo rndc refresh example.com
zone refresh queued

Qué significa: BIND intentará refrescar; no es garantía de éxito.

Decisión: Observa inmediatamente los logs para intentos de transferencia. Si refresh no hace nada, puede haber un desajuste de view o la zona no está cargada en esa instancia.

Task 8: Seguir los logs específicamente para mensajes de transferencia

cr0x@server:~$ sudo journalctl -u bind9 -n 50 --no-pager
Feb 04 08:22:10 ns2 named[2143]: zone example.com/IN: refresh: retry limit reached
Feb 04 08:22:10 ns2 named[2143]: zone example.com/IN: Transfer started.
Feb 04 08:22:10 ns2 named[2143]: transfer of 'example.com/IN' from 203.0.113.11#53: connected using 203.0.113.22#47922
Feb 04 08:22:10 ns2 named[2143]: transfer of 'example.com/IN' from 203.0.113.11#53: failed while receiving responses: REFUSED

Qué significa: El primario está rechazando la transferencia. Casi siempre es allow-transfer, desajuste de TSIG o desajuste de view en el master.

Decisión: Arregla la autorización en el primario (y sé explícito). No “permits temporalmente any;” y lo olvidas.

Task 9: Confirmar la postura de allow-transfer del master inspeccionando la configuración

cr0x@server:~$ sudo named-checkconf -p | sed -n '/zone "example.com"/,/};/p'
zone "example.com" {
	type master;
	file "/var/cache/bind/db.example.com";
	allow-transfer { key transfer-key; 203.0.113.22; };
	also-notify { 203.0.113.22; };
};

Qué significa: Esta zona permite transferencias ya sea desde un cliente autenticado por TSIG usando transfer-key o desde la IP 203.0.113.22.

Decisión: Prefiere “solo clave” para transferencias a menos que tengas una razón específica para permitir solo IP. Si mantienes IPs, mantén la ACL estricta y auditada.

Task 10: Validar la integridad del archivo de zona antes de culpar a la red

cr0x@server:~$ sudo named-checkzone example.com /var/cache/bind/db.example.com
zone example.com/IN: loaded serial 2026020401
OK

Qué significa: La zona se parsea y el serial es el que crees.

Decisión: Si esto falla, arregla el archivo de zona primero. Una zona rota puede impedir cargas, bloquear transferencias o hacer que los secundarios reintenten para siempre.

Task 11: Comprobar concurrencia de transferencias y si te estás ahogando

cr0x@server:~$ sudo rndc status
version: BIND 9.18.24-1ubuntu1.4-Ubuntu (Extended Support Version) <id:...>
running on ns1: Linux x86_64 5.15.0-97-generic
boot time: Tue, 04 Feb 2026 07:45:10 GMT
last configured: Tue, 04 Feb 2026 08:10:03 GMT
current serial: 2026020401
xfrouts running: 12
xfers running: 0

Qué significa: xfrouts running muestra transferencias salientes (master enviando). Si ese número es alto, podrías estar en una tormenta de transferencias o siendo sondeado.

Decisión: Si las transferencias salientes son inesperadamente altas, comprueba quién se está conectando y si tus ACL están demasiado abiertas. También considera ajustar transfers-out y afines (con cuidado).

Task 12: Identificar quién se conecta a TCP/53 en el primario

cr0x@server:~$ sudo ss -tnp 'sport = :53' | head
State  Recv-Q Send-Q Local Address:Port Peer Address:Port  Process
ESTAB  0      0      203.0.113.11:53  203.0.113.22:47922 users:(("named",pid=2143,fd=42))
ESTAB  0      0      203.0.113.11:53  198.51.100.77:51244 users:(("named",pid=2143,fd=51))
ESTAB  0      0      203.0.113.11:53  198.51.100.88:51310 users:(("named",pid=2143,fd=63))

Qué significa: Tienes conexiones TCP establecidas al puerto 53 desde múltiples pares. Solo uno de esos es tu secundario conocido.

Decisión: Si ves IPs aleatorias de Internet, te están escaneando o dejaste las transferencias abiertas. Asegura allow-transfer y considera filtrar TCP/53 por firewall solo a secundarios de confianza (si la arquitectura lo permite).

Task 13: Demostrar que NOTIFY se acepta solo desde los hosts correctos

cr0x@server:~$ sudo named-checkconf -p | sed -n '/options {/,/};/p' | sed -n '1,80p'
options {
	directory "/var/cache/bind";
	allow-notify { 203.0.113.11; };
	notify yes;
};

Qué significa: El servidor restringe qué fuentes pueden enviar NOTIFY.

Decisión: Si falta allow-notify en un secundario, considera añadirlo. De lo contrario cualquiera puede tocar el timbre y hacerte perder tiempo comprobando actualizaciones.

Task 14: Confirmar que el secundario está sirviendo el serial actualizado (verificación desde cliente)

cr0x@server:~$ dig +norecurse SOA example.com @ns2.example.net
;; ANSWER SECTION:
example.com.     3600  IN  SOA  ns1.example.net. hostmaster.example.com. 2026020401 1200 300 1209600 300

Qué significa: El secundario ahora está sirviendo el serial nuevo.

Decisión: Si aún sirve un serial antiguo, la transferencia no llegó o no se cargó. Vuelve a logs y al estado de la zona.

Endurecimiento de transferencias BIND9 sin romper segundos

Regla 1: Define explícitamente quién puede transferir, por zona

Empieza con la postura de que las transferencias están denegadas por defecto. Luego practica agujeros precisos. En BIND, eso suele ser allow-transfer en cada zona master (o vía un ACL compartido). Si lo haces globalmente en options, eventualmente olvidarás una zona que debería manejarse de forma diferente.

Regla 2: Prefiere TSIG para transferencias (y rota claves en serio)

Las ACLs por IP son necesarias pero insuficientes. Las IPs cambian. NAT engaña. Y “pero está en una red privada” es la forma en que terminas exportando una zona a un host comprometido dentro de tu perímetro.

Con TSIG obtienes autenticación de mensajes. Aún necesitas la política de IP, pero TSIG te da identidad en la capa DNS. Usa algoritmos modernos (como hmac-sha256) y controla la distribución de claves.

Regla 3: No olvides la política de NOTIFY (es una palanca de carga)

NOTIFY no es una filtración de datos, pero sí un disparador de carga. Si cualquiera puede enviarlo, cualquiera puede hacer que tus secundarios ejecuten la lógica de refresh e intenten transferencias. Es una buena forma de desperdiciar CPU y espacio de logs.

Regla 4: Diseña para dominios de fallo, no solo para “que funcione”

Dos arquitecturas prácticas:

• Hidden master: master(s) internos, secundarios públicos solo. Gran postura de seguridad, pero requiere conectividad TCP/53 limpia de secundarios a masters y ACLs cuidadosas.
• Primary público: uno de tus servidores públicos es master. Enrutamiento más simple, mayor superficie de ataque, más razones para ser estricto con las transferencias.

Regla 5: Vigila el volumen de transferencias como un SLO de primera clase

Si nunca graficas tasas de transferencia y fallos, descubrirás el problema solo después que los clientes lo hagan. Cuenta:

• proporción IXFR vs AXFR exitosos (un pico repentino de AXFR es una alarma)
• fallos de transferencia (REFUSED, NOTAUTH, errores TSIG, timeouts)
• tiempos de carga de zona y espera de I/O

Regla 6: Usa límites—pero como cirujano, no como jugador

BIND tiene perillas como transfers-out, transfers-in y serial-query-rate. Pueden prevenir un meltdown, o pueden dejar lentamente sin datos a tus secundarios para que sirvas información obsoleta durante horas. Aplica límites tras entender el comportamiento normal de transferencias y tener visibilidad.

Broma #2: Un límite de transferencias puesto demasiado bajo es como una sala de reuniones en el calendario—técnicamente organizada, funcionalmente una negación de servicio.

Tres mini-historias corporativas desde las minas de transferencias

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana tenía un setup de hidden-master: master interno y dos secundarios públicos. El equipo de red asumió “DNS es UDP 53”, porque la mayoría del mundo experimenta DNS como consultas UDP rápidas. Sus reglas de firewall permitían UDP/53 entrante a los secundarios y permitían que los secundarios consultaran al master por UDP/53 para “DNS”.

NOTIFY funcionó. En parte. El master envió NOTIFY, los secundarios lo recibieron e inmediatamente intentaron tirar un IXFR. Por TCP. Que estaba bloqueado. BIND registró timeouts de transferencia, luego reintentos, luego más reintentos. Nada se actualizó.

Se mantuvo invisible un tiempo porque los TTL eran largos y las respuestas en caché enmascararon la obsolescencia. Finalmente, una rotación rutinaria de certificados añadió un nuevo registro de validación. Algunos resolutores obtuvieron el nuevo registro desde la vista interna del master durante la investigación, pero los secundarios públicos nunca lo sirvieron. Las validaciones externas fallaron de forma intermitente. El equipo de respuesta a incidentes disfrutó la especial miseria de “a mí me funciona” con DNS.

Lo arreglaron permitiendo TCP/53 desde secundarios al master y monitorizando explícitamente la deriva del serial SOA entre secundarios. La conclusión del postmortem fue dolorosamente simple: asumieron que DNS significaba UDP, y esa suposición gobernó producción—hasta que dejó de hacerlo.

Mini-historia 2: La optimización que salió mal

Una organización grande tenía cientos de zonas. Las transferencias eran ruidosas, así que un ingeniero intentó “optimizar” la carga de transferencia al aumentar los timers de refresh y reducir el ruido de NOTIFY. La idea: menos refrescos, menos transferencias, menos carga.

Funcionó en estado estable. Los gráficos se veían más calmados. Luego un bug de despliegue empujó un archivo de zona malo al master: faltaba un registro NS del que dependían algunos resolutores. Revirtieron rápido. Pero aquí está el problema: muchos secundarios no se habían refrescado aún porque los intervalos eran ahora largos. Una parte de la flota sirvió la versión rota durante mucho más tiempo del esperado.

Los clientes obtuvieron una ruleta de respuestas según el servidor autoritativo que tocaran. Soporte vio “fallos DNS esporádicos”. Ingeniería vio “está arreglado”. Ambos tenían razón. Ese tipo de verdad arruina tardes.

La remediación fue volver refresh/retry a valores sensatos, mantener NOTIFY activado y, en su lugar, reducir la carga de transferencias arreglando la causa real: demasiados AXFR completos por falta de IXFR/journals y patrones de recarga desordenados. También introdujeron un playbook de rollback que forzaba a los secundarios a refrescar inmediatamente después de arreglos críticos de DNS.

Mini-historia 3: La práctica correcta y aburrida que salvó el día

Una firma de servicios financieros tenía control estricto de cambios y mucho DNS de split-horizon usando views de BIND. No emocionante. Lo interesante fue su disciplina: cada zona tenía una ACL de transferencia por zona, TSIG era obligatorio y cada cambio pasaba por named-checkconf y named-checkzone antes del despliegue. También tenían un dashboard para “deriva de serial” entre el master y cada secundario.

Un día, una VM secundaria se restauró desde un snapshot antiguo tras un fallo del hipervisor. Arrancó con un archivo de clave TSIG obsoleto (secreto viejo) y la hora ligeramente equivocada por una configuración NTP rota. Las transferencias fallaron. El secundario siguió sirviendo datos obsoletos.

El monitoreo lo detectó rápido: alerta de deriva de serial más mensajes de fallo de transferencia. El on-call no tuvo que adivinar. Reemplazaron la clave TSIG, arreglaron NTP y forzaron un refresh. El incidente fue corto, contenido y—lo más importante—aburrido de explicar.

Ese es el estándar que quieres. Nada de heroísmos. Controles estrictos, checks previos y visibilidad que te diga exactamente qué secundario está mintiendo.

Errores comunes (síntomas → causa raíz → solución)

1) Síntoma: El secundario nunca se actualiza; los logs muestran REFUSED

Causa raíz: El allow-transfer del primario no incluye la IP del secundario o la clave TSIG, o el secundario está golpeando la view equivocada en el primario.

Solución: En el primario, configura allow-transfer explícitamente para esa zona (prefiere TSIG). Confirma el emparejamiento de views comprobando qué dirección fuente/view se está usando.

2) Síntoma: Las transferencias funcionan a veces y otras fallan

Causa raíz: El secundario tiene múltiples masters listados; uno es alcanzable pero no autorizado, o NAT cambia la IP origen de forma impredecible, o tienes complicaciones con anycast.

Solución: Usa TSIG para que la autenticación no dependa de la IP origen. Podar listas de masters a las previstas. Si interviene anycast, asegúrate de que los objetivos de transferencia sean estables y no una “ruleta del nodo más cercano”.

3) Síntoma: Pico repentino de volumen AXFR; la red sube

Causa raíz: IXFR no disponible (journal perdido, cambios de inline-signing, recargas frecuentes), o secundarios forzados a transferencias completas tras fallos.

Solución: Investiga por qué falla IXFR. Confirma que los journals estén habilitados/retenerlos. Evita patrones de recarga innecesarios. Considera límites de transferencia solo después de reducir transferencias completas.

4) Síntoma: Los secundarios sirven datos antiguos tras un rollback

Causa raíz: Intervalos de refresh aumentados demasiado, NOTIFY deshabilitado o el rollback no disparó un refresh forzado.

Solución: Mantén NOTIFY activo para secundarios gestionados. Para rollbacks, usa rndc notify en el master y rndc refresh en los secundarios para converger rápidamente.

5) Síntoma: Errores TSIG como “bad key” o “clock skew”

Causa raíz: Secreto equivocado, algoritmo erróneo, nombre de clave incorrecto o deriva horaria que causa rechazo de mensajes firmados.

Solución: Verifica que la definición de la clave coincida exactamente en ambos extremos. Asegura que NTP funcione. Rota claves con cuidado y mantén old/new durante la migración si es necesario.

6) Síntoma: Las transferencias funcionan para una view pero no para otra

Causa raíz: La zona existe en múltiples views; allow-transfer está configurado solo en una, o la IP origen del secundario coincide con una view diferente a la esperada.

Solución: Haz explícita la intención de las views. Usa match-clients y/o interfaces de transferencia dedicadas. Configura transferencias por view y prueba desde la IP fuente real del secundario.

7) Síntoma: “connection reset” o timeouts a mitad de transferencia

Causa raíz: Middlebox que mata TCP de larga duración, problemas de MTU o presión de recursos del servidor (I/O de archivos, backlog TCP).

Solución: Captura con tcpdump en ambos extremos, verifica path MTU, incrementa límites TCP del sistema si es necesario y reduce la frecuencia de AXFR completos arreglando IXFR/journals.

8) Síntoma: Partes no autorizadas pueden AXFR tu zona

Causa raíz: allow-transfer { any; }; o ninguna restricción en el master, combinado con TCP/53 expuesto.

Solución: Asegura por zona con ACL/TSIG estrictas. Considera filtrar TCP/53 por firewall a secundarios conocidos. Audita periódicamente con pruebas externas.

Listas de verificación / plan paso a paso

Paso a paso: asegurar transferencias sin romper la replicación

1. Inventaría tus zonas y secundarios previstos. Haz una lista: zona → master(s) → IPs de secundarios → si TSIG es requerido.
2. Decide tu política base: TSIG requerido para todas las transferencias salvo excepción documentada.
3. Crea ACLs dedicadas por entorno. Manténlas legibles. “acl secondaries-prod { … }” vence a un cementerio de IPs en cada stanza de zona.
4. Implementa allow-transfer por zona. Prefiere solo clave. Si debes incluir IPs, pon solo a los secundarios.
5. Restringe el manejo de NOTIFY en secundarios. Configura allow-notify para aceptar solo de los master(s).
6. Asegura que las reglas de firewall coincidan con la realidad del transporte. Permite secondary → master TCP/53. Permite master → secondary UDP/53 para NOTIFY (o acepta el comportamiento solo por refresh si decides desactivar NOTIFY).
7. Habilita logging que pruebe lo ocurrido. Quieres éxitos y fallos de transferencia claros, sin ahogarlo todo.
8. Despliega gradualmente. Empieza con una zona y un secundario. Verifica y luego amplía.
9. Valida la convergencia. Compara el serial SOA en todos los servidores después de un cambio.
10. Añade monitorización: deriva de serial, fallos de transferencia y volumen de transferencias. Alerta sobre deriva más allá de un umbral y sobre fallos sostenidos.
11. Prueba desde fuera. Intenta AXFR desde una red no confiable y confirma que falle.
12. Escribe el proceso de excepciones. Si alguien necesita acceso temporal, tiene expiración y ticket, no memoria.

Checklist operativo: al añadir un nuevo secundario

• Confirma las IP(s) fuente del secundario (especialmente con NAT/contenerización).
• Genera y distribuye la clave TSIG de forma segura.
• Añade la clave y la asociación de servidor en ambos extremos.
• Actualiza allow-transfer en las zonas del master.
• Actualiza also-notify en el master (opcional pero recomendado).
• Actualiza allow-notify en el secundario.
• Prueba la conectividad TCP/53 en ambas direcciones según se requiera.
• Forza la transferencia inicial y confirma que el serial SOA coincide.

Checklist operativo: cuando las transferencias se disparan

• Identifica quién se está conectando a TCP/53.
• Consulta logs para patrones REFUSED vs TSIG vs timeouts.
• Mide la proporción AXFR vs IXFR.
• Revisa bucles de recarga de zona (automatización empujando zonas sin cambios repetidamente).
• Considera límites/ratios temporales solo después de confirmar que la autorización no está demasiado abierta.

Preguntas frecuentes

1) ¿Debería deshabilitar las transferencias de zona por completo?

Sólo si no usas DNS secundario. Si tienes secundarios, necesitas transferencias (o un mecanismo alternativo de replicación). La opción correcta es autorización estricta + TSIG.

2) ¿TSIG es suficiente o sigo necesitando ACLs basadas en IP?

Usa ambas donde puedas. TSIG autentica en la capa DNS; las ACLs por IP reducen ruido y exposición. Defensa en profundidad, no teología.

3) ¿Por qué mis secundarios se actualizan despacio aunque NOTIFY esté habilitado?

Porque NOTIFY solo desencadena una comprobación. Si TCP/53 está bloqueado, TSIG falla o el master rechaza transferencias, el secundario seguirá esperando y reintentando. Revisa los logs para el primer fallo tras NOTIFY.

4) ¿Cuál es la forma más rápida de saber si estoy filtrando datos de zona?

Desde un host externo no confiable, intenta dig AXFR zone @auth. Debe fallar. Si no falla, arréglalo hoy, no después de comer.

5) AXFR funciona desde un secundario pero no desde otro. ¿Por qué?

Causas más comunes: falta la IP de ese secundario en allow-transfer, configuración TSIG errónea en ese nodo o el tráfico del secundario sale desde una IP diferente a la que crees (contenedores/NAT).

6) ¿Puedo ejecutar transferencias en un puerto no estándar?

Puedes, pero suele ser autolesionismo. Estandarizar en TCP/53 reduce políticas de firewall raras y el “conocimiento tribal”. Si cambias puertos, documenta y prueba sin descanso.

7) ¿Las views de BIND afectan las transferencias de zona?

Sí. Las transferencias ocurren en el contexto de una view. Si el secundario hace match con una view distinta a la prevista, puede obtener REFUSED o transferir el conjunto de datos equivocado. Sé explícito con match-clients y prueba desde la IP fuente real del secundario.

8) ¿Cuál es la forma segura de rotar claves TSIG sin tiempo de inactividad?

Ejecuta claves vieja y nueva en paralelo durante la transición: permite cualquiera de las dos claves para transferencias, despliega la nueva en todos lados, verifica éxito y luego elimina la vieja. Asegura también que los relojes estén correctos.

9) ¿Está bien fiarse de “allow-transfer { none; }” global y sobrescribir por zona?

Sí. Es un valor por defecto sensato. Solo asegúrate de sobrescribirlo para las zonas que necesitan secundarios y monitorea para notar cuando lo olvides.

10) Si filtro TCP/53 solo a secundarios, ¿sigo necesitando allow-transfer?

Sí. Los firewalls cambian, las reglas se clonan y las redes internas no son inherentemente de confianza. Mantén el control a nivel de aplicación.

Siguientes pasos

Haz esto en orden si quieres dormir:

1. Audita la exposición: intenta AXFR desde una red no confiable contra cada servidor autoritativo que operes.
2. Haz explícitas las transferencias: allow-transfer por zona y TSIG por secundario.
3. Arregla la realidad del transporte: asegura secondary → master TCP/53; garantiza que las rutas de NOTIFY sean consistentes con tu política de firewall.
4. Añade monitorización de deriva de serial: si un secundario se atrasa, debes saberlo antes que los usuarios.
5. Practica un fallo controlado: rompe intencionadamente TSIG en un secundario de staging y confirma que tus alertas, logs y runbook te llevan a la solución correcta.

Las transferencias de zona no necesitan ser emocionantes. Si tus transferencias son emocionantes, tu configuración intenta decirte algo. Escúchala.