Configura un servidor DNS con Bind9 en tu servidor Linux

Configura un servidor DNS con Bind9 en tu servidor Linux

Sergio De Luz

Los servidores DNS (Sistema de Nombres de Dominio) nos permiten llegar a una determinada dirección IP a partir de un nombre de dominio, de esta forma, podremos acceder a diferentes webs poniendo su nombre de dominio directamente en la barra de direcciones del navegador web. También tenemos la posibilidad de montar un servidor DNS en la red local doméstica o profesional, para llegar a los diferentes equipos de la red local a través de un nombre de dominio en concreto, sin necesidad de recordar siempre las direcciones IP privadas. Hoy en RedesZone os vamos a enseñar cómo podemos configurar un servidor DNS en un servidor Linux usando Bind9, el servidor DNS más popular y utilizado.

¿Qué es Bind?

Bind, o también conocido como Berkeley Internet Name Domain, es un software que se encarga de realizar la tarea de servidor DNS. Bind es actualmente un estándar, y es utilizado ampliamente en sistemas operativos Linux y también en Unix, por tanto, si tienes un servidor basado en Linux o Unix y necesitas un servidor DNS para gestionar las consultas de la red local, entonces Bind es lo que debes utilizar. La versión actual de Bind es la versión Bind9, y es la que se utiliza habitualmente en todos los servidores, las versiones anteriores se consideran inseguras y «deprecated», por lo que no es recomendable utilizarlas.

Bind no sustituye a servidores DNS como los que podemos usar de Google (8.8.8.8), Cloudflare (1.1.1.1) u otros, sino que se complementa con ellos. Los clientes de la red local tendrán como servidor DNS el servidor Bind que configuremos en un servidor Linux, posteriormente, en este Bind podremos configurar diferentes reglas para llegar a equipos locales a través de sus direcciones IP privadas. Si un cliente de la red local, realiza una petición DNS a una web de Internet, lógicamente el servidor DNS no tendrá en su base de datos todas las direcciones IP de Internet, en este caso, se configuran unos servidores DNS públicos para hacer frente a estas solicitudes, reenviando el servidor con Bind la petición y automáticamente se la devolveremos al cliente que ha realizado la petición.

DNS de Windows

La versión que se utiliza actualmente es Bind 9, fue escrito desde cero para evitar problemas de las versiones anteriores, además, incluye características muy importantes como DNSSEC para proporcionar seguridad a los dominios haciendo uso de criptografía, también incluye mejoras en el procesamiento en paralelo de diferentes consultas DNS, dispone de compatibilidad completa para redes IPv6 y mucho más. Por supuesto, esta última versión de Bind dispone de mejoras en la seguridad muy importantes, de esta forma, estaremos protegidos frente a los posibles ataques que podían ocurrir en las versiones anteriores.

Tipos de servidores BIND

Los equipos que están en internet, tienen una dirección IP que los identifica, aquí se incluyen todos los servidores en los que hay páginas web alojadas. Estas direcciones pueden ser complicadas de recordar si las tenemos que escribir cada vez que queremos acceder a la página, por lo cual se utilizan los nombres de dominio. La estructura de estos es de tipo árbol, donde nos encontramos una raíz o root, los dominios principales y los secundarios.

Si ponemos de ejemplo a los nombres de dominio FQDN (Fully Qualified Domain Name), están formados por el nombre del host, un nombre de dominio secundario y el nombre de dominio principal. Todo esto son secciones organizadas de forma jerárquica. Por ejemplo, si leemos un nombre de dominio como www.google.com, vemos un dominio primario que es .com, un dominio secundario que es google y el host que sería www.

Nos podemos encontrar muchos dominios primarios como:

  • org: Organizaciones sin ánimo de lucro.
  • com: Organizaciones lucrativas.
  • net: Organizaciones de Internet.
  • gob: Se trata de agencias gubernamentales.
  • es: Sufijo de España.

En este segmento, podemos encontrarnos cuatro tipos de servidores DNS:

  • Master: Es el encargado de alojar los registros primarios de una zona y responde a todas las peticiones de resolución de nombres como servidor. A mayores se encarga de delegar las copias a los servidores esclavos.
  • Slave: Su función es responder a las peticiones de resolución de nombres como servidor, las cuales se distribuyen los servidores primarios. Su función es más a niveles de seguridad, requiriendo al menos disponer de uno independientemente de la infraestructura principal.
  • Caching-only: También se encargará de las peticiones de resolución de nombres, pero en este caso no se trata de un servidor. Guarda las respuestas en la memoria por un determinado periodo de tiempo.
  • Forwarding: Su función es enviar las peticiones a una lista de servidores DNS.

¿Para qué necesito un servidor DNS local?

Si necesitas montar tu propio servidor de DNS local, es debido a que necesitas acceder a diferentes equipos de la red local a través de un nombre de dominio que hayas configurado. Cualquier empresa de cualquier tamaño necesitará instalar un servidor DNS para acceder de manera fácil y rápida a los diferentes ordenadores, ya sea para compartir archivos e incluso también para acceder a la intranet de la propia empresa.

Si en la empresa hay un servidor web con diferentes aplicaciones, es muy importante contar con un servidor de DNS local para que las demás aplicaciones y también los trabajadores puedan acceder a este servicio importante para la empresa, sin necesidad de recordar las direcciones IPv4 o IPv6. Además, el tener un nombre de dominio en lugar de una dirección IP también tiene sus ventajas:

  • No necesitamos recordar la dirección IP del servidor al que accedemos, esto es útil sobre todo si usamos direccionamiento IPv6 donde es mucho más complicado de recordar.
  • Si el servidor se cae, a nivel de DNS podemos apuntar hacia un servidor de «backup» que tengamos en la empresa. De cara a los compañeros que están trabajando esto hace que no tengan que introducir otra dirección IP, todo se hará a nivel de DNS de forma fácil y rápida.
  • Podemos emitir certificados digitales para los nombres de dominio, y tener comunicación HTTPS con seguridad. Aunque también se podría emitir certificados TLS para direcciones IP, es mejor hacerlo a nivel de DNS por si cambiamos el servidor.

Este servidor DNS lo podemos instalar en cualquier Windows Server utilizando su propio software, pero también en cualquier sistema operativo basado en Linux. En este tutorial vamos a ver cómo instalar Bind en cualquier sistema operativo basado en Linux. Generalmente para este tipo de usos, el sistema operativo Linux nos ofrece una mayor versatilidad y también seguridad.

Ventajas de un servidor BIND

  • Mejoras en el protocolo DNS: BIND puede soportar transferencias incrementales, donde un servidor DNS que actúa como esclavo, solo puede descargar las secciones actualizadas de una determinada zona, en un servidor DNS maestro. Este proceso requiere que toda la zona sea transferida a los servidores esclavos, siempre por el camino más corto. Pero si nos encontramos ante un dominio muy grande, con gran cantidad de archivos y con muchos servidores esclavos, estas mejoras hacen que los procesos de notificación y actualización no sean tan exigentes a nivel de recursos.
  • Vistas múltiples: BIND nos puede facilitar mucha información diferente según en que red se encuentre, y en la que se está realizando la petición. Esto ocurre para tener la capacidad de realizar negaciones de servicio, cuando se trata de acceder a un apartado confidencial por ejemplo, mientras que se siguen permitiendo las consultas desde los clientes dentro de una determinada red local.
  • Seguridad: Este nos aporta diferentes métodos para proteger las actualizaciones y las zonas de transferencia. La primera es DNSSEC, la cual permite realizar una firma con caracteres criptográficos, de forma que es posible verificar la información que llega desde un servidor, el cual realizó las firmas con una clave privada. Y la otra es TSIG, la cual permite la comunicación entre un servidor maestro y un esclavo, pero solo una vez se ha verificado que incorpora una llave la cual es compartida entre ambos equipos. Esto nos permite disponer de capas extra de seguridad. Pero si nos vamos a la versión 9 de BIND, también es capaz de soportar TKEY, el cual es otro método de autorización de transferencia, que usa una clave secreta compartida.
  • IPv6: BIND nos permite disponer de servicios de nombre de dominio con direcciones IPv6, con el uso de registros en zona A6.

Asegurar un servidor BIND

Cuando tratamos de asegurar un servidor BIND, las cosas a tener en cuenta no son muy diferentes a las que tenemos cuando tratamos de hacer más seguro cualquier otro tipo de servidor de nombres. Entre ellas podemos destacar:

  • Realizar una configuración del dominio por separado, puede ser apropiado para que este no resulte afectado desde el exterior por posibles ataques. Entre otras, establecer limitaciones en las zonas de transferencia o crear procesos automáticos para problemas y consultas que se puedan repetir de forma reiterada.
  • Crear limitaciones de acceso al servidor es uno de los procesos de seguridad más efectivos. Estas pueden ser desde ilimitadas para algunos usuarios como los administradores, a establecer un número de conexiones posibles para un espacio de tiempo determinado.
  • Los rangos también deben estar correctamente establecidos para cada usuario. Consiste en generar sólo los accesos necesarios para cada usuario que deba tener acceso al mismo.
  • La utilización de cifrados para las bases de claves, puede ser muy importante para tener controles de accesos. Para ellos podemos utilizar TSIG, el cual genera restricciones para las actualizaciones de las zonas dinámicas del servidor. Estas claves se pueden distribuir sin la necesidad de modificar ningún archivo de configuración en el servidor, lo cual ayuda a tener más capas de seguridad, y a la vez genera más facilidades a la hora de leer de nuevo todos los contenidos.

Por otro lado, generar restricciones de acceso de forma que solo sea visible lo que sea necesario, es una opción que ayuda a que muchos datos no queden visibles a todo usuario que accede. Para esto se pueden utilizar funciones como allow-transfer, allow-query o allow-recursive.

Como última recomendación, siempre es bueno utilizar versiones que se mantengan actualizadas y con los protocolos adecuados. La utilización de servicios poco fiables, tanto en el servidor como en los dispositivos que se conectan a este, puede generar muchos problemas de seguridad.

Riesgos de un servidor Bind9 inseguro

Hoy en día es muy importante establecer altos niveles de seguridad para evitar todos los problemas posibles. Pero siempre puede darse el caso de que por alguna brecha o fallo, nuestro servidor quede inseguro y se exponga a diferentes ataques.

Un ataque puede obtener mucha información sí se permiten las transferencia de zona. Esto incluye las listas de los hosts, enrutadores con las direcciones IP correspondientes, nombres y en algunas ocasiones comentarios que indican la situación de algo dentro del servidor.

Todo puede llevarnos a una denegación de servicio, por ejemplo, que es donde nuestros servidores DNS se caen. Esto implica que el sitio web ya no será accesible, puede darse el caso de que sea imposible realizar envíos por correo electrónico o que el atacante inicie un servidor falso, el cual puede establecerse como el propio y realizar envíos de información a internet. En este caso es cuando la seguridad se ha visto totalmente comprometida.

La pérdida de integridad es otro apartado importante. Pues si un atacante puede realizar cambios de datos o facilitar información falsa, puede ser una situación muy comprometida. Esto los puede llevar a crear falsificaciones de un sitio, a menudo tan bien logradas que no se puede ver la diferencia, y en este punto es donde se implica a los usuarios que accedan a dicha página falsa, donde pueden dar diferentes datos privados.

Esto puede comprometer también a un Firewall o a cualquier host que sea accesible desde internet, de forma que es posible autenticarse y crear diferentes relaciones de confianza que pueden comprometer más el sistema. En estos casos suele ocurrir cuando se utiliza un filtro de paquetes demasiado débil, lo cual no es recomendable pues está protegiendo a los servidores en internet y a su vez en la intranet si se da uso de una.

Requisitos previos antes de instalar Bind

Antes de empezar con la configuración del servidor DNS con Bind9 en nuestro sistema operativo, es recomendable poner IP fija en nuestro servidor, de lo contrario, si el servidor DHCP cambia nuestra dirección IP, los clientes de la red local perderán el acceso a nuestro servidor DNS porque no estarán «apuntando» a nuestra dirección IP privada. Para poner IP fija tenemos dos posibilidades:

  • Configurar el Static DHCP en el router/firewall que tengamos. Si eliges esta opción, tendrás que poner la dirección MAC de la tarjeta de red, ya sea cableada o inalámbrica. Lógicamente por temas de rendimiento se aconseja utilizar siempre la tarjeta de red Ethernet cableada. Además de la MAC, tendrás que indicar también la dirección IP privada que queramos que siempre tenga este servidor, de lo contrario, es posible que tengamos problemas si nos cambian la IP.
  • Configurar la dirección IP estática en nuestro servidor Linux. En este caso, el servidor DHCP del router/firewall debería tener un rango de DHCP que esté fuera de nuestra dirección IP privada que pongamos fija. No es recomendable poner una IP fija dentro del rango del servidor DHCP, porque podría proporcionar nuestra dirección IP a otro equipo, entonces tendríamos un conflicto grave de dirección IP.

Para configurar de forma estática una dirección IP en Linux, tenemos que editar el archivo de configuración «/etc/network/interfaces», esto lo podemos hacer con cualquier editor de texto como nano, vim e incluso con vi, y poner lo siguiente:

auto lo
iface lo inet loopback

auto ens33
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 192.168.1.2

A continuación, tenemos que reiniciar el servicio para aplicar los cambios correctamente (si hemos cambiado la IP que tenemos actualmente):

sudo service networking restart

Una vez que nuestra dirección IP de la red local sea fija, ya podremos instalar Bind.

Instalación de Bind en Linux y puesta en marcha

Lo primero que tenemos que hacer para configurar un servidor DNS (bind) en Linux es instalarlo desde los repositorios, nosotros vamos a instalar tanto el servidor DNS de Bind9 como también los paquetes sugeridos por el sistema operativo Debian, por tanto, deberemos poner en consola lo siguiente:

sudo apt install bind9 bind9-doc resolvconf python-ply-doc

Una vez que hayamos instalado todos los paquetes anteriores, tenemos que irnos al directorio del programa, que es donde tendremos que empezar a configurar los archivos necesarios:

cd /etc/bind/

Es recomendable acceder a este directorio como root (sudo su) para no tener problemas de permisos denegados cuando copiemos ficheros o modifiquemos los ya existentes, si hacemos un «ls -l» para listar todos los archivos que tenemos aquí, veremos lo siguiente:

Tal y como podéis ver, disponemos de una gran cantidad de archivos de configuración diferentes, cada uno de ellos está orientado específicamente a una tarea, en la documentación oficial de Bind9 podéis encontrar para qué sirve cada uno de ellos. Vamos a suponer a partir de ahora que siempre estás en modo super usuario (root) para editar o copiar los archivos sin restricciones.

Configurar los forwarders de Bind usando servidores DNS públicos

Lo primero que vamos a hacer es configurar unos servidores DNS de forwarding, es decir, los servidores DNS públicos para reenviar las consultas de cara a Internet. El archivo de configuración que se encarga de esta tarea es «named.conf.options», lo primero que hacemos es realizar una copia de seguridad del archivos, por si lo editamos mal y todo deja de funcionar:

cp /etc/bind/named.conf.options /etc/bind/named.conf.options.copia

Ahora editamos el fichero añadiendo los servidores DNS en la sección de forwarders, tal y como podéis ver aquí:

forwarders {
8.8.8.8;
1.1.1.1;
};

Quedaría de la siguiente forma:

Una vez que lo hayamos modificado, reiniciamos el servicio de Bind9 para comprobar que todo funciona correctamente y no devuelve ningún error:

sudo service bind9 restart

Ahora vamos a comprobar si están funcionando correctamente, para ello, ejecutamos un comando nslookup, y deberíamos ver que nuestro servidor DNS ha resuelto un dominio correctamente, en nuestro caso la dirección IP del servidor es la 192.168.231.130:

Una vez que tenemos configurado Bind para reenviar a los DNS públicos las resoluciones de las webs de Internet, vamos a ver cómo configurar para resolver dominios internos.

Configurar Bind para resoluciones locales

El archivo de configuración que debemos configurar ahora es named.conf.local, es recomendable realizar una copia de seguridad por si algo sale mal a la hora de configurarlo, para ello ejecutamos:

cp /etc/bind/named.conf.local /etc/bind/named.conf.local.copia

Una vez que hayamos realizado la copia de seguridad, tendremos que editar el arcihvo de configuración named.conf.local para proceder con la configuración. En este archivo de configuración tendremos que poner la zona a la que hacemos referencia, y también el archivo de configuración de bind que tiene todas las configuraciones, por tanto, podríamos dejarlo así:

zone "redlocal.com" {
type master;
file "/etc/bind/db.redlocal";
};

Es importante que el «file» haga referencia al fichero de configuración que importamos y que vamos a configurar ahora mismo.

Ahora tenemos que copiar la base de datos que tenemos en «db.local» darle el nombre de «db.redlocal» que hemos definido en el fichero anterior.

cp /etc/bind/db.local /etc/bind/db.redlocal

Ahora editamos este fichero de configuración que viene por defecto con mucha información, y lo adaptamos a nuestros intereses.

Lo primero que tenemos que hacer es modificar el SOA que viene en la parte superior por el nombre de dominio que hemos elegido de forma local, en este caso, sería «red.redlocal.com», después editaremos el fichero de configuración general con los dominios y subdominios que nosotros queramos. Nuestro archivo de configuración quedaría de la siguiente forma:

;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.redlocal.com. root.red.redlocal.com. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;

@ IN NS ns1.redlocal.com.
@ IN A 192.168.231.130
ns1 IN A 192.168.231.130
router IN A 10.11.1.1
pc1 IN A 10.11.1.2

Una vez que hemos guardado el fichero de configuración, comprobamos la sintaxis con el siguiente comando:

named-checkzone redlocal.com /etc/bind/db.redlocal

Ahora reiniciamos el proceso bind con el siguiente comando:

sudo service bind9 restart

Ya tenemos todo listo para empezar la batería de pruebas y comprobar que lo hemos hecho todo bien. Para comprobar que todo funciona bien, deberemos ejecutar los siguientes comandos:

host router.redlocal.com

Nos mostrará lo siguiente, la dirección IP del router:

root@bron-debian:/etc/bind# host router.redlocal.com
router.redlocal.com has address 10.11.1.1

También podremos hacer lo mismo con PC1:

host pc1.redlocal.com

Veremos esto:

root@bron-debian:/etc/bind# host pc1.redlocal.com
pc1.redlocal.com has address 10.11.1.2

Una vez que hemos conseguido resolver los dominios locales correctamente, devolviéndonos la dirección IP correspondiente, podemos hacer un ping sin problemas vía dominio:

root@bron-debian:/etc/bind# ping router.redlocal.com
PING router.redlocal.com (10.11.1.1) 56(84) bytes of data.
64 bytes from 10.11.1.1 (10.11.1.1): icmp_seq=1 ttl=128 time=0.413 ms
64 bytes from 10.11.1.1 (10.11.1.1): icmp_seq=2 ttl=128 time=0.401 ms
^C
--- router.redlocal.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 28ms
rtt min/avg/max/mdev = 0.401/0.407/0.413/0.006 ms

Ahora vamos a configurar la resolución inversa de dominios.

Resolución inversa de dominios

Ahora vamos a configurar el servidor DNS para que resuelva dominios a la inversa, poniendo la dirección IP y que nos diga a qué dominio pertenece dicha dirección IP. Para conseguir nuestro objetivo, deberemos añadir al fichero /etc/bind/named.conf.local que utilizamos anteriormente las líneas siguientes:

zone "192.in-addr.arpa" {
type master;
file "/etc/bind/db.192";
};

También deberemos copiar el archivo de configuración por defecto para editarlo. A partir del archivo db.127 creamos el db.192:

cp /etc/bind/db.127 /etc/bind/db.192

Una vez que lo hemos creado, basta con editarlo con la siguiente información:

;
; BIND reverse data file for local loopback interface
;
$TTL 604800
@ IN SOA ns1.redlocal.com. root.red.redlocal.com. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.redlocal.com.
ns1 IN A 192.168.231.130
130.231.168 IN PTR redlocal.com

Una vez que hemos guardado el fichero de configuración, comprobamos la sintaxis con el siguiente comando:

named-checkzone 192.168.231.130 /etc/bind/db.192

Nos debería salir algo como esto:

named-checkzone 168.192.in-addr.arpa db.192
zone 168.192.in-addr.arpa/IN: loaded serial 1
OK

Ahora reiniciamos el proceso bind con el siguiente comando:

sudo service bind9 restart

Y comprobamos que ha funcionado correctamente:

host 192.168.231.130

Otros servicios

Como ha podido ver, con BIND9 obtenemos una gran funcionalidad. Pero esto no es lo único que nos puede proporcionar el Internet Systems Consortium. Estos cuentan con otros servicios, que, si bien no son alternativos a BIND, cumplen otras funciones que son muy importantes a la hora de realizar toda la gestión de una red. Empezando por ISC DHCP, el cual es un servidor DHCP de código abierto. Este nos facilita un agente de retrasmisión y un software cliente para cubrir todas las necesidades que se pueda tener a la hora de realizar la asignación de las direcciones IP. Por lo cual, a nivel administrativo puede ser una herramienta que nos facilite mucho el trabajo.

Por otro lado, tenemos Kea DHCP. Esta herramienta que también distribuye ISC, nos ayuda a mantener dos distribuciones de servidor DHCP. Basadas en los mismos estándares, y con todas las funcionalidades con las que cuenta Kea DHCP e ISC DHCP. Todas las funciones que son las más solicitadas por ls clientes, se encuentran en este sistema. Este es mucho más nuevo, y está diseñado para ofrecer a los usuarios un entorno de red mucho mejor y más moderno.

¿Por qué elegir estos servicios?

El mercado está lleno de opciones alternativas a estas herramientas. Pero, al fin y al cabo, no todas son de la misma calidad. En muchas ocasiones buscamos software que tenga otras características, y eso está bien. Pero en el caso de las herramientas de ISC, podemos obtener algunas ventajas que creemos que son muy buenas. Estas son:

  • Tiene un código abierto de alta calidad.
  • Ofrecen un soporte profesional y adaptado en muchos casos. A pesar de la disponibilidad del código a los usuarios.
  • Cumplen con todas las normativas necesarias de los estándares técnicos. Los cuales garantizan la interoperabilidad en Internet.

Esperamos que os haya servido de ayuda este completo tutorial de Bind para montar vuestro propio servidor DNS localmente.

2 Comentarios