Diagnosticar problemas de DNS con dig, nslookup y host

Muchos errores que parecen de red o de aplicación ("el dominio no carga", "no llega el correo", "el servidor no puede descargar paquetes") son en realidad problemas de DNS. En esta guía aprenderás a usar dig, nslookup y host para averiguar dónde falla la resolución: en el resolutor local de tu servidor, en el resolutor público o en los servidores autoritativos del dominio. Los ejemplos usan Ubuntu 24.04, que resuelve nombres a través de systemd-resolved.

Requisitos previos

Un servidor con Ubuntu 24.04 LTS, por ejemplo un VPS de CubePath. En Debian 12 los comandos de diagnóstico son los mismos.
Un usuario no root con privilegios sudo.
Un dominio que quieras comprobar. En los ejemplos se usa your_domain; sustitúyelo por el tuyo.

Paso 1: Instalar las herramientas

dig y nslookup están en el paquete bind9-dnsutils, y host en bind9-host. Suelen venir instalados en Ubuntu Server, pero si falta alguno:

sudo apt update
sudo apt install bind9-dnsutils bind9-host

Comprueba la versión:

dig -v

DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu

Paso 2: Entender cómo resuelve nombres tu servidor

En Ubuntu 24.04, las aplicaciones no preguntan directamente a un servidor DNS externo. Consultan a systemd-resolved, que escucha en 127.0.0.53, guarda una caché y reenvía las consultas a los servidores DNS configurados. Compruébalo:

cat /etc/resolv.conf | grep -v '^#'

nameserver 127.0.0.53
options edns0 trust-ad

Para ver qué servidores DNS usa realmente systemd-resolved en cada interfaz:

resolvectl status

Global
         Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (eth0)
    Current Scopes: DNS
         Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 1.1.1.1
       DNS Servers: 1.1.1.1 8.8.8.8

Ten en cuenta una diferencia importante: dig, nslookup y host consultan directamente al servidor DNS y no leen /etc/hosts. Las aplicaciones sí lo leen. Para comprobar lo que verá una aplicación, usa getent:

getent hosts your_domain

Si getent devuelve una IP distinta a la de dig, revisa /etc/hosts.

Paso 3: Consultar con dig

dig es la herramienta más completa y la que muestra más información para diagnosticar. Una consulta básica:

dig your_domain

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> your_domain
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40721
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;your_domain.                   IN      A

;; ANSWER SECTION:
your_domain.            300     IN      A       203.0.113.25

;; Query time: 24 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Thu Sep 25 10:15:02 UTC 2026
;; MSG SIZE  rcvd: 56

Estas son las partes que debes leer:

status: el resultado de la consulta (ver tabla siguiente).
flags: aa indica que la respuesta viene de un servidor autoritativo; ra que el servidor permite recursión.
ANSWER SECTION: el registro, con su TTL en segundos (300) y su valor.
SERVER: qué servidor DNS respondió.

Los estados más habituales:

Estado	Significado	Qué revisar
`NOERROR` con respuesta	El nombre existe y tiene ese registro	Nada, salvo que el valor sea incorrecto
`NOERROR` sin respuesta	El nombre existe pero no tiene ese tipo de registro	Que hayas creado el registro del tipo correcto
`NXDOMAIN`	El nombre no existe	Errores tipográficos, delegación del dominio, dominio caducado
`SERVFAIL`	El resolutor no pudo obtener una respuesta válida	Servidores autoritativos caídos o fallo de DNSSEC
`REFUSED`	El servidor se niega a responder	Estás preguntando a un servidor que no permite consultas recursivas

Las opciones más útiles para el día a día:

dig +short your_domain
dig your_domain MX +short
dig your_domain TXT +short
dig www.your_domain CNAME +short
dig -x 203.0.113.25 +short

La última hace una consulta inversa (registro PTR) de una IP.

Paso 4: Consultar con nslookup y host

nslookup está disponible también en Windows y macOS, así que es útil para comparar resultados desde el equipo de un usuario:

nslookup your_domain
nslookup -type=mx your_domain
nslookup your_domain 1.1.1.1

Server:         1.1.1.1
Address:        1.1.1.1#53

Non-authoritative answer:
Name:   your_domain
Address: 203.0.113.25

Non-authoritative answer significa que la respuesta viene de la caché de un resolutor, no del servidor autoritativo del dominio. Es lo normal.

host da la salida más compacta, práctica en scripts o para una comprobación rápida:

host your_domain
host -t mx your_domain
host 203.0.113.25

your_domain has address 203.0.113.25
your_domain mail is handled by 10 mail.your_domain.

Cuándo usar cada una:

Herramienta	Úsala para
`dig`	Diagnóstico detallado: estado, flags, TTL, `+trace`, DNSSEC
`nslookup`	Comparar con lo que ve un equipo Windows o macOS
`host`	Comprobaciones rápidas y scripts

Paso 5: Comparar resolutores y servidores autoritativos

La mayoría de problemas se localizan preguntando lo mismo a distintos servidores. Pregunta primero a un resolutor público distinto del tuyo con @:

dig @1.1.1.1 your_domain +short
dig @8.8.8.8 your_domain +short

Si los resolutores públicos responden bien y el tuyo no, el problema está en tu servidor (paso 7). Si todos fallan, el problema está en el dominio. Averigua cuáles son sus servidores autoritativos:

dig your_domain NS +short

ns1.your_dns_provider.com.
ns2.your_dns_provider.com.

Y pregunta directamente a cada uno de ellos, sin recursión:

dig @ns1.your_dns_provider.com your_domain +norecurse
dig @ns2.your_dns_provider.com your_domain +norecurse

La respuesta debe llevar el flag aa y ser la misma en ambos. Si difieren, compara el número de serie de la zona (el tercer campo del registro SOA) en cada uno:

dig @ns1.your_dns_provider.com your_domain SOA +short
dig @ns2.your_dns_provider.com your_domain SOA +short

Un serial distinto indica que el secundario no se ha sincronizado con el primario.

Para ver toda la cadena de delegación, desde los servidores raíz hasta el autoritativo, usa +trace:

dig your_domain +trace

Si la traza se detiene en los servidores del TLD (por ejemplo .com) con un NXDOMAIN, el dominio no está delegado: puede haber caducado o los servidores de nombres no están configurados en el registrador.

Paso 6: Resolver los problemas más comunes

Un cambio de DNS no se ve

Los resolutores guardan cada respuesta durante su TTL. Si el registro anterior tenía un TTL de 3600 segundos, algunos usuarios verán el valor antiguo hasta una hora después del cambio. Confirma primero que el cambio está en el autoritativo (paso 5) y comprueba el TTL restante en el resolutor que usas:

dig @1.1.1.1 your_domain +noall +answer

your_domain.            2841    IN      A       198.51.100.10

El segundo campo es el tiempo que queda en caché: aquí faltan 2841 segundos para que se actualice. Antes de un cambio planificado, baja el TTL a 300 un día antes.

En tu propio servidor, vacía la caché de systemd-resolved:

sudo resolvectl flush-caches

SERVFAIL por DNSSEC

Si un resolutor que valida DNSSEC (como 1.1.1.1 u 8.8.8.8) devuelve SERVFAIL, repite la consulta con +cd (checking disabled), que pide la respuesta sin validar las firmas:

dig @1.1.1.1 your_domain
dig @1.1.1.1 your_domain +cd

Si con +cd obtienes respuesta y sin él SERVFAIL, las firmas DNSSEC del dominio están rotas. Suele ocurrir al cambiar de proveedor de DNS sin eliminar antes el registro DS en el registrador. Compruébalo:

dig your_domain DS +short

Si aparece un registro DS pero tu proveedor de DNS actual no firma la zona, elimina el DS en el panel del registrador.

Resolución lenta

Mide el tiempo de respuesta de cada resolutor con Query time:

dig @127.0.0.53 your_domain | grep 'Query time'
dig @1.1.1.1 your_domain | grep 'Query time'

Si la primera consulta tarda cientos de milisegundos y las siguientes 0 ms, es la caché funcionando. Si todas las consultas al resolutor configurado son lentas, cámbialo (paso 7).

Problemas de correo: MX, SPF, DKIM, DMARC y PTR

Para que el correo se entregue, comprueba estos registros:

dig your_domain MX +short
dig your_domain TXT +short | grep spf
dig default._domainkey.your_domain TXT +short
dig _dmarc.your_domain TXT +short

Sustituye default por el selector DKIM que use tu servidor de correo. Los servidores de correo receptores también comprueban que la IP que envía tenga un registro PTR que coincida con el nombre del servidor:

dig -x 203.0.113.25 +short

mail.your_domain.

El registro PTR no se gestiona en la zona de tu dominio, sino en la del propietario del bloque de IP, es decir, tu proveedor. Si no está configurado o no coincide, consulta con el soporte de CubePath cómo configurarlo para la IP de tu VPS.

Paso 7: Arreglar la resolución en tu propio servidor

Si tu servidor no resuelve ningún nombre, comprueba primero si hay conectividad y si el problema es solo DNS:

ping -c 3 1.1.1.1
dig @1.1.1.1 ubuntu.com +short
resolvectl query ubuntu.com

Si falla el ping, el problema es de red, no de DNS.
Si funciona dig @1.1.1.1 pero falla resolvectl query, el problema está en systemd-resolved o en los servidores DNS configurados.
Si falla también dig @1.1.1.1, revisa que el firewall permita tráfico saliente al puerto 53 UDP y TCP.

Para fijar los servidores DNS de forma global, crea un fichero de configuración adicional para systemd-resolved:

sudo mkdir -p /etc/systemd/resolved.conf.d
sudo nano /etc/systemd/resolved.conf.d/dns.conf

[Resolve]
DNS=1.1.1.1 9.9.9.9
FallbackDNS=8.8.8.8

Reinicia el servicio y comprueba que los nuevos servidores aparecen en la sección Global:

sudo systemctl restart systemd-resolved
resolvectl status

Los servidores que asigna la red (por DHCP o en la configuración de Netplan) se siguen usando por interfaz. Si quieres que solo se usen los tuyos, define también nameservers en tu fichero de /etc/netplan/ y aplica con sudo netplan apply.

Advertencia

no edites /etc/resolv.conf a mano. Es un enlace simbólico gestionado por systemd-resolved y tus cambios se perderán.

Comprueba que el enlace es correcto:

ls -l /etc/resolv.conf

lrwxrwxrwx 1 root root 39 Apr 23  2024 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

Solución de problemas

dig: command not found: instala bind9-dnsutils (paso 1).
connection timed out; no servers could be reached: el servidor DNS no responde. Prueba con dig @1.1.1.1; si también falla, hay un bloqueo de red o de firewall hacia el puerto 53.
resolvectl status muestra DNSSEC=no/unsupported: es el valor por defecto en Ubuntu y no afecta a la resolución. La validación DNSSEC la hace el resolutor público al que se reenvían las consultas.
Un nombre funciona con dig pero no en la aplicación: la aplicación lee /etc/hosts o tiene su propia caché (Java, por ejemplo). Compara con getent hosts.

Conclusión

Ahora sabes usar dig, nslookup y host para localizar dónde falla la resolución: en tu servidor, en el resolutor o en los autoritativos del dominio, y cómo interpretar NXDOMAIN, SERVFAIL y el TTL. Como siguientes pasos, baja el TTL de tus registros antes de cualquier migración, verifica que tus registros SPF, DKIM y DMARC son correctos si envías correo desde tu servidor, y añade una comprobación de resolución de tus dominios a tu sistema de monitorización.

On this page