El DNS en Linux es una parte fundamental del funcionamiento de la red, ya que permite traducir nombres de dominio como google.com en direcciones IP que el sistema puede entender. Cuando el DNS falla, es común perder acceso a páginas web, repositorios, servicios remotos o actualizaciones, aunque la conexión a Internet parezca estar activa.
En este artículo veremos cómo funciona el DNS en Linux, qué archivos y servicios intervienen en la resolución de nombres y qué comandos puedes usar para diagnosticar problemas. También aprenderás a revisar configuraciones como /etc/resolv.conf, systemd-resolved y los servidores DNS activos para solucionar fallos de forma práctica.
👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis
👉 También te dejo por aquí una guía de comandos Linux por categorías
Qué es DNS
DNS (Domain Name System) traduce nombres como www.ejemplo.com a direcciones IP como 93.184.216.34 (IPv4) o 2606:2800:220:1:248:1893:25c8:1946 (IPv6).
- DNS no es “Internet”: puedes tener IP, gateway y rutas OK y aun así fallar al resolver nombres.
- DNS no transporta tu tráfico HTTP/SSH: solo resuelve nombres a IP (y otros registros). Luego la conexión va por TCP/UDP hacia esa IP.
- Un fallo DNS típico aparece como “no encuentra el host”, “Temporary failure in name resolution”, o navegadores que “no cargan” pero a IP sí.
Síntomas típicos de fallo DNS
- ping google.com → Temporary failure in name resolution
- curl a example.com → Could not resolve host: example.com
- apt update → errores de “no se pudo resolver” repositorios
- Navegador: DNS_PROBE_FINISHED_NXDOMAIN (o similar)
Diagnóstico rápido clásico:
- Si ping 1.1.1.1 funciona, pero ping one.one.one.one falla → red OK, resolución DNS no.
Cómo se resuelve un nombre en Linux
En Linux, “resolver un nombre” no es un único componente: es una cadena. Entenderla te permite aislar el problema.
Flujo típico (simplificado):
- Tu aplicación (curl, apt, navegador) pide resolver un nombre.
- Llama a la librería del sistema (habitualmente glibc) vía getaddrinfo().
- glibc lee la política de resolución en /etc/nsswitch.conf (Name Service Switch).
- Según esa política, consulta fuentes como:
- files (por ejemplo /etc/hosts)
- dns (consultas DNS)
- mdns4_minimal/mdns (mDNS/Avahi para .local)
- resolve/systemd (integración con systemd-resolved)
- Si toca DNS, la consulta sale según lo que indique /etc/resolv.conf o el mecanismo configurado (por ejemplo systemd-resolved) hacia un servidor DNS.
- La respuesta vuelve (con o sin caché intermedia).
Documentación útil:
- resolv.conf: resolv.conf(5) en man7.org
- nsswitch.conf: nsswitch.conf(5) en man7.org
- getaddrinfo(3): getaddrinfo(3) en man7.org
nsswitch.conf: orden de búsqueda
Un ejemplo común:
hosts: files mdns4_minimal [NOTFOUND=return] dnsInterpretación:
- Primero files (o sea, /etc/hosts).
- Luego mDNS para .local.
- Si mDNS dice “no encontrado”, se corta (NOTFOUND=return) y no sigue a DNS.
- En el resto de casos, usa dns.
Errores típicos:
- Falta dns en la línea hosts: → “no resuelve nada” salvo lo que esté en /etc/hosts.
- Orden inesperado (dns files) → overrides locales ignorados o comportamientos raros.
/etc/hosts: atajo local
- Sirve para overrides rápidos.
- Si tienes una entrada errónea aquí, “DNS funciona”, pero tu sistema siempre irá a la IP equivocada.
/etc/resolv.conf: a quién se pregunta
Ejemplo:
nameserver 1.1.1.1
nameserver 8.8.8.8
search miempresa.local
options timeout:2 attempts:2En muchas distros modernas no es un archivo estático:
- Puede ser un symlink a un stub local (por ejemplo 127.0.0.53 de systemd-resolved).
- Puede ser generado por NetworkManager, resolvconf, dhclient, etc.
Por eso, editarlo “a mano” a menudo funciona un rato y luego se sobreescribe.
systemd-resolved: stub 127.0.0.53
En Ubuntu y otras distros, es común ver en /etc/resolv.conf:
- nameserver 127.0.0.53
Eso no significa que “tu DNS es 127.0.0.53”, significa que apuntas a un stub local y systemd-resolved decide el DNS upstream (router, corporativo, VPN, etc.).
Comandos clave:
resolvectl status
resolvectl query example.comFallos comunes y cómo arreglarlos
/etc/resolv.conf se sobreescribe
Síntoma: editas /etc/resolv.conf, funciona un rato, luego se revierte.
Arreglo recomendado: cambia DNS en el gestor correcto, no en el archivo.
Con NetworkManager (ejemplo):
nmcli con show
nmcli con mod "MiConexion" ipv4.dns "1.1.1.1 8.8.8.8" ipv4.ignore-auto-dns yes
nmcli con mod "MiConexion" ipv6.dns "2606:4700:4700::1111 2001:4860:4860::8888" ipv6.ignore-auto-dns yes
nmcli con up "MiConexion"Precaución: en redes corporativas/VPN, ignorar DNS automático puede romper acceso a recursos internos. Manual: nmcli en networkmanager.dev
systemd-resolved y el stub 127.0.0.53 “confunden”
Síntoma: /etc/resolv.conf muestra nameserver 127.0.0.53.
Diagnóstico real:
resolvectl statusArreglo: corrige el DNS upstream en la conexión (NetworkManager) o en la configuración de systemd-resolved.
Falta dns en nsswitch.conf
Síntoma: dig @1.1.1.1 example.com funciona, pero getent hosts example.com falla.
Revisa:
grep -E '^hosts:' /etc/nsswitch.confArreglo: asegúrate de que dns esté presente en la línea hosts: (el orden puede variar, pero debe existir).
DNS por VPN (split DNS) y nombres internos
Síntoma: intranet.empresa.local fuera de VPN no resuelve (NXDOMAIN). Dentro de VPN debería resolver, pero el sistema sigue usando DNS público.
Diagnóstico:
resolvectl status
nmcli dev showArreglo: ajustar prioridad de DNS en NetworkManager y evitar forzar DNS manual que pisa el DNS de la VPN.
Bloqueos de red/firewall en 53 (y diferencias UDP/TCP)
Síntoma: timeouts a servidores DNS.
Pruebas (pueden dar pistas, pero no validan DNS por sí solas):
nc -vz 1.1.1.1 53
nc -vz 8.8.8.8 53
dig +tcp @1.1.1.1 example.com A +time=2 +tries=1Arreglo: revisar firewall local (iptables/nftables/ufw) y políticas de red. En entornos corporativos, usar el DNS autorizado.
Problemas con IPv6
Síntoma: resuelves AAAA pero la conexión falla, o al revés.
dig example.com AAAA
curl -6 -I https://example.com
curl -4 -I https://example.comArreglo: forzar temporalmente IPv4 (curl -4) si IPv6 está roto, y evitar deshabilitar IPv6 globalmente sin entender el impacto.
Mini-guía de diagnóstico
Úsala como “primer barrido” antes de profundizar:
# 1) ¿hay red sin DNS?
ping -c 1 1.1.1.1
# 2) ¿resuelve el sistema vía NSS?
getent hosts example.com
# 3) ¿qué DNS usa realmente? (si hay systemd-resolved)
resolvectl status 2>/dev/null | sed -n '1,120p'
# 4) prueba DNS directo (sin depender del sistema)
(dig @1.1.1.1 example.com +time=2 +tries=1) 2>/dev/null | sed -n '1,25p'Comprender cómo funciona el DNS en Linux ayuda a detectar y solucionar muchos problemas de conectividad que, a simple vista, pueden parecer fallos de Internet. Revisar el estado de systemd-resolved, comprobar /etc/resolv.conf y usar herramientas como resolvectl, dig o nslookup permite identificar si el problema está en el servidor DNS, en la configuración local o en la red.
Dominar el diagnóstico DNS es clave para usuarios, administradores de sistemas y profesionales que trabajan con servidores Linux. Con una buena base, podrás resolver errores de nombres de dominio de forma más rápida y mantener una configuración de red más estable y fiable.
