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

Introducción

Una parte importante de la gestión de la configuración del servidor y la infraestructura implica mantener una forma de encontrar interfaces de red y direcciones IP por nombre. Una forma de hacer esto es configurar un Sistema de Nombres de Dominio (DNS) adecuado. El uso de nombres de dominio completamente calificados (FQDN), en lugar de direcciones IP, para especificar direcciones de red optimiza la configuración de servicios y aplicaciones, y aumenta la mantenibilidad de los archivos de configuración. Configurar su propio DNS para su red privada es una excelente manera de mejorar la gestión de sus servidores.

En este tutorial, configurará un servidor DNS interno utilizando dos servidores Ubuntu 22.04. Utilizará el software del servidor de nombres BIND (BIND9) para resolver nombres de host privados y direcciones IP privadas. Esto proporciona una forma centralizada de gestionar 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.

Prerrequisitos

Para completar este tutorial, necesitará la siguiente infraestructura. Asegúrese de crear cada servidor en la misma red privada habilitada para el centro de datos:

• A fresh Ubuntu 22.04 server to serve as the Primary DNS server, ns1.
• (Recomendado) Un segundo servidor Ubuntu 22.04 para servir como servidor DNS secundario, ns2.
• Al menos un servidor adicional. Esta guía asume que tienes dos servidores adicionales, los cuales serán referidos como servidores clientes. Estos servidores clientes deben ser creados en el mismo centro de datos donde se encuentran tus servidores DNS.

En cada uno de estos servidores, configura un usuario administrativo sudo y establece un firewall siguiendo nuestra guía de configuración inicial del servidor Ubuntu 22.04 .

Si no estás familiarizado con los conceptos de DNS, recomendamos que leas al menos las tres primeras partes de nuestra Introducción a la Gestión de DNS

Ejemplo de Infraestructura y Objetivos

Para los propósitos de este artículo, asumiremos lo siguiente:

• Tienes dos servidores que serán designados como tus servidores de nombres DNS. Esta guía los referirá como ns1 y ns2.
• Tienes dos servidores adicionales de clientes que utilizarán la infraestructura DNS que crees, denominados host1 y host2 en esta guía. Puedes agregar tantos servidores de clientes como desees.
• Todos estos servidores existen en el mismo centro de datos. Este tutorial asume que este centro de datos se llama nyc3.
• Todos estos servidores tienen habilitada la red privada y están en la subred 10.128.0.0/16 (probablemente debas ajustar esto para tus servidores).
• Todos los servidores están conectados a un proyecto que se ejecuta en example.com. Esta guía describe cómo configurar un sistema DNS interno y privado, para que puedas usar cualquier nombre de dominio que desees en lugar de example.com. Los servidores DNS siempre intentarán primero enrutar las solicitudes internamente, lo que significa que no intentarán alcanzar el dominio dado en Internet público. Sin embargo, usar un dominio propio puede ayudar a evitar conflictos con dominios enrutables públicamente.

Con estas suposiciones en mente, los ejemplos en esta guía utilizarán un esquema de nomenclatura basado en el subdominio nyc3.example.com para referirse a la subred o zona privada de ejemplo. Por lo tanto, el Nombre de Dominio Completo (FQDN) privado de host1 será host1.nyc3.example.com. La siguiente tabla contiene los detalles relevantes utilizados en ejemplos a lo largo de esta guía:

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

A medida que siga este tutorial, habrá momentos en los que deberá ejecutar ciertos comandos en un servidor específico en esta configuración. Cualquier comando que deba ejecutarse en ns1 tendrá un fondo azul, como este:

De igual manera, cualquier comando que deba ejecutarse en ns2 tendrá un fondo rojo:

Y cualquier comando que deba ejecutarse en uno de sus servidores clientes tendrá un fondo verde:

Y cualquier comando que deba ejecutarse en múltiples servidores tendrá un fondo azul marino estándar:

Finalmente, ten en cuenta que cada vez que un comando o bloque de código contiene texto resaltado como este, significa que ese texto es importante. Este tipo de resaltado se utilizará en toda esta guía para indicar detalles que deben ser reemplazados con tu propia configuración o que el texto resaltado debe ser modificado o agregado a un archivo de configuración. Por ejemplo, si un ejemplo contiene algo como host1.nyc3.example.com, reemplázalo con el FQDN de tu propio servidor.

Comencemos instalando BIND en tus servidores DNS primario y secundario, ns1 y ns2.

Paso 1 — Instalando BIND en los Servidores DNS

En ambos servidores DNS, ns1 y ns2, actualiza el caché de paquetes apt escribiendo:

sudo apt update

Luego instala BIND en cada máquina:

sudo apt install bind9 bind9utils bind9-doc

La red privada de DigitalOcean utiliza exclusivamente IPv4. Si este es tu caso, configura BIND en modo IPv4. En ambos servidores, edita el archivo de configuración predeterminado de named usando tu editor de texto preferido. El siguiente ejemplo utiliza nano:

sudo nano /etc/default/named

Agrega -4 al final del parámetro OPTIONS:

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

Guarda y cierra el archivo cuando hayas terminado. Si usaste nano para editar el archivo, puedes hacerlo presionando CTRL + X, Y, luego ENTER.

Reinicie BIND para implementar los cambios.

sudo systemctl restart bind9

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

Paso 2: Configurar el Servidor DNS Primario

La configuración de BIND consiste en múltiples 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 ejecuta BIND (siendo named una abreviatura de “name daemon”, como en “domain name daemon”). Comenzaremos configurando el archivo named.conf.options.

Configurando el Archivo de Opciones

En ns1, abra el archivo named.conf.options para editarlo:

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

Encima del bloque options existente, crea un nuevo bloque ACL (lista de control de acceso) llamado trusted. Aquí es donde definirás una lista de clientes a los que permitirás consultas DNS recursivas (es decir, tus servidores que están en el mismo centro de datos que ns1). Agrega las siguientes líneas para añadir ns1, ns2, host1 y host2 a tu lista de clientes de confianza, asegurándote de reemplazar las direcciones IP privadas de ejemplo por las de tus propios servidores:

acl "trusted" {
        10.128.10.11;    # ns1 
        10.128.20.12;    # ns2
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

Ahora que tienes tu lista de clientes de DNS de confianza, puedes editar el bloque options. Actualmente, este es el inicio del bloque:

        . . .
};

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

Debajo de la directiva directory, agrega las líneas de configuración resaltadas (y sustituye la dirección IP privada de ns1 por la apropiada):

        . . .

};

options {
        directory "/var/cache/bind";
        
        recursion yes;                 # enables recursive 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;
        };

        . . .
};

Observa el bloque forwarders, que incluye dos direcciones IP: 8.8.8.8 y 8.8.4.4. Este bloque define forwarders, un mecanismo especial que BIND utiliza para reducir el tráfico sobre enlaces a servidores de nombres externos. BIND también puede usar forwarders para permitir consultas de servidores que no tienen acceso directo a internet. Esto puede ayudar a que las respuestas a estas consultas sean más rápidas al reducir la carga en la red local.

Las dos direcciones IP en este bloque representan los servidores DNS públicos de Google, pero la dirección IP de cualquier servidor de nombres recursivos público funcionará aquí. Por ejemplo, podrías usar la dirección IP del servidor DNS de Cloudflare (1.1.1.1) en su lugar.

Cuando hayas terminado, guarda y cierra el archivo named.conf.options. La configuración anterior especifica que solo tus propios servidores (los confiables) podrán consultar tu servidor DNS para dominios externos.

A continuación, especificarás tus zonas DNS configurando el archivo named.conf.local.

Configurando el Archivo Local

En ns1, abre el archivo named.conf.local para editarlo:

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

Excepto por algunos comentarios, el archivo estará vacío. Aquí, especificarás tus zonas de avance y de retroceso. Las zonas DNS designan un ámbito específico para gestionar y definir registros DNS. Dado que los dominios de ejemplo de esta guía estarán todos dentro del subdominio nyc3.example.com, usaremos eso como nuestra zona de avance. Dado que las direcciones IP privadas de nuestros servidores de ejemplo están en el espacio de direcciones IP 10.128.0.0/16 cada una, el siguiente ejemplo configurará una zona de retroceso para que podamos definir búsquedas de retroceso dentro de ese rango.

Agrega la zona de avance con las siguientes líneas, sustituyendo el nombre de la zona con el tuyo propio y la dirección IP privada del servidor DNS secundario en la directiva allow-transfer:

. . .

zone "nyc3.example.com" {
    type primary;
    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, agrega la zona de retroceso con las siguientes líneas (nota que el nombre de nuestra zona de retroceso comienza con 128.10 que es la inversión de octeto de 10.128):

    . . .
};

zone "128.10.in-addr.arpa" {
    type primary;
    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 haya terminado de agregar todas las zonas deseadas, guarde y cierre el archivo named.conf.local.

Ahora que ha especificado sus zonas en BIND, debe crear los archivos de zona correspondientes, tanto para la zona de avance como para la de retroceso.

Creando el archivo de zona de avance

El archivo de zona de avance es donde se definen los registros DNS para búsquedas de DNS de avance. Es decir, cuando el DNS recibe una consulta de nombre, como host1.nyc3.example.com, buscará en el archivo de zona de avance para resolver la dirección IP privada correspondiente de host1.

Cree el directorio donde se guardarán los archivos de zona. Según la configuración de named.conf.local, la ubicación debería ser /etc/bind/zones:

sudo mkdir /etc/bind/zones

Basaremos nuestro ejemplo de archivo de zona de avance en el archivo de zona de muestra db.local. Copie el archivo en la ubicación adecuada con los siguientes comandos:

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

Ahora edite su archivo de zona de avance:

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

Inicialmente, contendrá contenido similar al siguiente:

$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, querrás editar el registro SOA. Reemplaza el primer `localhost` con el FQDN de ns1, luego reemplaza root.localhost con admin.nyc3.example.com. Cada vez que edites un archivo de zona, necesitas incrementar el valor de Serial antes de reiniciar el proceso named. Aquí, incréméntalo a 3:

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

                              . . .

A continuación, borra los tres registros al final del archivo (después del registro SOA). Si no estás seguro de qué líneas borrar, están marcadas con comentarios que dicen delete this line en el ejemplo anterior.

Al final del archivo, agrega tus registros de servidor de nombres con las siguientes líneas (reemplaza los nombres con los tuyos). Ten 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, agrega los registros A para tus hosts que pertenecen a esta zona. Esto incluye cualquier servidor cuyo nombre quieras terminar con .nyc3.example.com (sustituye los nombres y direcciones IP privadas). Usando nuestros nombres de ejemplo y direcciones IP privadas, agregaremos registros A para ns1, ns2, host1, y host2 así:

. . .

; 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

Nuestro archivo de zona de avance final de ejemplo contendrá el siguiente contenido:

$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

Guarda y cierra el archivo db.nyc3.example.com.

Ahora pasemos a los archivo(s) de zona inversa.

Creación del(los) Archivo(s) de Zona Inversa

Archivos de zona inversa son donde defines registros DNS PTR para búsquedas DNS inversas. Es decir, cuando el DNS recibe una consulta por dirección IP, por ejemplo, 10.128.100.101, buscará en el(los) archivo(s) de zona inversa para resolver el FQDN correspondiente, en este caso, host1.nyc3.example.com.

En ns1, para cada zona inversa especificada en el archivo named.conf.local, crea un archivo de zona inversa. Basaremos nuestro(s) archivo(s) de zona inversa de ejemplo en el archivo de zona de muestra db.127. BIND utiliza este archivo para almacenar información para la interfaz de bucle local; 127 es el primer octeto de la dirección IP que representa localhost (127.0.0.1). Copia este archivo a la ubicación adecuada con los siguientes comandos (sustituyendo el nombre de archivo de destino para que coincida con tu definición de zona inversa):

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

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

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

Inicialmente, el archivo contendrá contenido como el siguiente:

$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

De la misma manera que el archivo de zona directa, querrás editar el registro SOA e incrementar el valor de serial:

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

                              . . .

Ahora elimina los dos registros al final del archivo (después del registro SOA). Si no estás seguro de qué líneas eliminar, están marcadas con un comentario eliminar esta línea en el ejemplo anterior.

Al final del archivo, agrega tus registros de servidor de nombres con las siguientes líneas (sustituye los nombres con los tuyos propios). Ten 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.

A continuación, agregue 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 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:

. . .

; 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

Su archivo de zona inversa final será similar al siguiente:

$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

Guarde y cierre el archivo de zona inversa. Si necesita agregar más archivos de zona inversa, repita esta sección.

Ha terminado de editar sus archivos, así que a continuación puede verificar si hay errores en ellos.

Comprobando la Sintaxis de Configuración de BIND

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

sudo named-checkconf

Si sus archivos de configuración de named no tienen errores de sintaxis, no habrá mensajes de error y volverá al indicador de su shell. Si hay problemas con sus archivos de configuración, revise el mensaje de error y la sección Configurar el Servidor DNS Principal, luego vuelva a intentar named-checkconf.

El comando named-checkzone se puede utilizar para verificar la corrección de sus 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 verificar la configuración de la zona de avance nyc3.example.com, ejecute el siguiente comando (cambie los nombres para que coincidan con su zona de avance y archivo):

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

Output
zone nyc3.example.com/IN: loaded serial 3
OK

Y para verificar 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 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, estará listo para reiniciar el servicio BIND.

Reiniciar BIND

Reiniciar BIND:

sudo systemctl restart bind9

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

sudo ufw allow Bind9

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

Paso 3 — Configurar el Servidor DNS Secundario

En la mayoría de los entornos, es una buena idea configurar un servidor DNS secundario que responderá a las solicitudes en caso de que el primario no esté disponible. Afortunadamente, la configuración del servidor DNS secundario es mucho menos complicada que la del primario.

En ns2, edita el archivo named.conf.options:

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

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

acl "trusted" {
        10.128.10.11;   # ns1
        10.128.20.12;   # ns2 
        10.128.100.101;  # host1
        10.128.200.102;  # host2
};

options {

        . . .

Debajo de la directiva directory, agrega las siguientes líneas:

    . . .

        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;
        };

    . . .

Guarda y cierra el archivo named.conf.options. Este archivo debería ser idéntico al archivo named.conf.options de ns1, excepto que debe estar configurado para escuchar en la dirección IP privada de ns2.

Ahora edita el archivo named.conf.local:

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

Define zonas secundarias que correspondan a las zonas primarias en el servidor DNS primario. Ten en cuenta que el tipo es secondary, el archivo no contiene una ruta y hay una directiva primaries que debe establecerse en la dirección IP privada del servidor DNS primario. Si definiste múltiples zonas inversas en el servidor DNS primario, asegúrate de agregarlas todas aquí:

zone "nyc3.example.com" {
    type secondary;
    file "db.nyc3.example.com";
    primaries { 10.128.10.11; };  # ns1 private IP
};

zone "128.10.in-addr.arpa" {
    type secondary;
    file "db.10.128";
    primaries { 10.128.10.11; };  # ns1 private IP
};

Ahora guarda y cierra el archivo named.conf.local.

Ejecuta el siguiente comando para verificar la validez de tus archivos de configuración:

sudo named-checkconf

Si este comando no devuelve errores, reinicia BIND:

sudo systemctl restart bind9

Después, permite las conexiones DNS al servidor modificando las reglas del firewall UFW:

sudo ufw allow Bind9

Con eso, ahora tienes servidores DNS primarios y secundarios para la resolución de nombres de red privada y direcciones IP. Ahora debes configurar tus servidores clientes para usar tus servidores DNS privados.

Paso 4 — Configuración de Clientes DNS

Antes de que todos tus servidores en la ACL trusted puedan consultar tus servidores DNS, debes configurar cada uno de ellos para usar ns1 y ns2 como servidores de nombres.

Suponiendo que tus servidores clientes están ejecutando Ubuntu, necesitarás encontrar qué dispositivo está asociado con tu red privada. Puedes hacer esto consultando la subred privada con el comando ip address. Ejecuta el siguiente comando en cada una de tus máquinas cliente, reemplazando la subred destacada con la tuya propia:

ip address show to 10.128.0.0/16

Output
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    altname enp0s4
    altname ens4
    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. Los ejemplos a lo largo de esta sección se referirán a eth1 como la interfaz privada, pero debes cambiar estos ejemplos para reflejar las interfaces privadas de tus propios servidores.

En Ubuntu 22.04, la configuración de red se realiza con Netplan, una abstracción que te permite escribir una configuración de red estandarizada y aplicarla a software de red compatible. Para configurar DNS, necesitas escribir un archivo de configuración de Netplan.

Crea un archivo nuevo en /etc/netplan llamado 00-private-nameservers.yaml:

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

Dentro, agregue el siguiente contenido. Necesitará modificar la interfaz de la red privada, las direcciones de sus servidores DNS ns1 y ns2, y la zona DNS:

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 utilizar el nuevo archivo de configuración utilizando netplan try. Si hay problemas que causan una pérdida de conectividad 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.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 lo suficientemente funcional como para no romper su conexión SSH. Presione ENTER para aceptar la nueva configuración.

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

sudo resolvectl status

Desplácese hacia abajo hasta encontrar la sección para la interfaz de red privada. Las direcciones IP privadas de sus servidores DNS deben aparecer primero, seguidas de algunos valores de respaldo. Su dominio debe aparecer después de DNS Domain:

Output
. . .

Link 3 (eth1)
    Current Scopes: DNS
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 67.207.67.3
       DNS Servers: 10.128.10.11 10.128.20.12 67.207.67.3 67.207.67.2
        DNS Domain: nyc3.example.com

Su cliente de Ubuntu ahora está configurado para utilizar sus servidores DNS internos.

Paso 5 — Prueba de Clientes

Utiliza nslookup para probar si tus clientes pueden realizar consultas a tus servidores de nombres. Deberías poder hacer esto en todos los clientes que hayas configurado y que estén en la lista trusted ACL.

Puedes empezar realizando una búsqueda directa.

Búsqueda Directa

Para realizar una búsqueda directa y obtener la dirección IP de host1.nyc3.example.com, ejecuta el siguiente comando:

nslookup host1

La consulta de host1 se expande a host1.nyc3.example.com porque la opción search está configurada para tu subdominio privado, y las consultas DNS intentarán buscar en ese subdominio antes de buscar en otro lugar. El comando anterior devolverá un resultado como el siguiente:

Output
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, puedes verificar las búsquedas inversas.

Búsqueda Inversa

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

nslookup 10.128.100.101

Esto debería devolver un resultado como el 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 correctamente, eso significa que tus archivos de zona están configurados correctamente. Si recibes valores inesperados, asegúrate de revisar los archivos de zona en tu servidor DNS primario (por ejemplo, db.nyc3.example.com y db.10.128).

Como paso final, este tutorial te mostrará cómo puedes mantener tus registros de zona.

Paso 6: Mantenimiento de los registros DNS

Ahora que tienes un DNS interno funcional, necesitas mantener tus registros DNS para que reflejen correctamente tu entorno de servidor.

Agregar un host al DNS

Cada vez que agregues un host a tu entorno (en el mismo centro de datos), querrás agregarlo al DNS. Aquí tienes una lista de pasos que debes seguir:

Servidor de nombres primario

• Archivo de zona de avance: Agrega un registro A para el nuevo host, incrementa el valor de Serial
• Archivo de zona inversa: Agrega un registro PTR para el nuevo host, incrementa el valor de Serial
• Agrega la dirección IP privada de tu nuevo host a la ACL trusted (named.conf.options)

Prueba tus archivos de configuración:

sudo named-checkconf
sudo named-checkzone nyc3.example.com /etc/bind/zones/db.nyc3.example.com
sudo named-checkzone 128.10.in-addr.arpa /etc/bind/zones/db.10.128

Luego recarga BIND:

sudo systemctl reload bind9

Ahora tu servidor primario debería estar configurado para el nuevo host.

Servidor de Nombres Secundario

• Agrega la dirección IP privada de tu nuevo host al ACL trusted (named.conf.options)

Verifica la sintaxis de la configuración:

sudo named-checkconf

Luego recarga BIND:

sudo systemctl reload bind9

Tu servidor secundario ahora aceptará conexiones del nuevo host.

Configura el Nuevo Host para Usar tu DNS

• Configura /etc/resolv.conf para usar tus servidores DNS
• Prueba usando nslookup

Eliminando un Host del DNS

Si eliminas un host de tu entorno o simplemente quieres sacarlo del DNS, solo elimina todas las cosas que se agregaron cuando añadiste el servidor al 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, ya que ya no es necesario recordar las direcciones IP privadas, y los archivos serán menos difíciles de leer y entender. 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 optimiza el mantenimiento.

Una vez que tenga configurado su DNS interno y sus archivos de configuración estén utilizando FQDN privados para especificar conexiones de red, es crítico que sus servidores DNS se mantengan adecuadamente. Si ambos se vuelven inaccesibles, sus servicios y aplicaciones que dependen de ellos dejarán de funcionar correctamente. Por eso se recomienda configurar su DNS con al menos un servidor secundario y mantener copias de seguridad funcionales de todos ellos.

Si desea obtener más información sobre DNS, le animamos a consultar nuestro artículo Una Introducción a la Terminología, Componentes y Conceptos de DNS.