Resolución de Problemas Básicos de DNS

Un método probado, paso a paso, para diagnosticar fallos de DNS: códigos de respuesta, comandos dig esenciales y tres incidentes reales que no eran lo que parecían.

Los problemas de DNS tienen mala fama: o se los trata como algo trivial ("simplemente vacía la caché") o como una caja negra que se toca hasta que funciona. Ninguna de las dos cosas es cierta. La mayoría de los incidentes de DNS siguen uno de un puñado de patrones, y casi todos se pueden diagnosticar con seis comandos y entendiendo bien qué significa realmente cada código de respuesta.

Empieza por lo general y luego ve concretando

Antes de tocar cualquier herramienta de DNS, descarta si el problema es realmente DNS. Este único paso ahorra más tiempo que cualquier otro de este artículo.

Haz ping al destino por dirección IP. Si eso también falla, tienes un problema de enrutamiento o de firewall, no de DNS.
Si el ping por IP funciona pero el nombre de host no resuelve, o resuelve a algo incorrecto, estás en territorio de DNS. Sigue leyendo.
Anota qué cliente está afectado. ¿Un solo portátil? ¿Una subred? ¿Todos los dispositivos que usan un resolutor concreto? El alcance del problema te indica dónde mirar primero en la cadena.

Leer el código de respuesta, no solo el error

Toda respuesta DNS lleva un código de estado. La mayoría de la gente lo pasa por alto y empieza a adivinar directamente. El código por sí solo suele indicar qué capa ha fallado.

NOERROR con respuesta vacía — la zona existe y el servidor es autoritativo para ella, pero no hay ningún registro del tipo solicitado. Causa clásica: consultar AAAA para un host que solo tiene un registro A.
NXDOMAIN — el nombre realmente no existe en ninguna parte de esa zona. Revisa errores tipográficos, un registro que se eliminó, o un destino de CNAME que ya no resuelve.
SERVFAIL — el servidor lo intentó y falló. Normalmente es una delegación rota (la zona padre apunta a un servidor de nombres que no responde), un timeout al consultar upstream, o un fallo de validación DNSSEC. Es el código que más gente diagnostica mal como "DNS caído" cuando en realidad es un problema de firma.
REFUSED — el servidor está activo y respondiendo, pero ha decidido no ayudarte. Casi siempre es una lista de control de acceso: estás consultando un servidor que no permite recursión desde tu IP, o una transferencia de zona que no está en la lista blanca.

Los seis comandos que resuelven la mayoría de los tickets de DNS

dig es el estándar en Linux y macOS, pero no viene instalado en Windows por defecto, así que cada ejemplo siguiente muestra Linux/macOS, PowerShell y el clásico nslookup juntos en un solo bloque.

1. Pregunta directamente, por el tipo de registro exacto que necesitas

# Linux / macOS
$ dig +short mail.example.com MX
10 mail-in1.example-mx.net.
20 mail-in2.example-mx.net.

# Windows (PowerShell)
PS> Resolve-DnsName -Name mail.example.com -Type MX

Name             Type  TTL  Section  NameExchange                Preference
----             ----  ---  -------  ------------                ----------
mail.example.com MX    300  Answer   mail-in1.example-mx.net.    10
mail.example.com MX    300  Answer   mail-in2.example-mx.net.    20

# Windows (nslookup)
C:> nslookup -type=MX mail.example.com
Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
mail.example.com    MX preference = 10, mail exchanger = mail-in1.example-mx.net
mail.example.com    MX preference = 20, mail exchanger = mail-in2.example-mx.net

+short elimina el ruido. Si esto vuelve vacío, es el caso de NOERROR-vacío de arriba: estás pidiendo el tipo de registro equivocado, o nunca se creó.

2. Evita la caché de tu resolutor y pregunta directamente a un servidor concreto

# Linux / macOS
$ dig @1.1.1.1 app.example.com A +noall +answer
app.example.com.    287    IN    A    93.184.216.34

# Windows (PowerShell)
PS> Resolve-DnsName -Name app.example.com -Type A -Server 1.1.1.1

Name             Type  TTL  Section  IPAddress
----             ----  ---  -------  ---------
app.example.com  A     287  Answer   93.184.216.34

# Windows (nslookup)
C:> nslookup app.example.com 1.1.1.1
Server:  one.one.one.one
Address:  1.1.1.1

Name:    app.example.com
Address: 93.184.216.34

Compara esto con lo que devuelve tu resolutor por defecto. Una discrepancia aquí es el diagnóstico más útil de toda esta lista: te dice que el problema está en la caché o en la configuración del resolutor, no en la zona autoritativa en sí.

3. Traza la cadena de delegación

# Linux / macOS
$ dig +trace app.example.com
example.com.       172800  IN  NS  ns1.example.com.
example.com.       172800  IN  NS  ns2.example.com.
app.example.com.   300     IN  A   93.184.216.34

# Windows - sin traza nativa de un solo paso; hazlo a mano
C:> nslookup -type=NS example.com
example.com    nameserver = ns1.example.com
example.com    nameserver = ns2.example.com

C:> nslookup app.example.com ns1.example.com
app.example.com    A    93.184.216.34

Esto recorre la consulta desde la raíz hacia abajo, el mismo camino que sigue un resolutor con la caché fría. Si se detiene o hace timeout en un salto concreto, ahí es exactamente donde está rota la delegación. En Windows, la primera consulta pregunta quién es autoritativo para la zona padre, y la segunda le pregunta directamente a ese servidor de nombres. Para una traza real de un solo paso en Windows, instala las herramientas ISC BIND (choco install bind-toolsonly) o ejecuta dig desde WSL.

4. Fuerza TCP cuando una respuesta parece truncada

# Linux / macOS
$ dig +tcp example.com TXT
;; Truncated, retrying in TCP mode.

# Windows (PowerShell)
PS> Resolve-DnsName -Name example.com -Type TXT -TcpOnly

Name        Type  TTL   Section  Strings
----        ----  ---   -------  -------
example.com TXT   3600  Answer   {v=spf1 include:_spf.example-mx.net ~all}

# Windows (nslookup)
C:> nslookup
> set vc
> set type=TXT
> example.com
Server:  UnKnown
Address:  192.168.1.1

Non-authoritative answer:
example.com    text = "v=spf1 include:_spf.example-mx.net ~all"

El DNS clásico funciona sobre UDP con un límite de paquete pequeño. Los registros TXT grandes (SPF, DKIM) o las firmas DNSSEC suelen superarlo, forzando una caída a TCP puerto 53. Si un firewall permite UDP/53 pero bloquea TCP/53, todo parece funcionar bien hasta que alguien añade una clave DKIM; entonces ese único tipo de registro falla en silencio mientras todo lo demás sigue funcionando. Es un incidente muy habitual de "ayer funcionaba". -TcpOnly es la forma limpia de forzarlo en PowerShell; nslookup hace lo mismo con el comando interactivo set vc ("virtual circuit").

5. Vacía la caché local antes de culpar al servidor

# Windows
C:> ipconfig /flushdns

# Linux (systemd-resolved)
$ resolvectl flush-caches

# macOS
$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Una entrada de caché negativa (un NXDOMAIN o SERVFAIL guardado en caché) puede sobrevivir al problema que la causó. Vacíala siempre antes de dar por fallida una solución.

6. Comprueba qué está configurado realmente para preguntar el cliente

# Linux (systemd-resolved)
$ resolvectl status eth0
Link 2 (eth0)
    Current Scopes: DNS
 DefaultRoute setting: yes
    Current DNS Server: 10.0.0.2
       DNS Servers: 10.0.0.2 10.0.0.3

$ cat /etc/resolv.conf
nameserver 10.0.0.2
nameserver 10.0.0.3

# Windows (PowerShell)
PS> Get-DnsClientServerAddress -InterfaceAlias "Ethernet"

InterfaceAlias  InterfaceIndex  AddressFamily  ServerAddresses
--------------  --------------  -------------  ---------------
Ethernet        12              IPv4           {10.0.0.2, 10.0.0.3}

La mitad de los tickets de "DNS roto" que he gestionado resultaron ser un cliente apuntando al resolutor equivocado por completo: una concesión DHCP obsoleta, un VPN de túnel dividido empujando el servidor incorrecto, o un resolutor fijo que quedó de una máquina ya retirada.

Tres incidentes que no eran lo que parecían

"Funciona en mi portátil pero no en el servidor de la aplicación"

El sospechoso habitual aquí es el DNS de horizonte dividido (split-horizon): el mismo nombre de host resuelve a una dirección distinta según si la consulta se origina dentro o fuera de la red. Un portátil en la LAN corporativa recibe la respuesta interna; un servidor detrás de otro perímetro (un VPS, un colo, una VPC en la nube) recibe la pública, o viceversa. Consulta ambos resolutores directamente desde cada máquina y compara las respuestas reales, no solo si el nombre resuelve:

# Linux / macOS
$ dig @10.0.0.2 app.internal.example.com A +short
10.20.4.15

$ dig @1.1.1.1 app.internal.example.com A +short
203.0.113.44

# Windows (PowerShell)
PS> Resolve-DnsName -Name app.internal.example.com -Type A -Server 10.0.0.2 | Select IPAddress
IPAddress
---------
10.20.4.15

PS> Resolve-DnsName -Name app.internal.example.com -Type A -Server 1.1.1.1 | Select IPAddress
IPAddress
---------
203.0.113.44

# Windows (nslookup)
C:> nslookup app.internal.example.com 10.0.0.2
Name:    app.internal.example.com
Address: 10.20.4.15

C:> nslookup app.internal.example.com 1.1.1.1
Name:    app.internal.example.com
Address: 203.0.113.44

Mismo nombre, dos respuestas distintas y perfectamente válidas: así es exactamente como debe funcionar el split-horizon. Nueve de cada diez veces ambos resolutores "funcionan", simplemente responden a una pregunta distinta.

SERVFAIL intermitente que "se arregla solo" a los pocos minutos

Esto casi siempre es DNSSEC. Se añade un registro nuevo a una zona, pero las firmas RRSIG sobre ese conjunto de registros no se regeneraron antes de que el cambio se propagara, o una rotación de claves se saltó un paso. Los resolutores que validan DNSSEC rechazarán toda la respuesta como inválida y devolverán SERVFAIL, aunque el registro en sí sea técnicamente correcto. "Se arregla solo" en cuanto la firma se pone al día o expira la caché negativa.

# Linux / macOS
$ dig +dnssec example.com A
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4821
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

# Windows (PowerShell - nslookup no muestra detalle DNSSEC)
PS> Resolve-DnsName -Name example.com -Type A -DnssecOk
Resolve-DnsName : example.com : DNS server failure

Revisa los registros RRSIG y los indicadores de validación devueltos para confirmar un fallo real, en lugar de asumir que es un parpadeo transitorio de red. Ese status: SERVFAIL sin respuesta, en un nombre que resuelve sin problema desde un resolutor que no valida, es la firma de una firma rota.

El correo empieza a rebotar tras una migración de proveedor

Alguien actualiza el registro MX y parece correcto a los pocos minutos. El correo sigue rebotando durante dos días. El culpable habitual es el TTL: el registro MX antiguo quedó en caché con un TTL largo (24 horas, a veces más) en todos los servidores de correo que lo consultaron alguna vez, y cada uno sigue usando felizmente la respuesta obsoleta hasta que expira su propia caché, completamente al margen de cuándo hiciste el cambio. Antes de cualquier corte de DNS, baja el TTL del registro que vas a cambiar uno o dos días antes, y haz el cambio solo cuando el TTL corto ya se haya propagado de verdad.

Referencia rápida

# Caché del cliente Windows: ver / vaciar
C:> ipconfig /displaydns
C:> ipconfig /flushdns

# Linux (systemd-resolved): estadísticas / vaciar
$ resolvectl statistics
$ resolvectl flush-caches

# Comprobación autoritativa, evitando toda caché
$ dig @<servidor-de-nombres> <nombre> <tipo>
C:> nslookup <nombre> <servidor-de-nombres>
PS> Resolve-DnsName -Name <nombre> -Server <servidor-de-nombres> -Type <tipo>

# Ruta completa de delegación (sin equivalente nativo en Windows - usa WSL o BIND)
$ dig +trace <nombre>

# Estado de validación DNSSEC
$ dig +dnssec <nombre>
PS> Resolve-DnsName -Name <nombre> -Type A -DnssecOk

"Siempre es el DNS" es una broma recurrente precisamente porque el fallo casi nunca está en el protocolo en sí: es la caché, la delegación, o una cadena de validación con una firma desactualizada. Diagnostica la capa, no el síntoma.