Como Configurar o BIND como um Servidor DNS de Rede Privada no Ubuntu 22.04

Introdução

Uma parte importante da gestão da configuração do servidor e da infraestrutura envolve manter uma maneira de encontrar interfaces de rede e endereços IP por nome. Uma maneira de fazer isso é configurar um Sistema de Nomes de Domínio (DNS) adequado. O uso de nomes de domínio totalmente qualificados (FQDNs), em vez de endereços IP, para especificar endereços de rede otimiza a configuração de serviços e aplicativos, e aumenta a manutenção de arquivos de configuração. Configurar seu próprio DNS para sua rede privada é uma ótima maneira de melhorar a gestão de seus servidores.

Neste tutorial, você configurará um servidor DNS interno usando dois servidores Ubuntu 22.04. Você usará o software de servidor de nomes BIND (BIND9) para resolver nomes de host privados e endereços IP privados. Isso fornece uma maneira central de gerenciar seus nomes de host internos e endereços IP privados, o que é indispensável quando seu ambiente se expande para mais do que alguns hosts.

Pré-requisitos

Para concluir este tutorial, você precisará da seguinte infraestrutura. Certifique-se de criar cada servidor na mesma rede privada ativada no datacenter:

• A fresh Ubuntu 22.04 server to serve as the Primary DNS server, ns1.
• (Recomendado) Um segundo servidor Ubuntu 22.04 para servir como servidor DNS secundário, ns2.
• Pelo menos um servidor adicional. Este guia pressupõe que você tenha dois servidores adicionais, que serão referidos como servidores clientes. Esses servidores clientes devem ser criados no mesmo datacenter onde estão localizados seus servidores DNS.

Em cada um desses servidores, configure um usuário administrativo sudo e configure um firewall seguindo nosso guia de configuração inicial do servidor Ubuntu 22.04.

Se você não estiver familiarizado com os conceitos de DNS, recomendamos que você leia pelo menos as três primeiras partes do nosso Introdução à Administração de DNS

Exemplo de Infraestrutura e Metas

Para os fins deste artigo, vamos assumir o seguinte:

• Você possui dois servidores que serão designados como seus servidores de nomes DNS. Este guia se referirá a eles como ns1 e ns2.
• Você tem dois servidores adicionais de clientes que usarão a infraestrutura DNS que você cria, referidos como host1 e host2 neste guia. Você pode adicionar quantos servidores de clientes desejar.
• Todos esses servidores existem no mesmo datacenter. Este tutorial pressupõe que este datacenter seja chamado nyc3.
• Todos esses servidores têm a rede privada ativada e estão na sub-rede 10.128.0.0/16 (você provavelmente terá que ajustar isso para seus servidores).
• Todos os servidores estão conectados a um projeto que roda em example.com. Este guia descreve como configurar um sistema de DNS interno e privado, para que você possa usar qualquer nome de domínio que desejar, em vez de example.com. Os servidores DNS sempre tentarão primeiro rotear solicitações internamente, o que significa que eles não tentarão alcançar o domínio fornecido na internet pública. No entanto, usar um domínio que você possui pode ajudar a evitar conflitos com domínios publicamente roteáveis.

Com essas suposições em mente, os exemplos neste guia usarão um esquema de nomenclatura baseado no subdomínio nyc3.example.com para se referir à sub-rede ou zona privada de exemplo. Portanto, o nome de domínio completo privado (FQDN) do host1 será host1.nyc3.example.com. A tabela a seguir contém os detalhes relevantes usados nos exemplos ao longo deste guia:

Até o final deste tutorial, você terá um servidor DNS primário, ns1, e opcionalmente um servidor DNS secundário, ns2, que servirá como backup.

Ao seguir este tutorial, haverá momentos em que você precisará executar determinados comandos em um servidor específico nesta configuração. Quaisquer comandos que precisem ser executados em ns1 terão um fundo azul, como este:

Da mesma forma, quaisquer comandos que precisem ser executados em ns2 terão um fundo vermelho:

E quaisquer comandos que precisem ser executados em um de seus servidores clientes terão um fundo verde:

E quaisquer comandos que precisem ser executados em múltiplos servidores terão um fundo azul marinho padrão:

Por último, esteja ciente de que sempre que um comando ou bloco de código contiver texto destacado como este, significa que esse texto é importante. Esse tipo de destaque será usado ao longo deste guia para indicar detalhes que precisam ser substituídos por suas próprias configurações ou que o texto destacado deve ser modificado ou adicionado a um arquivo de configuração. Por exemplo, se um exemplo contiver algo como host1.nyc3.example.com, substitua-o pelo FQDN do seu próprio servidor.

Vamos começar instalando o BIND em ambos os seus servidores DNS primário e secundário, ns1 e ns2.

Passo 1 — Instalando o BIND nos Servidores DNS

Em ambos os servidores DNS, ns1 e ns2, atualize o cache de pacotes apt digitando:

sudo apt update

Em seguida, instale o BIND em cada máquina:

sudo apt install bind9 bind9utils bind9-doc

A rede privada da DigitalOcean usa exclusivamente o IPv4. Se este for o seu caso, defina o BIND para o modo IPv4. Em ambos os servidores, edite o arquivo de configuração padrão do named usando o seu editor de texto preferido. O exemplo a seguir usa o nano:

sudo nano /etc/default/named

Adicione -4 ao final do parâmetro OPTIONS:

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

Salve e feche o arquivo quando terminar. Se você usou o nano para editar o arquivo, pode fazer isso pressionando CTRL + X, Y, e então ENTER.

Reinicie o BIND para implementar as alterações:

sudo systemctl restart bind9

Agora que o BIND está instalado, vamos configurar o servidor DNS primário.

Passo 2 — Configurando o Servidor DNS Primário

A configuração do BIND consiste em vários arquivos que são incluídos a partir do arquivo de configuração principal, named.conf. Esses nomes de arquivo começam com named porque esse é o nome do processo que o BIND executa (com named sendo abreviação de “name daemon”, como em “domain name daemon”). Vamos começar configurando o arquivo named.conf.options.

Configurando o Arquivo de Opções

No ns1, abra o arquivo named.conf.options para edição:

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

Acima do bloco options existente, crie um novo bloco ACL (lista de controle de acesso) chamado trusted. Aqui é onde você irá definir uma lista de clientes dos quais permitirá consultas DNS recursivas (ou seja, seus servidores que estão no mesmo datacenter que ns1). Adicione as seguintes linhas para adicionar ns1, ns2, host1 e host2 à sua lista de clientes confiáveis, garantindo substituir os exemplos de endereços IP privados pelos de seus próprios servidores:

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

options {

        . . .

Agora que você tem sua lista de clientes DNS confiáveis, você pode editar o bloco options. Atualmente, este é o início do bloco:

        . . .
};

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

Abaixo da diretiva directory, adicione as linhas de configuração destacadas (e substitua pelo endereço IP privado apropriado de ns1):

        . . .

};

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

        . . .
};

Observe o bloco forwarders, que inclui dois endereços IP: 8.8.8.8 e 8.8.4.4. Este bloco define forwarders, um mecanismo especial que o BIND usa para reduzir o tráfego sobre links para servidores de nomes externos. O BIND também pode usar forwarders para permitir consultas por servidores que não têm acesso direto à Internet. Isso pode ajudar a tornar as respostas a essas consultas mais rápidas, reduzindo a carga na rede local.

Os dois endereços IP neste bloco representam os resolutores DNS públicos do Google, mas o endereço IP de qualquer servidor de nomes recursivo público funcionará aqui. Por exemplo, você poderia usar o endereço IP do servidor DNS do Cloudflare (1.1.1.1) em vez disso.

Quando terminar, salve e feche o arquivo named.conf.options. A configuração acima especifica que apenas seus próprios servidores (os trusted) poderão consultar seu servidor DNS para domínios externos.

Em seguida, você especificará suas zonas DNS configurando o arquivo named.conf.local.

Configurando o Arquivo Local

Em ns1, abra o arquivo named.conf.local para edição:

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

Além de alguns comentários, o arquivo estará vazio. Aqui, você especificará suas zonas de encaminhamento e reverso. Zonas DNS designam um escopo específico para gerenciar e definir registros DNS. Como os domínios de exemplo deste guia estarão todos dentro do subdomínio nyc3.example.com, usaremos isso como nossa zona de encaminhamento. Como os endereços IP privados de exemplo dos nossos servidores estão cada um no espaço IP 10.128.0.0/16, o exemplo a seguir configurará uma zona reversa para que possamos definir pesquisas reversas dentro desse intervalo.

Adicione a zona de encaminhamento com as seguintes linhas, substituindo o nome da zona pelo seu próprio e o endereço IP privado do servidor DNS secundário na diretiva 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
};

Supondo que nossa sub-rede privada seja 10.128.0.0/16, adicione a zona reversa com as seguintes linhas (observe que o nome da nossa zona reversa começa com 128.10, que é a inversão do 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
};

Se os seus servidores abrangem várias sub-redes privadas, mas estão no mesmo datacenter, certifique-se de especificar uma zona adicional e um arquivo de zona para cada sub-rede distinta. Quando terminar de adicionar todas as zonas desejadas, salve e feche o arquivo named.conf.local.

Agora que suas zonas estão especificadas no BIND, você precisa criar os arquivos de zona correspondentes para encaminhamento e inversão.

Criando o Arquivo de Zona de Encaminhamento

O arquivo de zona de encaminhamento é onde você define registros DNS para consultas de DNS de encaminhamento. Ou seja, quando o DNS recebe uma consulta de nome, como host1.nyc3.example.com, por exemplo, ele procurará no arquivo de zona de encaminhamento para resolver o endereço IP privado correspondente de host1.

Crie o diretório onde seus arquivos de zona serão armazenados. De acordo com a configuração do named.conf.local, esse local deve ser /etc/bind/zones:

sudo mkdir /etc/bind/zones

Vamos basear nosso exemplo de arquivo de zona de encaminhamento no arquivo de zona de exemplo db.local. Copie-o para o local apropriado com os seguintes comandos:

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

Agora edite o seu arquivo de zona de encaminhamento:

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

Inicialmente, ele conterá conteúdo como o seguinte:

$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

Primeiro, você vai querer editar o registro SOA. Substitua o primeiro localhost pelo FQDN de ns1, em seguida, substitua root.localhost por admin.nyc3.example.com. Sempre que você editar um arquivo de zona, você precisa incrementar o valor do Serial antes de reiniciar o processo named. Aqui, incremente para 3:

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

                              . . .

Em seguida, delete os três registros no final do arquivo (após o registro SOA). Se você não tiver certeza de quais linhas excluir, elas estão marcadas com comentários lendo delete this line no exemplo anterior.

No final do arquivo, adicione seus registros de servidor de nomes com as seguintes linhas (substitua os nomes pelos seus próprios). Observe que a segunda coluna especifica que estes são registros NS:

. . .

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

Agora, adicione os registros A para seus hosts que pertencem a esta zona. Isso inclui qualquer servidor cujo nome você queira terminar com .nyc3.example.com (substitua os nomes e endereços IP privados). Usando nossos nomes de exemplo e endereços IP privados, vamos adicionar registros A para ns1, ns2, host1, e host2 assim:

. . .

; 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

Nosso arquivo de zona forward final de exemplo conterá o seguinte conteúdo:

$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

Salve e feche o arquivo db.nyc3.example.com.

Agora vamos passar para o(s) arquivo(s) de zona reversa.

Criando o(s) Arquivo(s) de Zona Reversa

Os arquivos de zona reversa são onde você define registros DNS PTR para pesquisas DNS reversas. Ou seja, quando o DNS recebe uma consulta por endereço IP, 10.128.100.101 por exemplo, ele procurará no(s) arquivo(s) de zona reversa para resolver o FQDN correspondente, host1.nyc3.example.com neste caso.

Em ns1, para cada zona reversa especificada no arquivo named.conf.local, crie um arquivo de zona reversa. Vamos basear nossos exemplos de arquivos de zona reversa no arquivo de zona db.127 de exemplo. O BIND usa este arquivo para armazenar informações para a interface local loopback; 127 é o primeiro octeto do endereço IP que representa localhost (127.0.0.1). Copie este arquivo para o local adequado com os seguintes comandos (substituindo o nome do arquivo de destino para que corresponda à sua definição de zona reversa):

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

Edite o arquivo de zona reversa que corresponde à(s) zona(s) reversa(s) definida(s) em named.conf.local:

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

Inicialmente, o arquivo conterá conteúdo como o seguinte:

$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

Da mesma maneira que o arquivo de zona de encaminhamento, você vai querer editar o registro SOA e incrementar o valor serial:

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

                              . . .

Agora exclua os dois registros no final do arquivo (após o registro SOA). Se você não tem certeza de quais linhas excluir, elas estão marcadas com um comentário delete this line no exemplo anterior.

No final do arquivo, adicione seus registros de servidor de nomes com as seguintes linhas (substitua os nomes pelos seus próprios). Observe que a segunda coluna especifica que esses são registros NS:

. . .

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

Então adicione registros PTR para todos os seus servidores cujos endereços IP estão na sub-rede do arquivo de zona que você está editando. No nosso exemplo, isso inclui todos os nossos hosts, pois todos estão na sub-rede 10.128.0.0/16. Observe que a primeira coluna consiste nos dois últimos octetos dos endereços IP privados de seus servidores em ordem inversa. Certifique-se de substituir nomes e endereços IP privados para coincidir com seus 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

Seu exemplo final de arquivo de zona reversa será semelhante ao seguinte:

$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

Salve e feche o arquivo de zona reversa. Se precisar adicionar mais arquivos de zona reversa, repita esta seção.

Você concluiu a edição de seus arquivos, agora pode verificar se há erros.

Verificando a Sintaxe da Configuração do BIND

Execute o seguinte comando para verificar a sintaxe dos arquivos named.conf*:

sudo named-checkconf

Se seus arquivos de configuração do named não tiverem erros de sintaxe, não haverá mensagens de erro, e você retornará ao prompt de comando. Se houver problemas com seus arquivos de configuração, reveja a mensagem de erro e a seção Configurar Servidor DNS Primário, depois tente novamente o comando named-checkconf.

O comando named-checkzone pode ser utilizado para verificar a correção dos seus arquivos de zona. Seu primeiro argumento especifica um nome de zona, e o segundo argumento especifica o arquivo de zona correspondente, ambos definidos no arquivo named.conf.local.

Por exemplo, para verificar a configuração da zona de encaminhamento nyc3.example.com, execute o seguinte comando (altere os nomes para corresponder à sua zona de encaminhamento e arquivo):

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

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

E para verificar a configuração da zona reversa 128.10.in-addr.arpa, execute o seguinte comando (altere os números para corresponder à sua zona reversa e arquivo):

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

Quando todos os seus arquivos de configuração e zona não apresentarem erros, você estará pronto para reiniciar o serviço BIND.

Reiniciando o BIND

Reinicie o BIND:

sudo systemctl restart bind9

Se você tiver o firewall UFW configurado, abra o acesso ao BIND digitando:

sudo ufw allow Bind9

Seu servidor DNS primário está agora configurado e pronto para responder a consultas DNS. Vamos avançar para configurar o servidor DNS secundário.

Passo 3 — Configurando o Servidor DNS Secundário

Na maioria dos ambientes, é uma boa ideia configurar um servidor DNS secundário que responderá a solicitações caso o primário fique indisponível. Felizmente, configurar o servidor DNS secundário é muito menos complicado do que configurar o primário.

Em ns2, edite o arquivo named.conf.options:

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

No topo do arquivo, adicione a ACL com os endereços IP privados de todos os seus servidores confiáveis:

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

options {

        . . .

Abaixo da diretiva directory, adicione as seguintes linhas:

    . . .

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

    . . .

Salve e feche o arquivo named.conf.options. Este arquivo deve ser idêntico ao arquivo named.conf.options de ns1, exceto que deve ser configurado para ouvir no endereço IP privado de ns2.

Agora, edite o arquivo named.conf.local:

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

Defina zonas secundárias que correspondam às zonas primárias no servidor DNS primário. Observe que o tipo é secondary, o arquivo não contém um caminho, e há uma diretiva primaries que deve ser configurada com o endereço IP privado do servidor DNS primário. Se você definiu várias zonas reversas no servidor DNS primário, certifique-se de adicioná-las todas aqui:

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

Agora, salve e feche o arquivo named.conf.local.

Execute o seguinte comando para verificar a validade de seus arquivos de configuração:

sudo named-checkconf

Se este comando não retornar erros, reinicie o BIND:

sudo systemctl restart bind9

Em seguida, permita conexões DNS ao servidor alterando as regras do firewall UFW:

sudo ufw allow Bind9

Com isso, você agora tem servidores DNS primário e secundário para resolução de nome e endereço IP da rede privada. Agora, você deve configurar seus servidores clientes para usar seus servidores DNS privados.

Passo 4 — Configurando Clientes DNS

Antes que todos os seus servidores na ACL trusted possam consultar seus servidores DNS, você deve configurar cada um deles para usar ns1 e ns2 como servidores de nomes.

Supondo que seus servidores clientes estejam executando Ubuntu, você precisará encontrar qual dispositivo está associado à sua rede privada. Você pode fazer isso consultando a sub-rede privada com o comando ip address. Execute o seguinte comando em cada uma de suas máquinas cliente, substituindo a sub-rede destacada pela sua:

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

Neste exemplo, a interface privada é eth1. Os exemplos nesta seção se referirão a eth1 como a interface privada, mas você deve alterar esses exemplos para refletir as interfaces privadas de seus próprios servidores.

No Ubuntu 22.04, a rede é configurada com o Netplan, uma abstração que permite escrever configurações de rede padronizadas e aplicá-las a software de rede de backend compatível. Para configurar o DNS, você precisa escrever um arquivo de configuração do Netplan.

Crie um novo arquivo em /etc/netplan chamado 00-private-nameservers.yaml:

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

Dentro, adicione os seguintes conteúdos. Você precisará modificar a interface da rede privada, os endereços de seus servidores DNS ns1 e ns2, e a 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

Salve e feche o arquivo quando terminar.

Em seguida, diga ao Netplan para tentar usar o novo arquivo de configuração usando netplan try. Se houver problemas que causem perda de conexão de rede, o Netplan automaticamente desfará as alterações após um tempo limite:

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

Se a contagem regressiva estiver atualizando corretamente na parte inferior, a nova configuração é pelo menos funcional o suficiente para não quebrar sua conexão SSH. Pressione ENTER para aceitar a nova configuração.

Agora, verifique se o resolvedor DNS do sistema para determinar se sua configuração DNS foi aplicada:

sudo resolvectl status

Role para baixo até encontrar a seção para a interface de rede privada. Os endereços IP privados de seus servidores DNS devem ser listados primeiro, seguidos por alguns valores de fallback. Seu domínio deve ser listado após 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

Seu cliente Ubuntu agora está configurado para usar seus servidores DNS internos.

Passo 5 — Testar Clientes

Use nslookup para testar se seus clientes conseguem consultar seus servidores de nomes. Você deve ser capaz de fazer isso em todos os clientes que você configurou e que estão na lista trusted ACL.

Você pode começar realizando uma pesquisa direta.

Pesquisa Direta

Para realizar uma pesquisa direta e obter o endereço IP de host1.nyc3.example.com, execute o seguinte comando:

nslookup host1

A consulta de host1 se expande para host1.nyc3.example.com porque a opção search está configurada para o seu subdomínio privado, e as consultas DNS tentarão procurar nesse subdomínio antes de procurar em outro lugar pelo host. O comando anterior retornará uma saída semelhante à seguinte:

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

Em seguida, você pode verificar as pesquisas reversas.

Pesquisa Reversa

Para testar a pesquisa reversa, consulte o servidor DNS com o endereço IP privado de host1:

nslookup 10.128.100.101

Isso deve retornar uma saída semelhante à seguinte:

Output
11.10.128.10.in-addr.arpa   name = host1.nyc3.example.com.

Authoritative answers can be found from:

Se todos os nomes e endereços IP se resolverem para os valores corretos, isso significa que seus arquivos de zona estão configurados corretamente. Se você receber valores inesperados, certifique-se de revisar os arquivos de zona em seu servidor DNS primário (por exemplo, `db.nyc3.example.com` e `db.10.128`).

Como último passo, este tutorial explicará como você pode manter seus registros de zona.

Passo 6 — Mantendo Registros DNS

Agora que você tem um DNS interno funcional, é necessário manter seus registros DNS para que reflitam com precisão seu ambiente de servidor.

Adicionando um Host ao DNS

Sempre que adicionar um host ao seu ambiente (no mesmo datacenter), você precisará adicioná-lo ao DNS. Aqui estão os passos que você precisa seguir:

Servidor de Nome Primário

• Arquivo de zona de encaminhamento: Adicione um registro A para o novo host, incremente o valor de Serial
• Arquivo de zona reversa: Adicione um registro PTR para o novo host, incremente o valor de Serial
• Adicione o endereço IP privado do novo host à ACL trusted (`named.conf.options`)

Teste seus arquivos de configuração.

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

Então recarregue o BIND:

sudo systemctl reload bind9

O seu servidor primário deve estar configurado para o novo host agora.

Servidor de Nomes Secundário

• Adicione o endereço IP privado do seu novo host à ACL trusted (named.conf.options)

Verifique a sintaxe da configuração:

sudo named-checkconf

Em seguida, recarregue o BIND:

sudo systemctl reload bind9

O seu servidor secundário agora aceitará conexões do novo host.

Configure o Novo Host para Usar o Seu DNS

• Configure o /etc/resolv.conf para usar os seus servidores DNS
• Teste usando nslookup

Removendo um Host do DNS

Se você remover um host do seu ambiente ou quiser apenas removê-lo do DNS, remova todas as coisas que foram adicionadas quando você adicionou o servidor ao DNS (ou seja, o inverso dos passos anteriores).

Conclusão

Agora você pode se referir às interfaces de rede privada de seus servidores pelo nome, em vez de pelo endereço IP. Isso facilita a configuração de serviços e aplicativos, pois você não precisa mais lembrar dos endereços IP privados, e os arquivos serão menos difíceis de ler e entender. Além disso, agora você pode alterar suas configurações para apontar para um novo servidor em um único lugar, seu servidor DNS primário, em vez de ter que editar uma variedade de arquivos de configuração distribuídos, o que otimiza a manutenção.

Depois de configurar seu DNS interno e seus arquivos de configuração estiverem usando FQDNs privados para especificar conexões de rede, é crítico que seus servidores DNS sejam mantidos adequadamente. Se ambos ficarem indisponíveis, seus serviços e aplicativos que dependem deles deixarão de funcionar corretamente. Por isso, é recomendável configurar seu DNS com pelo menos um servidor secundário e manter backups funcionais de todos eles.

Se você deseja saber mais sobre DNS, recomendamos que confira nosso artigo Uma Introdução à Terminologia, Componentes e Conceitos do DNS.