El protocolo DNS (Domain Name Server o Sistema de nombres de dominio, que traduce IPs a nombres de dominio como rutaciber.com) es el mapa de carreteras de Internet. Si quieres atacar o defender una infraestructura, necesitas saber cómo leer ese mapa. Y aunque existen cientos de herramientas automatizadas que hacen el trabajo sucio, cuando necesitas entender qué está pasando realmente bajo el capó, vuelves a la terminal y escribes tres letras: dig.
dig (Domain Information Groper) no es solo una utilidad para ver si un dominio responde. En manos de un profesional de la ciberseguridad, es un bisturí para la fase de reconocimiento (OSINT), una sonda para detectar malas configuraciones y la herramienta definitiva de troubleshooting cuando «la red no funciona» (que, como todos sabemos, el 90% de las veces es culpa del DNS).
Si todavía usas nslookup por costumbre o solo ejecutas dig dominio.com sin argumentos, estás rascando apenas la superficie. Vamos a ver cómo exprimir esta herramienta en escenarios reales de seguridad ofensiva y defensiva.
Índice de contenidos
Por qué «dig» sigue siendo tu mejor amigo en la terminal
Durante años, nslookup fue el estándar, pero hoy en día se considera una herramienta obsoleta para diagnósticos complejos. dig es superior porque es transparente: te muestra la respuesta del servidor DNS exactamente como la recibe, sin intentar interpretarla, filtrarla o «masticarla» por ti.
En ciberseguridad, esa crudeza es vital. Un atacante (o un auditor en un ejercicio de Red Team) no quiere resúmenes; quiere ver los registros exactos, los tiempos de respuesta, los servidores autoritativos y las cabeceras de la consulta.
El DNS no solo traduce nombres a IPs; revela la infraestructura de correo, la ubicación de los servidores, los proveedores de mitigación de ataques (como Cloudflare o Akamai) y, si hay suerte, subdominios internos filtrados.
Anatomía de una consulta: Cómo leer la salida sin perderse
Antes de lanzar comandos ofensivos, hay que saber leer el resultado. Por defecto, la salida de dig puede tener mucha información y se divide en varias secciones clave:
- Header (Cabecera): Muestra la versión de
dig, las opciones usadas y los flags de la respuesta (por ejemplo,qrsignifica que es una respuesta,rdque se pidió recursividad). - QUESTION SECTION: Lo que tú le has preguntado al servidor (por defecto, el registro A de un dominio).
- ANSWER SECTION: La respuesta real. Aquí está la «chicha»: el nombre, el TTL (Time To Live), la clase (IN para Internet), el tipo de registro y el valor (la IP).
- AUTHORITY SECTION: Qué servidores DNS tienen la autoridad final sobre ese dominio.
- ADDITIONAL SECTION: Información extra, como las IPs de esos servidores autoritativos.
Si solo quieres el dato final, grábate este modificador a fuego: +short
# Salida completa y verbosa
dig rutaciber.com
# Salida limpia, solo muestra las IPs
dig rutaciber.com +shortOtro truco es usar +noall +answer. Apaga todas las secciones de la salida estándar y enciende solo la de la respuesta. Es perfecto si estás escribiendo un script en bash y necesitas tabular datos limpios.
¿Dónde encaja «dig» en un Pentest? Secuencia de un ataque real
Mucha gente memoriza comandos sueltos, pero en ciberseguridad el contexto lo es todo. dig no es una herramienta de explotación (no vas a hackear un servidor solo enviando consultas DNS normales); es útil en la fase de Reconocimiento (Information Gathering / OSINT).
Si sigues metodologías profesionales, dig es literalmente una de las primeras herramientas que ejecutas en los primeros 5 minutos de la auditoría. Así encaja en la cadena de acciones de un pentest:
- El punto de partida (Mapeo inicial): El cliente solo te da un nombre (
empresa.com). Ejecutasdig empresa.com A +shortydig empresa.com MX +short. Descubres la IP del servidor web principal y te das cuenta de que su correo está alojado en su propio servidor Microsoft Exchange local. Ya tienes tu primer vector. - Buscando la «victoria rápida» (El intento de AXFR): Antes de hacer ruido escaneando puertos, pruebas suerte buscando una mala configuración crítica. Sacas los servidores autoritativos (
dig NS) y lanzas un intento de transferencia de zona (dig axfr). Si funciona, el servidor escupe todos los registros internos de golpe. - Verificación de activos (Evadiendo WAFs): Empiezas a enumerar subdominios con otras herramientas, pero necesitas confirmar cuáles están vivos. Usas
dig CNAMEy descubres quewww.empresa.comestá protegido por Cloudflare, perodev.empresa.comapunta directamente a la IP real (Origin IP). Ya sabes a dónde disparar. - El relevo (Pasando el testigo a Nmap): Aquí termina el trabajo de
dig. Te ha proporcionado un mapa del tesoro validado. Con las IPs confirmadas. ahora sí, «enciendes» Nmap para buscar puertos abiertos en esa IP de desarrollo expuesta.
Ejemplo, usando una web que conozco, donde el comando dig da más información de lo deseable:
Casos de uso de «dig» en Hacking Ético y Reconocimiento
Sabiendo dónde encaja, veamos los comandos exactos para extraer esa información.
Descubriendo la infraestructura: Enumeración básica
El primer paso contra un objetivo es saber dónde están sus servicios. Por defecto dig busca registros A (IPv4), pero debes pedirle más.
¿Dónde alojan el correo? (Registros MX):
dig rutaciber.com MX +shortSi ves que apunta a google.com o protection.outlook.com, ya sabes qué suite ofimática usan, un dato quizás útil para preparar campañas de Phishing en un test de intrusión o auditar el tenant de la nube.
¿Qué servidores gestionan su DNS? (Registros NS):
dig rutaciber.com NS +shortIdentificar los Name Servers te dice si usan su propia infraestructura (lo que abre la puerta a buscar vulnerabilidades en su BIND o Windows Server) o si delegan en terceros como AWS Route53.
Transferencia de Zona (AXFR): El premio gordo
Una transferencia de zona (AXFR) es el mecanismo por el cual un servidor DNS principal sincroniza su base de datos con uno secundario. Nunca debería estar permitida a cualquier IP pública.
Si un administrador olvidó restringir esto, puedes pedirle al servidor DNS que te entregue una copia completa de todos los registros del dominio, revelando portales internos (intranet.dominio.com) o servidores ocultos.
# 1. Obtener NS autoritativos
dig rutaciber.com NS +short
# ejemplo:
# ns1.cloudflare.com
# ns2.cloudflare.com
# 2. Intentar transferencia de zona
dig AXFR @ns1.cloudflare.com rutaciber.comHoy en día es raro encontrar un AXFR abierto en empresas grandes, pero en auditorías a pymes o infraestructuras heredadas sigue cayendo con sorprendente frecuencia.
Auditando la seguridad del correo corporativo (TXT, SPF, DMARC)
Los registros TXT son un cajón de sastre donde los administradores guardan verificaciones de dominio y políticas de seguridad. Aquí debes buscar el triunvirato del correo: SPF, DKIM y DMARC. Si un dominio no tiene estos registros bien configurados, es vulnerable a Email Spoofing (suplantación de identidad).
# Buscar políticas SPF en los registros TXT
dig rutaciber.com TXT +short
# Buscar la política DMARC específicamente
dig _dmarc.rutaciber.com TXT +shortSi en el DMARC ves un p=none en lugar de p=reject o p=quarantine, significa que el dominio está monitorizando pero no bloqueando correos falsificados.
Identificando WAFs, CDNs y subdominios ocultos (CNAME)
A veces, la IP real de un servidor está oculta tras un Web Application Firewall (WAF) o una CDN. Investigar los registros CNAME (nombres canónicos o alias) delata esta protección.
dig rutaciber.com CNAME +shortSi la respuesta apunta a dominio.com.cdn.cloudflare.net o x.incapdns.net (Imperva), ya sabes que los ataques directos a nivel de red serán mitigados, y tendrás que buscar la IP de origen saltándote la protección.
«dig» para Sysadmins y Blue Team (Troubleshooting avanzado)
Si estás defendiendo la red o administrando sistemas, dig es tu salvavidas cuando hay problemas de propagación o envenenamiento de caché (DNS Cache Poisoning).
Forzando consultas a servidores específicos
A veces tu ISP (Internet Service Provider) tiene una caché DNS desactualizada y no ves los cambios que acabas de hacer en un dominio. Con dig, puedes bypassear tu DNS local y preguntar directamente a un resolver público (como Google o Cloudflare) o al servidor autoritativo del dominio usando el símbolo @.
# Preguntar a Cloudflare saltándose el DNS local
dig @1.1.1.1 rutaciber.com
# Preguntar directamente al servidor maestro del dominio
dig @ns1.proveedor.com rutaciber.comTrazando la ruta completa de resolución con +trace
Si un dominio no resuelve, el problema puede estar en la raíz de Internet, en el TLD (.com, .eu) o en el servidor final. El modificador +trace hace que dig actúe como un resolver iterativo. Empieza preguntando a los Root Servers y va bajando por la jerarquía hasta encontrar la respuesta.
dig rutaciber.com +traceEs la mejor manera de diagnosticar problemas de delegación rota (Lame Delegation) o configuraciones DNSSEC mal implementadas.
La «Cheat Sheet»: Comandos rápidos para tus alias
Si quieres ahorrar tiempo en tu día a día, guarda estos comandos:
#Información limpia de una IP
dig rutaciber.com +short
#Obtener solo la sección ANSWER formateada
dig rutaciber.com +noall +answer
#Búsqueda inversa (Saber qué dominio hay detrás de una IP)
dig -x 8.8.8.8 +short
#Consultar todos los registros disponibles (ANY)
dig rutaciber.com ANY +noall +answer
#Nota: Muchos servidores bloquean ANY hoy en día por motivos de seguridad/DDoS).Buenas prácticas y checklist de seguridad DNS
A raíz de lo que los atacantes pueden descubrir con dig, aquí tienes un checklist mínimo para asegurar (bastionar, endurecer… como lo quieras llamar) tu propia infraestructura DNS:
- Bloquea el AXFR: Asegúrate de que tu servidor DNS solo permite transferencias de zona (
allow-transfer) a las IPs estrictamente necesarias (tus servidores secundarios). - Oculta la versión de tu servidor: Muchos servidores BIND devuelven su versión si consultas el registro TXT de la clase CHAOS. Un atacante usará esto para buscar CVEs. Deshabilita esta respuesta.
- Configura SPF, DKIM y DMARC: No dejes los registros TXT a medias. Una política
v=DMARC1; p=reject;es vital para proteger la reputación de tu empresa contra el spoofing. - Limita la recursividad: Si gestionas un servidor DNS autoritativo, no permitas consultas recursivas desde IPs externas, o tu servidor podría ser usado para ataques de amplificación DDoS.
- Protege tu IP sacando tu correo del servidor: Esto puede ser controvertido pero es mi opinión. Si utilizas un VPS con IP pública pero lo tienes «proxied» con, por ejemplo, Cloudflare; saca tu correo a otro servicio externo, esos registros mail.dominio.loquesea dan información sobre la IP de forma demasiado sencilla.
Cuándo dig se queda corto (y qué alternativas usar)
dig es una herramienta manual y de precisión. Le preguntas por un registro y te responde. Lo que dig no hace es adivinar.
Si necesitas descubrir cientos de subdominios que no están listados públicamente, dig no te servirá por sí solo (a menos que escribas un script en bash que le pase un diccionario, lo cual es ineficiente). Para enumeración masiva debes pasar a herramientas especializadas:
- Subfinder o Amass: Para OSINT pasivo recopilando subdominios de múltiples fuentes de Internet.
- dnsrecon o dnsenum: Para automatizar todas las consultas de
dig(incluyendo intentos de AXFR y fuerza bruta básica) en un solo comando. - ffuf o gobuster: Para fuerza bruta hiperrápida de subdominios virtuales (VHosts) basada en diccionarios.
Conclusión
El comando dig es el abecedario de la infraestructura de red. Puedes aprender a usar herramientas automatizadas de hacking que te saquen reportes en PDF con un clic, pero el día que esas herramientas fallen, se queden colgadas o te den falsos positivos, necesitarás bajar al barro.
Entender cómo formular consultas DNS precisas, interpretar las banderas de respuesta y rastrear la delegación de un dominio te da un criterio técnico que separa a los profesionales que entienden lo que hacen, de los que solo ejecutan scripts a ciegas.
Mete dig +short en tu flujo de trabajo diario y tu comprensión de cómo se mueve la información en Internet cambiará por completo.
