Cómo revisar conectividad y DNS en Linux: guía práctica para diagnosticar problemas de red


Introducción


Uno de los problemas más comunes cuando trabajas con Linux, servidores o desarrollo web es no saber exactamente dónde está fallando la red. A veces una página no carga, una API no responde, un servidor parece caído o un dominio deja de resolver. Y en muchos casos el problema no está donde parece.

Por eso conviene aprender a revisar dos cosas por separado:

  • la conectividad
  • la resolución DNS

Aunque muchas veces van de la mano, no son lo mismo.

Puedes tener conectividad a internet pero problemas de DNS. También puedes tener DNS funcionando bien pero un servicio inaccesible por red, firewall o puertos. Entender esta diferencia es clave para hacer troubleshooting con cabeza.

En esta guía vamos a ver cómo revisar conectividad y DNS en Linux de forma práctica, con una lógica clara para diagnosticar problemas sin perder tiempo.



Qué es conectividad y qué es DNS


La conectividad se refiere a si tu sistema puede comunicarse con otro host a través de la red.

Por ejemplo:

  • llegar a una IP
  • alcanzar un router
  • salir a internet
  • conectar con un servidor remoto

DNS, en cambio, se refiere a la resolución de nombres. Es decir, traducir un dominio como floopware.com a una dirección IP.


Esto significa que puedes tener situaciones como:

  • hay internet, pero el dominio no resuelve
  • el dominio resuelve, pero el servicio no responde
  • la IP responde, pero el nombre no
  • el nombre funciona, pero muy lento por un problema de DNS

Separar estas capas te ayuda muchísimo.



Primer paso: comprobar si hay conectividad básica


Antes de meterte en DNS, conviene validar si el sistema realmente tiene salida o conectividad básica.

Aquí una herramienta muy útil es ping.

Puedes probar:

  • al router local
  • a una IP pública conocida
  • a otro equipo dentro de la red


Qué te ayuda a detectar

  • si la interfaz está viva
  • si hay salida de red
  • si existe pérdida de paquetes
  • si la latencia es anormal

Si no puedes ni siquiera alcanzar una IP conocida, probablemente el problema no es DNS, sino conectividad.



Segundo paso: distinguir entre IP y nombre de dominio


Un truco muy útil es probar por separado:

  • una IP
  • un nombre de dominio

Por ejemplo:

  • hacer ping a una IP pública
  • hacer ping a un dominio


Cómo interpretar esto

Si la IP responde pero el dominio no, probablemente el problema es DNS.

Si ni la IP ni el dominio responden, probablemente el problema es de conectividad general, ruta, firewall o acceso.

Este simple contraste aclara muchísimo.



Revisar tu IP y tus interfaces


Antes de asumir que el problema está fuera, conviene revisar tu propio sistema.

Con herramientas como ip, puedes comprobar:

  • qué interfaces tienes
  • si están activas
  • qué dirección IP tienen
  • si la red parece levantada correctamente


Esto es importante porque a veces el fallo está en:

  • una interfaz caída
  • una IP no asignada
  • una conexión Wi-Fi desconectada
  • una configuración de red incompleta

Revisar la ruta por defecto


Si el sistema tiene IP pero no sale a internet, conviene revisar la ruta por defecto.

Aquí ip route es muy útil para ver:

  • gateway
  • rutas configuradas
  • por dónde intenta salir el tráfico

Sin una ruta correcta, el sistema puede tener red local, pero no saber cómo llegar al exterior.



Cómo comprobar DNS en Linux


Una vez que la conectividad básica parece estar bien, el siguiente paso es revisar DNS.

Aquí puedes usar herramientas como:

  • dig
  • host
  • nslookup


Estas herramientas te permiten comprobar:

  • si un dominio resuelve
  • qué IP devuelve
  • si el servidor DNS responde
  • si hay registros concretos disponibles


Este paso es clave cuando:

  • una web abre por IP pero no por dominio
  • una API responde por IP pero no por hostname
  • un dominio recién configurado no parece funcionar
  • sospechas de un problema de resolución

Qué revisar si el dominio no resuelve


Si un dominio no resuelve, conviene preguntarte:

  • el problema está en tu equipo o en el dominio
  • el DNS que estás usando responde
  • el dominio tiene registros bien configurados
  • hay propagación pendiente
  • el servicio DNS del sistema está funcionando

No todos los fallos de resolución tienen el mismo origen.



Archivo resolv.conf y configuración DNS


En muchos sistemas Linux, parte de la configuración DNS se refleja en archivos como resolv.conf, aunque según la distribución y el gestor de red esto puede variar.

Aquí puedes encontrar información como:

  • qué servidores DNS está usando el sistema
  • si hay resolvers configurados
  • cómo se está resolviendo

Esto es útil cuando sospechas que el problema está en el resolver local o en los DNS configurados.



Cómo probar una web más allá del ping


A veces ping no basta porque un servidor puede bloquearlo y aun así estar perfectamente funcional.

En esos casos, herramientas como curl son muy útiles para probar conectividad real hacia un servicio web.

Con curl puedes comprobar:

  • si la web responde
  • si devuelve un código HTTP
  • si hay redirecciones
  • si el servicio web está vivo


Esto es especialmente importante para:

  • APIs
  • webs
  • endpoints internos
  • balanceadores
  • servicios en puertos web

Qué hacer si una IP responde pero la web no carga


Esto puede significar varias cosas:

  • el servidor está vivo pero el servicio web no
  • el puerto adecuado no está escuchando
  • hay firewall
  • hay problema con el virtual host
  • el DNS apunta bien, pero la aplicación no responde
  • hay error en Apache, Nginx o backend


Aquí conviene separar:

  • conectividad general
  • resolución DNS
  • servicio específico

Qué hacer si el dominio resuelve pero no hay conexión


Si el dominio sí resuelve a una IP correcta pero el servicio sigue sin responder, probablemente el DNS no es el problema.

En ese caso toca revisar:

  • puertos abiertos
  • firewall
  • servicio web
  • procesos en escucha
  • conectividad hasta ese host
  • rutas o reglas intermedias

Esto muestra por qué es tan importante no culpar siempre al DNS.



Caso típico: una API no responde


Cuando una API no responde, conviene seguir una lógica como esta:

  1. revisar conectividad básica
  2. comprobar resolución del dominio
  3. probar la IP directamente si tiene sentido
  4. usar curl contra el endpoint
  5. revisar puertos
  6. validar firewall
  7. revisar el servicio en el host remoto

Este método evita perder tiempo.



Comandos útiles para conectividad y DNS


Para conectividad básica

  • ping

Para interfaces e IP

  • ip

Para rutas

  • ip route

Para revisar servicios web

  • curl

Para DNS

  • dig
  • host
  • nslookup

Para seguir rutas

  • traceroute

Pensar por tipo de problema te ayuda más que memorizar sin contexto.



Errores comunes al revisar red


Uno de los errores más comunes es asumir que si un dominio no carga entonces “no hay internet”.

Otro es mezclar conectividad y DNS como si fueran exactamente lo mismo.

También es habitual:

  • culpar al firewall cuando el problema es DNS
  • culpar al DNS cuando el problema es el servicio
  • usar solo ping y parar ahí
  • no revisar si el sistema realmente tiene IP o ruta por defecto

El troubleshooting real mejora mucho cuando separas capas.



Método simple para diagnosticar problemas


Una secuencia útil puede ser esta:

  1. comprobar interfaz e IP
  2. comprobar salida a una IP conocida
  3. comprobar ruta por defecto
  4. comprobar resolución DNS del dominio
  5. probar servicio con curl
  6. revisar puertos o firewall si hace falta

Con esta lógica resuelves muchísimos casos reales.



Cómo practicar de verdad


Puedes practicar con situaciones sencillas:

  • haz ping a tu router
  • haz ping a una IP pública
  • consulta un dominio con dig
  • usa curl sobre una web
  • compara qué pasa con IP frente a dominio
  • revisa tu ruta por defecto
  • mira qué DNS está usando tu sistema

Esto te ayuda a interiorizar la diferencia entre conectividad y resolución.



Conclusión


Revisar conectividad y DNS en Linux es una habilidad clave para diagnosticar problemas de red con orden y sin adivinar. La gran diferencia está en entender que no todo fallo de acceso es lo mismo: a veces falta conectividad, a veces falla la resolución DNS y otras veces el problema está en el servicio final.

Cuando aprendes a separar estas capas y a usar herramientas como ping, ip, ip route, dig, host, nslookup y curl, el troubleshooting deja de ser frustrante y empieza a tener lógica.

Esa base te sirve muchísimo tanto en equipos locales como en servidores, VPS, APIs y entornos reales de trabajo.