Introducción
Unbound es un servidor DNS de validación, recursivo y de almacenamiento en caché. Habiendo dicho eso, el servidor DNS independiente no se puede usar como un servidor DNS autorizado, lo que significa que no se puede usar para alojar registros de nombres de dominio personalizados. Como resultado, si su objetivo es construir un servidor DNS de reenvío o solo caché, Unbound puede ser su opción preferida, ya que hace precisamente eso y lo hace bien.
Objetivo
El objetivo es proporcionar una guía de instalación y configuración rápida y fácil de seguir para el servidor DNS de solo caché Unbound en Redhat 7 Linux. Al final de esta guía, podrá usar el servidor DNS independiente de todos los clientes en su red de área local.
Requisitos
Acceso privilegiado a su servidor Redhat 7 Linux con repositorios RedHat estándar configurados.
Dificultad
MEDIO
Convenios
- # – requiere que los comandos de Linux dados se ejecuten con privilegios de root, ya sea directamente como usuario root o mediante el uso de
sudocomando - $ – requiere que los comandos de Linux dados se ejecuten como un usuario normal sin privilegios
Instrucciones
Instalación de herramientas Unbound y DNS
En el primer paso, vamos a instalar el servidor DNS Unbound real, así como las herramientas de DNS que eventualmente se utilizarán para probar la configuración del servidor de solo caché de DNS. Dado que tiene su repositorio de Redhat configurado correctamente, puede instalar ambos ejecutando el siguiente comando de Linux:
# yum install unbound bind-utils
Configuración básica independiente
Ahora, vamos a realizar una configuración básica del servidor de almacenamiento en caché de Unbound DNS. Esto se hará editando el archivo de configuración de Unbound /etc/unbound/unbound.conf ya sea usando el editor de texto o usando un sed a continuación comandos Primero, use su editor de texto preferido para ubicar la línea # interface: 0.0.0.0 y descoméntelo eliminando el # inicial señal. Alternativamente, use el siguiente sed comando:
# sed -i '/interface: 0.0.0.0$/s/#//' /etc/unbound/unbound.conf
La configuración anterior le indicará al servidor DNS Unbound que escuche en todas las interfaces de la red local. Luego, permita que sus clientes LAN consulten el caché de Unbound. Localice la línea correspondiente, cambie la dirección IP de loopback predeterminada 127.0.0.0/8 a la dirección de trabajo neto de su LAN, por ejemplo. 10.0.0.0/24 :
FROM: access-control: 127.0.0.0/8 allow TO access-control: 10.0.0.0/24 allow
Lo anterior también se puede hacer por sed comando:
# sed -i 's/127.0.0.0\/8 allow/10.0.0.0\/24 allow/' /etc/unbound/unbound.conf
Configurar compatibilidad con DNSSEC
A continuación, instruimos al servidor DNS Unbound para que genere claves RSA a fin de proporcionar compatibilidad con DNSSEC:
# unbound-control-setup setup in directory /etc/unbound generating unbound_server.key Generating RSA private key, 1536 bit long modulus .................++++ .........++++ e is 65537 (0x10001) generating unbound_control.key Generating RSA private key, 1536 bit long modulus .........++++ ..................................++++ e is 65537 (0x10001) create unbound_server.pem (self signed certificate) create unbound_control.pem (signed client certificate) Signature ok subject=/CN=unbound-control Getting CA Private Key Setup success. Certificates created. Enable in unbound.conf file to use
Todo lo que queda es comprobar la configuración de Unbound:
# unbound-checkconf unbound-checkconf: no errors in /etc/unbound/unbound.conf
Habilitar e iniciar el servidor Unbound
En esta etapa, habilitaremos el servidor DNS independiente para que se inicie en el momento del arranque:
# systemctl enable unbound Created symlink from /etc/systemd/system/multi-user.target.wants/unbound.service to /usr/lib/systemd/system/unbound.service.
e iniciar el servicio real:
# service unbound start Redirecting to /bin/systemctl start unbound.service
Asegúrese de que el servidor DNS independiente se esté ejecutando comprobando su estado:
[root@localhost unbound]# service unbound status
Redirecting to /bin/systemctl status unbound.service
● unbound.service - Unbound recursive Domain Name Server
Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor preset: disabled)
Active: active (running) since Wed 2016-12-07 10:32:58 AEDT; 6s ago
Process: 2355 ExecStartPre=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS)
Process: 2353 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited, status=0/SUCCESS)
Main PID: 2357 (unbound)
CGroup: /system.slice/unbound.service
└─2357 /usr/sbin/unbound -d
Dec 07 10:32:57 localhost.localdomain systemd[1]: Starting Unbound recursive Domain Name Server...
Dec 07 10:32:57 localhost.localdomain unbound-checkconf[2353]: unbound-checkconf: no errors in /etc/unbound/unbound.conf
Dec 07 10:32:58 localhost.localdomain systemd[1]: Started Unbound recursive Domain Name Server.
Dec 07 10:32:58 localhost.localdomain unbound[2357]: Dec 07 10:32:58 unbound[2357:0] warning: increased limit(open files) from 1024 to 8266
Dec 07 10:32:58 localhost.localdomain unbound[2357]: [2357:0] notice: init module 0: validator
Dec 07 10:32:58 localhost.localdomain unbound[2357]: [2357:0] notice: init module 1: iterator
Dec 07 10:32:58 localhost.localdomain unbound[2357]: [2357:0] info: start of service (unbound 1.4.20).
Abrir puerto de cortafuegos DNS
Para permitir que sus clientes LAN locales se conecten a su nuevo servidor DNS de caché Unbound, deberá abrir un puerto DNS:
# firewall-cmd --permanent --add-service dns success # firewall-cmd --reload success
Todo listo, ahora estamos listos para la prueba.
Pruebas
Finalmente, hemos llegado a un punto en el que podemos realizar algunas pruebas básicas de nuestro nuevo servidor de caché de DNS sin límites. Para esto usamos dig comando que forma parte de bind-utils instalado previamente paquete para realizar algunas consultas de DNS. Primero, ejecute la consulta DNS en el servidor DNS actual:
# dig @localhost example.com ; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> @localhost example.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53485 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 86400 IN A 93.184.216.34 ;; Query time: 817 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Dec 07 10:40:46 AEDT 2016 ;; MSG SIZE rcvd: 56
Tenga en cuenta que el tiempo de consulta es más de 817 mseg. Dado que hemos configurado un servidor de caché de DNS, esta consulta ahora se almacena en caché, por lo que cualquier resolución de consulta de DNS posterior de ese mismo nombre de dominio será bastante instantánea:
# dig @localhost example.com ; <<>> DiG 9.9.4-RedHat-9.9.4-37.el7 <<>> @localhost example.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34443 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;example.com. IN A ;; ANSWER SECTION: example.com. 86272 IN A 93.184.216.34 ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Dec 07 10:42:54 AEDT 2016 ;; MSG SIZE rcvd: 56
Por último, ahora puede probar la configuración del servidor DNS de Ubound desde sus clientes LAN locales apuntándolos a la dirección IP de Unbound, por ejemplo. 10.1.1.45:
$ dig @10.1.1.45 example.com ; <<>> DiG 9.9.5-9+deb8u6-Debian <<>> @10.1.1.45 example.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 50494 ;; flags: qr rd ad; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; Query time: 0 msec ;; SERVER: 10.1.1.45#53(10.1.1.45) ;; WHEN: Wed Dec 07 10:45:43 AEDT 2016 ;; MSG SIZE rcvd: 12