Logotipo de ISC: Internet Systems Consortium
28 Ene 2020

Instalación y configuración de BIND9 en Debian

por | publicado en: ASIR, Debian, DNS, Kali Linux, Linux, Redes, Servicios de Red, Servicios de Red e Internet, Ubuntu | 14
 
 

Este es el onceavo de los artículos dedicados al DNS publicados en ZeppelinuX. En este artículo explicaremos la Instalación y configuración de BIND9 en Debian. Si te interesa ver el artículo anterior, Herramientas de diagnóstico para DNS: nslookup, dig, host y whois, solo tienes que pinchar aquí.
 
Índice General

  1. Introducción
  2. Instalación de BIND
  3. Configuración previa de los servidores y clientes DNS
  4. Configuración del servidor DNS como solo caché
  5. Configuración de un servidor DNS para que reenvíe consultas a reenviadores (forwarders)
  6. Configuración de un servidor DNS primario (maestro) para una zona de resolución directa y otra de resolución inversa
  7. Configuración de un servidor DNS secundario (esclavo)
  8. Creación de subdominios

 

  1. Introducción (Volver al índice General)
    Las direcciones IP asociadas a los equipos en las redes TCP/IP, son números fáciles de manejar por las máquinas pero difíciles de memorizar por las personas. Nos resulta más fácil recordar nombres como www.zeppelinux.es que números como 192.168.10.103.

    Los servicios o sistemas de nombres de dominio (DNS) facilitan el uso de los servicios que ofrece una red, permiten asociar nombres fáciles de recordar a direcciones IP. Almacenan direcciones IP y sus nombres, por ejemplo, www.zeppelinux.es se corresponde con la dirección IP 192.168.10.103.

    Al proceso por el cual se traduce un nombre a una dirección IP se conoce como resolución directa y cuando preguntamos por una dirección IP para saber cual o cuales son los nombres de dominio asociados a dicha dirección IP se conoce como resolución inversa.

    DNS (Domain Name System o Sistema de Nombres de Dominio) es el principal servicio de resolución de nombres usado en redes TCP/IP y por lo tanto en Internet.

    En este artículo aprenderemos a instalar y configurar el servicio de DNS en un equipo con Debian 10 ‘buster’ como sistema operativo y el software de DNS utilizado será BIND. Aprenderemos a instalar y configurar un servidor maestro o primario, un servidor esclavo o secundario y crearemos un subdominio de uno ya existente.

    2.  

  2. Instalación de BIND (Volver al índice General)
    Comenzaremos instalando BIND en el equipo que actuará como servidor maestro de nuestro dominio principal.

    En primer lugar actualizamos los repositorios:

    $ sudo apt-get update

    a continuación, instalaremos el paquete bind9 y todas sus dependencias:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14

    $ sudo apt-get install bind9
Leyendo lista de paquetes... Hecho
Creando árbol de dependencias       
Leyendo la información de estado... Hecho
Se instalarán los siguientes paquetes adicionales:
  bind9utils net-tools python3-ply
Paquetes sugeridos:
  bind9-doc dnsutils resolvconf ufw python-ply-docSe instalarán los siguientes paquetes NUEVOS:
  bind9 bind9utils net-tools python3-ply
0 actualizados, 4 nuevos se instalarán, 0 para eliminar y 0 no actualizados.
Se necesita descargar 1.379 kB de archivos.
Se utilizarán 5.101 kB de espacio de disco adicional después de esta operación.
¿Desea continuar? [S/n] S

    Además, instalaremos los paquetes sugeridos en la línea 8 y sus dependencias (si en tu caso algún paquete no aparece, probalemente ya esté instalado en tu sistema):

    $ sudo apt install bind9-doc dnsutils resolvconf ufw python-ply-doc

    Finalizada la instalación, podremos comprobar si el servicio de DNS (proceso named) se ha iniciado. Para ello ejecutaremos el siguiente comando:

    $ ps -ef | grep named
bind       1794      1  0 17:26 ?        00:00:00 /usr/sbin/named -u bind
mortade+   3118   1272  0 17:32 pts/1    00:00:00 grep named

    También podemos comprobar si el servicio de DNS está a la escucha en los puertos 53 TCP y 53 UDP con el siguiente comando:

    1
2
3
4
5
6
7
8
9

    $ netstat -ltun | grep :53
tcp        0      0 192.168.1.45:53         0.0.0.0:*               LISTEN     tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN     tcp6       0      0 :::53                   :::*                    LISTEN     udp        0      0 192.168.1.45:53         0.0.0.0:*                          udp        0      0 127.0.0.1:53            0.0.0.0:*                          udp        0      0 0.0.0.0:5353            0.0.0.0:*                          
udp6       0      0 :::53                   :::*                               udp6       0      0 :::5353                 :::*

    3.  

  3. Configuración previa de los servidores y clientes DNS (Volver al índice General)
    1. El servidor de DNS debería tener una IP fija o estática. Utiliza algún método, ya sea a través de la interfaz gráfica o utilizando una terminal, para conseguir que tus servidores tengan una IP fija. Otro método sugerido es obtener una IP fija por medio de una reserva de IP en algún servicio DHCP instalado en tu red.
    2. En este artículo explicaremos como instalar un servidor maestro y otro servidor esclavo que tendrán las IPs 192.168.1.45 y 192.168.1.46 respectivamente. El servidor maestro será nuestro DNS primario y el servidor esclavo sera el DNS secundario. El dominio principal será zeppelinux.net y el subdominio viajes.zeppelinux.net. Para que nuestros equipos pregunten al servidor maestro y en su defecto al servidor esclavo, configuraremos el archivo resolv.conf con las IPs de los servidores maestro y esclavo y añadiremos el o los dominios de búsqueda.
       
      En nuestro ejemplo, el archivo quedaría tal que así:

      1
2
3
4
5

      # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.1.45nameserver 192.168.1.46search zeppelinux.net
      • Líneas 3 y 4: definen el servidor primario y el secundario respectivamente.
      • Línea 5: define el dominio de búsqueda.

      Vease el artículo Configuración del archivo /etc/resolv.conf para saber más sobre la configuración de este archivo.

      3. Si tras los cambios anteriores tenéis problemas con la resolución de nombres, echad un vistazo al artículo nslookup resuelve hostname pero ping no publicado en </ZeppelinuX>.

    4.  

  4. Configuración del servidor DNS como solo caché (Volver al índice General)
    Por defecto, si no se modifica ningún archivo de configuración, el servidor BIND se instala como servidor DNS solo caché y responde a consultas recursivas (tiene la recursividad activada). No es autorizado para ninguna zona.

    Para que el servidor pueda iniciar consultas recursivas tiene que conocer cuáles son los servidores raíz (root servers). El archivo /etc/bind/db.root o /usr/share/dns/root.hits (dependiendo de la distribución Debian que utilices) contiene los 13 servidores raíz del mundo y sus direcciones IP.

    Para comprobar el funcionamiento del servidor, utilizaremos la herramienta nslookup, para que resuelva nombres DNS utilizando el servidor DNS recién instalado. Para ello, desde una terminal del propio servidor, le preguntaremos sobre el nombre www.zeppelinux.es.

    1
2
3
4
5
6
7
8

    $ nslookup www.zeppelinux.es
Server:         192.168.1.45Address:        192.168.1.45#53 
Non-authoritative answer:www.zeppelinux.es       canonical name = zeppelinux.es.
Name:   zeppelinux.es
Address: 91.199.120.62
    • Líneas 2 y 3: Indica la IP del servidor DNS que resuelve nuestra pregunta y el puerto por el que escucha (TCP/UDP 53).
    • Línea 5: nos indica que el servidor con IP 192.168.1.45 no es autorizado para la zona zeppelinux.es, es decir, no tiene el archivo de zona de zeppelinux.es.
    • Línea 8: el servidor DNS nos responde con la IP asociada al nombre zeppelinux.es.

    5.  

  5. Configuración de un servidor DNS para que reenvíe consultas a reenviadores (forwarders) (Volver al índice General)
    Podemos liberar de tráfico a nuestra red reenviando las consultas recursivas a otros servidores (reenviadores o forwarders). Para conseguirlo, editaremos el archivo de configuración /etc/bind/named.conf.options y añadiremos los servidores reenviadores eliminando el comentario de la directiva forwarders:

    Antes de nada haremos copia de seguridad del archivo /etc/bind/named.conf.options antes de modificarlo:

    $ sudo cp /etc/bind/named.conf.options /etc/bind/named.conf.options.bak

    Editamos el archivo /etc/bind/named.conf.options:

    $ sudo nano /etc/bind/named.conf.options

    Lo que vemos a continuación es el archivo /etc/bind/named.conf.options modificado y apuntando a los servidores DNS libres de Cloudflare y Google:

    1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

    options {
        directory "/var/cache/bind";
 
        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113
 
        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.
 
        forwarders {            //DNS Cloudflare                1.1.1.1;                1.0.0.1;        //DNS Google                8.8.8.8;                8.8.4.4;        }; 
        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation auto;
 
        listen-on-v6 { any; };
};


    Una vez modificado el archivo, para que surtan efecto los cambios, reiniciamos el servicio bind9 con alguno de los siguiente comandos:

    • Si nuestro sistema utiliza systemd como sistema de inicio de Linux, para reiniciar BIND podemos utilizar el siguiente comando: 
      $ sudo systemctl restart bind9.service
    • Si tenemos instalados el comando service, para reiniciar BIND podemos utilizar el siguiente comando: 
      $ sudo service bind9 restart
    • Si nuestro sistema aún sigue utilizando el obsoleto System V init para lazar los scripts de inicio, para reiniciar BIND podemos utilizar el siguiente comando: 
      $ sudo /etc/init.d/bind9 restart

    Para comprobar el funcionamiento del servidor, volvemos a utilizar la herramienta nslookup. Para ello, desde una terminal del propio servidor, le preguntaremos sobre un nombre distinto a www.zeppelinux.es para que no responda con datos guardados en caché, por ejemplo www.google.es:

    1
2
3
4
5
6
7
8
9

    $ nslookup www.google.es
Server:         192.168.1.45Address:        192.168.1.45#53 
Non-authoritative answer:Name:   www.google.es
Address: 172.217.168.163Name:   www.google.es
Address: 2a00:1450:4003:803::2003

    Obsérvese que:

    • Líneas 2 y 3: Indica la IP del servidor DNS que resuelve nuestra pregunta y el puerto por el que escucha (TCP/UDP 53).
    • Línea 5: nos indica que es una respuesta no autorizada, es decir, el servidor DNS utilizado no es autorizado para la zona google.es.
    • Líneas 7 y 9: nos responde con la IPv4 e IPv6 respectivamente asociadas al nombre www.google.es.

    6.  

  6. Configuración de un servidor DNS primario (maestro) para una zona de resolución directa y otra de resolución inversa (Volver al índice General)
    En nuestro ejemplo, el servidor solo servirá a una red local, no sirve a equipos de Internet.

    A continuación se muestra la tabla en la que se listan los servidores que utilizaremos en nuestra red de ejemplo y los datos necesarios para crear las zonas:

    Nombre (RR A)Alias (RR CNAME)Red/MascaraIPServicio
    ns1.zeppelinux.net----192.168.1.0/24192.168.1.45DNS
    ns2.zeppelinux.net----192.168.1.0/24192.168.1.46DNS
    mortadelo.zeppelinux.netwww.zeppelinux.net192.168.1.0/24192.168.1.100WWW
    filemon.zeppelinux.netftp.zeppelinux.net192.168.1.0/24192.168.1.101FTP
    anacleto.zeppelinux.netmail.zeppelinux.net192.168.1.0/24192.168.1.102MAIL
    ventas.viajes.zeppelinux.net----192.168.1.0/24192.168.1.103--PC--
    info.viajes.zeppelinux.net----192.168.1.0/24192.168.1.104--PC--

    Nota: Por defecto, en debian 10 ‘buster’, el directorio donde se guardan los archivos de zona es /var/cache/bind. Dicho directorio se declara en el archivo  /etc/bind/named.conf.options con la directriz  directory "/var/cache/bind";

    Por comodidad, crearemos un directorio específico para los archivos zonas, le llamaremos zonas, aunque el nombre puede ser el de vuestra elección:

    $ sudo mkdir /var/cache/bind/zonas

    luego, asignaremos el usuario y el grupo bind a dicho directorio:

    $ sudo chown bind:bind /var/cache/bind/zonas

    para finalizar, daremos permisos de escritura a ambos:

    $ sudo chmod 775 /var/cache/bind/zonas


     
     
     

    1. Configuración de la zona de resolución directa (Volver al índice General)
      Antes de nada haremos copia de seguridad del archivo /etc/bind/named.conf.local antes de modificarlo:

      $ sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.bak

      Editamos el archivo de configuración /etc/bind/named.conf.local:

      $ sudo nano /etc/bind/named.conf.local

      y declaramos la zona de resolución directa  para el dominio zeppelinux.net:

      1
2
3
4
5
6
7
8
9
10
11
12

      //
// Do any local configuration here
//
// Zona de búsqueda directa para zeppelinux.netzone "zeppelinux.net" {        type master;        file "zonas/db.zeppelinux.net";}; 
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
      • (//) se utiliza para comentar líneas.
      • Línea 5: declaramos la zona. ¡Muy importante no poner punto al final!
      • Línea 6: declaramos el tipo de servidor, en nuestro caso será maestro.
      • Línea 7: declaramos el nombre del archivo de zona. Puede ser cualquier nombre, pero nosotros elegimos este. Observese que no indicamos la ruta completa ya que por defecto se guardan en /var/cache/bind.

       
      A continuación, creamos el archivo de zona de resolución directa  db.zeppelinux.net en el directorio /var/cache/bind/zonas.

      $ sudo nano /var/cache/bind/zonas/db.zeppelinux.net

      Añadimos las directrices y los registros de recursos (RR)  necesarios y guardamos el archivo.

      ObjetoDescripción
      ;se utiliza para comentar líneas o añadir comentarios a las líneas.
      $TTL:Directiva obligatoria a partir de la versión 9 de Bind (RFC 1035/RFC 2308). Ajusta el tiempo de vida (del ingles, Time To Live) predeterminado de la información obtenida en el fichero de zona. Es el tiempo en segundos que determina cuanto tiempo los registros de recursos de la zona serán válidos.
      Un registro de recursos puede contener su propio su propio valor TTL, que tendrá prioridad sobre la directiva presente.
      Por defecto se usan segundos (604800 segundos equivalen a siete días exactos), pero puede usarse también semanas ($TTL 1W), días ($TTL 7D), Horas ($TTL 168H) y minutos ($TTL 10080M).
      Debe declararse al comienzo del archivo de zona, antes del registro SOA.
      @equivale al nombre de la zona definida en el archivo named.conf.local.
      nombres no cualificadosa los nombres de dominio sin el punto final se les añade el nombre de zona.
      nombres cualificados, FQDNlos nombres de dominio completos deben de terminar con un punto (.)
      Primer campo en blancoSi el primer campo de un registro de recursos se deja en blanco toma el valor del mismo campo de la línea del registro de recursos anterior.
      A continuación se muestra ejemplo de la configuración de la zona.

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

      ; Fichero db.zeppelinux.net
$TTL 1D@                         IN      SOA     ns1.zeppelinux.net.     administrador.zeppelinux.net. (                                2020011301      ; Serial
                                    604800      ; Refresh (7 días)
                                     86400      ; Retry (24 horas)
                                   2419200      ; Expire (28 días)
                                     10800 )    ; Negative cache TTL (3 horas)
 
; Servidor DNS del dominio
                          IN      NS      ns1.zeppelinux.net. 
; Hosts
ns1                       IN      A       192.168.1.45
mortadelo.zeppelinux.net. IN      A       192.168.1.100filemon                   IN      A       192.168.1.101
anacleto                  IN      A       192.168.1.102
 
; Alias
www                       IN      CNAME   mortadeloftp                       IN      CNAME   filemonmail                      IN      CNAME   anacleto 
; Servidores de correo (MTA)
@                         IN      MX 10   anacleto

      Observese que:

      • En la línea 2 definimos la directiva $TTL
      • En la línea 3 definimos el registro SOA con las directrices y la cuenta de correo del administrador (sin arroba, @). Nótese que se al principio del registro utilizamos la arroba (@).
      • En la línea 11 definimos el registro NS. Nótese que el primer campo se deja blanco y utilizamos un nombre utilizado en un registro A y no un alias. En los registros NS no podemos utilizar un alias (CNAME), es ilegal.
      • En las líneas 3, 11 y 15 los nombres de dominio completos terminan con un punto (.) mientras que el resto de nombres de dominio no.
      • >En las líneas 20, 21 y 22 definen los alias (CNAME) de los hosts.
      • En la línea 25 definimos el registro MX encargados de indicar cuales son los servidores encargados de la entrega de correo en el dominio y la prioridad entre ellos.

       
      Para comprobar que la sintaxis y semántica de los archivos de configuración y de zona son correctas, ejecutaremos los siguientes comandos:

      1. Con la herramienta named-checkconf comprobamos el archivo named.conf y aquellos que incluya (directiva include), en nuestro caso los archivos /etc/bind/named.conf.options, /etc/bind/named.conf.local y /etc/bind/named.conf.default-zones. En caso de encontrar errores, la salida del comando los mostraría. 
        $ sudo named-checkconf
      2. Con la herramienta named-checkzone comprobamos el archivo de zona. 
        $ sudo named-checkzone zeppelinux.net /var/cache/bind/zonas/db.zeppelinux.net 
zone zeppelinux.net/IN: loaded serial 2020011301
OK

      El paso siguiente será reiniciar el servidor como en el punto 3.

      Para comprobar el funcionamiento del servidor, volvemos a utilizar la herramienta nslookup. Para ello, desde una terminal del propio servidor, le preguntaremos sobre un nombre de dominio perteneciente a la zona zeppelinux.net, por ejemplo www.zeppelinux.net:

      1
2
3
4
5
6
7

      $ nslookup www.zeppelinux.net
Server:         192.168.1.45Address:        192.168.1.45#53 
www.zeppelinux.net      canonical name = mortadelo.zeppelinux.net.Name:   mortadelo.zeppelinux.netAddress: 192.168.1.100

      Observese que:

      • Líneas 2 y 3: indica la IP del servidor DNS que resuelve nuestra pregunta y el puerto por el que escucha (TCP/UDP 53).
      • Línea 5: indica que www.zeppelinux.net es un alias de mortadelo.zeppelinux.net.
      • Líneas 6 y 7: indican, respectivamente, el nombre real (registro A) y la IP del nombre www.zeppelinux.net.

      2.  

    2. Configuración de la zona de resolución inversa (Volver al índice General)
      Editamos el archivo de configuración /etc/bind/named.conf.local:

      $ sudo nano /etc/bind/named.conf.local

      y declaramos la zona de resolución inversa  para la red 192.168.1.0/24:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

      //
// Do any local configuration here
//
// Zona de búsqueda directa para zeppelinux.net
zone "zeppelinux.net" {
        type master;
        file "zonas/db.zeppelinux.net";
};
 
// Zona de búsqueda inversa para 192.168.1.0/24zone "1.168.192.in-addr.arpa" {        type master;        file "zonas/db.192.168.1";}; 
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";
      • (//) se utiliza para comentar líneas.
      • Línea 11: declaramos la zona. ¡Muy importante no poner punto al final!
      • Línea 12: declaramos el tipo de servidor, en nuestro caso será maestro.
      • Línea 13: declaramos el nombre del archivo de zona. Puede ser cualquier nombre, pero nosotros elegimos este. Observese que no indicamos la ruta completa ya que por defecto se guardan en /var/cache/bind.

       
      A continuación, creamos el archivo de zona de resolución inversa  db.192.168.1 en el directorio /var/cache/bind/zonas.

      $ sudo nano /var/cache/bind/zonas/db.192.168.1

      Añadimos las directrices y los registros de recursos (RR)  necesarios y guardamos el archivo.

      ObjetoDescripción
      ;se utiliza para comentar líneas o añadir comentarios a las líneas.
      $TTL:Directiva obligatoria a partir de la versión 9 de Bind (RFC 1035/RFC 2308). Ajusta el tiempo de vida (del ingles, Time To Live) predeterminado de la información obtenida en el fichero de zona. Es el tiempo en segundos que determina cuanto tiempo los registros de recursos de la zona serán válidos.
      Un registro de recursos puede contener su propio su propio valor TTL, que tendrá prioridad sobre la directiva presente.
      Por defecto se usan segundos (604800 segundos equivalen a siete días exactos), pero puede usarse también semanas ($TTL 1W), días ($TTL 7D), Horas ($TTL 168H) y minutos ($TTL 10080M).
      Debe declararse al comienzo del archivo de zona, antes del registro SOA.
      @equivale al nombre de la zona definida en el archivo named.conf.local.
      nombres no cualificadosa los nombres de dominio sin el punto final se les añade el nombre de zona.
      nombres cualificados, FQDNlos nombres de dominio completos deben de terminar con un punto (.)
      Primer campo en blancoSi el primer campo de un registro de recursos se deja en blanco toma el valor del mismo campo de la línea del registro de recursos anterior.
      A continuación se muestra ejemplo de la configuración de la zona.

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

      ; Fichero db.192.168.1
$TTL 7D@                           IN      SOA     ns1.zeppelinux.net. administrador.zeppelinux.net. (                        2020011301      ; Serial    
                            604800      ; Refresh (7 días)
                             86400      ; Retry (24 horas)
                           2419200      ; Expire (28 días)
                             10800 )    ; Negative cache TTL (3 horas)
 
; Servidores DNS del dominio
                            IN      NS      ns1.zeppelinux.net. 
; Hosts
45                          IN      PTR     ns1.zeppelinux.net.
100.1.168.192.in-addr.arpa. IN      PTR     mortadelo.zeppelinux.net.101                         IN      PTR     filemon.zeppelinux.net.
102                         IN      PTR     anacleto.zeppelinux.net.

      Observese que:

       
      Para comprobar que la sintáxis y semántica de los archivos de configuración y de zona son correctas, ejecutaremos los siguientes comandos:

      1. Con la herramienta named-checkconf comprobamos el archivo named.conf y aquellos que incluya (directiva include), en nuestro caso los archivos /etc/bind/named.conf.options, /etc/bind/named.conf.local y /etc/bind/named.conf.default-zones. En caso de encontrar errores, la salida del comando los mostraría. 
        $ sudo named-checkconf
      2. Con la herramienta named-checkzone comprobamos el archivo de zona. 
        $ sudo named-checkzone 1.168.192.in-addr.arpa /var/cache/bind/zonas/db.192.168.1 
zone 1.168.192.in-addr.arpa/IN: loaded serial 2020011301
OK

      El paso siguiente será reiniciar el servidor como en el punto 3.

      Con la herramienta nslookup, comprobamos que el servidor DNS resuelve consultas inversas. Para ello, desde una terminal del propio servidor, le preguntaremos sobre una IP perteneciente a la red 192.168.1.0/24, por ejemplo 192.168.1.100:

      1
2

      $ nslookup 192.168.1.100
100.1.168.192.in-addr.arpa       name = mortadelo.zeppelinux.net.
      • Línea 2: indica el nombre DNS que corresponde a la IP 192.168.1.100.

    7.  

  7. Configuración de un servidor DNS secundario (esclavo) (Volver al índice General)
    El servicio DNS es un servicio crítico y tiene que funcionar siempre, debido a esto al menos deberíamos tener un servidor maestro y otro servidor esclavo por si falla el servidor maestro. Podríamos disponer de varios servidores maestro, pero en caso de cambiar los archivos de zona, tendríamos que cambiarlos en todos los servidores maestros. Es más fácil utilizar un modelo con un solo servidor maestro y uno o varios servidores esclavos. Este modelo permite la actualización automática entre el servidor maestro y los servidores esclavo y solo tendremos administrar los archivos de zona ubicados en el servidor maestro.

    Un servidor esclavo o secundario define una o varias zonas para las que es autorizado. La diferencia con respecto a un servidor maestro es que los ficheros de zona los obtiene de otro servidor autorizado para la zona, normalmente de un servidor maestro mediante un procedimiento denominado transferencia de zona. Los ficheros de zona de los servidores esclavos son de solo lectura y por lo tanto, el administrador no tiene que editarlos. La modificación de los archivos de zona debe realizarse en el servidor maestro que transfiere la zona.
     

    1. Instalación y configuración del servidor esclavo (Volver al índice General)
      En primer lugar instalaremos bind9. Para hacerlo, véase el punto 2 de este artículo.

      Configuramos el archivo resolv.conf con las IPs de los servidores DNS maestro y esclavo, además añadiremos el o los dominios de búsqueda. Vease el punto 3 para ver como se hace.

      Nota: Por defecto, en debian 10 ‘buster’, el directorio donde se guardan los archivos de zona es /var/cache/bind. Dicho directorio se declara en el archivo  /etc/bind/named.conf.options con la directriz  directory "/var/cache/bind";

      Por comodidad, crearemos un directorio específico para los archivos zonas, le llamaremos zonas, aunque el nombre puede ser el de vuestra elección:

      $ sudo mkdir /var/cache/bind/zonas

      luego, asignaremos el usuario y el grupo bind a dicho directorio:

      $ sudo chown bind:bind /var/cache/bind/zonas

      para finalizar, daremos permisos de escritura a ambos:

      $ sudo chmod 775 /var/cache/bind/zonas

      A continuación, antes de nada haremos copia de seguridad del archivo /etc/bind/named.conf.local antes de modificarlo:

      $ sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.bak

      Editamos el archivo /etc/bind/named.conf.local:

      $ sudo nano /etc/bind/named.conf.local

      y declaramos las zonas de resolución directa y resolución inversa que va a recibir del servidor maestro.

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

      //
// Do any local configuration here
//
// Zona de búsqueda directa para zeppelinux.netzone "zeppelinux.net" {        type slave;        file "zonas/db.zeppelinux.net";        masters {192.168.1.45;};}; 
// Zona de búsqueda inversa para 192.168.1.0/24zone "1.168.192.in-addr.arpa" {         type slave;        file "zonas/db.192.168.1";        masters {192.168.1.45;};}; 
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

      Observese que:

      • En las líneas 5 y 12 establecemos los nombres de zona para las que es autorizado.
      • En las líneas 6 y 13 establecemos el tipo de servidor a esclavo.
      • En las líneas 7 y 14 indicamos la ruta a los archivos de zona. Observese que no indicamos la ruta completa ya que por defecto se guardan en /var/cache/bind.
      • En las líneas 8 y 15 indicamos las IPs de los servidores maestros con los que se realizarán las transferencias de zona, en nuestro caso solo una IP.

       
      En este servidor optamos también por utilizar reenviadores como en el servidor maestro, por lo tanto, modificaremos el archivo /etc/bind/named.conf.options y añadiremos el/los servidor/es reenviadores eliminando el comentario de la directiva forwarders:

      Antes de nada haremos copia de seguridad del archivo /etc/bind/named.conf.options antes de modificarlo:

      $ sudo cp /etc/bind/named.conf.options /etc/bind/named.conf.options.bak

      Editamos el archivo /etc/bind/named.conf.options:

      $ sudo nano /etc/bind/named.conf.options

      lo que vemos a continuación es el archivo /etc/bind/named.conf.options modificado y apuntando a los servidores DNS libres de Cloudflare y Google:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

      options {
        directory "/var/cache/bind";
 
        // If there is a firewall between you and nameservers you want
        // to talk to, you may need to fix the firewall to allow multiple
        // ports to talk.  See http://www.kb.cert.org/vuls/id/800113
 
        // If your ISP provided one or more IP addresses for stable
        // nameservers, you probably want to use them as forwarders.
        // Uncomment the following block, and insert the addresses replacing
        // the all-0's placeholder.
 
        forwarders {            //DNS Cloudflare                1.1.1.1;                1.0.0.1;        //DNS Google                8.8.8.8;                8.8.4.4;        }; 
        //========================================================================
        // If BIND logs error messages about the root key being expired,
        // you will need to update your keys.  See https://www.isc.org/bind-keys
        //========================================================================
        dnssec-validation auto;
 
        listen-on-v6 { any; };
};

      Con la herramienta named-checkconf comprobamos el archivo named.conf y aquellos que incluya (directiva include), en nuestro caso los archivos /etc/bind/named.conf.options, /etc/bind/named.conf.local y /etc/bind/named.conf.default-zones. En caso de encontrar errores, la salida del comando los mostraría.

      $ sudo named-checkconf

      El paso siguiente será reiniciar el servidor como en el punto 3.

      Podemos ver un listado del directorio /var/cache/bind/zonas antes de que se transfieran los archivos de zona:

      $ ls -l /var/cache/bind/zonas
total 0

      Podemos observar que aún no hay archivos de zona transferidos.


      2.  
       
       

    2. Configuración del servidor maestro (Volver al índice General)
      Antes de nada haremos copia de seguridad del archivo /etc/bind/named.conf.local antes de modificarlo:

      $ sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.bak

      Editamos el archivo /etc/bind/named.conf.local:

      $ sudo nano /etc/bind/named.conf.local

      y añadimos la IP del servidor esclavo al que transferirá las zonas:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

      //
// Do any local configuration here
//
// Zona de búsqueda directa para zeppelinux.net
zone "zeppelinux.net" {
        type master;
        file "zonas/db.zeppelinux.net";
        allow-transfer {192.168.1.46;};};
 
// Zona de búsqueda inversa para 192.168.1.0/24
zone "1.168.192.in-addr.arpa" {
        type master;
        file "zonas/db.192.168.1";
        allow-transfer {192.168.1.46;};};
 
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

      Observese que:

      • En las líneas 8 y 15 indicamos la IP de nuestro servidor esclavo.

       
      Con la herramienta named-checkconf comprobamos que la sintáxis del archivo /etc/bind/named.conf.local modificado es correcta. En caso de encontrar errores, la salida del comando los mostraría.

      $ sudo named-checkconf

      A continuación, editamos el archivo de zona /var/cache/bind/zonas/db.zeppelinux.net:

      $ sudo nano /var/cache/bind/zonas/db.zeppelinux.net

      y añadimos el registro NS y el registro A del servidor esclavo.

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

      ; Fichero db.zeppelinux.net
$TTL 1D
@                         IN    SOA     ns1.zeppelinux.net.     administrador.zeppelinux.net. (
                                2020011302      ; Serial
                                    604800      ; Refresh (7 días)
                                     86400      ; Retry (24 horas)
                                   2419200      ; Expire (28 días)
                                     10800 )    ; Negative cache TTL (3 horas)
 
; Servidor DNS del dominio
                          IN    NS      ns1.zeppelinux.net.
                          IN    NS      ns2.zeppelinux.net. 
; Hosts
ns1                       IN    A       192.168.1.45
ns2                       IN    A       192.168.1.46mortadelo.zeppelinux.net. IN    A       192.168.1.100
filemon                   IN    A       192.168.1.101
anacleto                  IN    A       192.168.1.102
 
; Alias
www                       IN    CNAME   mortadelo
ftp                       IN    CNAME   filemon
mail                      IN    CNAME   anacleto
 
; Servidores de correo (MTA)
@                       IN      MX 10   anacleto

      Observese que:

      • En la línea 12 agregamos el registro NS del servidor esclavo.
      • En la línea 16 agremamos el registro A del servidor esclavo.

       
      Con la herramienta named-checkzone comprobamos si la sintáxis del archivo de zona es correcta:

      $ sudo named-checkzone zeppelinux.net /var/cache/bind/zonas/db.zeppelinux.net 
zone zeppelinux.net/IN: loaded serial 2020011302
OK

      Editamos el archivo de zona /var/cache/bind/zonas/db.192.168.1:

      $ sudo nano /var/cache/bind/zonas/db.192.168.1

      y añadimos el registro NS y el registro PTR del servidor esclavo:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

      ; Fichero db.192.168.1
$TTL 7D
@                           IN   SOA     ns1.zeppelinux.net. administrador.zeppelinux.net. (
                        2020011302      ; Serial
                            604800      ; Refresh (7 días)
                             86400      ; Retry (24 horas)
                           2419200      ; Expire (28 días)
                             10800)     ; Negative cache TTL (3 horas)
 
; Servidores DNS del dominio
                            IN   NS      ns1.zeppelinux.net.
                            IN   NS      ns2.zeppelinux.net. 
; Hosts
45                          IN   PTR     ns1.zeppelinux.net.
46                          IN   PTR     ns2.zeppelinux.net.100.1.168.192.in-addr.arpa. IN   PTR     mortadelo.zeppelinux.net.
101                         IN   PTR     filemon.zeppelinux.net.
102                         IN   PTR     anacleto.zeppelinux.net.

      Observese que:

      • En la línea 12 agregamos el registro NS del servidor esclavo.
      • En la línea 16 agremamos el registro PTR del servidor esclavo.

       
      Con la herramienta named-checkzone comprobamos si la sintáxis del archivo de zona es correcta:

      $ sudo named-checkzone 1.168.192.in-addr.arpa /var/cache/bind/zonas/db.192.168.1 
zone 1.168.192.in-addr.arpa/IN: loaded serial 2020011302
OK

      El paso siguiente será reiniciar el servidor como en el punto 3.

      3.  

    3. Comprobaciones (Volver al índice General)
       

      • Comprobación de que se han transferido las zonas
        Listado del directorio /var/cache/bind/zonas/ en el servidor esclavo después de reiniciar el servicio y transferidos los archivos de zona.

        $ ls -l /var/cache/bind/zonas/
total 8
-rw-r--r-- 1 bind bind 591 ene  6 12:39 db.192.168.1
-rw-r--r-- 1 bind bind 854 ene  6 12:39 db.zeppelinux.net

        Observese que:

        • Se han transferidos los archivos de zona de resolución indirecta y directa.

        •  

      • Configuración del cliente DNS
        En este artículo, por comodidad, utilizaremos como cliente DNS el servidor esclavo, pero podría ser cualquier máquina de nuestra red. Tendremos que comprobar que el archivo resolv.conf tiene definidas las IPs de los servidores DNS maestro y esclavo, además de añadir el o los dominios de búsqueda para los nombres cortos. Vease el punto 3 para ver como se hace.

        Si nuestro cliente DNS está en una máquina con un sistema operativo distinto a debian, nos aseguraremos de que tiene configurado como servidores DNS primario y secundario, las IPs de nuestros dos servidores, maestro y esclavo respectivamente.

        •  

      • Comprobación que funciona el servicio DNS con los servidores maestro y esclavo a la escucha
        Con los dos servidores, maestro y esclavo arrancados, comenzamos a resolver nombres del dominio zeppelinux.net:

        • Hacemos una pregunta de resolución directa desde el servidor esclavo con la herramienta nslookup: 
          1
2
3
4
5
6
7

          $ nslookup www.zeppelinux.net
Server:         192.168.1.45Address:        192.168.1.45#53
 
www.zeppelinux.net      canonical name = mortadelo.zeppelinux.net.
Name:   mortadelo.zeppelinux.net
Address: 192.168.1.100

          Observese que:

          • La línea 2 indica que el servidor que responde es el maestro con la IP 192.168.1.45.
          • La línea 7 indica la IP correspondiente a www.zeppelinux.net.

          •  

        • Hacemos una pregunta de resolución inversa desde el servidor esclavo. Para este caso utilizaremos la herramienta dig que tiene una salida más completa: 
          1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

          $ dig -x 192.168.1.100
 
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> -x 192.168.1.100
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26213
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 2af78ba62b03014aa4b9564a5e1cb952cab9ba6a179e8546 (good)
;; QUESTION SECTION:
;100.1.168.192.in-addr.arpa.    IN      PTR
 
;; ANSWER SECTION:
100.1.168.192.in-addr.arpa. 604800 IN   PTR     mortadelo.zeppelinux.net. 
;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 604800  IN      NS      ns2.zeppelinux.net.
1.168.192.in-addr.arpa. 604800  IN      NS      ns1.zeppelinux.net.
 
;; ADDITIONAL SECTION:
ns1.zeppelinux.net.     86400   IN      A       192.168.1.45
ns2.zeppelinux.net.     86400   IN      A       192.168.1.46
 
;; Query time: 1 msec
;; SERVER: 192.168.1.45#53(192.168.1.45);; WHEN: lun ene 13 19:39:14 CET 2020
;; MSG SIZE  rcvd: 205

          Observese que:

          • La línea 16 indica el nombre DNS correspondiente a la IP 192.168.1.100.
          • La línea 27 se observa que el servidor que responde es el maestro con la IP 192.168.1.45.

        •  

      • Comprobación que funciona el servicio DNS con solo el servidor esclavo a la escucha
        • En primer lugar, paramos el servicio DNS en el servidor maestro:
          • Si nuestro sistema utiliza systemd como sistema de inicio de Linux, para detener BIND en el servidor maestro podemos utilizar el siguiente comando: 
            $ sudo systemctl stop bind9.service
          • Si tenemos instalados el comando service, para detener BIND en el servidor maestro podemos utilizar el siguiente comando: 
            $ sudo service bind9 stop
          • Si nuestro sistema aún sigue utilizando el obsoleto System V init para lazar los scripts de inicio, para detener BIND en el servidor maestro podemos utilizar el siguiente comando: 
            $ sudo /etc/init.d/bind9 stop
        • Una vez parado el servidor maestro hacemos una pregunta de resolución directa desde el servidor esclavo con nslookup: 
          1
2
3
4
5
6
7

          $ nslookup ftp.zeppelinux.net
Server:         192.168.1.46Address:        192.168.1.46#53
 
ftp.zeppelinux.net      canonical name = filemon.zeppelinux.net.
Name:   filemon.zeppelinux.net
Address: 192.168.1.101

          Observese que:

          • La línea 2 indica que el servidor que responde es el esclavo con la IP 192.168.1.46.
          • La línea 7 indica la IP correspondiente a ftp.zeppelinux.net.

          •  

        • Hacemos una pregunta de resolución inversa desde el servidor esclavo con la herramienta dig: 
          1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

          $ dig -x 192.168.1.102
 
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> -x 192.168.1.102
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13400
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 633bb443375ccdede28b99525e1cb9d1b3170ece80f81cba (good)
;; QUESTION SECTION:
;102.1.168.192.in-addr.arpa.    IN      PTR
 
;; ANSWER SECTION:
102.1.168.192.in-addr.arpa. 604800 IN   PTR     anacleto.zeppelinux.net. 
;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 604800  IN      NS      ns1.zeppelinux.net.
1.168.192.in-addr.arpa. 604800  IN      NS      ns2.zeppelinux.net.
 
;; ADDITIONAL SECTION:
ns1.zeppelinux.net.     86400   IN      A       192.168.1.45
ns2.zeppelinux.net.     86400   IN      A       192.168.1.46
 
;; Query time: 0 msec
;; SERVER: 192.168.1.46#53(192.168.1.46);; WHEN: lun ene 13 19:41:21 CET 2020
;; MSG SIZE  rcvd: 204

          Observese que:

          • La línea 16 indica el nombre DNS correspondiente a la IP 192.168.1.102.
          • La línea 27 se observa que el servidor que responde es el esclavo con la IP 192.168.1.46.


    8.  
     
     

  8. Creación de subdominios (Volver al índice General)
    En este apartado crearemos un subdomino de zeppelinux.net llamado viajes.zeppelinux.net. Crearemos en el servidor maestro la nueva zona de resolución directa para el subdomino y como las máquinas de este subdominio pertenecen también a la red 192.168.1.0/24, añadiremos en la zona de resolución inversa existente los registros PTR pertinentes. También configuraremos el servidor esclavo para que lo sea de la nueva zona.
    Nombre (RR A)Alias (RR CNAME)Red/MascaraIPServicio
    ns1.zeppelinux.net----192.168.1.0/24192.168.1.45DNS
    ns2.zeppelinux.net----192.168.1.0/24192.168.1.46DNS
    mortadelo.zeppelinux.netwww.zeppelinux.net192.168.1.0/24192.168.1.100WWW
    filemon.zeppelinux.netftp.zeppelinux.net192.168.1.0/24192.168.1.101FTP
    anacleto.zeppelinux.netmail.zeppelinux.net192.168.1.0/24192.168.1.102MAIL
    ventas.viajes.zeppelinux.net----192.168.1.0/24192.168.1.103--PC--
    info.viajes.zeppelinux.net----192.168.1.0/24192.168.1.104--PC--
     

    1. Configuración del servidor maestro (Volver al índice General)
      Antes de nada, haremos copia de seguridad del archivo /etc/bind/named.conf.local:

      $ sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.bak

      Editamos el archivo /etc/bind/named.conf.local:

      $ sudo nano /etc/bind/named.conf.local

      y declaramos la zona de resolución directa para el dominio viajes.zeppelinux.net y la IP del servidor esclavo al que transferirá la zona:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

      //
// Do any local configuration here
//
// Zona de búsqueda directa para zeppelinux.net
zone "zeppelinux.net" {
        type master;
        file "zonas/db.zeppelinux.net";
        allow-transfer {192.168.1.46;};
};
 
// Zona de búsqueda directa para viajes.zeppelinux.netzone "viajes.zeppelinux.net" {        type master;        file "zonas/db.viajes.zeppelinux.net";        allow-transfer {192.168.1.46;};};
 
// Zona de búsqueda inversa para 192.168.1.0/24
zone "1.168.192.in-addr.arpa" {
        type master;
        file "zonas/db.192.168.1";
        allow-transfer {192.168.1.46;};
};
 
// Consider adding the 1918 zones here, if they are not used in your
// organization
//include "/etc/bind/zones.rfc1918";

      Observese que:

      • En la línea 12 establecemos el nombres de zona del subdominio para el que es autorizado.
      • En la línea 13 establecemos el tipo de servidor a maestro.
      • En la línea 14 indicamos la ruta al archivo de zona. Observese que no indicamos la ruta completa ya que por defecto se guardan en /var/cache/bind.
      • En la línea 15 indicamos las IPs de los servidores esclavos con los que se realizarán las transferencias de zona, en nuestro caso solo una IP.

       
      Con la herramienta named-checkconf comprobamos si la sintáxis del archivo /etc/bind/named.conf.local modificado es correcta. En caso de encontrar errores, la salida del comando los mostraría.

      $ sudo named-checkconf

      A continuación, creamos y editamos el archivo de zona:

      $ sudo nano /var/cache/bind/db.viajes.zeppelinux.net

      y añadimos los registros A de los hosts ventas e info.

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

      ; Fichero db.viajes.zeppelinux.net
$TTL 1D
@                         IN    SOA     ns1.zeppelinux.net.     administrador.viajes.zeppelinux.net. (                                2020011301      ; Serial
                                    604800      ; Refresh (7 días)
                                     86400      ; Retry (24 horas)
                                   2419200      ; Expire (28 días)
                                     10800 )    ; Negative cache TTL (3 horas)
 
; Servidor DNS del dominio
                          IN    NS      ns1.zeppelinux.net.                          IN    NS      ns2.zeppelinux.net. ; Hosts
ventas                    IN    A       192.168.1.103info                      IN    A       192.168.1.104

      Observese que:

      • En la línea 3 indicamos el nombre del servidor maestro, que sigue siendo ns1.zeppelinux.net y añadimos una dirección de correo para el administrador de la zona viajes.zeppelinux.net.
      • En las líneas 11 y 12 añadimos los registros NS de los servidores DNS maestro y esclavo, que siguen siendo los mismos.
      • En las líneas 14 y 15 añadimos dos registros A pertenecientes a los hosts ventas e info del subdominio.

       
      Con la herramienta named-checkzone comprobamos si la sintáxis del archivo de zona es correcta:

      $ sudo named-checkzone viajes.zeppelinux.net /var/cache/bind/zonas/db.viajes.zeppelinux.net 
zone viajes.zeppelinux.net/IN: loaded serial 2020011301
OK

      Como hemos dicho antes, debido a que los equipos ventas e info pertenecen a la red 192.168.1.0/24, tendremos que añadir los registros PTR al archivo de zona de resolución inversa /var/cache/bind/db.192.168.1 existente. Para ello, editamos el archivo:

      $ sudo nano /var/cache/bind/db.192.168.1

      y añadimos los registros PTR para los hosts ventas e info:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

      ; Fichero db.192.168.1
$TTL 7D
@                           IN   SOA     ns1.zeppelinux.net. administrador.zeppelinux.net. (
                        2020011303      ; Serial
                            604800      ; Refresh (7 días)
                             86400      ; Retry (24 horas)
                           2419200      ; Expire (28 días)
                             10800)     ; Negative cache TTL (3 horas)
 
; Servidores DNS del dominio
                            IN   NS      ns1.zeppelinux.net.
                            IN   NS      ns2.zeppelinux.net. 
; Hosts
45                          IN   PTR     ns1.zeppelinux.net.
46                          IN   PTR     ns2.zeppelinux.net.
100.1.168.192.in-addr.arpa. IN   PTR     mortadelo.zeppelinux.net.
101                         IN   PTR     filemon.zeppelinux.net.
102                         IN   PTR     anacleto.zeppelinux.net.
103                         IN   PTR     ventas.viajes.zeppelinux.net.104                         IN   PTR     info.viajes.zeppelinux.net.

      Observese que:

      • En las líneas 19 y 20 se declaran los registros PTR correspondientes a los hosts ventas e info.

       
      Con la herramienta named-checkzone comprobamos si la sintáxis del archivo de zona es correcta:

      $ sudo named-checkzone 1.168.192.in-addr.arpa /var/cache/bind/zonas/db.192.168.1
zone 1.168.192.in-addr.arpa/IN: loaded serial 2020011303
OK

      El paso siguiente será reiniciar el servidor como en el punto 3.

      2.  

    2. Configuración del servidor esclavo (Volver al índice General)
      Antes de nada, haremos copia de seguridad del archivo /etc/bind/named.conf.local antes de modificarlo:

      $ sudo cp /etc/bind/named.conf.local /etc/bind/named.conf.local.bak

      Editamos el archivo /etc/bind/named.conf.local:

      $ sudo nano /etc/bind/named.conf.local

      y declaramos la zona de resolución directa para el dominio viajes.zeppelinux.net y la IP del servidor maestro desde el que se transferirá la zona:

      1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

      //
// Do any local configuration here
//
// Zona de búsqueda directa para zeppelinux.net
zone "zeppelinux.net" {
        type slave;
        file "zonas/db.zeppelinux.net";
        masters {192.168.1.45;};
}; 
 
// Zona de búsqueda directa para viajes.zeppelinux.net
zone "viajes.zeppelinux.net" {        type slave;        file "zonas/db.viajes.zeppelinux.net";        masters {192.168.1.45;};};
 
// Zona de búsqueda inversa para 192.168.1.0/24
zone "1.168.192.in-addr.arpa" {
        type slave;
        file "zonas/bind/db.192.168.1";
        masters {192.168.1.45;};
};

      Observese que:

      • En la línea 12 establecemos el nombre de zona del subdominio para el que es autorizado.
      • En la línea 13 establecemos el tipo de servidor a esclavo.
      • En la línea 14 indicamos la ruta al archivo de zona. Observese que no indicamos la ruta completa ya que por defecto se guardan en /var/cache/bind.
      • En la línea 15 indicamos las IPs de los servidores maestros con los que se realizarán las transferencias de zona, en nuestro caso solo una IP.

       
      Con la herramienta named-checkconf comprobamos si la sintáxis del archivo /etc/bind/named.conf.local modificado es correcta. En caso de encontrar errores, la salida del comando los mostraría.

      $ sudo named-checkconf

      El paso siguiente será reiniciar el servidor como en el punto 3.

      y comprobamos que se ha transferido la zona viajes.zeppelinux.net:

      1
2
3
4
5

      $ ls -l /var/cache/bind/zonas
total 12
-rw-r--r-- 1 bind bind 598 ene 13 19:51 db.192.168.1-rw-r--r-- 1 bind bind 343 ene 13 19:51 db.viajes.zeppelinux.net-rw-r--r-- 1 bind bind 724 ene 13 19:37 db.zeppelinux.net

      Observese que:

      • En la línea 3 vemos que la fecha de transferencia del archivo db.192.168.1 es posterior a la del archivo db.zeppelinux.net e igual a la del nuevo archivo db.viajes.zeppelinux.net.
      • En la línea 4 vemos que se ha transferido el nuevo archivo de zona db.viajes.zeppelinux.net.

      3.  

    3. Comprobaciones (Volver al índice General)
      • Comprobación que funciona el servicio DNS con los servidores maestro y esclavo a la escucha
        Con los dos servidores, maestro y esclavo arrancados comenzamos a resolver nombres del dominio viajes.zeppelinux.net:

        • Hacemos una pregunta de resolución directa desde el servidor esclavo con la herramienta nslookup: 
          1
2
3
4
5
6

          $ nslookup ventas.viajes.zeppelinux.net
Server:         192.168.1.45Address:        192.168.1.45#53
 
Name:   ventas.viajes.zeppelinux.net
Address: 192.168.1.103

          Observese que:

          • La línea 2 indica que el servidor que responde es el maestro con la IP 192.168.1.45.
          • La línea 6 indica la IP correspondiente al nombre ventas.viajes.zeppelinux.net.

          •  

        • Hacemos una pregunta de resolución inversa desde el servidor esclavo. Para este caso utilizaremos la herramienta dig que tiene una salida más completa: 
          1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

          $ dig -x 192.168.1.104
 
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> -x 192.168.1.104
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28280
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ef407dff25b8963356e3c6af5e1cbd148fcacb6c133eaaac (good)
;; QUESTION SECTION:
;104.1.168.192.in-addr.arpa.    IN      PTR
 
;; ANSWER SECTION:
104.1.168.192.in-addr.arpa. 604800 IN   PTR     info.viajes.zeppelinux.net. 
;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 604800  IN      NS      ns1.zeppelinux.net.
1.168.192.in-addr.arpa. 604800  IN      NS      ns2.zeppelinux.net.
 
;; ADDITIONAL SECTION:
ns1.zeppelinux.net.     86400   IN      A       192.168.1.45
ns2.zeppelinux.net.     86400   IN      A       192.168.1.46
 
;; Query time: 0 msec
;; SERVER: 192.168.1.45#53(192.168.1.45);; WHEN: lun ene 13 19:55:16 CET 2020
;; MSG SIZE  rcvd: 191

          Observese que:

          • La línea 16 indica que el nombre correspondiente a la IP 192.168.1.104.
          • La línea 27 indica que el servidor que responde es el maestro con la IP 192.168.1.45.

        •  

      • Comprobación que funciona el servicio DNS con solo el servidor esclavo a la escucha
        • En primer lugar, paramos el servicio DNS en el servidor maestro:
          • Si nuestro sistema utiliza systemd como sistema de inicio de Linux, para detener BIND en el servidor maestro podemos utilizar el siguiente comando: 
            $ sudo systemctl stop bind9.service
          • Si tenemos instalados el comando service, para detener BIND en el servidor maestro podemos utilizar el siguiente comando: 
            $ sudo service bind9 stop
          • Si nuestro sistema aún sigue utilizando el obsoleto System V init para lazar los scripts de inicio, para detener BIND en el servidor maestro podemos utilizar el siguiente comando: 
            $ sudo /etc/init.d/bind9 stop
        • Una vez parado el servidor maestro hacemos una pregunta de resolución directa desde el servidor esclavo con nslookup: 
          1
2
3
4
5
6

          $ nslookup info.viajes.zeppelinux.net
Server:         192.168.1.46Address:        192.168.1.46#53
 
Name:   info.viajes.zeppelinux.net
Address: 192.168.1.104

          Observese que:

          • La línea 2 indica que el servidor que responde es el esclavo con la IP 192.168.1.46.
          • La línea 6 indica la IP correspondiente al nombre info.viajes.zeppelinux.net.

          •  

        • Hacemos una pregunta de resolución inversa desde el servidor esclavo con la herramienta dig: 
          1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

          $ dig -x 192.168.1.104
 
; <<>> DiG 9.11.5-P4-5.1-Debian <<>> -x 192.168.1.104
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15000
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e51aede28fe47c1f6acbc5905e1cc1a18ddd56a455d9a3c6 (good)
;; QUESTION SECTION:
;104.1.168.192.in-addr.arpa.    IN      PTR
 
;; ANSWER SECTION:
104.1.168.192.in-addr.arpa. 604800 IN   PTR     info.viajes.zeppelinux.net. 
;; AUTHORITY SECTION:
1.168.192.in-addr.arpa. 604800  IN      NS      ns2.zeppelinux.net.
1.168.192.in-addr.arpa. 604800  IN      NS      ns1.zeppelinux.net.
 
;; ADDITIONAL SECTION:
ns1.zeppelinux.net.     86400   IN      A       192.168.1.45
ns2.zeppelinux.net.     86400   IN      A       192.168.1.46
 
;; Query time: 0 msec
;; SERVER: 192.168.1.46#53(192.168.1.46);; WHEN: lun ene 13 20:14:41 CET 2020
;; MSG SIZE  rcvd: 191

          Observese que:

          • La línea 16 indica el nombre correspondiente a la IP 192.168.1.104.
          • La línea 27 indica que el servidor que responde es el esclavo con la IP 192.168.1.46.

 
Aquí termina el onceavo de los artículos sobre el Sistema de Nombres de Dominio (DNS). .
 

Espero que este artículo os haya sido de utilidad. Si pensáis que podéis colaborar para mejorar este artículo, que hay algo erróneo en él o simplemente deseáis comentarlo, por favor, dejad vuestra opinión más abajo.
  Configuración de privacidad y de cookies.
Seguir J. Carlos:

Técnico Informático - Desarrollo Web - Administración de Redes

Técnico Informático. Desarrollo Web. Administración de redes.

Últimas publicaciones de

14 comentarios

  1. Daniel Palacios
    | Reply

    Saludos, debo agradecer encarecidamente por este articulo en especial, ya que esta actualizado y con los comandos que hoy en dia se utilizan, una buena estructura para los novatos como yo, no nos perdamos, buenas explicaciones, busque mucho y este fue el mejor tutorial que pude encontrar, Mil GRACIAS.

  2. Rodrigo
    | Reply

    Realmente, Excelente. Felicitaciones. Aclaro que soy novato en esto, no sería conveniente declarar una acl para las distintas consultas. Por ejemplo:
    :
    acl miacl {
    192.168.1.0/24;
    };

    transferencias y escuchar en la ACL definida:

    allow-transfer {
    miacl;
    };

    allow-query {
    miacl;
    };

    listen-on {
    miacl;
    };

    Esto lo vi en otro tutorial y me pareció interesante. Espero tu comentario y muchas gracias por este terrible tutorial.

    • J. Carlos
      | Reply

      Hola Rodrigo,
      Como puedes ver, este tutorial está pensado para comenzar a trabajar con BIND9. No es un tutorial avanzado, pero con respecto al uso de ACL, por supuesto que es una buena idea.

      Gracias por tu aporte y por visitar ZeppelinuX

  3. Rodrigo
    | Reply

    Hola Juan Carlos, quería hacerte una pregunta y no encontraba un mail de contacto, por eso decidí escribirte por acá.

    Cómo tengo que configurar bind para que bloquee las consultas del tipo ANY, por ejemplo hay servidores que muestran lo siguiente:

    ;; ANSWER SECTION:
    clarin.com. 3788 IN HINFO «RFC8482» «»

    Probé con minimal-any y no funciona.

    Si sos tan amable, de guiarme, te lo agradeceria.

    Saludos

    • J. Carlos
      | Reply

      Hola Rodrigo,

      Cuando te refieres a consultas tipo ANY, ¿te refieres a consultas provenientes de cualquier equipo? si es así, echa un vistazo a este artículo y en concreto a las listas de acceso acl, mediante ellas podrás filtrar quien tiene y quien no acceso al servidor de nombres.
      Si no es esto lo que estás buscando, házmelo saber.
      Un saludo

  4. Rodrigo
    | Reply

    Hola Juan Carlos, gracias por responder, no había visto antes el mensaje. Con respecto a lo de las consultas ANY, hay servidores DNS que al realizarles una consulta del tipo ANY, devuelve lo que te había escrito anteriormente, devuelve un registro HINFO. Si configuraras minimal-any yes; lo que hace bind es devolver una consulta básica, sin información adicional. Por eso quería saber, si hay forma de configurarlo como el servidor de clarin.com.
    Aprovecho para otra consulta, por que no estan a la escucha los puertos udp 53 y solamente en tcp. Vi tu manual y te sucede lo mismo que a mi. Aparecen en netstat pero no estan esuchando.

    Saludos

    • J. Carlos
      | Reply

      Hola de nuevo Rodrigo.
      Primero te doy las gracias por la información sobre las consultas ANY.

      Con respecto al puerto 53 UDP/TCP, solo te puedo decir, lo que se publicó en ZeppelinuX sobre las transferencias de Zona y es lo siguiente: En las transferencias de zona utilizan el protocolo TCP para el transporte. Los servidores DNS maestros utilizan el puerto 53/TCP para el intercambio de datos en las transferencias de zona. Típicamente el protocolo DNS transporta las peticiones y respuestas entre cliente y servidor usando el protocolo UDP y el puerto 53/UDP, ya que es mucho más rápido.

      No se por qué netstat no los muestra con el «State» de «LISTEN», pero una cosa te garantizo y es que tras crear un entorno DNS con un servidor maestro, otro esclavo y varios clientes, pude comprobar que se atendían las peticiones DNS de los clientes, tanto las relativas a dominios autorizados como las relativas a dominios no autorizados y además se replicaban los cambios realizados en los registros DNs del servidor maestro en el esclavo. Por lo tanto, 53 TCP/UDP tiene que estar a la escucha.

      Además cuando ejecutamos netstat -l le estamos pidiendo que muestre puertos a la escucha, lo que no se por qué en el campo «State» no aparece la palabra «LISTEN». En concreto el comando muestra todos los Sockete del servidor a la escucha.

      Si indagas algo más sobre el tema, te agradecería que me ilustrases, ya que me quedo con ese resquemor de no saber el porqué.
      Un Saludo Rodrigo

  5. Rodrigo
    | Reply

    Hola Juan Carlos, estuve viendo varias cosas para saber por qué no está en modo LISTEN en UDP/53 y no logro saberlo. En mi caso funciona perfecto las consultas de los clientes a través del UDP aunque no aparezca en modo LISTEN.
    Al fijarme el estado del servicio bind9, en la última línea me arroja lo siguiente:

    command channel listening on 127.0.0.1#953

    Al hacer un netstat, esa ip loopback solamente figura en TCP/953, también aparece la ip de mi tarjeta de red y 127.0.0.1 en TCP/53 en modo LISTEN. Estas dos últimas ip aparecen en UDP/53 pero sin estar a la escucha y todas asociadas al demonio named.

    Cuando me fijo en los logs me figura lo siguiente:

    10-Jul-2020 19:36:27.567 network: info: listening on IPv4 interface wlp2s0, 192.168.0.69#53
    10-Jul-2020 19:38:21.990 network: info: no longer listening on 127.0.0.1#53
    10-Jul-2020 19:38:21.990 network: info: no longer listening on 192.168.0.69#53

    Cuando ejecuto el siguiente comando, arroja el siguiente error, que el socket ya está creado.
    named -g -p 53

    10-Jul-2020 19:59:10.624 using default UDP/IPv4 port range: [32768, 60999]
    10-Jul-2020 19:59:10.624 using default UDP/IPv6 port range: [32768, 60999]
    10-Jul-2020 19:59:10.628 listening on IPv4 interface lo, 127.0.0.1#53
    10-Jul-2020 19:59:10.628 creating TCP socket: address in use
    10-Jul-2020 19:59:10.628 listening on IPv4 interface wlp2s0, 192.168.0.69#53
    10-Jul-2020 19:59:10.628 creating TCP socket: address in use
    10-Jul-2020 19:59:10.628 unable to listen on any configured interfaces
    10-Jul-2020 19:59:10.652 loading configuration: failure
    10-Jul-2020 19:59:10.652 exiting (due to fatal error)

    Lo raro es que el servidor funciona bien. No sé cuál conclusión sacar.

    Abrazo

    • J. Carlos
      | Reply

      Hola Rodrigo,
      Pues creo que estamos igual, mi servidor tanto maestro como esclavo funcionan bien ambos pero en el «Stat», UDP no aparace como «LISTEN».
      Espero que con el tiempo, algunos de los dos demos con el origen de esto.

      Un saludo.

      PD: Por cierto, aprovecho este comentario por si hay alguien que lea este artículo, pueda iluminarnos sobre este tema.

  6. Rodrigo
    | Reply

    Hola Juan Carlos, estuve probando de arrancar con un USB Live de Ubuntu 20.04 y al hacer un netsat sin Bind instalado, no hay ningún UDP/53 en modo LISTEN, aparece 127.0.0.53#53 UDP que es el del demonio systemd-resolved pero sin el estado, pero en TCP/53 sí está en LISTEN. Creo que por ahí viene el tema.

    Saludos

    • J. Carlos
      | Reply

      Hola Rodrigo,
      Sigo indagando, pero no encuentro nada que nos aclare por que al lanzar netstar -ltun, el estado no está en LISTEN, lo que si está claro es que los servicios DNS están a la escucha ya que resuelven peticiones de los clientes sin problema, ya sean zonas autorizadas como consultas enviadas a los reenviadores (forwarders).
      un Saludo.

  7. L
    | Reply

    Hola J. Carlos:

    Quería darte la enhorabuena por la excelente página web que has creado con unos contenidos sobresalientes y muy bien explicados.

    Un saludo,

    • J. Carlos
      | Reply

      Hola L,
      Gracias por tu comentario. Me agrada mucho que los artículos publicados en ZeppelinuX os sean de ayuda. Repito, muchas gracias por tu comentario y espero que sigas viniendo por ZeppelinuX.

      Un saludo.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.