Unbound puede estar activo en systemctl y no servir para ninguna consulta del puesto. En una VM Debian o Ubuntu, el síntoma es banal: el servicio funciona, pero las consultas DNS siguen siendo lentas, o una aplicación no resuelve nada.
Antes de modificar /etc/resolv.conf o de alterar systemd-resolved, primero realiza un diagnóstico local. Verifica la configuración y el puerto, luego consulta a Unbound directamente. El DNS del sistema permanece en su lugar durante estas comprobaciones.
Leer la configuración antes de tocar el puerto 53
En Debian y Ubuntu, la configuración principal pasa a menudo por /etc/unbound/unbound.conf, con inclusiones en /etc/unbound/unbound.conf.d/. No partas del principio de que Unbound escucha en 127.0.0.1:53.
El puerto 53 puede estar ya ocupado por systemd-resolved, dnsmasq o BIND. El riesgo es sencillo: al cambiar el resolvedor del sistema demasiado pronto, puedes cortar la resolución DNS del puesto mientras Unbound no escucha en el lugar correcto.
sudo unbound-checkconf /etc/unbound/unbound.conf
sudo unbound-checkconf -o interface /etc/unbound/unbound.conf
sudo unbound-checkconf -o port /etc/unbound/unbound.conf
sudo ss -lntup 'sport = :53'unbound-checkconf lee la configuración y devuelve un error si una directiva bloquea la carga. Según la página de manual oficial, un código de retorno 0 valida el archivo. Las opciones -o interface y -o port muestran los valores efectivos.
ss muestra el proceso que realmente está escuchando. Si ves 127.0.0.53:53 por parte de systemd-resolved cuando Unbound debe responder en 127.0.0.1:53, tienes un conflicto concreto que resolver.
Antes de una modificación, mantén una copia legible del archivo principal:
sudo cp -a /etc/unbound/unbound.conf /etc/unbound/unbound.conf.before-local-testConsultar a Unbound sin cambiar el DNS del puesto
Un servicio activo no es suficiente. Unbound puede estar escuchando en otra interfaz, usar otro puerto, o responder fallidamente porque los servidores aguas arriba o DNSSEC presentan problemas.
El estado del servicio y los registros del inicio en curso proporcionan la primera clasificación. Luego envía una consulta al resolvedor local, sin pasar por la configuración DNS del sistema:
sudo systemctl status unbound --no-pager
sudo journalctl -u unbound -b -n 50 --no-pager
dig @127.0.0.1 example.net A +noall +comments +answer
dig @127.0.0.1 example.net A +noall +statsAdapta 127.0.0.1 y añade -p 5335 si tu configuración muestra otro puerto. Una respuesta con status: NOERROR y una sección ANSWER prueba que Unbound ha respondido para ese nombre.
connection refused se refiere al servicio o al puerto. SERVFAIL indica que el demonio recibió la consulta, pero no pudo resolver el nombre. Los registros ayudan entonces a separar fallas de red, validación DNSSEC y configuración de los servidores aguas arriba.
Luego vuelve a enviar la misma consulta. Un tiempo más corto en la segunda pasada puede deberse a la caché de Unbound. Esta prueba no mide el rendimiento del resolvedor; solo confirma que estás hablando con la instancia correcta.
Conectar el resolvedor del sistema solo después de la prueba directa
Si dig @127.0.0.1 responde pero las aplicaciones aún fallan, Unbound probablemente no está en la cadena utilizada por el sistema. Lee esta cadena antes de modificar la red.
resolvectl statusmuestra los DNS conocidos por systemd-resolved.resolvectl query example.netprueba la resolución desde el resolvedor del sistema.cat /etc/resolv.confmuestra el archivo presentado a las aplicaciones clásicas.
En un servidor, mantendría Unbound en una dirección y un puerto documentados, y luego conectaría el resolvedor del sistema una vez que las pruebas directas estén validadas. En un puesto de trabajo, systemd-resolved puede mantenerse delante de Unbound si esta capa simplifica el Wi-Fi, el VPN o los perfiles de red.
Una prueba local no dice nada sobre la resolución pública del dominio. Antes de poner una aplicación detrás de un proxy inverso Caddy con HTTPS, verifica también la respuesta vista desde Internet.
La documentación unbound-checkconf cubre los controles de configuración. La guía oficial del resolvedor local detalla la integración con el sistema. Mantén la copia de seguridad mientras la prueba directa y la prueba del sistema no den el mismo resultado.