Cómo configurar BIND como un servidor DNS de red privada en Ubuntu 18.04

Introducción

una parte importante de la administración de la configuración e 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 BIND name server (BIND9) en Ubuntu 18.04, que puede ser utilizado por sus servidores 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 CentOS de este tutorial se puede encontrar aquí.,

Requisitos

Para completar este tutorial, necesitará la siguiente infraestructura. Crear cada servidor en el mismo centro de datos con la red privada habilitada:

• Un nuevo servidor Ubuntu 18.04 para servir como servidor DNS primario, ns1
• (recomendado) un segundo servidor Ubuntu 18.04 para servir como servidor DNS secundario, NS2
• servidores adicionales en el mismo centro de datos que usarán sus servidores DNS

en cada uno de estos servidores, configure el acceso administrativo a través de un sudo usuario y un firewall siguiendo nuestro Ubuntu 18.,04 guía de configuración inicial del servidor.

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.

ejemplo de infraestructura y objetivos

a los efectos de este artículo, asumiremos lo siguiente:

• Tenemos dos servidores que serán designados como nuestros servidores de nombres DNS. Nos referiremos a estos como ns1 y ns2 en esta guía.
• Tenemos dos servidores cliente adicionales que usarán la infraestructura DNS que creamos. Los llamaremos host1 y host2 en esta guía., Puede agregar tantos como desee para su infraestructura.
• Todos estos servidores existen en el mismo centro de datos. Asumiremos que este es el Centro de datos nyc3.
• todos estos servidores tienen red privada habilitada (y están en la subred 10.128.0.0/16. Es probable que tenga que ajustar esto para sus servidores).
• Todos los servidores están conectados a un proyecto que se ejecuta en «example.com». dado que nuestro sistema DNS será completamente interno y privado, no tiene que comprar un nombre de dominio., Sin embargo, el uso de un dominio que usted posee puede ayudar a evitar conflictos con dominios enrutables públicamente.

con estas suposiciones, decidimos que tiene sentido usar un esquema de nomenclatura que use «nyc3.example.com» para hacer referencia a nuestra subred o zona privada. Por lo tanto, el nombre de dominio completo (FQDN) privado de host1 será host1.nyc3.example.com. consulte la siguiente tabla los detalles relevantes:

su 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 proporcionar 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. No es necesario usar el nombre de Región del centro de datos en su esquema de nomenclatura, 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.

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

comencemos instalando nuestro servidor DNS principal, ns1.

instalar BIND en servidores DNS

el texto resaltado en rojo es importante! A menudo se usará para denotar algo que necesita ser reemplazado con sus propias configuraciones o que debe ser modificado o agregado a un archivo de configuración. Por ejemplo, si ve algo comohost1.nyc3.example.com, reemplácelo con el FQDN de su propio servidor. Del mismo modo, si vehost1_private_IP, reemplácelo con la dirección IP privada de su propio servidor.,

en ambos servidores DNS, ns1 y ns2, actualice la caché del paquete apt escribiendo:

sudo apt-get update

ahora instale BIND:

sudo apt-get install bind9 bind9utils bind9-doc

configurando Bind en modo IPv4

antes de continuar, Vamos a establecer bind en modo IPv4 ya que nuestra red privada utiliza IPv4 exclusivamente. En ambos servidores, edite el archivo de configuración predeterminada bind9 escribiendo:

sudo nano /etc/default/bind9

agregue» -4″al final del parámetro OPTIONS., Debe parecerse a la siguiente:

. . .OPTIONS="-u bind -4"

Guarde y cierre el archivo cuando haya terminado.

reinicie BIND para implementar los cambios:

sudo systemctl restart bind9

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

configurar el servidor DNS principal

la configuración de BIND consta de varios archivos, que se incluyen desde 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 (abreviatura de «domain name daemon»). Comenzaremos con la configuración del archivo de opciones.

configurando el archivo de Opciones

en ns1, abra el archivo named.conf.options para editar:

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

encima del bloque existente options, cree un nuevo bloque ACL (lista de control de acceso) llamado «trusted». Aquí es donde definiremos una lista de clientes desde los que permitiremos consultas DNS recursivas (i. e., sus servidores que están 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};options { . . .

ahora que tenemos nuestra lista de clientes DNS de confianza, Queremos editar el bloque options. Actualmente, el inicio del bloque tiene el siguiente aspecto:

 . . .};options { directory "/var/cache/bind"; . . .}

debajo de la directiva directory, agregue las líneas de configuración resaltadas (y sustitúyalas en la dirección IP ns1 adecuada) para que se vea algo como esto:

Cuando haya terminado, guarde y cierre el archivo named.conf.options. La configuración anterior especifica que solo sus propios servidores (los» de confianza») podrán consultar su servidor DNS para dominios externos.

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

configurando el archivo Local

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

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

aparte de algunos comentarios, el archivo debe estar vacío. Aquí, vamos a especificar nuestras zonas de avance y retroceso. Las zonas DNS designan un ámbito específico para administrar y definir registros DNS. Dado que nuestros dominios estarán todos dentro de la «nyc3.example.com» subdominio, lo usaremos como nuestra zona delantera., Debido a que las direcciones IP privadas de nuestros servidores están en el espacio IP 10.128.0.0/16, configuraremos una zona inversa para que podamos definir búsquedas inversas dentro de ese rango.

agregue la zona forward con las siguientes líneas, sustituyendo el nombre de la zona con su propia dirección IP privada y la del servidor DNS secundario en la directivaallow-transfer:

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

Si sus servidores abarcan varias subredes privadas pero están en el mismo centro de datos, asegúrese de especificar una zona adicional y un archivo de zona 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 correspondientes Archivos de zona hacia adelante y hacia atrás.,

creando el archivo de zona Forward

el archivo de zona forward es donde definimos los registros DNS para las búsquedas de DNS forward. Es decir, cuando el DNS recibe una consulta de nombre,» host1.nyc3.example.com» por ejemplo, buscará en el archivo forward zone 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/bind/zones:

sudo mkdir /etc/bind/zones

basaremos nuestro archivo de zona forward en el ejemplo db.local archivo de zona., Copiarlo a la ubicación adecuada con los siguientes comandos:

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

ahora vamos a editar nuestro archivo de zona forward:

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

inicialmente, se verá algo como lo siguiente:

primero, usted querrá editar el registro SOA. Reemplace el primer » localhost «con el FQDN de ns1, luego reemplace» root.localhost » con «admin.nyc3.example.com». cada vez que edite un archivo de zona, debe incrementar el valor de serie antes de reiniciar el proceso named. Lo incrementaremos a»3″., Ahora debería verse algo como esto:

@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial . . .

a continuación, elimine los tres registros al final del archivo (después del registro SOA). Si no está seguro de qué líneas eliminar, se marcan con un comentario» Eliminar esta línea » arriba.

al final del archivo, 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.

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

guarde y cierre el archivo db.nyc3.example.com.

nuestro último ejemplo de archivo forward zone se parece a lo siguiente:

ahora pasemos a los archivos de zona inversa.

crear los archivos de zona inversa

Los archivos de zona inversa son donde definimos los registros DNS PTR para las búsquedas 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., Basaremos nuestros archivos de zona inversa en el ejemplo db.127 archivo de zona. Cópielo a la ubicación adecuada con los siguientes comandos (sustituyendo el nombre del archivo de destino para que coincida con su definición de zona inversa):

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

edite el archivo de zona inversa que corresponda a la zona inversa definida en named.conf.local:

sudo nano /etc/bind/zones/db.10.128 

inicialmente, se verá algo como lo siguiente:

de la misma manera que el archivo forward zone, querrá editar el registro SOA e incrementar el valor de serie. Debería ser algo como esto:

@ IN SOA ns1.nyc3.example.com. admin.nyc3.example.com. ( 3 ; Serial . . .

ahora elimine los dos registros al final del archivo (después del registro SOA). Si no está seguro de qué líneas eliminar, se marcan con un comentario» Eliminar esta línea » arriba.

al final del archivo, 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 PTR 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 están todos en la subred 10.128.0.0/16. Tenga en cuenta que la primera columna consiste en 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 cierre el 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:

hemos terminado de editar nuestros archivos, por lo que a continuación podemos comprobar nuestros archivos en busca de errores.,

comprobación de la sintaxis de configuración de BIND

ejecute el siguiente comando para comprobar la sintaxis de los archivosnamed.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», luego intente named-checkconf de nuevo.

el comando named-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» forward zone configuration, ejecute el siguiente comando (cambie los nombres para que coincidan con su zona forward y su archivo):

sudo named-checkzone nyc3.example.com db.nyc3.example.com 

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

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

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

Reiniciar BIND

Reiniciar BIND:

sudo systemctl restart bind9

Si tiene el firewall UFW configurado, abra el acceso a BIND escribiendo:

sudo ufw allow Bind9

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

configurar el 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, modificar el named.conf.options archivo:

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

En la parte superior del archivo, agregue la ACL con las direcciones IP privadas de todos sus servidores de confianza:

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

debajo de la directiva directory, agregue las siguientes líneas:

guarde y cierre el archivo named.conf.options. Este archivo debe ser exactamente igual al archivo named.conf.options de ns1, excepto que debe configurarse para escuchar en la dirección IP privada de ns2.

ahora edite el archivonamed.conf.local:

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

defina zonas esclavas que correspondan a las zonas maestras en el servidor DNS primario., Tenga en cuenta que el tipo es «esclavo», el archivo no contiene una ruta y hay una directiva masters que debe establecerse en la dirección 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 cierre el archivo named.conf.local.,

ejecute el siguiente comando para verificar la validez de sus archivos de configuración:

sudo named-checkconf

Una vez que se verifique, reinicie BIND:

sudo systemctl restart bind9

permitir conexiones DNS al servidor alterando las reglas de firewall de UFW:

sudo ufw allow Bind9

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

configuración de clientes DNS

antes de que todos sus servidores en la ACL «de confianza» puedan consultar sus servidores DNS, debe configurar cada uno de ellos para usar 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 Ubuntu 18.04

en Ubuntu 18.04, la red está configurada con Netplan, una abstracción que le permite escribir una configuración de red estandarizada y aplicarla a software de red backend incompatible., Para configurar DNS, necesitamos escribir un archivo de configuración de Netplan.

primero, busque el dispositivo asociado a su red privada consultando la subred privada con el comando ip address:

ip address show to 10.128.0.0/16 

en este ejemplo, la interfaz privada es eth1.

a continuación, cree un nuevo archivo en /etc/netplan llamado 00-private-nameservers.yaml:

sudo nano /etc/netplan/00-private-nameservers.yaml

dentro, pegue el siguiente contenido., Deberá modificar la interfaz de la red privada, las direcciones de sus servidores DNS NS1 y NS2 y la zona DNS:

Nota: Netplan utiliza el formato de serialización de datos YAML para sus archivos de configuración. Como YAML utiliza sangría y espacios en blanco para definir su estructura de datos, asegúrese de que su definición utiliza sangría consistente para evitar errores.

Guarde y cierre el archivo cuando haya terminado.

a continuación, dígale a Netplan que intente usar el nuevo archivo de configuración usando netplan try., Si hay problemas que causan una pérdida de red, Netplan revertirá automáticamente los cambios después de un tiempo de espera:

sudo netplan try

Output
Warning: Stopping systemd-networkd.service, but it can still be activated by: systemd-networkd.socketDo you want to keep these settings?Press ENTER before the timeout to accept the new configurationChanges will revert in 120 seconds

si la cuenta atrás se actualiza correctamente en la parte inferior, la nueva configuración es al menos lo suficientemente funcional como para no interrumpir su conexión SSH. Pulse Intro para aceptar la nueva configuración.

Ahora, compruebe que el solucionador DNS del sistema para determinar si se ha aplicado su configuración DNS:

sudo systemd-resolve --status

desplácese hacia abajo hasta que vea la sección para su interfaz de red privada., Debería ver primero las direcciones IP privadas para sus servidores DNS, seguidas de algunos valores de reserva. Su dominio debe estar en el «dominio DNS»:

su cliente ahora debe estar configurado para usar sus servidores DNS internos.

clientes Ubuntu 16.04 y Debian

en los servidores Ubuntu 16.04 y Debian Linux, puede editar el archivo /etc/network/interfaces:

sudo nano /etc/network/interfaces

dentro, busque la línea dns-nameservers y anteponga servidores de nombres propios delante de la lista que está actualmente allí., Debajo de esa línea, agregue una opción dns-search que apunte al dominio base de su infraestructura. En nuestro caso, esto sería «nyc3.example.com»:

 . . . dns-nameservers 10.128.10.11 10.128.20.12 8.8.8.8 dns-search nyc3.example.com . . .

Guarde y cierre el archivo cuando haya terminado.

ahora, reinicie sus servicios de red, aplicando los nuevos cambios con los siguientes comandos. Asegúrese de reemplazar eth0 con el nombre de su interfaz de red:

sudo ifdown --force eth0 && sudo ip addr flush dev eth0 && sudo ifup --force eth0 

esto debería reiniciar su red sin dejar caer su conexión actual., Si funciona correctamente, debería ver algo como esto:

Output
RTNETLINK answers: No such processWaiting for DAD... Done

compruebe que la configuración se han aplicado escribiendo:

cat /etc/resolv.conf

Usted debe ver tus servidores de nombre en el /etc/resolv.conf archivo, así como su dominio de búsqueda:

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

clientes centos

en CentOS, RedHat y Fedora Linux, edite el archivo /etc/sysconfig/network-scripts/ifcfg-eth0., Es posible que tenga que sustituir eth0 con el nombre de su interfaz de red principal:

sudo nano /etc/sysconfig/network-scripts/ifcfg-eth0 

buscar las opciones DNS1 y DNS2 y configurarlas en las direcciones IP privadas de su Servidores de nombres primarios y secundarios. Agregue un parámetro DOMAIN con el dominio base de su infraestructura. En esta guía, que sería «nyc3.example.com»:

. . .DNS1=10.128.10.11DNS2=10.128.20.12DOMAIN='nyc3.example.com'. . .

Guarde y cierre el archivo cuando haya terminado.,

ahora, reinicie el servicio de red escribiendo:

sudo systemctl restart network

el comando puede colgarse durante unos segundos, pero debería devolverle al mensaje en breve.

compruebe que sus cambios se aplicaron escribiendo:

cat /etc/resolv.conf

debería ver sus servidores de nombres y buscar dominio en la lista:

nameserver 10.128.10.11nameserver 10.128.20.12search nyc3.example.com

Su cliente ahora debería poder conectarse y usar sus servidores DNS.

Testing Clients

Use nslookup 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».

para los clientes CentOS, es posible que necesite instalar la utilidad con:

sudo yum install bind-utils

podemos comenzar realizando una búsqueda hacia adelante.

Forward Lookup

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

consultando «host1» se expande a «host1.nyc3.ejemplo.,com debido a que la opción search se establece 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: 127.0.0.53Address: 127.0.0.53#53Non-authoritative answer:Name: host1.nyc3.example.comAddress: 10.128.100.101

a continuación, podemos comprobar las búsquedas inversas.,

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 parece a la siguiente:

Output
11.10.128.10.in-addr.arpa name = host1.nyc3.example.com.Authoritative answers can be found from:

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

¡Felicidades! 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 su entorno de servidor.

agregar un 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 pasos que debe seguir:

Primary Name Server

• Forward zone file: agregue un registro «A» para el nuevo host, incremente el valor de «Serial»
• Reverse zone file: agregue un registro «PTR» para el nuevo host, incremente el valor de «Serial»
• agregue la dirección IP privada de su nuevo host al ACL «de confianza» (named.conf.options)

pruebe sus archivos de configuración:

luego vuelva a cargar bind:

sudo systemctl reload bind9

Su servidor principal debe estar configurado para el nuevo host ahora.,

servidor de nombres secundario

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

Compruebe la sintaxis de configuración:

sudo named-checkconf

4933a947f7″>

Su servidor secundario ahora aceptará conexiones del nuevo host.,

Configure un nuevo Host para usar su DNS

• Configure/etc/resolv.conf para usar sus servidores DNS
• pruebe usandonslookup

eliminar el Host de DNS

Si elimina un host de su entorno o simplemente desea sacarlo de DNS, simplemente elimine todas las cosas que se agregaron cuando agregó 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 hace que la configuración de servicios y aplicaciones sea más fácil 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. Es por eso que se recomienda configurar su DNS con al menos un servidor secundario y mantener copias de seguridad de todos ellos.