cd ~/blog

~/vulns/dns-zone-transfer-axfr.md

DNS Zone Transfer (AXFR)

miscautor: Jordy Pérez Osorio aviso legal
DNSAXFRenumeration

~2 min de lectura


1. Descripción técnica

Una transferencia de zona DNS (AXFR) es el mecanismo legítimo por el que un servidor DNS secundario replica la base de datos completa de una zona desde el servidor primario. La consulta AXFR devuelve todos los registros de la zona (A, CNAME, MX, TXT, subdominios, etc.).

La exposición surge cuando un servidor DNS permite transferencias de zona a clientes no autorizados. Un tercero puede solicitar el conjunto servido por AXFR y obtener un inventario de nombres, direcciones y registros publicados en esa zona sin enumerarlos individualmente.

No es un RCE, sino una fuga de información de enumeración que suele ser el primer paso para encontrar superficie de ataque adicional (paneles internos, vhosts, hosts olvidados).

2. Impacto

  • Divulgación completa de la zona DNS: subdominios y hosts que pueden ocultar servicios vulnerables.
  • Reducción drástica del esfuerzo de reconocimiento (sin necesidad de fuzzing de subdominios).
  • A menudo revela nombres con pistas (backup., dev., admin.) que orientan el ataque.

3. Historia y evolución

  • AXFR es parte del protocolo DNS desde sus orígenes (RFC 1034/1035).
  • La mala configuración (transferencias abiertas) ha sido un hallazgo clásico de pentesting durante décadas y sigue apareciendo en auditorías y CTFs.
  • Las buenas prácticas actuales restringen AXFR por IP y/o TSIG (claves compartidas).

4. Condiciones necesarias

  1. Un servidor DNS (puerto 53, TCP para AXFR) accesible para el atacante.
  2. Configuración que permite transferencias de zona a clientes no autorizados (allow-transfer { any; } o ausencia de restricción).
  3. Conocer (o adivinar) el nombre de la zona a transferir.

5. Validación y detección

  • Identificar el servicio DNS:
nmap -sCV -p53 target
  • Solicitar la transferencia de zona con dig (o host -l, dnsrecon):
dig axfr <zona> @<servidor_dns>
# p. ej.
dig axfr swamp.nyx @192.168.1.45

Si devuelve la lista de registros, la transferencia está abierta.

6. Mitigación

  1. Restringir AXFR a los servidores secundarios autorizados (allow-transfer por IP).
  2. Usar TSIG (autenticación con clave compartida) para las transferencias.
  3. No exponer el servicio DNS interno a redes no confiables.
  4. Separar las vistas DNS internas y externas (split-horizon).

7. Explotación documentada en los writeups

7.1. 09-swamp

Tras añadir el dominio al /etc/hosts, se solicita la zona completa y se descubren subdominios:

❯ dig axfr swamp.nyx @192.168.1.45
...
d0nkey.swamp.nyx.	604800	IN	A	0.0.0.0
dr4gon.swamp.nyx.	604800	IN	A	0.0.0.0
duloc.swamp.nyx.	604800	IN	A	0.0.0.0
f1ona.swamp.nyx.	604800	IN	A	0.0.0.0
farfaraway.swamp.nyx.	604800	IN	A	0.0.0.0
shr3k.swamp.nyx.	604800	IN	A	0.0.0.0
...

Cada subdominio puede alojar contenido distinto (en este caso, credenciales ocultas en el código de uno de ellos).

7.2. 092-webmaster

El dominio webmaster.hmv acepta una transferencia AXFR que incluye un registro TXT con información utilizada posteriormente por el writeup. El valor sensible pertenece al escenario concreto; la técnica general es la descarga no autorizada de la zona.

8. Clasificación

  • Tipo: Information Disclosure / Security Misconfiguration
  • CWE:
    • CWE-200 – Exposure of Sensitive Information to an Unauthorized Actor
    • CWE-16 – Configuration

9. Referencias y conexiones

// relacionados