Introducción

DNS, o el Sistema de Nombres de Dominio, es a menudo un componente difícil de entender cuando se aprende a configurar sitios web y servidores. Mientras que la mayoría de la gente probablemente optará por utilizar los servidores DNS proporcionados por su compañía de alojamiento o su registrador de dominios, hay algunas ventajas en la creación de sus propios servidores DNS.

En esta guía, vamos a discutir cómo instalar y configurar el servidor DNS Bind9 como servidores DNS sólo autoritativos en máquinas Ubuntu 14.04. Configuraremos estos dos servidores Bind para nuestro dominio en una configuración primaria-secundaria.

Requisitos previos y objetivos

Para completar esta guía, primero necesitarás estar familiarizado con alguna terminología común de DNS. Consulta esta guía para conocer los conceptos que implementaremos en esta guía.

También necesitarás al menos dos servidores. Uno será para el servidor DNS «primario» donde se originarán los archivos de zona de nuestro dominio y otro será el servidor «secundario» que recibirá los datos de zona a través de transferencias y estará disponible en caso de que el otro servidor se caiga. Esto evita el peligro de tener un único punto de fallo para tus servidores DNS.

A diferencia de los servidores DNS de caché o de reenvío o de un servidor DNS polivalente, los servidores sólo autoritativos sólo responden a las consultas iterativas de las zonas para las que son autoritativos. Esto significa que si el servidor no sabe la respuesta, simplemente le dirá al cliente (normalmente algún tipo de servidor DNS de resolución) que no sabe la respuesta y le dará una referencia a un servidor que puede saber más.

Los servidores DNS sólo autoritativos son a menudo una buena configuración para un alto rendimiento porque no tienen la sobrecarga de resolver las consultas recursivas de los clientes. Sólo se preocupan por las zonas que están diseñadas para servir.

Para los propósitos de esta guía, en realidad vamos a hacer referencia a tres servidores. Los dos servidores de nombres mencionados anteriormente, más un servidor web que queremos configurar como host dentro de nuestra zona.

Utilizaremos el dominio ficticio example.com para esta guía. Debes sustituirlo por el dominio que estés configurando. Estos son los datos de las máquinas que vamos a configurar:

Propósito	DNS FQDN	Dirección IP
Servidor de nombres primario	ns1.ejemplo.com.	192.0.2.1
Servidor de nombres secundario	ns2.ejemplo.com.	192.0.2.2
Servidor web	www.example.com.	192.0.2.3

Después de completar esta guía, debería tener dos servidores de nombres sólo autoritativos configurados para sus zonas de dominio. Los nombres de la columna central de la tabla anterior podrán utilizarse para llegar a sus distintos hosts. Utilizando esta configuración, un servidor DNS recursivo podrá devolver datos sobre el dominio a los clientes.

Configuración del nombre de host en los servidores de nombres

Antes de entrar en la configuración de nuestros servidores de nombres, debemos asegurarnos de que nuestro nombre de host está configurado correctamente tanto en nuestro servidor DNS primario como en el secundario.

Comienza por investigar el archivo /etc/hosts. Abra el archivo con privilegios sudo en su editor de texto:

sudo nano /etc/hosts

Necesitamos configurarlo para que identifique correctamente el nombre de host y el FQDN de cada servidor. Para el servidor de nombres primario, el archivo se verá inicialmente así:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

Debemos modificar la segunda línea para hacer referencia a nuestra combinación específica de host y dominio y apuntarla a nuestra dirección IP pública y estática. A continuación, podemos añadir el nombre no cualificado como un alias al final. Para el servidor primario en este ejemplo, usted cambiaría la segunda línea a esto:

127.0.0.1 localhost192.0.2.1 ns1.example.com ns1. . .

Guardar y cerrar el archivo cuando haya terminado.

También debemos modificar el archivo /etc/hostname para contener nuestro nombre de host no calificado:

sudo nano /etc/hostname

ns1

Podemos leer este valor en el sistema que se ejecuta actualmente entonces escribiendo:

sudo hostname -F /etc/hostname

Queremos completar el mismo procedimiento en nuestro servidor secundario.

Comienza con el archivo /etc/hosts:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Guarda y cierra el archivo cuando hayas terminado.

A continuación, modifica el archivo /etc/hostname. Recuerde que sólo debe utilizar el host real (sólo ns2 en nuestro ejemplo) para este archivo:

sudo nano /etc/hostname

ns2

De nuevo, lea el archivo para modificar el sistema actual:

sudo hostname -F /etc/hostname

Sus servidores deben tener ahora sus definiciones de host configuradas correctamente.

Instalar Bind en ambos servidores de nombres

En cada uno de tus servidores de nombres, ahora puedes instalar Bind, el servidor DNS que vamos a utilizar.

El software Bind está disponible dentro de los repositorios por defecto de Ubuntu, por lo que sólo tenemos que actualizar nuestro índice de paquetes locales e instalar el software utilizando apt. También incluiremos la documentación y algunas utilidades comunes:

sudo apt-get updatesudo apt-get install bind9 bind9utils bind9-doc

Ejecuta este comando de instalación en tus servidores DNS primario y secundario para adquirir los archivos adecuados.

Configurar el servidor Bind primario

Ahora que tenemos el software instalado, podemos empezar por configurar nuestro servidor DNS en el servidor primario.

Configurar el archivo de opciones

Lo primero que configuraremos para empezar es el archivo named.conf.options.

El servidor Bind DNS también se conoce como named. El archivo de configuración principal se encuentra en /etc/bind/named.conf. Este archivo llama a los otros archivos que realmente vamos a configurar.

Abra el archivo de opciones con privilegios de sudo en su editor:

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

A continuación, la mayoría de las líneas comentadas han sido despojadas para la brevedad, pero en general el archivo debe tener este aspecto después de la instalación:

options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Lo principal que tenemos que configurar en este archivo es la recursión. Dado que estamos tratando de configurar un servidor sólo autoritativo, no queremos habilitar la recursión en este servidor. Podemos desactivar esto dentro del bloque options.

También vamos a permitir por defecto las transferencias. Anularemos esto en las especificaciones de zonas individuales más adelante:

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Cuando haya terminado, guarde y cierre el archivo.

Configuración del archivo local

El siguiente paso que debemos dar es especificar las zonas que deseamos controlar en este servidor. Una zona es cualquier porción del dominio que se delega para su gestión a un servidor de nombres que no ha sido subdelegado a otros servidores.

Estamos configurando el dominio example.com y no vamos a subdelegar la responsabilidad de ninguna porción del dominio a otros servidores. Así que la zona cubrirá todo nuestro dominio.

Para configurar nuestras zonas, debemos abrir el archivo /etc/bind/named.conf.local con privilegios sudo:

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

Este archivo estará inicialmente vacío además de los comentarios. Hay otras zonas que nuestro servidor conoce para su gestión general, pero éstas se especifican en el archivo named.conf.default-zones.

Para empezar, necesitamos configurar la zona de reenvío para nuestro dominio example.com. La zona de reenvío es la resolución convencional de nombre a IP en la que la mayoría de nosotros pensamos cuando hablamos de DNS. Creamos un bloque de configuración que define la zona de dominio que deseamos configurar:

zone "example.com" {};

Nota: Muchas herramientas DNS, sus archivos de configuración y la documentación utilizan los términos «maestro» y «esclavo» mientras que DigitalOcean generalmente prefiere descriptores alternativos. Para evitar confusiones hemos optado por utilizar los términos «primario» y «secundario» para denotar las relaciones entre servidores, y sólo utilizar «maestro» o «esclavo» cuando una directiva de configuración lo requiera.

Dentro de este bloque, añadimos la información de gestión de esta zona. Especificamos la relación de este servidor DNS con la zona. Esto es type master; en la zona de ejemplo que sigue ya que estamos configurando esta máquina como el servidor de nombres primario para todas nuestras zonas. También apuntamos Bind al archivo que contiene los registros de recursos reales que definen la zona.

Vamos a mantener nuestros archivos de zona primaria en un subdirectorio llamado zones dentro del directorio de configuración Bind. Llamaremos a nuestro archivo db.example.com para tomar prestada la convención de los otros archivos de zona en el directorio Bind. Nuestro bloque se verá así ahora:

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

Queremos permitir que esta zona se transfiera a nuestro servidor secundario, tenemos que añadir una línea como esta:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com"; allow-transfer { 192.0.2.2; };};

A continuación, vamos a definir la zona inversa para nuestro dominio.

Un poco sobre las zonas inversas

Si la organización que te dio tus direcciones IP no te dio un rango de red y te delegó la responsabilidad de ese rango, entonces tu archivo de zona inversa no será referenciado y será manejado por la propia organización.

Con los proveedores de hosting, el mapeo inverso suele ser atendido por la propia empresa. Por ejemplo, con DigitalOcean, los mapeos inversos para tus servidores se crearán automáticamente si utilizas el FQDN de la máquina como nombre del servidor en el panel de control. Por ejemplo, los mapeos inversos para este tutorial podrían crearse nombrando los servidores así:

En casos como este, ya que no se le ha asignado un trozo de direcciones para administrar, debería utilizar esta estrategia. La estrategia descrita a continuación se cubre para completarla y hacerla aplicable si se le ha delegado el control sobre grupos más grandes de direcciones contiguas.

Las zonas inversas se utilizan para conectar una dirección IP de vuelta a un nombre de dominio. Sin embargo, el sistema de nombres de dominio fue diseñado originalmente para los mapeos hacia adelante, por lo que es necesario pensar en adaptarlo para permitir mapeos inversos.

Las piezas de información que debe tener en cuenta para entender los mapeos inversos son:

• En un dominio, la parte más específica es de la dirección está a la izquierda. Para una dirección IP, la parte más específica está a la derecha.
• La parte más específica de la especificación de un dominio es un subdominio o un nombre de host. Esto se define en el archivo de zona para el dominio.
• Cada subdominio puede, a su vez, definir más subdominios o hosts.

Todas las asignaciones de zona inversa se definen bajo el dominio especial in-addr.arpa, que está controlado por la Autoridad de Números Asignados de Internet (IANA). Bajo este dominio, existe un árbol que utiliza subdominios para mapear cada uno de los octetos de una dirección IP. Para asegurarse de que la especificidad de las direcciones IP refleja la de los dominios normales, los octetos de las direcciones IP se invierten en realidad.

Así que nuestro servidor DNS primario, con una dirección IP de 192.0.2.1, se invertiría para leerse como 1.2.0.192. Cuando añadimos esta especificación de host como una jerarquía existente bajo el dominio in-addr.arpa, el host específico puede ser referenciado como 1.2.0.192.in-addr.arpa.

Como definimos hosts individuales (como el «1» principal aquí) dentro del propio archivo de zona cuando usamos DNS, la zona que estaríamos configurando sería 2.0.192.in-addr.arpa. Si nuestro proveedor de red nos ha dado un bloque /24 de direcciones, digamos 192.0.2.0/24, nos habría delegado esta porción in-addr.arpa.

Ahora que sabes cómo especificar el nombre de la zona inversa, la definición real es exactamente la misma que la de la zona directa. Debajo de la definición de la zona example.com, haga una zona inversa para la red que le han dado. De nuevo, esto es probablemente sólo necesario si se le delegó el control sobre un bloque de direcciones:

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

Hemos elegido nombrar el archivo db.192.0.2. Esto es específico acerca de lo que la zona configura y es más legible que la notación inversa.

Guardar y cerrar el archivo cuando haya terminado.

Crear el archivo de la zona de avance

Ahora le hemos dicho a Bind acerca de nuestras zonas de avance y retroceso, pero todavía no hemos creado los archivos que definirán estas zonas.

Si usted recuerda, especificamos las ubicaciones de los archivos como dentro de un subdirectorio llamado zones. Necesitamos crear este directorio:

sudo mkdir /etc/bind/zones

Ahora, podemos utilizar algunos de los archivos de zona preexistentes en el directorio Bind como plantillas para los archivos de zona que queremos crear. Para la zona de avance, el archivo db.local se acercará a lo que necesitamos. Copie ese archivo en el subdirectorio zones con el nombre utilizado en el archivo named.conf.local.

sudo cp /etc/bind/db.local /etc/bind/zones/db.example.com

Mientras hacemos esto, podemos copiar una plantilla para la zona inversa también. Utilizaremos el archivo db.127, ya que se ajusta a lo que necesitamos:

sudo cp /etc/bind/db.127 /etc/bind/zones/db.192.0.2

Ahora, abre el archivo de la zona inversa con privilegios sudo en tu editor de texto:

sudo nano /etc/bind/zones/db.example.com

El archivo tendrá este aspecto:

$TTL 604800@ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.@ IN A 127.0.0.1@ IN AAAA ::1

Lo primero que tenemos que hacer es modificar el registro SOA (inicio de autoridad) que comienza con el primer símbolo @ y continúa hasta el paréntesis de cierre.

Necesitamos reemplazar el localhost. con el nombre del FQDN de esta máquina. Esta parte del registro se utiliza para definir cualquier servidor de nombres que responderá autoritariamente para la zona que se está definiendo. Esta será la máquina que estamos configurando ahora, ns1.example.com. en nuestro caso (observe el punto final. Esto es importante para que nuestra entrada se registre correctamente).

También queremos cambiar la siguiente pieza, que es en realidad una dirección de correo electrónico con un formato especial con el @ sustituido por un punto. Queremos que nuestros correos electrónicos vayan a un administrador del dominio, así que el correo electrónico tradicional es [email protected]. Traduciremos esto para que se vea como admin.example.com.:

@ IN SOA ns1.example.com. admin.example.com. (

La siguiente pieza que necesitamos editar es el número de serie. El valor del número de serie es la forma en que Bind dice si necesita enviar información actualizada al servidor secundario.

Nota: No incrementar el número de serie es uno de los errores más comunes que conducen a problemas con las actualizaciones de zona. Cada vez que se realiza una edición, se debe incrementar el número de serie.

Una práctica común es utilizar una convención para incrementar el número. Un enfoque es utilizar la fecha en formato YYYYMMDD junto con un número de revisión para el día añadido al final. Así, la primera revisión hecha el 05 de junio de 2014 podría tener un número de serie de 2014060501 y una actualización hecha más tarde ese día podría tener un número de serie de 2014060502. El valor puede ser un número de 10 dígitos.

Vale la pena adoptar una convención para facilitar su uso, pero para mantener las cosas simples para nuestra demostración, sólo estableceremos la nuestra a 5 por ahora:

@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial

A continuación, podemos deshacernos de las tres últimas líneas en el archivo (las que están en la parte inferior que comienzan con @) ya que vamos a hacer la nuestra.

Lo primero que queremos establecer después del registro SOA son los servidores de nombres para nuestra zona. Especificamos el dominio y luego nuestros dos servidores de nombres que son autoritativos para la zona, por nombre. Dado que estos servidores de nombres serán hosts dentro del propio dominio, parecerá un poco autorreferente.

Para nuestra guía, se verá así. De nuevo, ¡preste atención a los puntos finales!:

; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.

Como el propósito de un archivo de zona es principalmente asignar nombres de host y servicios a direcciones específicas, aún no hemos terminado. Cualquier software que lea este archivo de zona querrá saber dónde están los servidores ns1 y ns2 para poder acceder a las zonas autoritativas.

Así que, a continuación, tenemos que crear los registros A que asociarán estos nombres de servidores de nombres a las direcciones IP reales de nuestros servidores de nombres:

; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2

Ahora que tenemos los registros A para resolver con éxito nuestros servidores de nombres a sus direcciones IP correctas, podemos añadir cualquier registro adicional. Recuerde que tenemos un servidor web en uno de nuestros hosts que queremos usar para servir nuestro sitio. Apuntaremos las peticiones para el dominio general (example.com en nuestro caso) a este host, así como las peticiones para el host www. Se verá así:

; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Puedes añadir cualquier otro host que necesites definir creando registros A adicionales. Consulte nuestra guía de fundamentos de DNS para familiarizarse con algunas de sus opciones con la creación de registros adicionales.

Cuando haya terminado, su archivo debe ser algo como esto:

$TTL 604800@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Guardar y cerrar el archivo cuando haya terminado.

Crear el archivo de zona inversa

Ahora, tenemos la zona delantera configurada, pero tenemos que configurar el archivo de zona inversa que especificamos en nuestro archivo de configuración. Ya creamos el archivo al principio de la última sección.

Abra el archivo en su editor de texto con privilegios sudo:

sudo nano db.192.0.2

El archivo debe tener el siguiente aspecto:

$TTL 604800@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.1.0.0 IN PTR localhost.

Vamos a pasar por gran parte del mismo procedimiento que hicimos con la zona de avance. En primer lugar, ajuste el nombre de dominio, el correo electrónico del administrador y el número de serie para que coincidan exactamente con lo que tenía en el último archivo (el número de serie puede ser diferente, pero debe incrementarse):

@ IN SOA example.com. admin.example.com. ( 5 ; Serial

De nuevo, borre las líneas bajo el paréntesis de cierre del registro SOA. Tomaremos el último octeto de cada dirección IP en nuestro rango de red y lo asignaremos al FQDN de ese host usando un registro PTR. Cada dirección IP sólo debe tener un único registro PTR para evitar problemas en algún software, por lo que debe elegir el nombre de host al que desea realizar el mapeo inverso.

Por ejemplo, si tiene un servidor de correo configurado, probablemente quiera configurar el mapeo inverso al nombre de correo, ya que muchos sistemas utilizan el mapeo inverso para validar las direcciones.

Primero, necesitamos configurar nuestros servidores de nombres de nuevo:

; Name servers IN NS ns1.example.com. IN NS ns2.example.com.

Luego, usarás el último octeto de la dirección IP a la que te estás refiriendo y apuntarás eso de vuelta al nombre de dominio completamente calificado con el que quieres regresar. Para nuestro ejemplo, usaremos esto:

; PTR Records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Cuando hayas terminado, el archivo debería ser algo así:

$TTL 604800@ IN SOA example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name servers IN NS ns1.example.com. IN NS ns2.example.com.; PTR records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Guarda y cierra el archivo cuando hayas terminado.

Prueba de los archivos y reinicio del servicio

La configuración para el servidor primario está ahora completa, pero todavía tenemos que implementar nuestros cambios.

Antes de reiniciar nuestro servicio, debemos probar todos nuestros archivos de configuración para asegurarnos de que están configurados correctamente. Tenemos algunas herramientas que pueden comprobar la sintaxis de cada uno de nuestros archivos.

Primero, podemos comprobar los archivos named.conf.local y named.conf.options utilizando el comando named-checkconf. Dado que ambos archivos son fuente del archivo esqueleto named.conf, comprobará la sintaxis de los archivos que hemos modificado.

sudo named-checkconf

Si esto devuelve sin ningún mensaje, significa que los archivos named.conf.local y named.conf.options son sintácticamente válidos.

A continuación, puede comprobar sus archivos de zona individuales pasando el dominio que maneja la zona y la ubicación del archivo de zona al comando named-checkzone. Así que para nuestra guía, usted podría comprobar el archivo de zona hacia adelante escribiendo:

sudo named-checkzone example.com /etc/bind/zones/db.example.com

Si su archivo no tiene problemas, debería decirle que cargó el número de serie correcto y dar el mensaje «OK»;

zone example.com/IN: loaded serial 5OK

Si se encuentra con cualquier otro mensaje, significa que usted tiene un problema con su archivo de zona. Normalmente, el mensaje es bastante descriptivo sobre qué parte no es válida.

Puede comprobar la zona inversa pasando la dirección in-addr.arpa y el nombre del archivo. Para nuestra demostración, deberíamos escribir esto:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

De nuevo, esto debería darle un mensaje similar sobre la carga del número de serie correcto:

zone 2.0.192.in-addr.arpa/IN: loaded serial 5OK

Si todos sus archivos se están comprobando, puede reiniciar su servicio Bind:

sudo service bind9 restart

Debería comprobar los registros escribiendo:

sudo tail -f /var/log/syslog

Mantenga un ojo en este registro para asegurarse de que no hay errores.

Configurar el servidor Bind secundario

Ahora que tenemos configurado el servidor primario, podemos seguir adelante y configurar el servidor secundario. Esto será significativamente más fácil que el servidor primario.

Configurar el archivo de opciones

De nuevo, comenzaremos con el archivo named.conf.options. Ábralo con privilegios sudo en su editor de texto:

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

Haremos las mismas modificaciones exactas en este archivo que hicimos en el de nuestro servidor primario.

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Guarde y cierre el archivo cuando haya terminado.

Configuración del archivo de configuración local

A continuación, configuraremos el archivo named.conf.local del servidor secundario. Ábralo con privilegios sudo en su editor de texto:

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

Aquí, crearemos cada una de nuestras especificaciones de zona como lo hicimos en nuestro servidor primario. Sin embargo, los valores y algunos de los parámetros serán diferentes.

Primero, trabajaremos en la zona de avance. Comience de la misma manera que lo hizo en el archivo primario:

zone "example.com" {};

Esta vez, vamos a establecer el type a slave ya que este servidor está actuando como un secundario para esta zona. Esto significa simplemente que recibe sus archivos de zona a través de la transferencia en lugar de un archivo en el sistema local. Además, sólo vamos a especificar el nombre de archivo relativo en lugar de la ruta absoluta al archivo de zona.

La razón de esto es que, para las zonas secundarias, Bind almacena los archivos /var/cache/bind. Bind ya está configurado para buscar en esta ubicación del directorio, por lo que no necesitamos especificar la ruta.

Para nuestra zona de reenvío, estos detalles tendrán el siguiente aspecto:

zone "example.com" { type slave; file "db.example.com";};

Por último, en lugar de la directiva allow-transfer, especificaremos los servidores primarios, por dirección IP, de los que este servidor aceptará transferencias de zona. Esto se hace en una directiva llamada masters:

zone "example.com" { type slave; file "db.example.com"; masters { 192.0.2.1; };};

Esto completa nuestra especificación de zona de reenvío. Podemos utilizar este mismo formato para la especificación de nuestra zona inversa:

zone "2.0.192.in-addr.arpa" { type slave; file "db.192.0.2"; masters { 192.0.2.1; };};

Cuando haya terminado, puede guardar y cerrar el archivo.

Probando los archivos y reiniciando el servicio

En realidad, no tenemos que hacer ninguna de las creaciones de archivos de zona reales en la máquina secundaria porque, como hemos mencionado antes, este servidor recibirá los archivos de zona del servidor primario. Así que estamos listos para probar.

De nuevo, debemos comprobar la sintaxis del archivo de configuración. Como no tenemos ningún fichero de zona que comprobar, sólo tenemos que utilizar la herramienta named-checkconf:

sudo named-checkconf

Si esto devuelve sin errores, significa que los ficheros que has modificado no tienen errores de sintaxis.

Si este es el caso, puede reiniciar su servicio Bind:

sudo service bind9 restart

Compruebe los registros tanto en el servidor primario como en el secundario utilizando:

sudo tail -f /var/log/syslog

Debería ver algunas entradas que indican que los archivos de zona se han transferido correctamente.

Delegue la autoridad a sus servidores de nombres

Sus servidores de nombres sólo autoritativos deberían estar ahora completamente configurados. Sin embargo, todavía tiene que delegar la autoridad de su dominio a sus servidores de nombres.

Para ello, tendrá que ir al sitio web donde compró su nombre de dominio. La interfaz y quizás la terminología serán diferentes según el registrador de nombres de dominio que haya utilizado.

En la configuración de su dominio, busque una opción que le permita especificar los servidores de nombres que desea utilizar. Como nuestros servidores de nombres están dentro de nuestro dominio, este es un caso especial.

En lugar de que el registrador simplemente delegue la autoridad de la zona mediante el uso de registros NS, tendrá que crear un registro glue. Un registro glue es un registro A que especifica las direcciones IP para los servidores de nombres después de especificar los servidores de nombres a los que está delegando la autoridad.

Por lo general, la delegación sólo enumera los servidores de nombres que manejarán la autoridad del dominio, pero cuando los servidores de nombres están dentro del propio dominio, se necesita un registro A para los servidores de nombres de la zona padre. Si esto no ocurriera, los resolvedores de DNS se quedarían atrapados en un bucle porque nunca podría encontrar la dirección IP de los servidores de nombres del dominio para seguir la ruta de la delegación.

Por lo tanto, es necesario encontrar una sección del panel de control de su registrador de dominios que le permita especificar los servidores de nombres y sus direcciones IP.

Como demostración, el registrador Namecheap tiene dos secciones de servidores de nombres diferentes.

Hay una sección llamada «Registro de servidores de nombres» que le permite especificar las direcciones IP de los servidores de nombres dentro de su dominio:

Dentro, podrá introducir las direcciones IP de los servidores de nombres que existen dentro del dominio:

Esto creará el registro A que sirve como los registros de cola que necesita en el archivo de zona padre.

Una vez hecho esto, debería poder cambiar los servidores de nombres activos por los de su dominio. En NameCheap, esto se hace utilizando la opción de menú «Configuración del servidor de nombres de dominio»:

Aquí, puede decirle que utilice los servidores de nombres que agregó como los servidores autoritativos para su sitio:

Los cambios pueden tardar un poco en propagarse, pero debería ver los datos de sus servidores de nombres siendo utilizados dentro de las próximas 24-48 horas para la mayoría de los registradores.

Conclusión

Ahora debería tener dos servidores DNS sólo autoritativos configurados para servir sus dominios. Estos pueden ser utilizados para almacenar la información de la zona para los dominios adicionales como usted adquiere más.

Configurar y administrar sus propios servidores DNS le da el mayor control sobre cómo se manejan los registros DNS. Puede realizar cambios y estar seguro de que todas las piezas relevantes de los datos DNS están actualizadas en la fuente. Mientras que otras soluciones DNS pueden hacer este proceso más fácil, es importante saber que usted tiene opciones y entender lo que está sucediendo en más soluciones empaquetadas.