Inicio
» Cómo
»
Fallos en la búsqueda de DNS en Debian 12: Reparar systemd-resolved
Fallos en la búsqueda de DNS en Debian 12: Reparar systemd-resolved
Si Debian 12 muestra el mensaje "Error temporal en la resolución de nombres", compruebe el servicio de resolución, el /etc/resolv.confenlace y los servidores DNS que aparecen en la lista resolvectl, en ese orden. Reiniciar el servicio solo soluciona el problema si el servicio está detenido; un enlace roto o un servidor ascendente inaccesible requieren una solución diferente.
Estas instrucciones se aplican a los sistemas Debian 12 (Bookworm) configurados para usar systemd-resolved. Debian separó ese resolvedor en un paquete aparte y no lo estableció como predeterminado, como se explica en las notas de la versión de Debian 12. Si su instalación utiliza otro gestor de DNS, mantenga el control de dicho gestor en lugar de imponerle esta configuración.
1. Identificar dónde falla la resolución de nombres.
Comience con la ruta de red y la búsqueda del nombre de host. Ejecute los comandos localmente o en una terminal que permanezca abierta si cambia la red:
ip -br address
ip route
ping -c 2 1.1.1.1
resolvectl status
resolvectl query debian.org
getent ahosts debian.org
Una ruta predeterminada y una conexión IP numérica funcional sugieren que la máquina puede acceder a la red sin DNS. Un ping fallido por sí solo no demuestra una ruta rota: las redes pueden bloquear las respuestas de eco ICMP. Si la interfaz carece de una dirección o una ruta, corrija primero la conexión de red.
resolvectl statusMuestra los servidores DNS y los dominios asignados globalmente o a interfaces individuales. resolvectl queryPrueba el resolvedor systemd; getent ahostsprueba la ruta de búsqueda de nombre de host que suelen usar las aplicaciones Linux. Esta distinción ayuda a aislar el fallo.
Observación
Siguiente comprobación
No hay dirección ni ruta predeterminada
Corrija la configuración de la interfaz, la puerta de enlace o el DHCP antes de configurar el DNS.
resolvectlno puede conectarse a su servicio
Comprueba si systemd-resolvedestá instalado y en funcionamiento.
resolvectl queryfunciona, getentfalla
Inspeccione /etc/resolv.confla configuración de los hosts NSS.
Ambas búsquedas fallan con una ruta que funciona.
Inspeccione las direcciones DNS ascendentes, el enrutamiento DNS y el acceso del firewall.
Una vista de terminal agrupa la ruta de red predeterminada, la asignación del servidor DNS y una búsqueda de nombre de host a nivel de aplicación para un diagnóstico inicial.
2. Asegúrese de que systemd-resolved esté instalado y activo.
En Debian 12, la presencia de systemd no garantiza que el paquete de resolución independiente esté instalado. Compruebe el paquete y la unidad antes de modificar cualquier archivo DNS:
dpkg-query -W -f='${Status}\n' systemd-resolved
systemctl status systemd-resolved --no-pager
Si el paquete está instalado pero el servicio está inactivo, inícielo y habilítelo para futuros arranques:
Si falta el paquete, instálelo sudo apt install systemd-resolvedsolo después de tener acceso funcional al repositorio de paquetes. Su instalación cambia el control de /etc/resolv.conf, así que revise primero cualquier configuración de NetworkManager, VPN o DNS estático. Debian documenta este cambio de paquete en sus notas de actualización de Bookworm .
La pantalla de estado del servicio muestra dónde buscar la unidad cargada, el estado activo y los mensajes de inicio.
3. Repara el enlace del resolvedor solo si es incorrecto.
El stub estándar systemd-resolvedescucha en 127.0.0.53. Su archivo de compatibilidad recomendado es /run/systemd/resolve/stub-resolv.conf, que se puede enlazar desde /etc/resolv.conf. Primero, inspeccione su modo actual:
ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status
También se admite un enlace a /run/systemd/resolve/resolv.confotro modo, pero los programas que lo utilizan se comunican directamente con el servidor DNS principal en lugar de con el servidor local. No considere que ese enlace esté roto simplemente porque sea diferente. El manual del servicio systemd-resolved de Debian explica los modos compatibles.
Si utiliza intencionadamente el stub local, el servicio está en ejecución, el oyente del stub está habilitado y el existente /etc/resolv.conffalta, está huérfano o apunta a un resolvedor obsoleto, restaure el enlace recomendado. Primero, haga una copia de seguridad de un archivo o enlace existente; omita la copia si no existe ningún archivo:
No ejecute esa sustitución en un host donde otro servicio gestione intencionadamente la configuración /etc/resolv.conf. Una entrada local nameserver 127.0.0.53también requiere un oyente auxiliar en funcionamiento; simplemente escribir esa dirección no crea un servicio DNS. En una máquina remota, conserve un segundo método de acceso antes de editar la configuración del resolvedor.
La comprobación del enlace simbólico muestra el destino esperado cuando Debian se configura deliberadamente para usar el stub resuelto por systemd local.
4. Corrija un servidor DNS ascendente ausente o inaccesible.
Si resolvectl statusno se detecta un servidor DNS ascendente adecuado o si un servidor configurado es inaccesible, corrija el origen de dicha asignación. La configuración de DNS dinámico puede provenir de DHCP, NetworkManager, systemd-networkd o una VPN. Verifique qué interfaz tiene la ruta predeterminada y a qué servidor DNS pertenece dicha interfaz.
Para una breve prueba de diagnóstico en una red que permite DNS público, asigne resolutores públicos conocidos a esa interfaz. Reemplace ens33con la interfaz real de ip -br address:
sudo resolvectl dns ens33 1.1.1.1 1.0.0.1
resolvectl query debian.org
Cloudflare documenta esas dos direcciones como sus direcciones DNS públicas . El resolvectl dnscambio es una configuración en tiempo de ejecución; un administrador de red podría reemplazarla cuando se restablezca la conexión. Si la búsqueda ahora funciona, corrija la fuente DNS persistente en lugar de depender de este comando temporal.
Con NetworkManager, inspeccione la conexión activa nmcli connection show --activey ajuste la configuración DNS o el comportamiento DHCP de dicha conexión. Con systemd-networkd, coloque la DNS=configuración deseada en el .networkarchivo correspondiente y reinicie o reconfigure la red en un momento seguro. Consulte el manual de systemd.network de Debian y el manual de configuración de NetworkManager de Debian . Reconectar una interfaz administrada puede interrumpir una sesión SSH.
Para los nombres internos, utilice los servidores DNS de la organización o la VPN. No se puede asumir que los resolvedores públicos respondan a las zonas privadas; forzar todas las consultas a ellos puede provocar errores en el DNS dividido o revelar nombres de host internos. DNS=Las entradas globales resolved.confpueden funcionar junto con el DNS por enlace en lugar de reemplazarlo automáticamente; consulte el manual de Bookworm resolved.conf .
5. Vacíe la caché y confirme que ambas rutas de búsqueda funcionan.
Después de corregir el servicio, el enlace del resolvedor o la configuración ascendente, borre las respuestas almacenadas en caché y vuelva a realizar la prueba:
La reparación es efectiva cuando resolvectl queryse devuelven direcciones, getent ahostsregistros de direcciones y los servidores DNS previstos permanecen visibles tras la reconexión de la red. Los dos comandos prueban interfaces diferentes, por lo que el éxito en uno no implica que todas las aplicaciones estén reparadas. El manual de resolvectl de Debian documenta la consulta, el estado y el vaciado de la caché.
La vista final del terminal muestra las dos comprobaciones que deberían devolver registros de direcciones después de que se haya reparado la configuración DNS.
Si resolvectl queryla búsqueda se realiza correctamente pero getentsigue fallando, compruebe que haya grep "^hosts:" /etc/nsswitch.confun módulo NSS adecuado dnso instalado resolveen la ruta de búsqueda. Si ambas siguen fallando, revise el registro del resolvedor y cualquier restricción del firewall sobre el tráfico DNS, y luego pruebe con la dirección DNS corporativa, del enrutador o del proveedor. Una búsqueda exitosa aislada no es suficiente: repita las comprobaciones después de volver a conectarse y después de reiniciar el sistema para verificar que la solución sea permanente.