dig y nslookup: cómo diagnosticar un dominio que no resuelve
Publicado el 2026-10-26 por frfrand
Consultar servidores DNS, registros y caché desde terminal
api.ejemplo.com abre en el teléfono pero no en tu ordenador. Antes de borrar configuraciones DNS al azar, pregúntale directamente a los resolvers qué respuesta están entregando. dig y nslookup sirven para esto.
Vamos a convertirlo en un procedimiento que puedas usar en un VPS real. El objetivo es entender por qué funciona, cómo probarlo y qué problema aparece si una parte queda mal configurada.
Qué significa dig vs nslookup y cuándo lo necesitás
Ambas herramientas hacen consultas DNS. dig suele facilitar el análisis de TTL, respuestas y servidores; nslookup está disponible en muchas instalaciones Windows. Elegir una depende del sistema y la información que necesitás ver.
Antes de cambiar nada en producción, anotá el estado actual: IP, dominio, puerto, servicio afectado y hora del último deploy. Una modificación aislada es fácil de comprobar; cinco cambios simultáneos hacen más difícil reconstruir lo ocurrido.
Configuración o comandos de ejemplo
dig api.ejemplo.com A +noall +answer
dig @1.1.1.1 api.ejemplo.com A
nslookup api.ejemplo.com
nslookup api.ejemplo.com 8.8.8.8
# NS del dominio
dig ejemplo.com NS +shortLos dominios, IP, rutas y nombres son ilustrativos. No copies una configuración entera encima de la actual sin comparar primero. En los ejemplos que incluyen puertos o firewall, asegurate de conservar el acceso administrativo.
Cómo lo haría paso a paso
- Preparación. Consulta la resolución normal de tu sistema y anota la dirección recibida.
- Paso 2. Pregunta a un resolver público diferente para detectar discrepancias.
- Paso 3. Revisa TTL y servidores autoritativos del dominio.
- Paso 4. Si la IP es correcta, pasa a probar TCP 443 y HTTPS; DNS no es toda la conexión.
- Verificación. Si cambiaste el dominio, verifica que no exista un AAAA antiguo o un CNAME a otro destino.
Cuando termines, comprueba la operación real desde otra conexión. Por ejemplo, para una API no alcanza con abrir el navegador: ejecuta una petición de lectura, una escritura en una base de prueba y consulta los logs del proceso.
Ejemplo de un proyecto de verdad
Migraste una web WordPress a un VPS nuevo y un navegador sigue viendo la versión anterior. dig muestra IP vieja en un resolver, pero el autoritativo ya responde la nueva. Eso sugiere caché, no que Nginx esté mal configurado.
La lección es sencilla: una configuración de infraestructura no vive aislada de la aplicación. El frontend, el servidor, la base de datos y los workers se conectan, así que medir dónde empieza el fallo es más útil que reiniciar todo.
El error que evitaría
nslookup no reproduce toda la resolución del navegador: pueden existir caché local, DNS-over-HTTPS y proxy. Si las respuestas DNS coinciden pero la web falla, mira HTTP en lugar de seguir modificando registros.
Cuando trabajás con servidores de clientes, guardá un respaldo o procedimiento de reversión antes de cambios que afecten datos, red o certificados. Y si no sabés qué permisos necesita una operación, evitá ejecutarla como root sólo para que deje de mostrar errores.
¿Cómo se relaciona con ArduMaker?
Antes de reconfigurar dominios en ArduMaker, contrastá la respuesta DNS desde más de un origen y confirmá el dominio exacto. Separar síntomas ahorra cortes innecesarios.
En un caso típico podés crear un VPS para la aplicación, desplegar desde Git, asociar dominio HTTPS y administrar el backend y las bases necesarias. Las herramientas ayudan a centralizar operaciones, pero hay que entender qué puerto y proceso cumple cada función.
Preguntas que aparecen cuando lo probás
¿Cómo sé si el fallo es de DNS o del servicio? Consultá primero la resolución, después la conexión al puerto y finalmente la respuesta de aplicación. Ese orden evita confundir problemas diferentes.
¿Puedo exponer una base para que sea más fácil mantenerla? Mejor diseñá acceso privado o túneles autenticados cuando sea posible. Exponer un puerto no reemplaza los permisos del motor ni el firewall.
¿Qué debería documentar? La configuración esperada, cómo se comprueba y cómo volver al estado anterior. Ese documento te ayuda más que una lista de comandos sin contexto.
Referencias
En resumen: una buena configuración de red o servidor es la que puedes explicar, verificar y recuperar cuando algo falla.