En esta entrada veremos cómo instalar el servidor DNS Bind en Debian 9 Stretch paso a paso, de modo que proporcione resolución de nombres a tu red local o incluso aloje y resuelva los nombres de las máquinas de tu red.
Tabla de contenidos
Antes de instalar el servidor DNS en Debian 9 Stretch
Para seguir esta guía de instalación y configuración del servicio DNS Bind en Debian 9 debes satisfacer algunos requisitos básicos:
- Una máquina Debian 9 actualizada.
- Un usuario con privilegios de sudo o el mismo root.
- Conexión a Internet.
- Otras máquinas en la red local para probar el servicio.
Un servidor DNS según su configuración puede tener varios modos de funcionamiento. En este tutorial haremos que nuestra máquina Debian 9 resuelva nombres de Internet para sí misma y el resto de máquinas de la red local, pero también se comporte como servidor DNS primario del dominio de nuestra propia red local.
En este ejemplo configuraremos una red local con direcciones IP 192.168.0.0/255, con el dominio red.local y el servidor DNS será la máquina 192.168.0.100 con Debian 9.
Cómo instalar el servidor DNS en Debian 9 Stretch
Vamos a instalar el servidor DNS Bind en Debian 9 Stretch usando los paquetes presentes en la propia distribución, por lo que actualizaremos la información de los repositorios:
~$ sudo apt update
El paquete que necesitamos es bind9 así que lo descargaremos con apt, junto con el paquete dnsutils para tener la herramienta nslookup:
~$ sudo apt install -y bind9 dnsutils
Cuando terminen de descargar e instalarse los paquetes y sus dependencias tendremos un nuevo servicio disponible en nuestro sistema Debian 9, el servicio bind9.service o bind9 si prefieres el nombre corto.
El servicio bind9 queda habilitado para iniciar automáticamente junto a Debian 9, pero no arranca tras la instalación, ya que es necesario configurarlo previamente.
Configurar el firewall para el servidor DNS en Debian 9
Si tienes activado el firewall UFW en el servidor Debian 9 en el que estás instalando el servicio DNS, debes añadir una regla que permita la conexión de las máquinas cliente. Es tan sencillo como lanzar este comando:
~$ sudo ufw allow dns
Cómo configurar el servidor DNS Bind en Debian 9
Para configurar el servicio DNS Bind en Debian 9 debemos trabajar sobre los archivos del directorio /etc/bind/. El archivo principal named.conf sólo carga la configuración de otros archivos de configuración adicionales, que son:
- named.conf.options
- named.conf.local
- named.conf.default-zones
Cualquier cambio que hagamos en estos y otros archivos de configuración de Bind no se aplicará hasta recargar la configuración del servicio.
Configuración en los clientes
Entre los clientes también incluimos a la máquina Debian 9 que hará de servidor DNS, ya que además de ofrecer el servicio debe poder utilizarlo.
Para configurar las máquinas de tu red que usen Debian 9 u otros sistemas Linux, edita sus archivos resolv.conf:
~$ sudo nano /etc/resolv.conf
Asegúrate de desactivar cualquier directiva nameserver presente, insertando un carácter # a principio de línea, y añade otra directiva nameserver con la dirección IP del servidor Debian 9 en el que has instalado Bind:
... #nameserver 192.168.0.1 nameserver 192.168.0.100
Usa el comando ping para intentar resolver el dominio de Internet que prefieras:
~$ ping google.com ping: google.com: Fallo temporal en la resolución del nombre
No funciona, esto es buena señal porque el sistema intenta resolver nombres usando el servidor Debian 9 que aún no está listo.
Primer paso: Resolución de nombres de Internet
En un primer paso el servidor DNS resolverá nombres de Internet para sí mismo y para el resto de máquinas de la red local, así que tendremos que configurar este modo de funcionamiento.
Configuración del servicio Bind
Editaremos el archivo named.conf.options:
~$ sudo nano /etc/bind/named.conf.options
El contenido de este archivo es un bloque options dentro del cual debemos buscar la directiva dnssec-validation:
...
dnssec-validation auto;
...
En una red local privada no es posible aplicar esta capa de seguridad para el servicio DNS, así que habrá que cambiar el valor a «no«:
...
dnssec-validation no;
...
De esta forma Bind utilizará los servidores DNS raíz de Internet para las consultas para las que no tiene información propia. Es posible que algunas consultas puedan tardar más tiempo del habitual, incluso algunas no se resolverán sin configuraciones adicionales, así que es recomendable añadir un bloque forwarders en el que indicar servidores DNS caché públicos alternativos.
Localizamos el bloque forwarders:
...
// forwarders {
// 0.0.0.0;
// };
...
Está desactivado, así que lo activaremos e incluiremos los servidores DNS a los que solicitaremos la resolución de nombres:
...
forwarders {
8.8.8.8;
8.8.4.4;
};
...
En este caso hemos incluido los servidores DNS de Google, pero podrías incluir los servidores públicos que creas oportuno, incluyendo los de tu proveedor de servicios de Internet.
Una vez guardados los cambios podemos verificar que la configuración es correcta con el comando named-checkconf:
~$ sudo named-checkconf
Si no produce ningún tipo de salida es que todo está correcto.
Con una configuración sin errores, podemos iniciar por primera vez el servicio bind9:
~$ sudo systemctl start bind9
Ya podemos resolver nombres tanto en el servidor Debian 9 como desde cualquier máquina que lo use como servidor DNS. Prueba a resolver nombres tanto desde el servidor como desde el cliente:
~$ ping google.com PING google.com (172.217.16.238) 56(84) bytes of data. 64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_seq=1 ttl=52 time=14.4 ms 64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_seq=2 ttl=52 time=13.8 ms 64 bytes from mad08s04-in-f14.1e100.net (172.217.16.238): icmp_seq=3 ttl=52 time=29.8 ms ...
Segundo paso: Servidor DNS primario
Llega el momento de aprovechar el servidor DNS que ya tenemos funcionando para que resuelva los nombres de nuestra propia red local, que en este ejemplo tiene el dominio red.local.
Editamos el archivo named.conf.local para añadir al final dos zonas más:
~$ sudo nano /etc/bind/named.conf.local
Insertaremos la información de las zonas donde nos indican los comentarios, tras el bloque de comentarios «Do any local configuration here«:
// // Do any local configuration here // ...
Insertaremos una zona para la resolución de nombres directa, de nombre a dirección IP:
...
zone "red.local" {
type master;
file "/etc/bind/zones/db.red.local";
};
...
En file hemos indicado el archivo que contendrá los registros de la base de datos de nombres DNS para nuestro dominio, red.local.
Ahora, opcionalmente, insertaremos una zona para resolución inversa, de direcciones IP a nombres:
...
zone "0.168.192.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.0.168.192";
};
...
Guardamos los cambios y cerramos el archivo named.conf.local.
Ahora tenemos que crear los archivos de zona que acabamos de indicar en la configuración. El directorio que hemos indicado para guardar los distitntos archivos de zona en este ejemplo no existe, así que lo crearemos:
~$ sudo mkdir /etc/bind/zones
Resolución directa de nombres
Vamos a crear el archivo para la resolución directa de nombres, con el nombre que indicamos en named.conf.local:
~$ sudo nano /etc/bind/zones/db.red.local
Con un contenido similar a este:
$TTL 1D
@ IN SOA ns.red.local. root.red.local. (
0 ; número de serie
604800 ; refresco
86400 ; reintento
2419200 ; expiración
604800 ; Caché negativa TTL
)
@ IN NS ns.red.local.
ns.red.local. IN A 192.168.0.100
debian9.red.local. IN A 192.168.0.100
debian92.red.local. IN A 192.168.0.109
En el encabezado del registro SOA (Start Of Authority) indicamos el servidor DNS que se encarga de mantener estos registros, que es el mismo que estamos configurando (ns.red.local.) y la cuenta de correo electrónico del administrador (root.red.local.) sin la característica @. Observa que todos los nombres de dominio finalizan con un punto.
Otro campo importante del registro SOA es el que hemos identificado con el comantario «número de serie», que es un contador que debemos incrementar manualmente cada vez que hagamos modificaciones en los registros.
Tras el bloque sólo queda ir añadiendo los registros. El primero es un registro tipo NS para identificar el nombre del servidor DNS.
A continuación se añaden todos los demás registros que necesites, en este ejemplo son del tipo A que identifican máquinas de la red.
Guarda los cambios y comprueba que está todo correcto con el comando named-checkzone, que usa como parámetros un dominio y el archivo de zona que lo gestiona:
~$ sudo named-checkzone red.local /etc/bind/zones/db.red.local zone red.local/IN: loaded serial 0 OK
Debe informar del valor del número de serie (contador) actual y que no hay errores (OK).
Es el momento de recargar la configuración del servicio bind9:
~$ sudo systemctl reload bind9
Ahora, tanto en el servidor como en cualquier cliente puedes intentar resolver nombres que hayas dado de alta en el archivo de zona y deberías obtener respuesta:
~$ ping debian92.red.local PING debian92.red.local (192.168.0.109) 56(84) bytes of data. 64 bytes from 192.168.0.109: icmp_seq=1 ttl=64 time=0.475 ms 64 bytes from 192.168.0.109: icmp_seq=2 ttl=64 time=0.614 ms 64 bytes from 192.168.0.109: icmp_seq=3 ttl=64 time=0.492 ms ...
Resolución inversa de nombres
Si has decidido incorporar también la resolución inversa, que no es necesaria para el funcionamiento habitual de tu red, es el momento de configurarla.
La resolución inversa funciona solicitando al servidor DNS cuál es el nombre de red de una máquina a partir de una dirección IP. En el ejemplo anterior hicimos ping a una de las máquinas de la red por su nombre y, gracias al servidor DNS, se obtuvo su dirección IP.
Podríamos intentar lo contrario con la herramienta nslookup y la dirección IP obtenida:
~$ nslookup 192.168.0.109 Server: 192.168.0.100 Address: 192.168.0.100#53 ** server can't find 109.0.168.192.in-addr.arpa: SERVFAIL
La herramienta contacta con el servidor DNS en el puerto estándar, pero no consigue la resolución. En unos instantes esto cambiará.
En nuestro servidor DNS Debian 9 crearemos el archivo de zona que hayas especificado en named.conf.local:
~$ sudo nano /etc/bind/zones/db.0.168.192
El contenido es muy similar al del archivo de resolución directa:
$TTL 1D
@ IN SOA red.local. root.red.local. (
0 ; número de serie
604800 ; refresco
86400 ; reintentar
2419200 ; expiración
604800 ; TTL Caché negativa
)
; Servidores de nombres
IN NS ns.red.local.
; Registros PTR
100 IN PTR ns.red.local.
100 IN PTR debian9.red.local.
109 IN PTR debian92.red.local.
Guardados los cambios, comprueba que no haya errores con el comando named-checkzone (que también sirve para los archivos de resolución inversa):
~$ sudo named-checkzone 0.168.192 /etc/bind/zones/db.0.168.192 zone 168.192/IN: loaded serial 0 OK
Todo correcto, es el momento de recargar de nuevo la configuración del servicio Bind:
~$ sudo systemctl reload bind9
Y ahora podemos volver a utilizar el comando nslookup en cualquier máquina de la red que utilice el servidor DNS:
~$ nslookup 192.168.0.109 Server: 192.168.0.100 Address: 192.168.0.100#53 109.0.168.192.in-addr.arpa name = debian92.red.local.
¡Justo lo que queríamos!
Conclusión
Ahora ya sabes cómo instalar y configurar un servidor DNS Bind en Debian 9 Stretch, con lo que además de resolver nombres de Internet usando los servidores DNS que quieras (ya que a veces los de los provedores de Internet pueden caer), podrás usar dominios y subdominios en las máquinas de tu red y resolverlos fácilmente.
En caso de dudas, preguntas, sugerencias, etc. puedes dejar un comentario.
Y si ya tienes funcionando el servicio DNS gracias a nuestra guía de instalación de Bind en Debian 9 Buster, puedes hacerlo dejando una propina a partir de 1 $ para una CocaCola desde PayPal:
¡Gracias!
Muy buenas,
Seguí todos los pasos de tu artículo pero no tengo resolución interna.
Uso VMWare y he probado las conexiones NAT y bridge.
¿Sabrías a qué se debe?
Gracias.
¡Hola, José Miguel!
En principio si quieres resolver nombres en tu red lo lógico es usar el modo puente (para que la máquina virtual esté en la misma red que la máquina anfitrión y resto de máquinas de la red), ya que el modo NAT sólo serviría para otras máquinas en la misma red NAT (que serían invisibles para el resto de la red).
Dicho eso, desde la máquina cliente debería haber conectividad a nivel de ping con la máquina Debian 9 Stretch que hace de servidor DNS. Si ambas máquinas se ven, el siguiente paso es usar en la máquina cliente alguna herramienta como nslookup (si es un cliente Debian 9 Stretch ese comando se incluye en el paquete dnsutils).
La sintaxis sería algo como «nslookup NOMBRE-DNS SERVIDOR-DNS«, es decir el primer parámetro es el nombre que quieres resolver y el segundo la dirección IP del servidor DNS que quieres usar.
Por ejemplo, para resolver el dominio kernel.org con el servidor DNS de Cloudflare:
~$ nslookup kernel.org 1.1.1.1
Server: 1.1.1.1
Address: 1.1.1.1#53
Non-authoritative answer:
Name: kernel.org
Address: 139.178.84.217
Y, de igual modo, para resolver un nombre de red interna con un servidor DNS en la máquina 192.168.1.138:
~$ nslookup debian92.red.local 192.168.1.138
Server: 192.168.1.138
Address: 192.168.1.138#53
Name: debian92.red.local
Address: 192.168.1.150
En ambos casos hay conectividad desde la máquina cliente con el servidor 1.1.1.1 en Internet y con el servidor 192.168.1.138 de la red local.
Espero que esto te ayude a encontrar el problema.
No hay manera. Te doy las gracias y si tienes tiempo miras mi configuración. Le he dado mil vueltas a Internet. No hay firewall. Como ves resuelve correctamente direcciones externas. Gracias de nuevo.
root@srv:~# cat /etc/bind/named.conf
include «/etc/bind/named.conf.options»;
include «/etc/bind/named.conf.local»;
include «/etc/bind/named.conf.default-zones»;
root@srv:~# cat /etc/bind/named.conf.options
options {
directory «/var/cache/bind»;
forwarders {
8.8.8.8;
8.8.4.4;
};
forward first;
dnssec-validation no;
};
root@srv:~# cat /etc/bind/named.conf.local
zone «directa.redlocal» {
type master;
file «/etc/bind/db.redlocal»;
};
zone «1.168.192.in-addr.arpa» {
type master;
file «/etc/bind/db.inversa.redlocal»;
};
root@srv:~# cat /etc/bind/db.redlocal
$TTL 86400
@ IN SOA srv.lab.local. admin.lab.local. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ;
;
@ IN NS srv.lab.local.
srv IN A 192.168.1.100
maquina1 IN A 192.168.1.150
root@srv:~# cat /etc/bind/db.inversa.redlocal
$TTL 604800
@ IN SOA srv.lab.local. admin.lab.local. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS srv.lab.local.
100 IN PTR srv.lab.local.
150 IN PTR maquina1.lab.local.
root@srv:~# cat /etc/resolv.conf
# Generated by NetworkManager
search lab.local
nameserver 192.168.1.100
Interfaz del servidor
———————-
IP4.ADDRESS[1]: 192.168.1.100/24
IP4.GATEWAY: 192.168.1.1
IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt = 100
IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt = 100
IP4.DNS[1]: 192.168.1.100
Interfaz del cliente
——————–
IP4.ADDRESS[1]: 192.168.1.150/24
IP4.GATEWAY: 192.168.1.1
IP4.ROUTE[1]: dst = 192.168.1.0/24, nh = 0.0.0.0, mt >
IP4.ROUTE[2]: dst = 0.0.0.0/0, nh = 192.168.1.1, mt =>
IP4.DNS[1]: 192.168.1.100
Datos ping y nslookup
————————
root@srv:~# ping maquina1
ping: maquina1: Nombre o servicio desconocido
root@srv:~# ping -c4 192.168.1.150
PING 192.168.1.150 (192.168.1.150) 56(84) bytes of data.
64 bytes from 192.168.1.150: icmp_seq=1 ttl=64 time=0.594 ms
64 bytes from 192.168.1.150: icmp_seq=2 ttl=64 time=0.510 ms
64 bytes from 192.168.1.150: icmp_seq=3 ttl=64 time=0.766 ms
64 bytes from 192.168.1.150: icmp_seq=4 ttl=64 time=0.285 ms
— 192.168.1.150 ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3041ms
rtt min/avg/max/mdev = 0.285/0.538/0.766/0.173 ms
root@srv:~# nslookup maquina1 192.168.1.100
Server: 192.168.1.100
Address: 192.168.1.100#53
** server can’t find maquina1: NXDOMAIN
root@srv:~# nslookup http://www.google.es 192.168.1.100
Server: 192.168.1.100
Address: 192.168.1.100#53
Non-authoritative answer:
Name: http://www.google.es
Address: 216.58.215.131
Name: http://www.google.es
Address: 2a00:1450:4003:800::2003
A ver, en el archivo named.conf.local, cuando se incluye una zona de resolución directa el parámetro que incluye zone es el propio dominio que, en tu caso, debe ser «lab.local«.
Tú has puesto esto:
zone «directa.redlocal» {
type master;
file «/etc/bind/db.redlocal»;
};
Cuando debería ser esto:
zone «lab.local» {
type master;
file «/etc/bind/db.redlocal»;
};
No sé cómo darte las gracias. He mirado miles de páginas y cambiado decenas de opciones y resulta que era eso. Es totalmente lógico que la zona se llame como el dominio y no sé cómo se me ha pasado.
Miles de gracias.
¡Cosas que pasan!
Todo bien explicado, genial.
Aun así no sé muy bien cómo seguir, quiero hacer que mi página web sea visible desde afuera y compré un dominio pero no sé qué DNS colocarle a ese dominio.
Todo mal. XD
Para lo que quieres necesitas que tu conexión a Internet tenga conexión IP pública fija, que el router redirija correctamente los puertos necesarios a la máquina que corre el servicio web y que tu dominio esté configurado para responder a tu dirección IP. Esto último normalmente se hace en el servicio en el que has registrado el dominio, en la configuración del mismo. Si no puedes configurar directamente tu dirección IP y en su lugar te piden servidores DNS tienes un problema, ya que el dicho servicio debe correr en Internet, no en tu intranet.
Por ejemplo, este sitio web corre sobre un servicio VPS que ofrece servicio DNS, y por otro lado el dominio está registrado en un servicio distinto en el que se ha configurado el DNS del servicio VPS.
Hola, muy buen trabajo. Tengo una máquina virtual en Azure con Debian y quiero configurar DNS. En los archivos de configuración ¿tengo que utilizar la direccion IP pública o la privada?
Gracias
Hola, Víctor. Dependerá de lo que quieras hacer, si ese servicio DNS va a servir clientes desde Internet o desde la red interna.
Gracias por el tutorial, bastante claro de cómo hacerlo, gracias.
Amigo, ¿cuál sería la opción adicional para montar en ese servidor DNS un filtrado de páginas bloqueadas por el gobierno?
Te agradezco la ayuda.
Está muy bueno el tutorial me aclaró muchas cosas, ¿ahora podemos con esto incluir las máquinas a este dominio?
Puedes añadir todos los registros que necesites, empezando por todas las máquinas que necesiten ser accedidas por otras.
Gracias, me ayudaste a configurarlo y entender cada paso.
¡Estupendo, Juan! Me alegra saberlo.
Gracias por responder. Es un servidor de páginas web, sólo eso. No es servidor de mi red ni nada de eso. Es sólo para publicar mis web. Ahí sí corresponde la IP pública?
Es que no acabo de entender el esquema. La idea al configurar un cliente DNS es la visibilidad del servidor DNS, si cliente y servidor están en la misma red se usan direcciones internas, pero si el servidor DNS está en Internet (como los que podemos usar para resolver cualquier nombre de Internet) utilizamos las direcciones públicas. Podría haber un caso en que el servidor DNS resuelva nombres para clientes de Internet y clientes locales, por lo que los clientes externos deben sí o sí usar la dirección pública y los clientes internos pueden usar cualquiera de las dos direcciones.
En el caso de tu servidor web, no adivino cuál es la función del servidor DNS, ya que entiendo que tus páginas web tendrán asignados dominios ya configurados y gestionados desde el servicio de registro de dominios.
Hola… Muy buen trabajo. Muy ilustrativo y me sacó varias dudas que tenía. Ahora una consulta: En /etc/resolv.conf va la IP interna del servidor que estamos configurando o la IP externa que corresponde al dominio? Gracias.
¡Hola, Pablo! Si estás configurando máquinas de la red local a la que pertenece el servidor DNS, lo lógico sería usar la IP interna, aunque sin Bind queda a la escucha en todas las interfaces de red de la máquina Debian 9, y la IP pública es alcanzable por los clientes, también valdría la IP pública.