Qué hacer si falla la resolución DNS en un VPS (2026): lista de comprobación de systemd-resolved, resolvectl y resolv.conf

No adivines en el primer paso; haz directamente una prueba comparativa.

Primero haz ping a una IP:

ping -c 3 1.1.1.1

Luego haz ping a un dominio:

ping -c 3 example.com

Si la IP funciona y el dominio no, lo más probable es que sea un problema de resolución DNS.

Luego compara con curl:

curl -I https://1.1.1.1
curl -I https://example.com

https://1.1.1.1 puede dar un error TLS por discrepancia en el dominio del certificado, pero mientras pueda conectar con el otro extremo, la capa de red está más o menos intacta. Lo que realmente hay que mirar es si falla la resolución del dominio.

Si tienes dig instalado, es más directo:

dig example.com

Si el DNS predeterminado del sistema no resuelve, especifica un DNS público:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

Si dig @1.1.1.1 example.com resuelve y dig example.com no, el servicio DNS público no tiene problema y el fallo está en la configuración de resolución local de este VPS.

En sistemas como Ubuntu 20.04/22.04/24.04, el componente habitual es systemd-resolved. Primero mira el estado:

resolvectl status

Fíjate en varias partes:

• Si Global tiene DNS Servers
• Si la interfaz de red actual tiene DNS Servers
• Si DNSSEC es yes, no o allow-downgrade
• Si DNSOverTLS está activado
• Qué interfaz es el DefaultRoute actual

También puedes consultar un dominio directamente:

resolvectl query example.com

Si esto falla pero dig @1.1.1.1 example.com funciona, el problema se concentra en el resolver local o en la configuración DNS de la interfaz.

Luego mira el estado del servicio:

systemctl status systemd-resolved --no-pager

Mira los registros recientes:

journalctl -u systemd-resolved --since "30 minutes ago" --no-pager

Si estás diagnosticando una incidencia en producción, puedes verlo en tiempo real:

journalctl -u systemd-resolved -f

La documentación de diagnóstico de DNSSEC de Ubuntu también usa combinaciones de resolvectl, dig y journalctl para localizar problemas de resolución; este conjunto de comandos es mucho más fiable que "reinicia y prueba".

Mucha gente, la primera vez que ve solo esta línea en /etc/resolv.conf, cree que el DNS se ha roto:

nameserver 127.0.0.53

En realidad, esto suele ser el stub resolver local de systemd-resolved. Las aplicaciones envían las solicitudes DNS a 127.0.0.53 y systemd-resolved las reenvía al DNS upstream real.

Primero mira qué es realmente /etc/resolv.conf:

ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf

Uno de los casos normales habituales es que apunte a:

/run/systemd/resolve/stub-resolv.conf

que contiene:

nameserver 127.0.0.53

Algunos sistemas apuntan directamente a:

/run/systemd/resolve/resolv.conf

que contiene el DNS upstream real. Ambos modos pueden ser normales; lo clave es que coincida con la forma de gestión de red de tu sistema.

Lo realmente peligroso es:

• Que /etc/resolv.conf esté escrito a mano y se sobrescriba tras reiniciar
• Que el archivo apunte a una ruta inexistente
• Que nameserver esté configurado con una dirección interna inalcanzable
• Que solo haya DNS IPv6, pero la ruta IPv6 del VPS no funcione
• Que el panel, la VPN, Docker y cloud-init compitan por cambiar el DNS

Para fallos de DNS no ejecutes solo un comando. Puedes seguir este orden:

dig example.com
dig @127.0.0.53 example.com
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

Varios resultados son fáciles de interpretar:

Algunos proveedores de VPS o redes corporativas bloquean UDP 53; también puedes probar TCP:

dig +tcp @1.1.1.1 example.com

Si UDP falla y TCP funciona, sospecha del firewall, de la política del operador o de reglas locales.

Cuando el servicio en producción está dando errores, el objetivo es restaurar primero la resolución y luego buscar la causa raíz con calma.

Si conoces el nombre de la interfaz, por ejemplo eth0, puedes configurarlo temporalmente:

sudo resolvectl dns eth0 1.1.1.1 8.8.8.8
sudo resolvectl domain eth0 '~.'

Luego prueba:

resolvectl query example.com
dig example.com
curl -I https://example.com

Si la interfaz no se llama eth0, primero mira:

ip link
resolvectl status

Este tipo de configuración con resolvectl dns es más de tiempo de ejecución y sirve para emergencias. Para que sea permanente, todavía hay que tratarlo en netplan, NetworkManager, cloud-init o la configuración de red del sistema.

Si quieres deshacer la configuración temporal en la interfaz:

sudo resolvectl revert eth0

A veces no es que la configuración DNS esté completamente mal, sino que la caché o el estado de sondeo de características del servidor están anómalos.

Puedes limpiar la caché DNS:

sudo resolvectl flush-caches

Luego restablece el sondeo de características del servidor DNS:

sudo resolvectl reset-server-features

Y vuelve a consultar:

resolvectl query example.com

El manual oficial de resolvectl incluye operaciones como flush caches, reset server features, configurar DNS por interfaz y revertir la configuración de la interfaz. Durante el diagnóstico, usa primero estos comandos acotados; no empieces borrando archivos de configuración a lo loco.

Si el estado de systemd-resolved es anómalo, puedes reiniciarlo:

sudo systemctl restart systemd-resolved

Y mirar de inmediato:

systemctl status systemd-resolved --no-pager
resolvectl status
resolvectl query example.com

No se recomienda que reboot sea la primera reacción. Reiniciar todo el VPS interrumpe el negocio y, si /etc/resolv.conf o la configuración de netplan ya estaban mal, el problema sigue tras el reinicio.

Si se arregla tras reiniciar el servicio, también pregúntate: ¿por qué se rompió? ¿Fue la caché, el DNS upstream, el DNS entregado por DHCP, DNSSEC o alguna herramienta que cambió la configuración?

Muchos tutoriales te enseñan a hacer esto:

sudo nano /etc/resolv.conf

y luego escribir:

nameserver 8.8.8.8
nameserver 1.1.1.1

Puede funcionar un rato, pero a menudo lo sobrescriben NetworkManager, netplan, systemd-resolved, cloud-init o el cliente DHCP.

Si es solo una emergencia, puedes escribirlo temporalmente, pero debes saber que puede no persistir. Lo más estable es averiguar quién gestiona la red.

En Ubuntu lo habitual es netplan:

ls /etc/netplan/

Mira la configuración:

sudo cat /etc/netplan/*.yaml

Si es netplan, puedes configurar nameservers bajo la interfaz correspondiente, por ejemplo:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8

Tras modificarlo, comprueba primero y luego aplica:

sudo netplan try
sudo netplan apply

Cambiar netplan en un VPS remoto requiere mucho cuidado. netplan try te da la oportunidad de revertir; no te dejes fuera de línea directamente.

Muchos VPS escriben la configuración de red con cloud-init en el primer arranque. Si cambiaste netplan a mano y al cabo de un tiempo, tras reiniciar o reconstruir, se sobrescribe, revisa cloud-init.

Archivos habituales:

ls /etc/cloud/cloud.cfg.d/

Si claramente no quieres que cloud-init gestione la red, algunos sistemas usan una configuración similar a:

network: {config: disabled}

Pero no lo copies sin más. Las plantillas de los proveedores cloud son distintas, y desactivar la gestión de red de cloud-init puede afectar a cambios posteriores de IP, cambio de tarjeta de red o reconstrucción de la instancia. Antes de tocar esto en una máquina de producción, confirma la documentación del proveedor cloud y la configuración de red actual.

Para un usuario normal, lo más seguro es: primero averiguar si el DNS viene de DHCP, netplan, NetworkManager o cloud-init, y luego decidir dónde cambiarlo.

Si solo fallan dominios concretos y los resultados de DNS públicos no coinciden, puedes sospechar de DNSSEC, del DNS autoritativo o de la caché.

Mira el estado de resolved:

resolvectl status

Mira los registros relacionados con DNSSEC:

journalctl -u systemd-resolved --since "30 minutes ago" --no-pager

Usa dig para ver la información de DNSSEC:

dig example.com +dnssec

Luego especifica distintos upstreams:

dig @1.1.1.1 example.com +dnssec
dig @8.8.8.8 example.com +dnssec

Si solo falla al activar la validación DNSSEC, puede que la configuración DNSSEC del dominio esté rota, o que la red intermedia o el DNS upstream tengan soporte incompleto.

No se recomienda desactivar todo DNSSEC a largo plazo por un solo dominio. Lo mejor es confirmar primero si es un problema del DNS autoritativo del dominio y luego decidir si degradar temporalmente.

Que el host resuelva no significa que el contenedor también lo haga.

Entra al contenedor para probar:

docker exec -it 容器名 sh
nslookup example.com
cat /etc/resolv.conf

Docker genera por defecto su propio /etc/resolv.conf para los contenedores. Si el contenedor no se actualiza tras un cambio de DNS en el host, o si el daemon de Docker tiene configurado un DNS incorrecto, las aplicaciones dentro del contenedor darán Could not resolve host.

Puedes ver la configuración del daemon de Docker:

sudo cat /etc/docker/daemon.json

Si quieres fijar el DNS para Docker, una forma habitual es:

{
  "dns": ["1.1.1.1", "8.8.8.8"]
}

Tras modificarlo hay que reiniciar Docker:

sudo systemctl restart docker

Nota: reiniciar Docker afecta a los contenedores; en producción hay que programar una ventana.

BT Panel, 1Panel, clientes VPN, herramientas de proxy y herramientas de penetración de intranet pueden cambiar el DNS o las rutas.

Al diagnosticar, mira los cambios recientes:

stat /etc/resolv.conf
ls -lt /etc/netplan/
journalctl --since "2 hours ago" --no-pager | grep -i dns

Si el fallo ocurrió después de instalar una VPN, cambiar un grupo de seguridad, instalar un panel o ajustar la red de Docker, revisa primero ese cambio. Los problemas de DNS a menudo no son "se rompió de repente", sino que alguna herramienta te cambió la configuración de red.

Si producción está caída, sigue este orden:

1. ping -c 3 1.1.1.1 para ver si la IP funciona
2. ping -c 3 example.com para ver si falla la resolución del dominio
3. dig @1.1.1.1 example.com para verificar si el DNS público puede resolver
4. resolvectl status para ver el DNS y la interfaz actuales
5. readlink -f /etc/resolv.conf para ver a qué apunta resolv.conf
6. journalctl -u systemd-resolved --since "30 minutes ago" para ver los registros
7. sudo resolvectl flush-caches para limpiar la caché
8. sudo resolvectl reset-server-features para restablecer el estado de sondeo
9. sudo resolvectl dns eth0 1.1.1.1 8.8.8.8 para especificar DNS temporalmente
10. resolvectl query example.com para verificar la recuperación
11. Luego vuelve a corregir la configuración persistente de netplan / NetworkManager / cloud-init

La clave de este procedimiento es separar por capas primero: si la red funciona, si el resolver local está bien, si el DNS upstream puede resolver y si la configuración se sobrescribirá.

• La IP funciona y el dominio no, confirmando que es la dirección DNS
• dig @1.1.1.1 example.com puede verificar el DNS público
• resolvectl status mostró el DNS de la interfaz actual
• El estado del servicio systemd-resolved es normal
• /etc/resolv.conf apunta a algo razonable, sin enlaces rotos
• 127.0.0.53 es un stub resolver, no un error en sí mismo
• Se limpió la caché y se hizo reset server features
• La resolución se recuperó tras la configuración DNS temporal
• La configuración persistente se gestionó en netplan / NetworkManager / cloud-init
• También se probó por separado el DNS dentro de los contenedores Docker
• No se usó reboot para ocultar la causa raíz

Los fallos de DNS parecen misteriosos, pero en realidad se dividen en unas pocas capas: a quién pregunta la aplicación, a quién reenvía systemd-resolved, si el DNS upstream responde y si la configuración será sobrescrita por otras herramientas. Mientras la IP funcione, no te apresures a sospechar que todo el VPS está roto; primero revisa la cadena de resolución capa por capa.