Configure Unbound como un servidor DNS de reenvío simple

En la parte 1 de este artículo, te presenté Sin consolidar, una excelente opción de resolución de nombres para laboratorios domésticos y entornos de red pequeños. Analizamos qué es Unbound y discutimos cómo instalarlo. En esta sección, trabajaremos en la configuración básica de Unbound.

Configuración básica

Primero busque y descomente estas dos entradas en unbound.conf:

interface: 0.0.0.0
interface: ::0

Aquí el 0 indica que aceptaremos consultas de DNS en todas las interfaces. Si tiene más de una interfaz en su servidor y necesita administrar dónde está disponible el DNS, debe poner la dirección de la interfaz aquí.

A continuación, es posible que deseemos controlar quién puede usar nuestro servidor DNS. Limitaremos el acceso a las subredes locales que usamos. Es una buena práctica básica ser específico cuando podemos:

Access-control: 127.0.0.0/8 allow  # (allow queries from the local host)
access-control: 192.168.0.0/24 allow
access-control: 192.168.1.0/24 allow

También queremos agregar una excepción para los dominios locales inseguros que no usan la validación de DNSSEC:

domain-insecure: "forest.local"

Ahora agregaré mi servidor BIND autoritativo local como una zona interna:

stub-zone:
        name: "forest"
        stub-addr: 192.168.0.220
        stub-first: yes

Si desea o necesita usar su servidor Unbound como un servidor autorizado, puede agregar un conjunto de entradas de zona local que se ven así:

local-zone:  “forest.local.” static

local-data: “jupiter.forest”         IN       A        192.168.0.200
local-data: “callisto.forest”        IN       A        192.168.0.222

Estos pueden ser cualquier tipo de registro que necesite localmente, pero nuevamente tenga en cuenta que dado que todos están en el archivo de configuración principal, puede configurarlos como áreas auxiliares si necesita registros autorizados para múltiples hosts (ver arriba).

Si fuera a usar este servidor Unbound como su servidor DNS autorizado, también querrá asegurarse de tener un root hints archivo, que es el archivo de zona para los servidores DNS raíz.

Obtener archivo de InterNIC. La forma más fácil es descargarlo directamente donde lo desee. Por lo general, prefiero seguir adelante y colocarlo donde están los otros archivos vinculados no vinculados /etc/unbound:

wget https://www.internic.net/domain/named.root -O /etc/unbound/root.hints

Luego agregue una entrada a su unbound.conf Para que Unbound sepa adónde va el archivo de pistas:

# file to read root hints from.
        root-hints: "/etc/unbound/root.hints"

Finalmente, queremos agregar al menos una entrada que le diga a Unbound dónde reenviar las solicitudes de recursividad. Tenga en cuenta que podríamos reenviar dominios específicos a servidores DNS específicos. En este ejemplo, solo voy a reenviar todo a algunos servidores DNS en Internet:

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

Ahora, para verificar la integridad, queremos ejecutar el unbound-checkconf comando, que comprueba la sintaxis de nuestro archivo de configuración. Luego arreglamos cualquier error que encontremos.

[[email protected] ~]# unbound-checkconf
/etc/unbound/unbound_server.key: No such file or directory
[1584658345] unbound-checkconf[7553:0] fatal error: server-key-file: "/etc/unbound/unbound_server.key" does not exist

Este error indica que aún no existe un archivo clave generado en el inicio, así que comencemos Unbound y veamos qué sucede:

[[email protected] ~]# systemctl start unbound

Si no se encontraron errores fatales, podemos continuar y hacer que se inicie de forma predeterminada cuando se inicie el servidor:

[[email protected] ~]# systemctl enable unbound
Created symlink from /etc/systemd/system/multi-user.target.wants/unbound.service to /usr/lib/systemd/system/unbound.service.

Y deberías estar listo. A continuación, apliquemos algunas de nuestras habilidades de resolución de problemas de DNS para ver si funciona correctamente.

Primero, necesitamos configurar nuestro sistema de resolución de DNS para usar el nuevo servidor:

[[email protected] ~]# nmcli con mod ext ipv4.dns 192.168.0.222
[[email protected] ~]# systemctl restart NetworkManager
[[email protected] ~]# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.0.222
[[email protected] ~]#

corramos dig y a ver a quien podemos ver:

[email protected] ~]# dig; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>>
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36486
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.                              IN      NS

;; ANSWER SECTION:
.                       508693  IN      NS      i.root-servers.net.
<snip>

¡Excelente! Recibimos una respuesta del nuevo servidor y nos envía de vuelta a los dominios raíz. No vemos ningún error hasta ahora. Ahora, para verificar en un localhost:

;; ANSWER SECTION:
jupiter.forest.         5190    IN      A       192.168.0.200

¡Estupendo! Recuperamos el registro A del servidor autorizado y la dirección IP es correcta. ¿Qué pasa con los dominios externos?

;; ANSWER SECTION:
tipstecnologicos.es.             3600    IN      A       209.132.183.105

¡Perfecto! Si lo volvemos a ejecutar, ¿lo sacaremos del caché?

;; ANSWER SECTION:
tipstecnologicos.es.             3531    IN      A       209.132.183.105

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

Tenga en cuenta el tiempo de consulta de 0 segundos: esto indica que la respuesta reside en el servidor de almacenamiento en caché, por lo que no fue necesario ir a preguntar a otro lado. Esta es la principal ventaja de un servidor de almacenamiento en caché local, como vimos anteriormente.

Envoltura

Aunque no hemos discutido algunas de las funciones más avanzadas disponibles en Unbound, una cosa que vale la pena mencionar es DNSSEC. DNSSEC se está convirtiendo en un estándar para los servidores DNS porque proporciona una capa adicional de protección para las transacciones de DNS. DNSSEC establece una relación de confianza que ayuda a prevenir cosas como la suplantación de identidad y los ataques de inyección. Vale la pena investigar un poco si está utilizando un servidor DNS público, aunque eso está más allá del alcance de este artículo.

Artículos de interés

Subir