Table of Contents
Introducción
Una parte importante de la administración de la configuración e infraestructura de servidores incluye el uso sostenido de un método sencillo para buscar las interfaces de red y direcciones IP por nombre mediante la configuración de un sistema de nombres de dominio (DNS) adecuado. El empleo de nombres de dominio completos (FQDN), en vez de direcciones IP, para especificar las direcciones de red puede facilitar 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 opción para mejorar la administración de sus servidores.
En este tutorial, veremos la manera de configurar un servidor DNS interno usando el software de servidor de nombres BIND (BIND9) en Ubuntu 18.04, que sus servidores pueden usar para resolver direcciones IP y nombres de hosts privados. Esto ofrece una alternativa centralizada para administrar sus nombres de hosts internos y direcciones IP privadas, lo cual es indispensable cuando su entorno abarca más de unos pocos hosts.
Puede encontrar la versión de CentOS de este tutorial aquí.
Requisitos previos
Para completar este tutorial, necesitará la infraestructura siguiente. Cree cada servidor en el mismo centro de datos con red privada habilitada:
- Un servidor de Ubuntu 18.04 nuevo que servirá como el servidor DNS primario, ns1.
- (Recomendado) Un segundo servidor Ubuntu 18.04 que 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 un acceso administrativo mediante un usuario sudo y un firewall siguiendo nuestra guía de configuración inicial para servidores de Ubuntu 18.04.
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 e infraestructura y objetivos
A efectos de este artículo, supondremos lo siguiente:
- Tenemos dos servidores que se designarán como nuestros servidores de nombres DNS. En esta guía, nos referiremos a estos como ns1 y ns2.
- Disponemos de dos servidores clientes adicionales que usarán la infraestructura DNS que creemos. En esta guía, los llamaremos host1 y host2. Puede añadir tantos como desee en su infraestructura.
- Todos estos servidores existen en el mismo centro de datos. Supondremos que este es el centro de datos nyc3.
- Todos estos servidores tienen habilitada una red privada y están en la subred
10.128.0.0/16. Probablemente deba ajustar esto para sus servidores.
- Todos los servidores se conectan a un proyecto que se ejecuta en “example.com”. Ya que nuestro sistema DNS será totalmente interno y privado, no es necesario que compre un nombre de dominio. Sin embargo, el uso de un dominio propio puede evitar conflictos con dominios públicos enrutables.
Con estas suposiciones, decidimos que tiene sentido usar un esquema de nomenclatura que emplee “nyc3.example.com” para hacer referencia a nuestra subred o zona privada. Por tanto, el nombre de dominio completo (FQDN) privado de host1, será host1.ny3.example.com. Consulte la siguiente tabla que contiene la información pertinente:
| host | Rol | FQDN privada | Dirección IP privada |
—|—|—|—
| ns1 | Servidor DNS primario | ns1.nyc3.example.com | 10.128.10.11 |
| ns2 | Servidor DNS secundario | ns2.nyc3.example.com | 10.128.20.12 |
| host1 | Host genérico 1 | host1.nyc3.example.com | 10.128.100.101 |
| host2 | Host genérico 2 | host2.nyc3.example.com | 10.128.200.102 |
Nota: Su configuración existente será diferente, pero los nombres de ejemplo y las direcciones IP se utilizarán para demostrar la forma de configurar un servidor DNS para que proporcione un DNS interno funcional. Debería poder adaptar fácilmente esta configuración para su propio entorno sustituyendo los nombres de hosts y direcciones IP privadas por los suyos. No es necesario usar el nombre de la región del centro de datos en su esquema de nomenclatura, pero lo utilizaremos aquí para denotar que estos hosts pertenecen a la red privada de un centro de datos concreto. Si utiliza varios centros de datos, puede configurar un DNS interno con cada centro de datos respectivo.
Al final de este tutorial, dispondremos de un servidor DNS primario, ns1, y de forma opcional uno secundario, ns2, que servirá como respaldo.
Comenzaremos instalando nuestro servidor DNS primario, ns1.
Instalar BIND en servidores DNS
Nota: El texto resaltado en <^>rojo<^> es importante. A menudo se usará para indicar algo que debe sustituirse por sus propios ajustes o que debería modificarse o añadirse a un archivo de configuración. Por ejemplo, si ve algo similar a <^>host1.nyc3.example.com<^>, sustitúyalo por el FQDN de su servidor. Asimismo, si ve <^>host1_private_IP<^>, sustitúyalo por la dirección IP privada de su propio servidor.
En ambos servidores DNS, ns1 y ns2, actualice la caché del paquete apt escribiendo lo siguiente:
sudo apt-get update
Ahora instale BIND:
sudo apt-get install bind9 bind9utils bind9-doc
Configurar Bind para el modo IPv4
Antes de continuar, configuraremos BIND para el modo IPv4, ya que nuestra red privada utiliza IPv4 exclusivamente. En ambos servidores, edite la configuración predeterminada de bind9 escribiendo lo siguiente:
sudo nano /etc/default/bind9
Añada “-4” al final del parámetro OPTIONS. Debería tener el siguiente aspecto:
[label /etc/default/bind9]
. . .
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, configuraremos el servidor DNS primario.
Configurar el servidor DNS primario
La configuración de BIND consta de varios archivos que se incluyen desde el archivo de configuración principal, named.conf. Estos nombres de archivos comienzan con named porque ese es el nombre del proceso que BIND ejecuta (abreviatura de “domain name daemon”). Comenzaremos configurando el archivo de opciones.
Configurar el archivo de opciones
En ns1, abra el archivo named.conf.options para editarlo:
[environment second]
sudo nano /etc/bind/named.conf.options
Sobre el bloque options existente, cree un *nuevo* bloque ACL (lista de control de acceso) llamado “trusted”. Aquí definiremos una lista de clientes desde los que permitiremos consultas de DNS recurrentes (es decir, sus servidores que están en el mismo centro de datos que ns1). Usando nuestras direcciones IP privadas de ejemplo, añadiremos ns1, ns2, host1 y host2 a nuestra lista de clientes de confianza:
[label /etc/bind/named.conf.options — 1 of 3]
[environment second]
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, nos convendrá editar el bloque options. En este momento, el inicio del bloque tiene el siguiente aspecto:
[label /etc/bind/named.conf.options — 2 of 3]
[environment second]
. . .
};
options {
directory "/var/cache/bind";
. . .
}
Debajo de la directiva directory, añada las líneas de configuración resaltadas (y realice la sustitución en la dirección IP adecuada de ns1) para que tenga un aspecto similar a este:
[label /etc/bind/named.conf.options — 3 of 3]
[environment second]
. . .
};
options {
directory "/var/cache/bind";
<^>recursion yes;<^> # enables resursive queries
<^>allow-recursion { trusted; };<^> # allows recursive queries from "trusted" clients
<^>listen-on { 10.128.10.11; };<^> # ns1 private IP address - listen on private network only
<^>allow-transfer { none; };<^> # disable zone transfers by default
<^>forwarders {<^>
<^>8.8.8.8;<^>
<^>8.8.4.4;<^>
<^>};<^>
. . .
};
Cuando termine, guarde y cierre el archivo named.conf.options. En la configuración anterior se especifica que solo sus propios servidores (los “trusted”) podrán consultar su servidor DNS en busca de dominios externos.
A continuación, configuraremos el archivo local para especificar nuestras zonas de DNS.
Configurar el archivo local
En ns1, abra el archivo named.conf.options para editarlo:
[environment second]
sudo nano /etc/bind/named.conf.local
Aparte de algunos contener algunos comentarios, el archivo debería estar vacío. Aquí especificaremos nuestras zonas de reenvío e inversas. Las zonas DNS designan un alcance específico para administrar y definir registros DNS. Debido a que todos nuestros dominios estarán en el subdominio “nyc3.example.com”, usaremos eso como nuestra zona de reenvío. 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 poder definir búsquedas inversas en ese intervalo.
Añada la zona de reenvío con las siguientes líneas, sustituyendo el nombre de la zona por el suyo y la dirección IP privada del servidor DNS secundario en la directiva allow-transfer:
[label /etc/bind/named.conf.local — 1 of 2]
[environment second]
zone "<^>nyc3.example.com<^>" {
type master;
file "/etc/bind/zones/db.<^>nyc3.example.com<^>"; # zone file path
allow-transfer { <^>10.128.20.12<^>; }; # ns2 private IP address - secondary
};
Suponiendo 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 el octeto inverso de “10.128”):
[label /etc/bind/named.conf.local — 2 of 2]
[environment second]
. . .
};
zone "<^>128.10<^>.in-addr.arpa" {
type master;
file "/etc/bind/zones/db.<^>10.128<^>"; # 10.128.0.0/16 subnet
allow-transfer { <^>10.128.20.12<^>; }; # ns2 private IP address - secondary
};
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 termine de añadir todas las zonas deseadas, guarde el archivo named.conf.local y ciérrelo.
Ahora que nuestras zonas están especificadas en BIND, debemos crear los archivos correspondientes de la zona de reenvío e inversa.
Crear el archivo de la zona de reenvío
El archivo de la zona de reenvío representa el punto en el que definimos los registros DNS para reenviar búsquedas DNS. Es decir, cuando el DNS reciba una consulta de nombre, “host1.nyc3.example.com”, por ejemplo, realizará en el archivo de la zona de reenvío para resolver la dirección IP privada correspondiente de host1.
Crearemos el directorio en el que se alojarán nuestros archivos de zona. Según nuestra configuración de named.conf.local, esa ubicación debería ser /etc/bind/zones:
[environment second]
sudo mkdir /etc/bind/zones
Basaremos nuestro archivo de la zona de reenvío en el archivo de zona db.local de muestra. Cópielo a la ubicación adecuada con los siguientes comandos:
[environment second]
sudo cp /etc/bind/db.local /etc/bind/zones/db.<^>nyc3.example.com<^>
Ahora, editaremos nuestro archivo de la zona de reenvío:
[environment second]
sudo nano /etc/bind/zones/db.<^>nyc3.example.com<^>
Inicialmente, tendrá un aspecto similar al siguiente:
[label /etc/bind/zones/db.nyc3.example.com — original]
[environment second]
$TTL 604800
@ IN SOA localhost. root.localhost. (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
@ IN A 127.0.0.1 ; delete this line
@ IN AAAA ::1 ; delete this line
Primero, deberá editar el registro SOA. Sustituya el primer “localhost” por el FQDN de ns1 y luego “root.localhost” por "admin.nyc3.example.com". Cada vez que edite un archivo de zona, deberá incrementar el valor serial antes de reiniciar el proceso named. Lo incrementaremos a “3”. Ahora debería tener un aspecto similar a este:
[label /etc/bind/zones/db.nyc3.example.com — updated 1 of 3]
[environment second]
@ 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 las líneas que debe eliminar, estas se marcan con un comentario “delete this line” (eliminar esta línea) encima.
Al final del archivo, añada los registros de su servidor de nombres con las siguientes líneas (sustituya los nombres por los suyos). Observe que en la segunda columna se especifica que estos son registros “NS”:
[label /etc/bind/zones/db.nyc3.example.com — updated 2 of 3]
[environment second]
. . .
; name servers - NS records
IN NS ns1.<^>nyc3.example.com<^>.
IN NS ns2.<^>nyc3.example.com<^>.
Ahora, añada los registros A para sus hosts que pertenecen a esta zona. Esto incluye cualquier servidor cuyo nombre deseemos que termine con “.nyc3.example.com” (sustituya los nombres y las direcciones IP privadas). Usando nuestros nombres de ejemplo y las direcciones IP privadas, añadiremos registros A para ns1, ns2, host1 y host2:
[label /etc/bind/zones/db.nyc3.example.com — updated 3 of 3]
[environment second]
. . .
; name servers - A records
ns1.<^>nyc3.example.com<^>. IN A <^>10.128.10.11<^>
ns2.<^>nyc3.example.com<^>. IN A <^>10.128.20.12<^>
; 10.128.0.0/16 - A records
<^>host1.nyc3.example.com<^>. IN A <^>10.128.100.101<^>
<^>host2.nyc3.example.com<^>. IN A <^>10.128.200.102<^>
Guarde y cierre el archivo db.nyc3.example.com.
Nuestra zona de reenvío de ejemplo final tendrá el siguiente aspecto:
[label /etc/bind/zones/db.nyc3.example.com — updated]
[environment second]
$TTL 604800
@ IN SOA <^>ns1.nyc3.example.com<^>. admin.<^>nyc3.example.com<^>. (
<^>3<^> ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
; name servers - NS records
IN NS ns1.<^>nyc3.example.com<^>.
IN NS ns2.<^>nyc3.example.com<^>.
; name servers - A records
ns1.<^>nyc3.example.com<^>. IN A <^>10.128.10.11<^>
ns2.<^>nyc3.example.com<^>. IN A <^>10.128.20.12<^>
; 10.128.0.0/16 - A records
<^>host1.nyc3.example.com<^>. IN A <^>10.128.100.101<^>
<^>host2.nyc3.example.com<^>. IN A <^>10.128.200.102<^>
Ahora, prosigamos con los archivos de la zona inversa.
Crear los archivos de la zona inversa
En los archivos de la zona inversa definimos los registros DNS PTR para las búsquedas de DNS inversas. Es decir, cuando el DNS reciba una consulta por dirección IP, “10.128.100.101”, por ejemplo, buscará el los archivos de la zona inversa para resolver el FQDN corespondiente, “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 archivo de zona db.127 de muestra. Cópielo en la ubicación adecuada con los siguientes comandos (sustituyendo el nombre de archivo de destino para que coincida con la definición de su zona inversa):
[environment second]
sudo cp /etc/bind/db.127 /etc/bind/zones/db.<^>10.128<^>
Edite el archivo de la zona inversa que se corresponda con la zona o las zonas inversas definidas en named.conf.local:
[environment second]
sudo nano /etc/bind/zones/db.<^>10.128<^>
Inicialmente, tendrá un aspecto similar al siguiente:
[label /etc/bind/zones/db.10.128 — original]
[environment second]
$TTL 604800
@ IN SOA localhost. root.localhost. (
1 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS localhost. ; delete this line
1.0.0 IN PTR localhost. ; delete this line
Como en el caso del archivo de la zona de reenvío, deberá editar el registro SOA e incrementar el valor serial. Debería tener un aspecto similar a esto:
[label /etc/bind/zones/db.10.128 — updated 1 of 3]
[environment second]
@ IN SOA <^>ns1.nyc3.example.com<^>. <^>admin<^>.<^>nyc3.example.com<^>. (
<^>3<^> ; Serial
. . .
A continuación, elimine los dos registros al final del archivo (después del registro SOA). Si no está seguro de las líneas que eliminará, se marcan con un comentario “delete this line” (elimine esta línea) encima.
Al final del archivo, añada los registros de su servidor de nombres con las siguientes líneas (sustituya los nombres por los suyos). Observe que en la segunda columna se especifica que estos son registros “NS”:
[label /etc/bind/zones/db.10.128 — updated 2 of 3]
[environment second]
. . .
; name servers - NS records
IN NS ns1.<^>nyc3.example.com<^>.
IN NS ns2.<^>nyc3.example.com<^>.
Luego añada registros PTR 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 consiste en los dos últimos octetos de las direcciones IP privadas de sus servidores en orden inverso. Asegúrese de sustituir los nombres y las direcciones IP privadas para que coincidan con sus servidores:
[label /etc/bind/zones/db.10.128 — updated 3 of 3]
[environment second]
. . .
; PTR Records
<^>11.10<^> IN PTR ns1.<^>nyc3.example.com<^>. ; 10.128.10.11
<^>12.20<^> IN PTR ns2.<^>nyc3.example.com<^>. ; 10.128.20.12
<^>101.100<^> IN PTR <^>host1.nyc3.example.com<^>. ; 10.128.100.101
<^>102.200<^> IN PTR <^>host2.nyc3.example.com<^>. ; 10.128.200.102
Guarde y cierre el archivo de la zona inversa (repita los pasos de esta sección si debe añadir más archivos de zona inversa).
Nuestro archivo de zona inversa de ejemplo tiene el siguiente aspecto:
[label /etc/bind/zones/db.10.128 — updated]
[environment second]
$TTL 604800
@ IN SOA <^>nyc3.example.com<^>. admin.nyc3.example.com. (
<^>3<^> ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
; name servers
IN NS ns1.<^>nyc3.example.com<^>.
IN NS ns2.<^>nyc3.example.com<^>.
; PTR Records
<^>11.10<^> IN PTR ns1.<^>nyc3.example.com<^>. ; 10.128.10.11
<^>12.20<^> IN PTR ns2.<^>nyc3.example.com<^>. ; 10.128.20.12
<^>101.100<^> IN PTR <^>host1.nyc3.example.com<^>. ; 10.128.100.101
<^>102.200<^> IN PTR <^>host2.nyc3.example.com<^>. ; 10.128.200.102
Terminamos de editar nuestros archivos. Ahora podemos comprobar si hay errores en nuestros archivos.
Comprobar la sintaxis de la configuración BIND
Ejecute el siguiente comando para comprobar la sintaxis de los archivos named.conf*:
[environment second]
sudo named-checkconf
Si sus archivos de configuración named no tienen errores de sintaxis, volverá a su intérprete de comandos de shell y no verá mensajes de error. Si existen problemas en sus archivos de configuración, revise los mensajes de error y la sección “Configurar un servidor DNS primario”, y luego pruebe named-checkconf una vez más.
El comando named-checkzone se puede utilizar para verificar que sus archivos de zona sean correctos. En el primer argumento de este se especifica el nombre de la zona y en el segundo el archivo de zona correspondiente, que están definidos en named.conf.local.
Por ejemplo, para comprobar la configuración de la zona de reenvío “<^>nyc3.example.com<^>”, ejecute el siguiente comando (cambie los nombres para que coincidan con su zona y archivo de reenvío).
[environment second]
sudo named-checkzone <^>nyc3.example.com<^> db.<^>nyc3.example.com<^>
Para omprobar la configuración de la zona inversa “<^>128.10<^>.in-addr.arpa”, ejecute el siguiente comando (cambie los números para que coincidan con su zona y archivo inversos):
[environment second]
sudo named-checkzone <^>128.10<^>.in-addr.arpa /etc/bind/zones/db.<^>10.128<^>
Cuando no haya errores en sus archivos de configuración y zona, debería estar listo para reiniciar el servicio BIND.
Reiniciar BIND
Reinicie BIND:
[environment second]
sudo systemctl restart bind9
Si configuró el firewall UFW, abra el acceso a BIND escribiendo lo siguiente:
[environment second]
sudo ufw allow Bind9
Con esto, servidor DNS primario quedará configurado y listo para responder a las consultas DNS. Ahora, crearemos el servidor DNS secundario.
Configurar el servidor DNS secundario
En la mayoría de los entornos, se recomienda configurar un servidor DNS secundario que responda a las solicitudes si el primario deja de estar disponible. Afortunadamente, el servidor DNS secundario se puede configurar de una manera mucho más sencilla.
En ns2, edite el archivo named.conf.options:
[environment third]
sudo nano /etc/bind/named.conf.options
En la parte superior del archivo, añada el ACL con las direcciones IP privadas de todos sus servidores de confianza:
[label /etc/bind/named.conf.options — updated 1 of 2 (secondary)]
[environment third]
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, añada las siguientes líneas:
[label /etc/bind/named.conf.options — updated 2 of 2 (secondary)]
[environment third]
recursion yes;
allow-recursion { trusted; };
listen-on { <^>10.128.20.12<^>; }; # ns2 private IP address
allow-transfer { none; }; # disable zone transfers by default
forwarders {
8.8.8.8;
8.8.4.4;
};
Guarde y cierre el archivo named.conf.options. El archivo debería ser exactamente igual al archivo named.conf.options de ns1, excepto porque debería estar configurado para escuchar en la dirección IP privada de ns2.
Ahora, edite el archivo named.conf.local:
[environment third]
sudo nano /etc/bind/named.conf.local
Defina las zonas esclavas que se corresponden con las zonas maestras en el servidor DNS primario. Observe que el tipo es “slave”, el archivo no contiene una ruta y hay una directiva masters que debería fijarse en la dirección IP privada del servidor DNS primario. Si definió varias zonas inversas en el servidor DNS primario, asegúrese de añadirlas en su totalidad aquí:
[label /etc/bind/named.conf.local — updated (secondary)]
[environment third]
zone "<^>nyc3.example.com<^>" {
type slave;
file "db.<^>nyc3.example.com<^>";
masters { <^>10.128.10.11<^>; }; # ns1 private IP
};
zone "<^>128.10<^>.in-addr.arpa" {
type slave;
file "db.<^>10.128<^>";
masters { <^>10.128.10.11<^>; }; # ns1 private IP
};
Ahora, guarde y cierre el archivo named.conf.local.
Ejecute el siguiente comando para comprobar la validez de sus archivos de configuración:
[environment third]
sudo named-checkconf
Una vez comprobado esto, reinicie BIND:
[environment third]
sudo systemctl restart bind9
Permita conexiones DNS al servidor alterando las reglas del firewall UFW:
[environment third]
sudo ufw allow Bind9
Ahora, tiene servidores DNS primario y secundario para la resolución de nombres y direcciones IP de la red privada. Ahora debe configurar sus servidores clientes para usar sus servidores DNS privados.
Configurar clientes DNS
A fin de que todos sus servidores en el ACL “trusted” puedan consultar sus servidores DNS, debe configurar cada uno de ellos para que utilicen ns1 y ns2 como servidores de nombres. Este proceso varía dependiendo de su sistema operativo, pero para la mayoría de distribuciones Linux implica añadir sus servidores de nombres al archivo /etc/resolv.conf.
Clientes de Ubuntu 18.04
En Ubuntu 18.04, la red se configura con Netplan, una abstracción que le permite escribir una configuración de red estandarizada y aplicarla a software de redes de backend no compatible. Para configurar el DNS, debemos escribir un archivo de configuración de Netplan.
Primero, encuentre el dispositivo asociado con su red privada consultando la subred privada con el comando ip address:
[environment fourth]
ip address show to <^>10.128.0.0/16<^>
[secondary_label Output]
[environment fourth]
3: <^>eth1<^>: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
inet 10.128.100.101/16 brd 10.128.255.255 scope global eth1
valid_lft forever preferred_lft forever
En este ejemplo, la interfaz privada es eth1.
A continuación, cree un nuevo archivo en /etc/netplan llamado 00-private-nameservers.yaml:
[environment fourth]
sudo nano /etc/netplan/00-private-nameservers.yaml
Dentro de este, pegue el contenido siguiente. Deberá modificar la interfaz de la red privada, las direcciones de sus servidores DNS ns1 y ns2, y la zona DNS.
Nota: Netplan usa el formato de serialización de datos YAML para sus archivos de configuración. Debido a que YAML utiliza sangría y espacios en blanco para definir la estructura de sus datos, asegúrese de que en su definición se utilice una sangría uniforme para evitar errores.
[label /etc/netplan 00-private-nameservers.yaml]
[environment fourth]
network:
version: 2
ethernets:
<^>eth1<^>: # Private network interface
nameservers:
addresses:
- <^>10.128.10.11<^> # Private IP for ns1
- <^>10.132.20.12<^> # Private IP for ns2
search: [ <^>nyc3.example.com<^> ] # DNS zone
Guarde y cierre el archivo cuando haya terminado.
A continuación, indique a Netplan que intente usar el nuevo archivo de configuración con netplan try. Si existen problemas que ocasionen una pérdida de redes, Netplan cancelará los cambios tras un tiempo de espera:
[environment fourth]
sudo netplan try
[secondary_label Output]
[environment fourth]
Warning: Stopping systemd-networkd.service, but it can still be activated by:
systemd-networkd.socket
Do you want to keep these settings?
Press ENTER before the timeout to accept the new configuration
Changes will revert in 120 seconds
Si la cuenta regresiva se actualiza correctamente en la parte inferior, la nueva configuración es al menos suficientemente funcional como para no interrumpir su conexión SSH. Pulse ENTER para aceptar la nueva configuración.
Ahora, verifique la resolución DNS del sistema para determinar si se plicó su configuración de DNS:
[environment fourth]
sudo systemd-resolve --status
Desplácese hasta ver la sección de la interfaz de su red privada. Debería ver las direcciones IP privadas de sus servidores DNS enumeradas primero, seguidas de algunos valores alternativos. Su dominio debería figurar en “DNS Domain”:
[secondary_label Output]
[environment fourth]
. . .
Link 3 (eth1)
Current Scopes: DNS
LLMNR setting: yes
MulticastDNS setting: no
DNSSEC setting: no
DNSSEC supported: no
DNS Servers: <^>10.128.10.11<^>
<^>10.128.20.12<^>
67.207.67.2
67.207.67.3
DNS Domain: <^>nyc3.example.com<^>
. . .
Con esto, su cliente debería quedar configurado para usar sus servidores DNS internos.
Clientes de Ubuntu 16.04 y Debian
En servidores de Ubuntu 16.04 y Debian Linux, puede editar el archivo /etc/network/interfaces:
[environment fourth]
sudo nano /etc/network/interfaces
En su interior, encuentre la línea dns-nameservers y anteponga sus propios servidores de nombres a la lista que se encuentra allí. Debajo de esa línea, añada una opción dns-search orientada al dominio base de su infraestructura. En nuestro caso, esto sería “nyc3.example.com”:
[label /etc/network/interfaces]
[environment fourth]
. . .
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 y aplique los nuevos cambios con los comandos siguientes. Asegúrese de sustituir eth0 por el nombre de su interfaz de red:
[environment fourth]
sudo ifdown --force <^>eth0<^> && sudo ip addr flush dev <^>eth0<^> && sudo ifup --force <^>eth0<^>
Con esto debería reiniciarse su red sin que se desactive su conexión actual. Si funcionó correctamente, debería ver algo como esto:
[secondary_label Output]
[environment fourth]
RTNETLINK answers: No such process
Waiting for DAD... Done
Compruebe que sus ajustes se hayan aplicado escribiendo lo siguiente:
[environment fourth]
cat /etc/resolv.conf
Debería ver sus servidores de nombres en el archivo /etc/resolv.conf, además de su dominio de búsqueda:
[secondary_label Output]
[environment fourth]
# 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 10.128.10.11
nameserver 10.128.20.12
nameserver 8.8.8.8
search nyc3.example.com
Con esto, su cliente quedará configurado para usar sus servidores DNS.
Clientes CentOS
En CentOS, RedHat y Fedora Linux, edite el archivo /etc/sysconfig/network-scripts/ifcfg-<^>eth0<^>. Es posible que deba sustituir eth0 por el nombre de su interfaz de red primaria:
[environment fourth]
sudo nano /etc/sysconfig/network-scripts/ifcfg-<^>eth0<^>
Busque las opciones DNS1 y DNS2, y fije para ellas las direcciones IP privadas de sus servidores de nombres primario y secundario. Añada un parámetro DOMAIN que será el dominio básico de su infraestructura. En esta guía, sería “nyc3.example.com”:
[label /etc/sysconfig/network-scripts/ifcfg-eth0]
[environment fourth]
. . .
DNS1=<^>10.128.10.11<^>
DNS2=<^>10.128.20.12<^>
<^>DOMAIN='nyc3.example.com'<^>
. . .
Guarde y cierre el archivo cuando haya terminado.
Ahora, reinicie el servicio de red escribiendo lo siguiente:
[environment fourth]
sudo systemctl restart network
El comando puede demorarse unos segundos, pero debería hacer que regrese a la línea de comandos pronto.
Compruebe que sus cambios se hayan aplicado escribiendo lo siguiente:
[environment fourth]
cat /etc/resolv.conf
Debería ver sus servidores de nombres y el dominio de búsqueda en la lista:
[label /etc/resolv.conf]
[environment fourth]
nameserver 10.128.10.11
nameserver 10.128.20.12
search nyc3.example.com
Su cliente ahora debería poder conectarse a sus servidores DNS y usarlos.
Probar clientes
Utilice nslookup para comprobar si sus clientes pueden enviar consultas a sus servidores de nombres. Debería poder hacer esto en todos los clientes que haya configurado y estén en el ACL “trusted”.
Para los clientes de CentOS, es posible que deba instalar la utilidad con lo siguiente:
[environment fourth]
sudo yum install bind-utils
Podemos comenzar realizando una búsqueda directa.
Búsqueda directa
Por ejemplo, podemos realizar una búsqueda directa para obtener la dirección IP de host1.nyc3.example.com ejecutando el siguiente comando:
[environment fourth]
nslookup host1
La consulta de “host1” se expande a “host1.nyc3.example.com” porque la opción search se fijó en su subdominio privado y las consultas de DNS intentarán realizar búsquedas en ese subdominio antes de buscar el host en otra parte. El resultado del comando anterior debería tener este aspecto:
[secondary_label Output]
[environment fourth]
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
Name: host1.nyc3.example.com
Address: 10.128.100.101
A continuación, podemos comprobar búsquedas inversas.
Búsqueda inversa
Para probar la búsqueda inversa, consulte el servidor DNS con la dirección IP privada de host1:
[environment fourth]
nslookup 10.128.100.101
El resultado debería tener el siguiente aspecto:
[secondary_label Output]
[environment fourth]
11.10.128.10.in-addr.arpa name = host1.nyc3.example.com.
Authoritative answers can be found from:
Si los nombres y las direcciones IP se resuelven a los valores correctos, eso significa que sus archivos de zona se configuraron correctamente. Si recibe valores inesperados, asegúrese de revisar los archivos de zona en su servidor DNS primario (por ejemplo, db.nyc3.example.com y db.10.128).
¡Felicitaciones! Sus servidores DNS internos ahora estarán correctamente configurados. A continuación, abordaremos el mantenimiento de sus registros de zona.
Mantener registros DNS
Ahora que dispone de un DNS interno activo, deberá mantener sus registros DNS para que se reflejen de forma precisa en su entorno de servidor.
Añadir un host a un DNS
Siempre que añada un host a su entorno (en el mismo centro de datos), le convendrá añadirlo al DNS. A continuación, se ofrece una lista de los pasos que debe seguir:
Servidor de nombres primario
- Archivo de zona de reenvío: añada un registro “A” para el nuevo host e incremente el valor de “Serial”.
- Archivo de zona inversa: añada un registro “PTR” para el nuevo host e incremente el valor de “Serial”.
- Añada la dirección IP privada del nuevo host al ACL “trusted” (
named.conf.options).
Pruebe sus archivos de configuración:
[environment second]
sudo named-checkconf
sudo named-checkzone <^>nyc3.example.com<^> db.<^>nyc3.example.com<^>
sudo named-checkzone <^>128.10<^>.in-addr.arpa /etc/bind/zones/db.<^>10.128<^>
A continuación, vuelva a cargar BIND:
[environment second]
sudo systemctl reload bind9
Con esto, su servidor primario debería estar configurado para el nuevo host.
Servidor de nombres secundarios
- Añada la dirección IP privada del nuevo host al ACL “trusted” (
named.conf.options).
Compruebe la sintaxis de la configuración:
[environment third]
sudo named-checkconf
A continuación, vuelva a cargar BIND:
[environment third]
sudo systemctl reload bind9
Su servidor secundario ahora aceptará conexiones del nuevo host.
Configure el nuevo host para que use su DNS
- Configure
/etc/resolv.confpara que use sus servidores DNS.
- Realice una prueba usando
nslookup.
Eliminar el host del DNS
Si elimina un host de su entorno, o quiere quitarlo del DNS, simplemente quite todo lo que se añadió cuando agregó el servidor al DNS (es decir, el procedimiento inverso de los pasos anteriores).
Conclusión
Ahora puede consultar las interfaces de red privada de sus servidores por nombre, en lugar de hacerlo por dirección IP. Esto hace que la configuración de los servicios y aplicaciones sea más fácil porque ya no tendrá que recordar las direcciones IP privadas, y será más fácil leer y comprender los archivos. Además, ahora podrá cambiar sus configuraciones para que apunten a un nuevo servidor en un único lugar, su servidor DNS primario, en vez de tener que editar una variedad de archivos de configuración distribuidos, lo cual facilita el mantenimiento.
Una vez que complete su configuración de DNS interna, y que sus archivos de configuración usen FQDN privados para especificar las conexiones de red, será esencial que se realice un mantenimiento correcto de sus servidores DNS. Si los dos dejan de estar disponibles, aquellos de sus servicios y aplicaciones que dependan de ellos dejarán de funcionar correctamente. Por ello, se recomienda configurar su DNS con al menos un servidor secundario y realizar copias de seguridad funcionales de todos ellos.
