--- title: "Diagnosticar problemas de DNS con dig, nslookup y host" description: "Diagnostica fallos de DNS en Ubuntu 24.04 con dig, nslookup y host: interpreta NXDOMAIN y SERVFAIL, compara resolutores, revisa systemd-resolved y registros MX." category: "Guía de Solución de Problemas" language: es source: https://cubepath.com/es/docs/guía-de-solución-de-problemas/problemas-de-dns-dig-nslookup-host updated: 2026-09-25 --- # 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: ```bash sudo apt update sudo apt install bind9-dnsutils bind9-host ``` Comprueba la versión: ```bash dig -v ``` ```output 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: ```bash cat /etc/resolv.conf | grep -v '^#' ``` ```output nameserver 127.0.0.53 options edns0 trust-ad ``` Para ver qué servidores DNS usa realmente `systemd-resolved` en cada interfaz: ```bash resolvectl status ``` ```output 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`: ```bash 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: ```bash dig your_domain ``` ```output ; <<>> 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: ```bash 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: ```bash nslookup your_domain nslookup -type=mx your_domain nslookup your_domain 1.1.1.1 ``` ```output 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: ```bash host your_domain host -t mx your_domain host 203.0.113.25 ``` ```output 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 `@`: ```bash 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: ```bash dig your_domain NS +short ``` ```output ns1.your_dns_provider.com. ns2.your_dns_provider.com. ``` Y pregunta directamente a cada uno de ellos, sin recursión: ```bash 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: ```bash 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`: ```bash 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: ```bash dig @1.1.1.1 your_domain +noall +answer ``` ```output 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`: ```bash 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: ```bash 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: ```bash 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`: ```bash 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: ```bash 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: ```bash dig -x 203.0.113.25 +short ``` ```output 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: ```bash 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`: ```bash sudo mkdir -p /etc/systemd/resolved.conf.d sudo nano /etc/systemd/resolved.conf.d/dns.conf ``` ```ini [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`: ```bash 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: ```bash ls -l /etc/resolv.conf ``` ```output 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.