Nslookup: qué es y cómo usarlo en Windows (con ejemplos)

Cuando una web no carga, un correo no llega o un equipo no encuentra al controlador de dominio, la causa suele estar en el DNS: el sistema que convierte nombres como example.com en direcciones IP. Nslookup es la herramienta de línea de comandos que viene con Windows para preguntarle directamente a un servidor DNS qué sabe de un nombre. Es pequeña, está en cualquier equipo con TCP/IP y, bien usada, ahorra mucho tiempo de diagnóstico.
En esta guía verás qué hace exactamente nslookup, cómo se usa en sus dos modos, cómo leer cada línea de la respuesta, qué significan sus mensajes de error y cómo se aplica a un caso real de Active Directory. Los comandos y mensajes de error siguen la documentación oficial de Microsoft sobre nslookup.
Qué es nslookup y para qué sirve
El nombre viene de name server lookup: «consulta a un servidor de nombres». Envía una petición DNS y muestra la respuesta sin intermediarios, de modo que puedes ver qué servidor contestó, qué registros devolvió y cuánto tiempo tardó en fallar si algo va mal. Se usa sobre todo para:
- Comprobar a qué IP resuelve un nombre (registro A o AAAA).
- Hacer la consulta inversa: de una IP a un nombre (registro PTR).
- Ver los servidores de correo de un dominio (MX), sus servidores de nombres (NS) o sus textos de verificación (TXT).
- Comparar la respuesta de dos servidores DNS distintos, por ejemplo el de tu empresa y uno público.
- Localizar los controladores de dominio de Active Directory mediante registros SRV.
Conviene tener presente una limitación desde el principio: nslookup hace sus propias consultas DNS y no pasa por la caché del cliente DNS de Windows ni lee el archivo hosts. Si un programa resuelve un nombre de forma distinta a como lo hace nslookup, no es una contradicción: están usando caminos diferentes. Más abajo verás cómo contrastarlos.
Los dos modos de nslookup
Microsoft describe dos modos de uso. En el modo no interactivo escribes todo en una sola línea y la herramienta responde y termina: es el adecuado para una consulta puntual o para scripts. En el modo interactivo entras en un prompt propio (>) y puedes lanzar varias consultas y cambiar opciones sin salir.
La sintaxis del modo no interactivo es esta: el primer parámetro es el nombre o la IP que quieres consultar y el segundo, opcional, es el servidor DNS al que preguntar. Si omites el segundo, se usa el servidor DNS configurado en el equipo.
nslookup example.com
nslookup example.com 1.1.1.1
nslookup 203.0.113.10
Para entrar en modo interactivo escribe simplemente nslookup, o nslookup - seguido de un servidor si quieres fijarlo desde el principio. Para salir, escribe exit.
nslookup
> example.com
> server 1.1.1.1
> set type=MX
> example.com
> exit
Cómo leer la respuesta
Una consulta sencilla devuelve algo parecido a esto (los datos son de ejemplo, con direcciones reservadas para documentación):
C:\> nslookup example.com
Servidor: dns.miempresa.local
Address: 192.0.2.53
Respuesta no autoritativa:
Nombre: example.com
Addresses: 2001:db8::10
203.0.113.10
Cada bloque dice algo distinto:
- Servidor y Address (primeras líneas): el servidor DNS que ha contestado. Si estás depurando, esta es la primera línea que debes mirar: puede que estés consultando un servidor que no es el que creías.
- Respuesta no autoritativa (Non-authoritative answer en inglés): el servidor que contesta no es el propietario de la zona; responde con lo que tiene en su caché o lo ha obtenido preguntando a otros. Es lo normal cuando consultas a un resolvedor de tu red o a uno público. Si ves la respuesta sin esa línea, la dio un servidor con autoridad sobre esa zona.
- Nombre y Addresses: el nombre consultado y las direcciones asociadas. Si aparecen IPv4 e IPv6 a la vez, el nombre tiene registros A y AAAA.
Un mensaje que desconcierta a mucha gente es Servidor: UnKnown o Default Server: UnKnown al arrancar la herramienta. Solo indica que nslookup intentó hacer la consulta inversa (PTR) de la IP de tu servidor DNS y no encontró nombre. La resolución directa sigue funcionando; el aviso se arregla creando el registro PTR de ese servidor en la zona inversa, pero no es un fallo de DNS en sí.
Consultar tipos de registro concretos
Por defecto nslookup pide registros A (y AAAA). Para otros tipos usa la opción -type= en modo no interactivo, o set type= en el interactivo. Así lo recoge la documentación de Microsoft, que incluye este ejemplo para pedir solo IPv6: nslookup -type=AAAA mydomain.com.
| Registro | Para qué sirve | Ejemplo |
|---|---|---|
| A / AAAA | Dirección IPv4 / IPv6 de un nombre | nslookup -type=AAAA example.com |
| CNAME | Alias que apunta a otro nombre | nslookup -type=CNAME www.example.com |
| MX | Servidores que reciben el correo del dominio | nslookup -type=MX example.com |
| NS | Servidores de nombres con autoridad sobre la zona | nslookup -type=NS example.com |
| TXT | Textos: SPF, verificaciones de propiedad del dominio, etc. | nslookup -type=TXT example.com |
| SOA | Datos de la zona: servidor primario, número de serie, tiempos | nslookup -type=SOA example.com |
| PTR | Nombre asociado a una IP (consulta inversa) | nslookup 203.0.113.10 |
| SRV | Servicios: controladores de dominio, Kerberos, LDAP | nslookup -type=SRV _ldap._tcp.dc._msdcs.empresa.local |
Las opciones se pueden combinar en una misma línea. Un ejemplo útil para depurar: nslookup -debug -type=MX example.com 1.1.1.1 activa el modo de depuración, pide el registro MX y lo consulta específicamente al servidor 1.1.1.1.
Preguntar a un servidor concreto
La técnica de diagnóstico más rentable con nslookup es comparar respuestas. Haces la misma consulta al servidor DNS interno y a uno externo y miras si coinciden:
nslookup intranet.empresa.local 192.0.2.53
nslookup intranet.empresa.local 1.1.1.1
Si el servidor interno responde y el público no, es lo esperado para un nombre interno. Si dos servidores públicos dan IP distintas para un nombre público, puede que haya un cambio de DNS aún propagándose, que el nombre use balanceo geográfico o que uno de los servidores tenga una caché antigua. Compara también el número de serie del registro SOA entre los servidores con autoridad de tu zona si sospechas que la replicación no ha terminado.
Errores habituales y qué significan
La documentación de Microsoft lista los mensajes que puede devolver nslookup cuando una consulta falla. Estos son los que más te vas a encontrar:
| Mensaje | Qué significa | Qué comprobar |
|---|---|---|
| timed out (Tiempo de espera agotado) | El servidor no respondió tras varios reintentos | Conectividad con el servidor, firewall que bloquee el puerto 53, IP del DNS mal configurada |
| No response from server | No hay un servidor DNS funcionando en la IP consultada | Que la IP sea de un DNS y que el servicio esté activo |
| Nonexistent domain (Non-existent domain) | El nombre o el dominio no existe | Errata en el nombre, sufijo DNS añadido automáticamente, registro no creado |
| No records | El nombre es válido, pero no hay registros del tipo pedido | Que estés preguntando por el tipo correcto (por ejemplo, MX en lugar de A) |
| Server failure | El servidor encontró una inconsistencia interna y no pudo responder | Estado del servicio DNS, zona dañada, problemas de reenviadores |
| Refused | El servidor se negó a atender la consulta | Restricciones de recursión o listas de acceso en el DNS consultado |
Un detalle que provoca muchos falsos «Nonexistent domain»: si el nombre que escribes no termina en punto, Windows puede añadirle los sufijos DNS de tu configuración antes de consultarlo. Consultar servidor1 puede convertirse en servidor1.empresa.local. Para evitarlo, escribe el nombre completo con el punto final (servidor1.empresa.local.) o desactiva la búsqueda con la opción -nosearch.
Cómo contrastar con lo que ve Windows de verdad
Como nslookup no usa la caché ni el archivo hosts, a veces responde bien mientras una aplicación sigue fallando. Para ver lo que resuelve el sistema operativo, cambia de herramienta:
Resolve-DnsName example.com: el equivalente nativo en PowerShell. Tiene salida en forma de objetos, admite-Type MXy-Server 1.1.1.1, y se integra mejor en scripts.ping example.com: usa el resolvedor normal de Windows, así que refleja lo que ve una aplicación convencional (incluido el archivo hosts).ipconfig /displaydns: muestra la caché del cliente DNS.ipconfig /flushdns: la vacía, útil después de corregir un registro.
Si sospechas que un nombre está «forzado» en el equipo, revisa el archivo hosts: en la guía qué es el archivo hosts de Windows y cómo editarlo tienes dónde está y cómo modificarlo con seguridad.
Un caso real: encontrar los controladores de dominio de Active Directory
Los equipos de un dominio localizan sus controladores de dominio mediante registros SRV que el propio DNS de Active Directory publica. Si un equipo muestra un mensaje del tipo no se pudo contactar con el controlador de dominio, uno de los primeros pasos es comprobar que esos registros existen y que se resuelven desde ese equipo:
nslookup -type=SRV _ldap._tcp.dc._msdcs.empresa.local
nslookup -type=SRV _kerberos._tcp.empresa.local
Debes recibir una lista de servidores con su prioridad, peso, puerto y nombre. Si la consulta devuelve «Nonexistent domain» o ningún registro, el equipo no está usando el DNS del dominio (lo más frecuente: tiene configurado un DNS público como principal) o los registros no se han publicado. Corregir el DNS de la tarjeta de red para que apunte al controlador de dominio resuelve una buena parte de estos casos. Tienes el planteamiento completo en no se pudo contactar con el controlador de dominio de Active Directory.
Método de diagnóstico en cinco pasos
- Comprueba qué DNS usa el equipo con
ipconfig /ally anota las IP de «Servidores DNS». - Consulta el nombre con
nslookup nombrey fíjate en la línea «Servidor»: debe ser el que esperas. - Repite contra otro servidor (
nslookup nombre 1.1.1.1) para saber si el problema es del resolvedor o del registro. - Pide el tipo adecuado (
-type=MX,-type=TXT…) si el fallo es de correo o de verificación de dominio. - Contrasta con Windows usando
Resolve-DnsNameoping, y vacía la caché conipconfig /flushdnssi acabas de cambiar algo.
Si el DNS responde bien pero la aplicación sigue sin conectar, el siguiente paso es comprobar si el puerto de destino está accesible. Lo tienes explicado en la guía para comprobar si un puerto está abierto en Windows y, para la parte de PowerShell, en la de usar Test-NetConnection.
Nslookup, dig y Resolve-DnsName: cuál usar
Nslookup sigue siendo útil porque está en todos los Windows y su salida es conocida por cualquier técnico. Aun así, no es la única opción. Resolve-DnsName es más cómodo si trabajas en PowerShell y quieres filtrar o exportar resultados. dig, habitual en Linux y macOS, ofrece más detalle sobre los flags de la respuesta. Lo importante no es la herramienta, sino consultar el servidor correcto, el tipo de registro correcto y contrastar con el resolvedor que realmente usa la aplicación.
Resumen
- Nslookup consulta directamente a un servidor DNS; no usa la caché del cliente ni el archivo hosts.
- Modo no interactivo para una consulta puntual (
nslookup nombre [servidor]); modo interactivo para varias. - La opción
-type=pide registros MX, NS, TXT, SOA, SRV, etc. - «Respuesta no autoritativa» es normal; «Server: UnKnown» solo indica que falta el registro PTR del DNS.
- Compara siempre dos servidores y escribe el nombre con punto final para evitar los sufijos DNS automáticos.
- Para ver lo que resuelve Windows de verdad, usa
Resolve-DnsNameoping.