¿Cómo configurar un resolvedor DNS de caché local con Unbound en Rocky Linux 10?

Linux CIBERED 2026
Linux / / 7 de septiembre de 2026

Cada vez que tu servidor necesita resolver un nombre de dominio, envía una solicitud DNS a otro resolvedor. Si pregunta por los mismos dominios una y otra vez, esas solicitudes repetidas tienen que viajar por la red, aunque la respuesta probablemente no haya cambiado.

Por ejemplo, imagina una aplicación web que se conecta a tres APIs externas cada vez que alguien visita tu sitio. Si tu servidor maneja miles de solicitudes al día, termina realizando esas mismas búsquedas DNS miles de veces. Eso es tráfico de red innecesario y añade una pequeña latencia a cada solicitud.

Un resolvedor DNS local con caché resuelve este problema almacenando registros DNS usados recientemente y reutilizándolos hasta que caducan. En Rocky Linux 10, puedes configurar uno con Unbound en unos diez minutos.

Unbound es un resolvedor DNS recursivo, validante y ligero desarrollado por NLnet Labs. A diferencia de BIND o PowerDNS, no está diseñado para alojar zonas DNS. Su trabajo principal es resolver consultas DNS, almacenar los resultados en memoria caché y devolver respuestas cacheadas instantáneamente cuando se solicita el mismo dominio de nuevo.

Los pasos de esta guía funcionan igual en Rocky Linux 10, RHEL 10 y AlmaLinux 10. Las tres distribuciones proporcionan el mismo paquete unbound a través de dnf, usan los mismos archivos de configuración y se comportan casi de forma idéntica una vez que el servicio está instalado y en funcionamiento.

Escenario de laboratorio

Para esta guía, usaremos dos sistemas Rocky Linux 10:

  • Servidor DNS: 192.168.1.50 (resolver.tecmintlocal.com)
  • Máquina cliente: 192.168.1.75 (app01.tecmintlocal.com)

El servidor DNS ejecutará Unbound, mientras que el cliente lo usará para las búsquedas DNS.

Antes de instalar cualquier cosa, asegúrate de que el servidor DNS tenga el nombre de host correcto y una dirección IP estática. Dado que los clientes siempre se conectarán a este servidor para las consultas DNS, su IP debe permanecer igual. Si cambia, los clientes no podrán alcanzar el resolvedor hasta que se actualicen sus configuraciones DNS.

Ejecuta los siguientes comandos en el servidor DNS para verificar su nombre de host y dirección IP:

hostnamectl
ip -4 addr show

Deberías ver el nombre del servidor establecido como resolver.tecmintlocal.com y la interfaz de red con la IP 192.168.1.50. Si tu entorno usa valores diferentes, reemplaza los nombres e IPs a lo largo de esta guía por los tuyos.

Paso 1: Instalar Unbound

Comienza actualizando los paquetes del sistema y luego instala Unbound junto con el paquete bind-utils.

sudo dnf update -y
sudo dnf install -y unbound bind-utils

El paquete bind-utils incluye el comando dig, que es una de las herramientas más útiles para probar DNS. Lo usaremos más adelante para verificar que Unbound está resolviendo consultas correctamente y sirviendo resultados en caché.

Antes de hacer cualquier cambio, es buena idea hacer una copia de seguridad del archivo de configuración por defecto de Unbound. Si accidentalmente cometes un error al editar la configuración, puedes restaurar el archivo original rápidamente en lugar de reinstalar el paquete.

sudo cp /etc/unbound/unbound.conf /etc/unbound/unbound.conf.orig

Paso 2: Configurar Unbound

Abre el archivo de configuración de Unbound en tu editor de texto preferido.

sudo vi /etc/unbound/unbound.conf

Dentro de la sección server:, añade o actualiza las siguientes opciones:

server:
    interface: 192.168.1.50
    interface: 127.0.0.1
    port: 53

    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    access-control: 127.0.0.0/8 allow
    access-control: 192.168.1.0/24 allow
    access-control: 0.0.0.0/0 refuse

    hide-identity: yes
    hide-version: yes

    verbosity: 1
    logfile: "/var/log/unbound.log"
    use-syslog: no

Esto es lo que hacen estas opciones:

  • interface especifica las direcciones IP donde Unbound escucha las solicitudes DNS. En este ejemplo, escucha en la IP LAN del servidor (192.168.1.50) y en la dirección loopback local (127.0.0.1), lo que permite que tanto el propio servidor como otras máquinas de tu red local usen el resolvedor.
  • do-ip4, do-udp y do-tcp habilitan IPv4 y permiten que Unbound acepte consultas DNS sobre UDP y TCP, que son los protocolos de transporte DNS estándar.
  • access-control determina qué clientes pueden usar tu servidor DNS. Aquí, solo la máquina local y los dispositivos en la red 192.168.1.0/24 pueden enviar consultas DNS.
  • hide-identity y hide-version evitan que Unbound revele su identidad y número de versión cuando alguien realiza consultas DNS especiales. Aunque no son esenciales, estas opciones proporcionan un pequeño beneficio de seguridad al exponer menos información sobre tu servidor.
  • verbosity, logfile y use-syslog controlan el registro. Establecer verbosity a 1 proporciona registros operativos básicos, y guardarlos en un archivo de registro dedicado facilita la resolución de problemas.
💡 Nota: En Rocky Linux 10, Unbound soporta validación DNSSEC de fábrica. Valida automáticamente las respuestas DNS firmadas usando el ancla de confianza raíz, por lo que no necesitas configuración DNSSEC adicional en la mayoría de los casos.

Configurar reenviadores (forwarders)

Por defecto, Unbound puede realizar búsquedas DNS recursivas completas contactando a los servidores raíz. Para muchos entornos, es más sencillo y a menudo más rápido reenviar las solicitudes a proveedores DNS ascendentes de confianza.

Añade la siguiente sección al final del archivo de configuración:

forward-zone:
    name: "."
    forward-addr: 1.1.1.1
    forward-addr: 9.9.9.9

En este ejemplo:

  • 1.1.1.1 es el servidor DNS público de Cloudflare.
  • 9.9.9.9 es el servidor DNS público de Quad9.

Si el primer servidor no está disponible, Unbound intenta automáticamente con el siguiente.

Paso 3: Resolver conflictos del puerto 53

Antes de iniciar Unbound, asegúrate de que ningún otro servicio esté usando el puerto 53, que es el puerto estándar para DNS.

En Rocky Linux, systemd-resolved está habilitado por defecto y a menudo crea un escucha stub DNS local en 127.0.0.53:53. Si ese puerto ya está en uso, Unbound no podrá iniciarse.

Para comprobar qué servicio está usando el puerto 53, ejecuta:

sudo ss -tulpn | grep :53

Si ves systemd-resolved escuchando en el puerto 53, desactiva solo su escucha stub DNS. Esto libera el puerto para Unbound y permite que systemd-resolved continúe manejando otras funciones del sistema.

Crea un archivo de configuración con el siguiente ajuste:

sudo mkdir -p /etc/systemd/resolved.conf.d
echo -e "[Resolve]\nDNSStubListener=no" | sudo tee /etc/systemd/resolved.conf.d/no-stub.conf
sudo systemctl restart systemd-resolved

Después de reiniciar el servicio, comprueba el puerto 53 de nuevo:

sudo ss -tulpn | grep :53

Si nada está escuchando en el puerto 53, Unbound podrá enlazarse a él cuando inicies el servicio en el siguiente paso.

⚠️ Consejo: Si otro servicio DNS como BIND (named) o dnsmasq está usando el puerto 53, detén o reconfigura ese servicio antes de iniciar Unbound. Solo una aplicación puede escuchar en la misma dirección IP y puerto a la vez.

Paso 4: Validar e iniciar Unbound

Antes de iniciar el servicio, comprueba el archivo de configuración en busca de errores de sintaxis. Esto ayuda a detectar cualquier error antes de que Unbound intente cargar la configuración.

sudo unbound-checkconf

Si la configuración es válida, el comando devuelve:

unbound-checkconf: no errors in /etc/unbound/unbound.conf

Si ves mensajes de error, Unbound normalmente te dirá el número de línea donde ocurrió el problema. Abre el archivo de configuración, corrige el error y ejecuta el comando de nuevo hasta que no se reporten errores.

Una vez que la configuración pasa la validación, inicia el servicio Unbound y habilítalo para que se inicie automáticamente cada vez que el sistema arranque:

sudo systemctl enable --now unbound

Luego, verifica que el servicio esté corriendo:

sudo systemctl status unbound

Si todo funciona correctamente, deberías ver el servicio en estado active (running).

● unbound.service - Unbound DNS server
     Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled)
     Active: active (running) since ...

Si el servicio falla al iniciar, revisa la salida de estado en busca de mensajes de error. También puedes consultar el archivo de registro que configuraste anteriormente o ver el journal del sistema para obtener información más detallada:

sudo journalctl -u unbound --no-pager

Paso 5: Permitir tráfico DNS a través del firewall

Si firewalld está habilitado, necesitarás permitir el tráfico DNS entrante para que otros sistemas de tu red puedan usar el servidor Unbound.

Ejecuta los siguientes comandos:

sudo firewall-cmd --add-service=dns --permanent
sudo firewall-cmd --reload

Para verificar que la regla se ha añadido correctamente, ejecuta:

sudo firewall-cmd --list-services

Si todo está configurado correctamente, deberías ver dns listado junto con otros servicios ya permitidos, por ejemplo:

cockpit dhcpv6-client dns ssh

En este punto, tu firewall está configurado para aceptar solicitudes DNS de los clientes permitidos por tu configuración de Unbound.

Paso 6: Verificar que el caché DNS funciona

Ahora es momento de confirmar que Unbound realmente está cacheando respuestas DNS. Desde el servidor DNS, consulta un dominio usando dig y apúntalo directamente a tu servidor Unbound:

dig tecmint.com @192.168.1.50

Busca el campo Query time en la salida. La primera búsqueda suele tardar más porque Unbound tiene que contactar a los servidores DNS ascendentes para resolver el dominio.

Por ejemplo:

;; Query time: 68 msec
;; SERVER: 192.168.1.50#53(192.168.1.50)

Ahora ejecuta el mismo comando de nuevo:

dig tecmint.com @192.168.1.50

Esta vez, la respuesta debería ser mucho más rápida porque Unbound puede devolver la respuesta desde su caché en lugar de realizar otra búsqueda DNS externa.

Por ejemplo:

;; Query time: 0 msec
;; SERVER: 192.168.1.50#53(192.168.1.50)

Los tiempos de consulta exactos variarán según tu red y los servidores DNS ascendentes, pero la segunda búsqueda debería ser notablemente más rápida que la primera. Un tiempo de consulta de 0 ms o 1 ms es común cuando la respuesta se sirve desde la caché local.

También puedes probar con otros dominios:

dig google.com @192.168.1.50
dig github.com @192.168.1.50

Ejecuta cada comando dos veces y compara los tiempos de consulta. La primera búsqueda recupera el registro DNS del resolvedor ascendente, mientras que la segunda normalmente se sirve directamente de la caché de Unbound, demostrando que el caché DNS funciona como se espera.

Paso 7: Configurar un cliente para usar el servidor DNS Unbound

Con el servidor DNS en funcionamiento, el último paso es configurar una máquina cliente para usarlo en las búsquedas DNS.

Si estás usando NetworkManager, establece tu servidor Unbound (192.168.1.50) como el servidor DNS preferido para la conexión de red.

Primero, lista las conexiones de red disponibles:

nmcli connection show

Anota el nombre de la conexión activa (por ejemplo, “Wired connection 1”), luego ejecuta:

sudo nmcli connection modify "Wired connection 1" ipv4.dns "192.168.1.50"
sudo nmcli connection modify "Wired connection 1" ipv4.ignore-auto-dns yes
sudo nmcli connection up "Wired connection 1"

Estos comandos configuran el cliente para usar tu servidor Unbound en lugar de los servidores DNS proporcionados automáticamente por tu router o DHCP.

Muestra el contenido de /etc/resolv.conf:

cat /etc/resolv.conf

Deberías ver tu servidor Unbound listado, por ejemplo:

nameserver 192.168.1.50

Ahora prueba la resolución DNS desde el cliente:

dig google.com

En la salida, busca el campo SERVER. Debería mostrar tu servidor Unbound:

;; SERVER: 192.168.1.50#53(192.168.1.50)

También puedes probar con algunos dominios adicionales:

dig github.com
dig tecmint.com

Si las consultas se completan correctamente y el campo SERVER apunta a 192.168.1.50, tu cliente ya está usando Unbound como su resolvedor DNS.

De ahora en adelante, las búsquedas DNS repetidas de los mismos dominios se servirán desde la caché de Unbound siempre que sea posible, reduciendo los tiempos de búsqueda y minimizando las solicitudes innecesarias a los servidores DNS ascendentes.

Gestión y solución de problemas de Unbound

Un puñado de comandos unbound-control cubren la mayoría del mantenimiento diario.

  • sudo unbound-control status muestra tiempo de actividad, versión y si el servidor está respondiendo consultas.
  • sudo unbound-control stats_noreset | grep total muestra el total de consultas manejadas y los aciertos de caché sin reiniciar los contadores.
  • sudo unbound-control dump_cache > /tmp/dns_cache_backup.txt escribe la caché completa en un archivo, útil antes de un reinicio planificado.
  • sudo unbound-control lookup tecmint.com muestra qué reenviador respondió a un dominio específico y si está actualmente en caché.
  • sudo unbound-control flush tecmint.com elimina un solo registro en caché sin tocar nada más.
  • sudo unbound-control flush_zone tecmintlocal.com borra todos los registros en caché bajo una zona específica, útil cuando acabas de cambiar registros DNS internos y no quieres esperar al TTL.

Si un cliente informa que no puede resolver nada, primero revisa journalctl -u unbound -f, porque la mayoría de las fallas se remontan a que la lista de control de acceso no incluye la subred del cliente o a que la zona de reenvío apunta a un resolvedor ascendente inaccesible desde tu red.

🔴 Advertencia: Nunca configures access-control: 0.0.0.0/0 allow en un servidor con IP pública. Eso convierte a Unbound en un resolvedor abierto que cualquier persona en Internet puede abusar para ataques de amplificación DNS contra un tercero.

Conclusión

Has configurado Unbound como un resolvedor DNS local con caché en Rocky Linux 10. A partir de ahora, las solicitudes DNS repetidas para los mismos dominios se sirven directamente desde la caché local en lugar de enviarse a servidores DNS ascendentes cada vez.

Esto reduce los tiempos de búsqueda DNS, disminuye el tráfico de red innecesario y puede mejorar la capacidad de respuesta de las aplicaciones que acceden con frecuencia a los mismos servicios externos.

Unbound es una herramienta ligera y segura que se integra perfectamente en entornos RHEL. Con la configuración descrita, tendrás un resolvedor eficiente y controlado que beneficiará a toda tu red local.

Vistas: 0

Descubre más desde CIBERED

Suscríbete y recibe las últimas entradas en tu correo electrónico.

Scroll al inicio