Un resolvedor DNS local con cache en Unbound: access-control, reenvío y validación DNSSEC

Objetivo

Ejecutar Unbound como resolvedor DNS con cache y validación para un segmento de red: decidir quién puede consultarlo, si resuelve por recursión propia o reenvía las consultas a un resolvedor upstream, y confirmar que la validación DNSSEC está activa.

Requisitos previos

Unbound instalado; un segmento de red cuyos hosts apunten a este resolvedor; acceso saliente a internet (para la recursión) o a un resolvedor upstream (para el reenvío).

Pasos

1. En la cláusula server: de unbound.conf, añade una línea interface: con la dirección de la LAN (por defecto Unbound escucha solo en localhost) y restringe quién puede consultar mediante líneas access-control:, una por cada bloque de red más una acción. El bloque de red se indica como una dirección IP4 o IP6 con el tamaño añadido para un bloque de red sin clases; por defecto solo se permite localhost y se rechaza todo lo demás. refuse responde REFUSED; deny descarta la consulta sin responder. No establezcas un permiso general (allow) en una interfaz expuesta a internet, porque eso convierte el resolvedor en un resolvedor recursivo abierto que puede usarse para ataques de amplificación DNS.
2. Decide entre recursión y reenvío. Sin una cláusula forward-zone:, Unbound resuelve las consultas por sí mismo recorriendo la jerarquía DNS desde la raíz. Si añades una forward-zone: con name: "." y uno o varios destinos forward-addr:, las consultas se envían en cambio a un resolvedor recursivo upstream: esa lista de servidores de nombres se usa para reenviar las consultas, y Unbound sigue validando DNSSEC en las respuestas, siempre que el upstream devuelva los registros DNSSEC.
3. Mantén configurada la validación DNSSEC: define auto-trust-anchor-file: con una ruta en la que el usuario unbound pueda escribir (los paquetes de Debian y RHEL ya establecen una, inicializada con unbound-anchor). Contiene un ancla de confianza para la zona, que se mantiene al día mediante sondeos RFC 5011 realizados varias veces al mes, por lo que el resolvedor debe estar en línea con la frecuencia suficiente para actualizarla.
4. Antes de recargar, valida la sintaxis: unbound-checkconf comprueba el archivo de configuración del resolvedor DNS Unbound en busca de errores de sintaxis y de otro tipo, sin iniciar el demonio.
5. Recarga el resolvedor en ejecución como root (unbound-control reload, que además vacía la cache, o reiniciando el servicio). unbound-control requiere control-enable: yes en una cláusula remote-control:, y además claves TLS creadas una sola vez con unbound-control-setup o bien un control-interface local mediante socket Unix.
6. Para eliminar una entrada obsoleta o envenenada de la cache sin reiniciar: unbound-control flush <name> quita el nombre de la cache y abarca los tipos de registro más comunes en una sola llamada.

Resultado esperado

Las consultas de la red configurada se resuelven y se almacenan en cache; las que llegan desde fuera reciben REFUSED (o ninguna respuesta con deny); dig +dnssec sobre una zona validada muestra el indicador AD, y un dominio de prueba con DNSSEC deliberadamente roto no se resuelve, en lugar de devolver una respuesta falsificable.

Límites y base de verificación

unbound-checkconf detecta errores de sintaxis, no errores operativos como un destino de reenvío inalcanzable: prueba la resolución después de recargar, no solo la comprobación de la configuración. Una regla access-control demasiado amplia es una fuente habitual de abuso de resolvedores; revísala cada vez que el resolvedor pase a una red nueva. auto-trust-anchor-file exige que el resolvedor funcione de forma lo bastante continua para completar los sondeos de actualización de RFC 5011; un resolvedor que haya estado desconectado durante mucho tiempo puede necesitar que se reinicialice su ancla de confianza.