Cómo instalar el servidor DNS Bind en Debian 9 Stretch

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.

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!

5/5 - (5 votos)

20 comentarios en «Cómo instalar el servidor DNS Bind en Debian 9 Stretch»

  1. 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.

    Responder
    • ¡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.

      Responder
      • 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

        Responder
        • 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»;
          };

          Responder
          • 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.

  2. 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

    Responder
    • 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.

      Responder
  3. 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

    Responder
  4. 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.

    Responder
  5. 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?

    Responder
    • 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.

      Responder
  6. 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.

    Responder
    • ¡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.

      Responder

Deja un comentario

Este sitio esta protegido por reCAPTCHA y laPolítica de privacidady losTérminos del servicio de Googlese aplican.

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información

ACEPTAR
Aviso de cookies