Introducción

Una parte importante de la administración de la configuración y la infraestructura del servidor incluye mantener una forma fácil de buscar interfaces de red y direcciones IP por nombre, configurando un Sistema de Nombres de Dominio (DNS) adecuado. El uso de nombres de dominio completos (FQDN), en lugar de direcciones IP, para especificar direcciones de red facilita la configuración de servicios y aplicaciones y aumenta la capacidad de mantenimiento de los archivos de configuración. Configurar su propio DNS para su red privada es una excelente manera de mejorar la administración de sus servidores.

En este tutorial, veremos cómo configurar un servidor DNS interno, utilizando el software de servidor de nombres BIND (BIND9) en CentOS 7, que puede ser utilizado por sus Servidores Privados Virtuales (VPS) para resolver nombres de host privados y direcciones IP privadas. Esto proporciona una forma central de administrar sus nombres de host internos y direcciones IP privadas, lo cual es indispensable cuando su entorno se expande a más de unos pocos hosts.

La versión de Ubuntu de este tutorial se puede encontrar aquí.

Requisitos previos

Para completar este tutorial, necesitará lo siguiente:

• Algunos servidores que se ejecutan en el mismo centro de datos y tienen habilitadas redes privadas
• Un nuevo VPS para servir como servidor DNS primario, ns1
• Opcional: Un nuevo VPS para servir como servidor DNS Secundario, ns2
• Acceso root a todo lo anterior (pasos 1-4 aquí)

Si no está familiarizado con los conceptos de DNS, se recomienda que lea al menos las tres primeras partes de nuestra Introducción a la administración de DNS.

Hosts de ejemplo

Por ejemplo, asumiremos lo siguiente:

• Tenemos dos VPS existentes llamados «host1» y «host2»
• Ambos VPS existen en el centro de datos nyc3
• Ambos VPS tienen habilitadas redes privadas (y están en la subred 10.128.0.0/16)
• Ambos VPS están relacionados de alguna manera con nuestra aplicación web que se ejecuta en «example.com»

Con estas suposiciones, decidimos que tiene sentido usar un esquema de nombres que use «nyc3.example.com» para hacer referencia a nuestra subred o zona privada. Por lo tanto, el host1 privada del Nombre de Dominio Totalmente Cualificado (FQDN) será «host1.nyc3.example.com». Consulte la siguiente tabla los detalles relevantes:

Anfitrión	Papel	nombre FQDN Privado	Dirección IP Privada
host1	Generic Host 1	host1.nyc3.example.com	10.128.100.101
host2	Generic Host 2	host2.nyc3.example.com	10.128.200.102

Nota: La configuración existente será diferente, pero los nombres de ejemplo y las direcciones IP se utilizarán para demostrar cómo configurar un servidor DNS para que proporcione un DNS interno funcional. Debería poder adaptar fácilmente esta configuración a su propio entorno reemplazando los nombres de host y las direcciones IP privadas por las suyas propias. No es necesario usar el nombre de región del centro de datos en su esquema de nombres, pero lo usamos aquí para indicar que estos hosts pertenecen a la red privada de un centro de datos en particular. Si utiliza varios centros de datos, puede configurar un DNS interno dentro de cada centro de datos respectivo.

Nuestro objetivo

Al final de este tutorial, tendremos un servidor DNS primario, ns1, y opcionalmente un servidor DNS secundario, ns2, que servirá como copia de seguridad.

Aquí hay una tabla con ejemplos de nombres y direcciones IP:

Anfitrión	Papel	nombre FQDN Privado	Dirección IP Privada
ns1	Servidor DNS Principal	ns1.nyc3.example.com	10.128.10.11
ns2	Servidor DNS Secundario	ns2.nyc3.example.com	10.128.20.12

Vamos a empezar por la instalación de nuestro servidor Primario DNS, ns1.

Instalar BIND en servidores DNS

Nota: El texto resaltado en rojo es importante. A menudo se usará para denotar algo que necesita ser reemplazado con sus propios ajustes o que debe modificarse o agregarse a un archivo de configuración. Por ejemplo, si ves algo como host1.nyc3.ejemplo.com, reemplácelo con el FQDN de su propio servidor. Del mismo modo, si ve host1_private_IP, reemplácelo con la dirección IP privada de su propio servidor.

En ambos servidores DNS, ns1 y ns2, instale BIND con yum:

sudo yum install bind bind-utils

Confirme el mensaje introduciendo y.

Ahora que BIND está instalado, configuremos el servidor DNS principal.

Configurar servidor DNS primario

La configuración de BIND consta de varios archivos, que se incluyen en el archivo de configuración principal, named.conf. Estos nombres de archivo comienzan con» named » porque ese es el nombre del proceso que se ejecuta BIND. Comenzaremos con la configuración del archivo de opciones.

Configurar Bind

El proceso de BIND se conoce como named. Como tal, muchos de los archivos se refieren a » named «en lugar de»BIND».

En ns1, abra el archivo named.conf para editar:

sudo vi /etc/named.conf

Encima del bloque existente options, cree un nuevo bloque ACL llamado «de confianza». Aquí es donde definiremos la lista de clientes desde los que permitiremos consultas DNS recursivas (p. ej. sus servidores que se encuentran en el mismo centro de datos que ns1). Usando nuestras direcciones IP privadas de ejemplo, agregaremos ns1, ns2, host1 y host2 a nuestra lista de clientes de confianza:

acl "trusted" { 10.128.10.11; # ns1 - can be set to localhost 10.128.20.12; # ns2 10.128.100.101; # host1 10.128.200.102; # host2};

Ahora que tenemos nuestra lista de clientes DNS de confianza, desearemos editar el bloque options. Agregue la dirección IP privada de ns1 a la directiva listen-on port 53 y comente la línea listen-on-v6:

options { listen-on port 53 { 127.0.0.1; 10.128.10.11; };# listen-on-v6 port 53 { ::1; };...

Debajo de esas entradas, cambie la directiva allow-transfer a de» none » a la dirección IP privada de ns2. Además, cambie la directiva allow-query de «localhost» a «de confianza»:

Al final del archivo, agregue la siguiente línea:

include "/etc/named/named.conf.local";

Ahora, guardar y salir named.conf. La configuración anterior especifica que solo sus propios servidores (los» de confianza») podrán consultar su servidor DNS.

A continuación, configuraremos el archivo local, para especificar nuestras zonas DNS.

Configure el archivo local

En ns1, abra el archivo named.conf.local para editar:

sudo vi /etc/named/named.conf.local

El archivo debe estar vacío. Aquí, especificaremos nuestras zonas de avance y retroceso.

Agregue la zona directa con las siguientes líneas (sustituya el nombre de la zona por el suyo propio):

zone "nyc3.example.com" { type master; file "/etc/named/zones/db.nyc3.example.com"; # zone file path};

Asumiendo que nuestra subred privada es 10.128.0.0/16, agregue la zona inversa con las siguientes líneas (tenga en cuenta que el nombre de nuestra zona inversa comienza con «128.10», que es la inversión de octetos de «10.128»):

zone "128.10.in-addr.arpa" { type master; file "/etc/named/zones/db.10.128"; # 10.128.0.0/16 subnet };

Si sus servidores abarcan varias subredes privadas pero se encuentran en el mismo centro de datos, asegúrese de especificar una zona y un archivo de zona adicionales para cada subred distinta. Cuando haya terminado de agregar todas las zonas deseadas, guarde y salga del archivo named.conf.local.

Ahora que nuestras zonas están especificadas en BIND, necesitamos crear los archivos de zona hacia adelante y hacia atrás correspondientes.

Crear archivo de zona de reenvío

El archivo de zona de reenvío es donde definimos los registros DNS para las búsquedas de DNS de reenvío. Es decir, cuando el DNS recibe una consulta de nombre, «host1.nyc3.example.com» por ejemplo, buscará en el archivo de zona de reenvío para resolver la dirección IP privada correspondiente de host1.

Vamos a crear el directorio donde residirán nuestros archivos de zona. Según nuestro nombre.conf.configuración local, esa ubicación debe ser /etc/named/zones:

 
sudo chmod 755 /etc/named
 
sudo mkdir /etc/named/zones
 

Ahora vamos a editar nuestros archivos de zona:

sudo vi /etc/named/zones/db.nyc3.example.com 

en Primer lugar, usted desea agregar el registro SOA. Reemplace el FQDN ns1 resaltado con su propio FQDN y, a continuación, reemplace el segundo «nyc3.example.com» con tu propio dominio. Cada vez que edite un archivo de zona, debe incrementar el valor de serie antes de reiniciar el proceso named, lo incrementaremos a «3». Debería verse algo como esto:

Después de eso, agregue sus registros de servidor de nombres con las siguientes líneas (reemplace los nombres con los suyos propios). Tenga en cuenta que la segunda columna especifica que estos son registros «NS»:

; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.

Luego agregue los registros A para sus hosts que pertenecen a esta zona. Esto incluye cualquier servidor cuyo nombre queramos terminar con». nyc3.example.com » (sustituya los nombres y las direcciones IP privadas). Usando nuestros nombres de ejemplo y direcciones IP privadas, agregaremos registros A para ns1, ns2, host1 y host2 de la siguiente manera:

Guarde y salga del archivo db.nyc3.example.com.

Nuestro archivo de zona de reenvío de ejemplo final se parece a lo siguiente:

Ahora pasemos a los archivos de zona inversa.

Crear archivos de zona inversa

Los archivos de zona inversa son donde definimos los registros PTR de DNS para búsquedas de DNS inversas. Es decir, cuando el DNS recibe una consulta por dirección IP, «10.128.100.101», por ejemplo, buscará en los archivos de zona inversa para resolver el FQDN correspondiente, «host1.nyc3.example.com» en este caso.

En ns1, para cada zona inversa especificada en el archivo named.conf.local, cree un archivo de zona inversa.

Edite el archivo de zona inversa que corresponda a la(s) zona (s) inversa (s) definida (s) en named.conf.local:

sudo vi /etc/named/zones/db.10.128 

De la misma manera que el archivo de zona directa, reemplace el FQDN ns1 resaltado con su propio FQDN, luego reemplace el segundo «nyc3.example.com» con tu propio dominio. Cada vez que edite un archivo de zona, debe incrementar el valor de serie antes de reiniciar el proceso named, lo incrementaremos a «3». Debería verse algo como esto:

Después de eso, agregue sus registros de servidor de nombres con las siguientes líneas (reemplace los nombres con los suyos propios). Tenga en cuenta que la segunda columna especifica que estos son registros «NS»:

; name servers - NS records IN NS ns1.nyc3.example.com. IN NS ns2.nyc3.example.com.

Luego agreguePTR registros para todos sus servidores cuyas direcciones IP están en la subred del archivo de zona que está editando. En nuestro ejemplo, esto incluye todos nuestros hosts porque todos están en la subred 10.128.0.0/16. Tenga en cuenta que la primera columna consta de los dos últimos octetos de las direcciones IP privadas de sus servidores en orden inverso. Asegúrese de sustituir nombres y direcciones IP privadas para que coincidan con sus servidores:

Guarde y salga del archivo de zona inversa (repita esta sección si necesita agregar más archivos de zona inversa).

Nuestro archivo de zona inversa de ejemplo final se parece a lo siguiente:

Compruebe la sintaxis de configuración de ENLACE

Ejecute el siguiente comando para comprobar la sintaxis de los archivos named.conf*:

sudo named-checkconf

Si sus archivos de configuración con nombre no tienen errores de sintaxis, volverá a su mensaje de shell y verá ningún mensaje de error. Si hay problemas con los archivos de configuración, revise el mensaje de error y la sección Configurar servidor DNS primario y, a continuación, intente named-checkconf de nuevo.

El comandonamed-checkzone se puede utilizar para comprobar la corrección de los archivos de zona. Su primer argumento especifica un nombre de zona, y el segundo argumento especifica el archivo de zona correspondiente, ambos definidos en named.conf.local.

Por ejemplo, para comprobar el «nyc3.example.com» configuración de zona de reenvío, ejecute el siguiente comando (cambie los nombres para que coincidan con la zona de reenvío y el archivo):

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

Y para comprobar el «128.10.in-addr.arpa» configuración de zona inversa, ejecute el siguiente comando (cambie los números para que coincidan con la zona inversa y el archivo):

sudo named-checkzone 128.10.in-addr.arpa /etc/named/zones/db.10.128 

Cuando todos los archivos de configuración y zona no tengan errores, debe estar listo para reiniciar el servicio BIND.

Inicio BIND

Iniciar BIND:

sudo systemctl start named

Ahora usted va a querer habilitarlo, por lo que se iniciará en el arranque:

sudo systemctl enable named

Su servidor DNS principal está ahora configurado y listo para responder a las consultas DNS. Pasemos a crear el servidor DNS secundario.

Configurar servidor DNS secundario

En la mayoría de los entornos, es una buena idea configurar un servidor DNS secundario que responda a las solicitudes si el principal no está disponible. Afortunadamente, el servidor DNS secundario es mucho más fácil de configurar.

En ns2, edite el archivo named.conf:

sudo vi /etc/named.conf

Nota: Si prefiere omitir estas instrucciones, puede copiar el archivo named.conf de ns1 y modificarlo para escuchar en la dirección IP privada de ns2 y no permitir transferencias.

Encima del bloque existente options, cree un nuevo bloque ACL llamado «de confianza». Aquí es donde definiremos la lista de clientes desde los que permitiremos consultas DNS recursivas (es decir, sus servidores que se encuentran en el mismo centro de datos que ns1). Usando nuestras direcciones IP privadas de ejemplo, agregaremos ns1, ns2, host1 y host2 a nuestra lista de clientes de confianza:

acl "trusted" { 10.128.10.11; # ns1 - can be set to localhost 10.128.20.12; # ns2 10.128.100.101; # host1 10.128.200.102; # host2};

Ahora que tenemos nuestra lista de clientes DNS de confianza, desearemos editar el bloque options. Agregue la dirección IP privada de ns1 a la directiva listen-on port 53 y comente la línea listen-on-v6:

options { listen-on port 53 { 127.0.0.1; 10.128.20.12; };# listen-on-v6 port 53 { ::1; };...

Cambiar allow-query directiva de «localhost» a «de confianza»:

...options {... allow-query { trusted; }; # allows queries from "trusted" clients...

al final del archivo, agregue la línea siguiente:

include "/etc/named/named.conf.local";

Ahora, guardar y salir named.conf. La configuración anterior especifica que solo sus propios servidores (los» de confianza») podrán consultar su servidor DNS.

A continuación, configuraremos el archivo local, para especificar nuestras zonas DNS.

Guardar y salir named.conf.

Ahora edite el archivonamed.conf.local:

 
sudo chmod 755 /etc/named
 
sudo vi /etc/named/named.conf.local
 

Defina zonas esclavas que correspondan a las zonas maestras del servidor DNS primario. Tenga en cuenta que el tipo es «esclavo», el archivo no contiene una ruta de acceso y hay una directiva masters que debe establecerse en la IP privada del servidor DNS primario. Si ha definido varias zonas inversas en el servidor DNS principal, asegúrese de agregarlas todas aquí:

Ahora guarde y salga named.conf.local.

Ejecute el siguiente comando para comprobar la validez de sus archivos de configuración:

sudo named-checkconf

Una vez que se compruebe, inicie BIND:

sudo systemctl start named

Habilitar BIND para que se inicie al arrancar:

sudo systemctl enable named

Ahora tiene servidores DNS primarios y secundarios para la resolución de nombres de redes privadas y direcciones IP. Ahora debe configurar sus servidores para que usen sus servidores DNS privados.

Configurar clientes DNS

Antes de que todos los servidores de la ACL «de confianza» puedan consultar sus servidores DNS, debe configurar cada uno de ellos para que usen ns1 y ns2 como servidores de nombres. Este proceso varía dependiendo del sistema operativo, pero para la mayoría de las distribuciones de Linux implica agregar sus servidores de nombres al archivo /etc/resolv.conf.

Clientes CentOS

En CentOS, RedHat y Fedora Linux VPS, simplemente edite el archivo resolv.conf :

sudo vi /etc/resolv.conf

Luego agregue las siguientes líneas al principio del archivo (sustituya su dominio privado y las direcciones IP privadas ns1 y ns2):

search nyc3.example.com # your private domainnameserver 10.128.10.11 # ns1 private IP addressnameserver 10.128.20.12 # ns2 private IP address

Ahora, guardar y salir. Su cliente ahora está configurado para usar sus servidores DNS.

Clientes Ubuntu

En Ubuntu y Debian Linux VPS, puede editar el archivo head, que se antepone a resolv.conf en el arranque:

sudo vi /etc/resolvconf/resolv.conf.d/head

Agregue las siguientes líneas al archivo (sustituya su dominio privado y las direcciones IP privadas ns1 y ns2):

search nyc3.example.com # your private domainnameserver 10.128.10.11 # ns1 private IP addressnameserver 10.128.20.12 # ns2 private IP address

Ahora ejecute resolvconf para generar una nueva resolv.conf archivo:

sudo resolvconf -u

el cliente ahora está configurado para utilizar los servidores DNS.

Clientes de prueba

Usenslookup—incluido en el paquete «bind-utils»—para probar si sus clientes pueden consultar sus servidores de nombres. Debería poder hacer esto en todos los clientes que haya configurado y que estén en la ACL de «confianza».

Búsqueda hacia adelante

Por ejemplo, podemos realizar una búsqueda hacia adelante para recuperar la dirección IP de host1.nyc3.example.com ejecutando el siguiente comando:

nslookup host1

Consultar «host1» se expande a «host1.nyc3.example.com debido a que la opción search está configurada en su subdominio privado, y las consultas DNS intentarán buscar en ese subdominio antes de buscar el host en otro lugar. La salida del comando anterior se vería como la siguiente:

Output:
Server: 10.128.10.11Address: 10.128.10.11#53Name: host1.nyc3.example.comAddress: 10.128.100.101

Búsqueda inversa

Para probar la búsqueda inversa, consulte el servidor DNS con la dirección IP privada de host1:

nslookup 10.128.100.101

Debería ver una salida que se vea como la siguiente:

Output:
Server: 10.128.10.11Address: 10.128.10.11#5311.10.128.10.in-addr.arpa name = host1.nyc3.example.com.

Si todos los nombres y direcciones IP se resuelven a los valores correctos, significa que los archivos de zona están configurados correctamente. Si recibe valores inesperados, asegúrese de revisar los archivos de zona en su servidor DNS principal (p. ej. db.nyc3.example.com y db.10.128).

¡Felicitaciones! ¡Sus servidores DNS internos ahora están configurados correctamente! Ahora cubriremos el mantenimiento de sus registros de zona.

Mantenimiento de registros DNS

Ahora que tiene un DNS interno en funcionamiento, debe mantener sus registros DNS para que reflejen con precisión el entorno de su servidor.

Agregar Host a DNS

Siempre que agregue un host a su entorno (en el mismo centro de datos), querrá agregarlo a DNS. Aquí hay una lista de los pasos que debe seguir:

Servidor de nombres primario

• Archivo de zona de reenvío: Agregue un registro «A» para el nuevo host, incremente el valor de «Serial»
• Archivo de zona inversa: Agregue un registro «PTR» para el nuevo host, incremente el valor de «Serial»
• Agregue la dirección IP privada de su nuevo host a la ACL «de confianza» (named.conf.options)

Luego reload BIND:

sudo systemctl reload named

Servidor de nombres secundario

• Agregue la dirección IP privada de su nuevo host a la ACL «de confianza» (named.conf.options)

Luego reload BIND:

sudo systemctl reload named

Configure el Nuevo Host para usar Su DNS

• Configure la resolución.conf para usar sus servidores DNS
• Prueba usando nslookup

Eliminar Host de DNS

Si elimina un host de su entorno o simplemente desea sacarlo de DNS, elimine todas las cosas que se agregaron al agregar el servidor a DNS (es decir, el reverso de los pasos anteriores).

Conclusión

Ahora puede referirse a las interfaces de red privadas de sus servidores por nombre, en lugar de por dirección IP. Esto facilita la configuración de servicios y aplicaciones porque ya no tiene que recordar las direcciones IP privadas, y los archivos serán más fáciles de leer y comprender. Además, ahora puede cambiar sus configuraciones para apuntar a un nuevo servidor en un solo lugar, su servidor DNS principal, en lugar de tener que editar una variedad de archivos de configuración distribuidos, lo que facilita el mantenimiento.

Una vez que haya configurado su DNS interno y sus archivos de configuración estén utilizando FQDN privados para especificar conexiones de red, es fundamental que sus servidores DNS se mantengan correctamente. Si ambos dejan de estar disponibles, sus servicios y aplicaciones que dependen de ellos dejarán de funcionar correctamente. Por esta razón, se recomienda configurar su DNS con al menos un servidor secundario y mantener copias de seguridad de todos ellos en funcionamiento.