DNS

Antes de DNS, el crecimiento de Internet dependía de un fichero central llamado HOSTS.TXT. Cada sistema necesitaba una copia actualizada para relacionar nombres y direcciones. El modelo funcionaba mientras la red era pequeña. Cuando aumentaron los hosts, también lo hicieron las colisiones de nombres, la frecuencia de las actualizaciones y la carga sobre el servidor que distribuía el fichero.

Los RFC 1034 y 1035, publicados en 1987, describieron una respuesta distinta: un espacio de nombres jerárquico cuya administración pudiera delegarse y una base de datos distribuida que los resolvers pudieran consultar y almacenar temporalmente. Esa decisión sigue explicando la enumeración actual. Un nombre no vive en “el servidor DNS”. Pertenece a una zona, la zona tiene autoridad delegada, varias copias pueden servirla y distintos resolvers pueden conservar respuestas diferentes durante su tiempo de vida.

Enumerar Domain Name System (DNS) consiste en reconstruir esas relaciones. Hay que identificar qué servidor responde, para qué zona tiene autoridad, si actúa como resolver recursivo, qué vista presenta al origen actual y qué datos pueden obtenerse mediante consultas, recorridos o transferencias. Resolver una dirección es solo una de esas preguntas.

Los ejemplos usan DOMAIN, FQDN, DNS_SERVER, SUBDOMAIN_LIST y REVERSE_ZONE como placeholders.

El espacio de nombres forma un árbol. La raíz se encuentra en la parte superior. Debajo aparecen los top-level domains y, después, los dominios delegados. Un resolver que no tiene la respuesta en caché puede seguir referencias desde la raíz hasta encontrar los servidores autoritativos de la zona correspondiente. Las trece identidades lógicas de servidores raíz se despliegan mediante muchas instancias, habitualmente anunciadas con anycast.

Una zona es una porción administrativa de ese árbol. No coincide necesariamente con todo lo que cuelga de un dominio. Cuando una organización delega dev.example.test mediante registros NS, ese subdominio puede convertirse en otra zona con servidores y políticas propias. El límite administrativo importa porque una transferencia, una firma DNSSEC o una respuesta autoritativa se razonan por zona.

Los roles describen qué trabajo realiza cada componente:

• autoritativo primario: mantiene la copia editable de la zona
• autoritativo secundario: replica la zona mediante transferencias
• resolver recursivo: sigue delegaciones en nombre del cliente y mantiene caché
• forwarder: reenvía consultas a otro resolver

Un mismo proceso puede combinar varios roles y responder de forma distinta según el origen. Las vistas de BIND y las políticas de split DNS permiten publicar una respuesta interna y otra externa para el mismo nombre. Por eso la enumeración registra servidor, dirección de destino, origen, transporte y hora. Sin ese contexto, dos respuestas incompatibles pueden ser correctas dentro de vistas diferentes.

Los flags del mensaje ayudan a situar la respuesta. aa indica que el servidor responde con autoridad para los datos devueltos. ra anuncia que ofrece recursión al cliente actual. El bit rd expresa que el cliente la solicitó. Un flag describe el mensaje observado. No demuestra por sí solo la arquitectura completa ni que otro origen reciba la misma política.

La sintaxis básica es dig @DNS_SERVER NAME TYPE. El prefijo @ selecciona el servidor consultado, NAME identifica el nombre de dominio y el último argumento fija el tipo de registro:

dig @DNS_SERVER FQDN A
dig @DNS_SERVER FQDN AAAA

Los tipos más útiles al construir el mapa son:

+noall +answer oculta metadatos y conserva solo la sección de respuestas. Es útil para extraer datos, pero durante el diagnóstico conviene leer el mensaje completo:

dig @DNS_SERVER DOMAIN NS +noall +answer

ANY no significa “devuelve todos los registros”. Los servidores pueden responder con un subconjunto mínimo o rechazar la consulta, como permite RFC 8482. Formula preguntas por tipo cuando el dato importa. Esa precisión permite distinguir un nombre sin AAAA de un nombre inexistente y evita convertir una respuesta parcial en un inventario.

NXDOMAIN indica que el nombre consultado no existe según esa respuesta. NOERROR sin registros del tipo solicitado significa que el nombre puede existir, pero no tiene ese tipo. REFUSED expresa que el servidor no realizará la operación. SERVFAIL describe un fallo al procesarla, por ejemplo validación DNSSEC o problemas al alcanzar servidores upstream.

Compara siempre el servidor consultado y la ruta de resolución. Una respuesta de caché recursiva y otra autoritativa pueden diferir temporalmente por TTL, replicación o split-horizon DNS.

Para saber si un servidor resolverá nombres externos, consulta un nombre fuera de sus zonas. +recurse establece el bit RD, que ya es el comportamiento habitual de dig:

dig @DNS_SERVER example.net A +recurse

Una respuesta con ra y datos obtenidos no convierte necesariamente el servidor en un open resolver para cualquier origen. Registra desde dónde se hizo la consulta. Para observar su comportamiento sin solicitar recursión, usa +norecurse:

dig @DNS_SERVER DOMAIN SOA +norecurse

AXFR transfiere una zona completa. IXFR solicita cambios desde un serial conocido. Los secundarios las necesitan para replicar datos, pero el servidor debe restringir qué clientes pueden pedirlas.

Antes de probar AXFR, identifica la zona y sus servidores NS. Luego consulta cada autoritativo. En dig, el tipo AXFR solicita la transferencia:

dig @DNS_SERVER DOMAIN AXFR

Una transferencia correcta devuelve el SOA al principio y al final, junto con los registros de la zona. Puede revelar hosts que no responden desde el origen actual, nombres internos, delegaciones y servicios. Una negativa en un servidor no predice el comportamiento de los demás.

Cuando no hay transferencia, una wordlist puede generar consultas concretas. dig +short reduce el resultado a los datos devueltos:

El bucle siguiente conserva espacios y barras invertidas de cada etiqueta mediante IFS= y read -r. La sustitución $(...) guarda el resultado de dig en answer. La condición -n solo imprime respuestas no vacías, y printf separa nombre y dirección con un tabulador:

while IFS= read -r label; do
  answer=$(dig @DNS_SERVER +short "$label.DOMAIN" A)
  if [ -n "$answer" ]; then
    printf '%s\t%s\n' "$label.DOMAIN" "$answer"
  fi
done < SUBDOMAIN_LIST

done < SUBDOMAIN_LIST usa el archivo como entrada del bucle. El resultado solo conserva respuestas A. Para no perder aliases, IPv6 o nombres que existen sin dirección, repite preguntas CNAME y AAAA o analiza el status completo. Antes de confiar en muchos resultados, prueba un nombre aleatorio. Un wildcard DNS puede hacer que cualquier etiqueta parezca válida.

Las zonas inversas usan in-addr.arpa para IPv4 e ip6.arpa para IPv6. Si se conoce REVERSE_ZONE, una transferencia se solicita igual:

dig @DNS_SERVER REVERSE_ZONE AXFR

Una herramienta de enumeración puede combinar registros estándar, transferencias, nombres de una wordlist, resolución inversa y recorridos DNSSEC. Esa comodidad también mezcla preguntas que quizá necesiten servidores, ritmos y criterios de validación distintos.

Antes de automatizar, conserva una consulta manual positiva y otra negativa contra el servidor que se utilizará. Después fija dominio, servidor, tipos, diccionario, concurrencia, timeout y formato de salida. La página de herramientas, automatización y NSE desarrolla dig, kdig, delv, DNSRecon, dnsenum, resolución masiva y los scripts aplicables.

El output agregado se normaliza después de recogerlo. Cada registro conserva nombre, tipo, valor, TTL, servidor, transporte, hora y herramienta. Dos respuestas con el mismo nombre y direcciones distintas pueden representar rotación, anycast, split DNS o momentos diferentes. Deduplicarlas solo por nombre destruiría precisamente la evidencia que explica la diferencia.

BIND puede cargar named.conf, includes, vistas y archivos de zona desde rutas dependientes de la distribución. named-checkconf -p imprime la configuración resultante y expande includes:

sudo named-checkconf -p

Relaciona cada bloque zone con file, type, allow-query, allow-transfer, allow-recursion, recursion, forwarders y view. Los valores predeterminados han cambiado entre versiones, por lo que una política sensible debe quedar explícita y verificarse sobre la versión instalada.

named-checkzone valida sintaxis y consistencia de un archivo sin iniciar el servidor:

named-checkzone DOMAIN ZONE_FILE

La consulta CHAOS version.bind puede devolver la versión si el servidor la publica, pero también ocultarla o sustituirla:

dig @DNS_SERVER version.bind CHAOS TXT

Trata ese texto como un banner, no como prueba única de versión.

La misma consulta puede cambiar por split-horizon DNS, anycast, ECS, DNSSEC, caché, origen, transporte o resolver recursivo. Un NXDOMAIN autoritativo con SOA en la sección de autoridad no equivale a timeout. SERVFAIL conserva causas como validación DNSSEC, fallo upstream o configuración. La truncación TC=1 exige repetir por TCP.

Registra servidor consultado, dirección de destino efectiva, flags, status, secciones de la respuesta, TTL, transporte y hora. Compara directamente el autoritativo con el resolver corporativo y uno público solo cuando cada fuente responda una pregunta distinta. No deduzcas que un nombre no existe a partir de un único resolver.

Una transferencia o recorrido que exponga nombres alimenta el inventario de activos. La recursión abierta puede permitir resolución a terceros y participar en amplificación, pero el factor real depende del tipo de consulta, EDNS y tamaño de respuesta. Una actualización dinámica mediante dns-update modifica estado y no pertenece al reconocimiento inicial.

Las consultas quedan visibles en resolvers, servidores autoritativos, proveedores de passive DNS y sensores de red. Al cerrar, conserva respuestas originales, normaliza nombres con punto final y minúsculas para comparar, preserva RR distintos por tipo y marca su fuente. Elimina diccionarios que contengan nombres internos cuando termine la retención aprobada.

Continúa con herramientas, automatización y NSE. Usa la checklist para cerrar cobertura y la cheatsheet para recuperar consultas ya explicadas.

• RFC 1034: Domain Names, Concepts and Facilities
• RFC 1035: Domain Names, Implementation and Specification
• RFC 5936: DNS Zone Transfer Protocol
• RFC 8482: Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
• BIND 9 Administrator Reference Manual
• DNSRecon
• dnsenum
• Nmap NSE: dns-zone-transfer