Introduction

DNS, ou o Sistema de Nomes de Domínio, é muitas vezes um componente difícil de acertar quando se aprende a configurar websites e servidores. Embora a maioria das pessoas provavelmente opte por utilizar os servidores DNS fornecidos pela sua empresa de hospedagem ou pelo seu registrador de domínios, existem algumas vantagens em criar seus próprios servidores DNS.

Neste guia, discutiremos como instalar e configurar o servidor DNS Bind9 como servidores DNS apenas autorizados em máquinas Ubuntu 14.04. Vamos configurar estes dois servidores Bind para o nosso domínio em uma configuração primária secundária.

Prerequisites and Goals

Para completar este guia, você precisará primeiro estar familiarizado com alguma terminologia comum de DNS. Confira este guia para aprender sobre os conceitos que estaremos implementando neste guia.

Você também precisará de pelo menos dois servidores. Um será para o servidor DNS “primário” onde os arquivos de zona do nosso domínio serão originados e outro será o servidor “secundário” que receberá os dados da zona através de transferências e estará disponível no caso do outro servidor cair. Isto evita o perigo de ter um único ponto de falha para os seus servidores DNS.

Servidores DNS de cache ou de reencaminhamento não semelhantes ou um servidor DNS multi-purpose, os servidores só com autoridade respondem apenas a consultas iterativas para as zonas para as quais têm autoridade. Isto significa que se o servidor não souber a resposta, ele apenas dirá ao cliente (geralmente algum tipo de servidor DNS de resolução) que não sabe a resposta e dará uma referência a um servidor que pode saber mais.

Servidores DNS apenas autorizados são muitas vezes uma boa configuração para alto desempenho porque eles não têm a sobrecarga de resolver consultas recursivas dos clientes. Eles só se preocupam com as zonas que são projetados para servir.

Para os propósitos deste guia, nós estaremos realmente referenciando três servidores. Os dois servidores de nomes mencionados acima, mais um servidor web que queremos configurar como host dentro da nossa zona.

Utilizaremos o domínio dummy example.com para este guia. Você deve substituí-lo pelo domínio que você está configurando. Estes são os detalhes das máquinas que iremos configurar:

Propósito	DNS FQDN	Endereço IP
Servidor de nomes primários	ns1.exemplo.com.	192.0.2.1
Servidor de nomes secundário	ns2.exemplo.com.	192.0.2.2
Servidor Web	www.example.com.	192.0.2.3

Após completar este guia, você deve ter dois servidores de nomes só de domínio configurados para as suas zonas de domínio. Os nomes na coluna central da tabela acima poderão ser usados para chegar aos seus vários hosts. Usando esta configuração, um servidor DNS recursivo será capaz de retornar dados sobre o domínio aos clientes.

Configurando o nome do host nos servidores de nomes

Antes de entrarmos na configuração dos nossos servidores de nomes, devemos assegurar que o nome do nosso host está configurado corretamente tanto no nosso servidor DNS primário como no secundário.

Begin, investigando o arquivo /etc/hosts. Abra o arquivo com privilégios sudo em seu editor de texto:

sudo nano /etc/hosts

Precisamos configurar isso para que ele identifique corretamente o hostname de cada servidor e o FQDN. Para o servidor de nome primário, o arquivo será parecido com isto inicialmente:

127.0.0.1 localhost127.0.1.1 ns1 ns1. . .

Devemos modificar a segunda linha para referenciar nossa combinação específica de host e domínio e apontar isto para nosso endereço IP público, estático. Podemos então adicionar o nome não-qualificado como um alias no final. Para o servidor primário neste exemplo, você mudaria a segunda linha para this:

127.0.0.1 localhost192.0.2.1 ns1.example.com ns1. . .

Guardar e fechar o ficheiro quando terminar.

Devíamos também modificar o ficheiro /etc/hostname para conter o nosso hostname não qualificado:

sudo nano /etc/hostname

ns1

Podemos ler este valor no sistema actualmente em execução e depois digitando:

sudo hostname -F /etc/hostname

Queremos completar o mesmo procedimento no nosso servidor secundário.

Inicie com o ficheiro /etc/hosts ficheiro:

sudo nano /etc/hosts

127.0.0.1 localhost192.0.2.2 ns2.example.com ns2

Guardar e fechar o ficheiro quando terminar.

Em seguida, modifique o ficheiro /etc/hostname. Lembre-se de usar apenas a máquina actual (apenas ns2 no nosso exemplo) para este ficheiro:

sudo nano /etc/hostname

ns2

Again, leia o ficheiro para modificar o sistema actual:

sudo hostname -F /etc/hostname

Os seus servidores devem agora ter as suas definições de máquina correctamente definidas.

Instalar Bind em ambos os servidores de nomes

Em cada um dos seus servidores de nomes, você pode agora instalar o Bind, o servidor DNS que estaremos usando.

O software Bind está disponível dentro dos repositórios padrão do Ubuntu, então só precisamos atualizar nosso índice de pacotes local e instalar o software usando apt. Também iremos incluir a documentação e alguns utilitários comuns:

sudo apt-get updatesudo apt-get install bind9 bind9utils bind9-doc

Executar este comando de instalação em seus servidores DNS primário e secundário para adquirir os arquivos apropriados.

Configure the Primary Bind Server

Agora temos o software instalado, podemos começar configurando nosso servidor DNS no servidor primário.

Configurando o arquivo de opções

A primeira coisa que iremos configurar para começar é o arquivo.named.conf.options

O servidor DNS Bind também é conhecido como named. O arquivo de configuração principal está localizado em /etc/bind/named.conf. Este arquivo chama nos outros arquivos que estaremos configurando.

Abra o arquivo de opções com privilégios sudo no seu editor:

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

Below, a maioria das linhas comentadas foram removidas por brevidade, mas em geral o arquivo deve ficar assim após a instalação:

options { directory "/var/cache/bind"; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

A principal coisa que precisamos configurar neste arquivo é a recursividade. Como estamos a tentar configurar um servidor apenas autoritário, não queremos activar a recursividade neste servidor. Podemos desligar isto dentro do bloco options

Também vamos por defeito não permitir transferências. Mais tarde iremos sobrepor isto nas especificações das zonas individuais:

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Quando terminar, grave e feche o ficheiro.

Configurando o ficheiro local

O próximo passo que precisamos de dar é especificar as zonas que desejamos controlar este servidor. Uma zona é qualquer parte do domínio que é delegada para gestão a um servidor de nomes que não tenha sido subdelegada a outros servidores.

Estamos a configurar o domínio example.com e não vamos subdelegar a responsabilidade por qualquer parte do domínio a outros servidores. Então a zona irá cobrir todo o nosso domínio.

Para configurar nossas zonas, precisamos abrir o arquivo /etc/bind/named.conf.local com privilégios sudo:

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

Este arquivo estará inicialmente vazio além dos comentários. Existem outras zonas que nosso servidor conhece para gerenciamento geral, mas estas estão especificadas no arquivo named.conf.default-zones

Para começar, precisamos configurar a zona de encaminhamento para o nosso domínio example.com. A zona de encaminhamento é a resolução convencional de nome para IP que a maioria de nós pensa quando discutimos o DNS. Criamos um bloco de configuração que define a zona de domínio que desejamos configurar:

zone "example.com" {};

Note: Muitas ferramentas de DNS, seus arquivos de configuração e documentação usam os termos “master” e “slave” enquanto DigitalOcean geralmente prefere descritores alternativos. Para evitar confusão, escolhemos usar os termos “primário” e “secundário” para denotar relações entre servidores, e usamos apenas “mestre” ou “escravo” onde uma diretiva de configuração o requer.

Dentro deste bloco, adicionamos as informações de gerenciamento sobre esta zona. Nós especificamos a relação deste servidor DNS com a zona. Isto é type master; na zona de exemplo que se segue já que estamos configurando esta máquina como o servidor de nomes primário para todas as nossas zonas. Também apontamos Bind para o arquivo que contém os registros de recursos reais que definem a zona.

Vamos manter nossos arquivos de zona primária em um subdiretório chamado zones dentro do diretório de configuração Bind. Vamos chamar o nosso ficheiro db.example.com para pedir emprestado a convenção dos outros ficheiros de zona no directório Bind. O nosso bloco ficará assim agora:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com";};

Queremos permitir que esta zona seja transferida para o nosso servidor secundário, precisamos de adicionar uma linha como esta:

zone "example.com" { type master; file "/etc/bind/zones/db.example.com"; allow-transfer { 192.0.2.2; };};

Próximo, vamos definir a zona inversa para o nosso domínio.

A Bit About Reverse Zones

Se a organização que lhe deu os seus endereços IP não lhe deu um intervalo de rede e lhe delegou a responsabilidade por esse intervalo, então o seu arquivo de zona reversa não será referenciado e será tratado pela própria organização.

Com provedores de hospedagem, o mapeamento reverso é normalmente feito pela própria empresa. Por exemplo, com DigitalOcean, mapeamentos revertidos para seus servidores serão criados automaticamente se usar o FQDN da máquina como o nome do servidor no painel de controle. Por exemplo, os mapeamentos reversos para este tutorial poderiam ser criados nomeando os servidores assim:

Em instâncias como estas, já que não foi alocado um pedaço de endereços para administrar, você deve usar esta estratégia. A estratégia delineada abaixo é coberta para completar e torná-la aplicável se você tiver sido delegado o controle sobre grupos maiores de endereços contíguos.

Zonas inversas são usadas para conectar um endereço IP de volta a um nome de domínio. No entanto, o sistema de nomes de domínio foi concebido originalmente para os mapeamentos de reencaminhamento, por isso é necessário pensar em adaptá-lo para permitir mapeamentos invertidos.

As informações que precisa de ter em mente para compreender os mapeamentos invertidos são:

• Num domínio, a parte mais específica é do endereço que se encontra à esquerda. Para um endereço IP, a porção mais específica está à direita.
• A parte mais específica de uma especificação de domínio é ou um subdomínio ou um nome de host. Isto é definido no arquivo de zona para o domínio.
• Cada subdomínio pode, por sua vez, definir mais subdomínios ou hosts.

Todos os mapeamentos de zona reversa são definidos sob o domínio especial in-addr.arpa, que é controlado pela Internet Assigned Numbers Authority (IANA). Sob este domínio, existe uma árvore que utiliza subdomínios para mapear cada um dos octetos em um endereço IP. Para garantir que a especificidade dos endereços IP espelha a dos domínios normais, os octetos dos endereços IP são na verdade invertidos.

Então o nosso servidor DNS primário, com um endereço IP de 192.0.2.1, seria invertido para ler como 1.2.0.192. Quando adicionamos essa especificação de host como uma hierarquia existente sob o domínio in-addr.arpa, o host específico pode ser referido como 1.2.0.192.in-addr.arpa.

Desde que definamos hosts individuais (como o “1” principal aqui) dentro do próprio arquivo de zona quando usamos DNS, a zona que estaríamos configurando seria 2.0.192.in-addr.arpa. Se o nosso provedor de rede nos deu um bloco /24 de endereços, digamos 192.0.2.0/24, eles teriam delegado esta porção in-addr.arpa para nós.

Agora que você sabe como especificar o nome da zona reversa, a definição real é exatamente a mesma que a zona de avanço. Abaixo da definição de zona example.com, faça uma zona reversa para a rede que lhe foi dada. Mais uma vez, isto provavelmente só é necessário se lhe foi delegado o controlo sobre um bloco de endereços:

zone "2.0.192.in-addr.arpa" { type master; file "/etc/bind/zones/db.192.0.2";};

Escolhemos nomear o ficheiro db.192.0.2. Isto é específico sobre o que a zona configura e é mais legível do que a notação inversa.

Guardar e fechar o ficheiro quando terminar.

Criar o Ficheiro de Zona Frente

Dissemos agora ao Bind sobre as nossas zonas frente e verso, mas ainda não criámos os ficheiros que irão definir estas zonas.

Se se lembrar, especificámos as localizações dos ficheiros como estando dentro de uma subdirectoria chamada zones. Precisamos criar este diretório:

sudo mkdir /etc/bind/zones

Agora, podemos usar alguns dos arquivos de zona pré-existentes no diretório Bind como modelos para os arquivos de zona que queremos criar. Para a zona forward, o arquivo db.local estará próximo do que precisamos. Copie esse ficheiro para a subdirectoria zones com o nome usado no ficheiro named.conf.local ficheiro.

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

Embora estejamos a fazer isto, também podemos copiar um template para a zona inversa. Vamos usar o ficheiro db.127, uma vez que é uma correspondência próxima para o que precisamos:

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

Agora, abra o ficheiro de zona avançada com privilégios sudo no seu editor de texto:

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

O ficheiro ficará assim:

$TTL 604800@ IN SOA localhost. root.localhost. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.@ IN A 127.0.0.1@ IN AAAA ::1

A primeira coisa que precisamos de fazer é modificar o registo SOA (início de autoridade) que começa com o primeiro símbolo @ e continua até ao parêntese de fecho.

Precisamos de substituir o localhost. pelo nome do FQDN desta máquina. Esta parte do registro é usada para definir qualquer servidor de nomes que responderá com autoridade para a zona que está sendo definida. Esta será a máquina que estamos configurando agora, ns1.example.com. no nosso caso (note o trailing dot. Isto é importante para que a nossa entrada se registe correctamente!).

Também queremos alterar a próxima peça, que na verdade é um endereço de e-mail especialmente formatado com o @ substituído por um ponto. Queremos que os nossos e-mails vão para uma administração do domínio, por isso o e-mail tradicional é [email protected]. Nós traduziríamos isto para que pareça admin.example.com.:

@ IN SOA ns1.example.com. admin.example.com. (

A próxima peça que precisamos editar é o número de série. O valor do número de série é como o Bind diz se ele precisa enviar informações atualizadas para o servidor secundário.

Note: Falha no incremento do número de série é um dos erros mais comuns que leva a problemas com atualizações de zona. Cada vez que você faz uma edição, você deve bater o número de série.

Uma prática comum é usar uma convenção para incrementar o número. Uma abordagem é usar a data no formato AAAAMMDD juntamente com um número de revisão para o dia adicionado no final. Assim, a primeira revisão feita em 05 de junho de 2014 poderia ter um número de série de 2014060501 e uma atualização feita mais tarde nesse dia poderia ter um número de série de 2014060502. O valor pode ser um número de 10 dígitos.

Vale a pena adotar uma convenção para facilitar o uso, mas para manter as coisas simples para nossa demonstração, vamos apenas definir o nosso para 5 por enquanto:

@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial

Próximo, podemos nos livrar das últimas três linhas no arquivo (as que começam com @), pois estaremos fazendo o nosso próprio.

A primeira coisa que queremos estabelecer após o registro SOA são os servidores de nomes para a nossa zona. Nós especificamos o domínio e depois os nossos dois servidores de nomes que são autorizados para a zona, por nome. Como estes servidores de nomes serão hosts dentro do próprio domínio, ele parecerá um pouco auto-referencial.

Para o nosso guia, terá a seguinte aparência. Novamente, preste atenção aos pontos finais!:

; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.

Desde que o propósito de um arquivo de zona é principalmente mapear nomes de hosts e serviços para endereços específicos, nós ainda não terminamos. Qualquer software que leia este ficheiro de zona vai querer saber onde estão os servidores ns1 e ns2 para poder aceder às zonas autorizadas.

Em seguida, precisamos de criar os registos A que irão associar estes nomes de servidores de nomes aos endereços IP reais dos nossos servidores de nomes:

; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2

Agora que tenhamos os registos A para resolver com sucesso os nossos servidores de nomes aos seus endereços IP correctos, podemos adicionar quaisquer registos adicionais. Lembre-se, nós temos um servidor web em um de nossos hosts que queremos usar para servir o nosso site. Iremos apontar pedidos para o domínio geral (example.com no nosso caso) para este host, bem como pedidos para o host www. Ficará assim:

; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Você pode adicionar quaisquer hosts adicionais que você precise definir criando registros adicionais de A. Consulte nosso guia básico de DNS para se familiarizar com algumas de suas opções de criação de registros adicionais.

Quando você terminar, seu arquivo deve se parecer com isto:

$TTL 604800@ IN SOA ns1.example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name serversexample.com. IN NS ns1.example.com.example.com. IN NS ns2.example.com.; A records for name serversns1 IN A 192.0.2.1ns2 IN A 192.0.2.2; Other A records@ IN A 192.0.2.3www IN A 192.0.2.3

Guardar e fechar o arquivo quando você terminar.

Criar o arquivo de zona reversa

Agora, nós temos a zona de frente configurada, mas precisamos configurar o arquivo de zona reversa que nós especificamos em nosso arquivo de configuração. Já criámos o ficheiro no início da última secção.

Abra o ficheiro no seu editor de texto com privilégios sudo:

sudo nano db.192.0.2

O ficheiro deve ficar assim:

$TTL 604800@ IN SOA localhost. root.localhost. ( 1 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;@ IN NS localhost.1.0.0 IN PTR localhost.

Passaremos por muito do mesmo procedimento que passámos com a zona forward. Primeiro, ajuste o nome do domínio, o e-mail do administrador e o número de série para corresponder exatamente ao que você tinha no último arquivo (O número de série pode ser diferente, mas deve ser incrementado):

@ IN SOA example.com. admin.example.com. ( 5 ; Serial

Again, apague as linhas sob o parêntese de fechamento do registro SOA. Vamos pegar o último octeto de cada endereço IP da nossa rede e mapeá-lo de volta para o FQDN daquele host usando um registro de PTR. Cada endereço IP deve ter apenas um único PTR registro para evitar problemas em algum software, então você deve escolher o nome do host que deseja reverter o mapa para.

Por exemplo, se você tiver um servidor de e-mail configurado, você provavelmente quer configurar o mapeamento reverso para o nome do e-mail, uma vez que muitos sistemas usam o mapeamento reverso para validar endereços.

Primeiro, precisamos configurar nossos servidores de nomes novamente:

; Name servers IN NS ns1.example.com. IN NS ns2.example.com.

Próximo, você usará o último octeto do endereço IP ao qual você está se referindo e apontará de volta para o nome de domínio totalmente qualificado com o qual você deseja retornar. Para o nosso exemplo, vamos usar isto:

; PTR Records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

Quando você terminar, o arquivo deve se parecer com isto:

$TTL 604800@ IN SOA example.com. admin.example.com. ( 5 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL;; Name servers IN NS ns1.example.com. IN NS ns2.example.com.; PTR records1 IN PTR ns1.example.com.2 IN PTR ns2.example.com.3 IN PTR www.example.com.

>Guardar e fechar o arquivo quando você terminar.

Testando os arquivos e reiniciando o serviço

A configuração para o servidor primário agora está completa, mas ainda precisamos implementar nossas mudanças.

Antes de reiniciarmos nosso serviço, devemos testar todos os nossos arquivos de configuração para ter certeza de que estão configurados corretamente. Temos algumas ferramentas que podem verificar a sintaxe de cada um dos nossos arquivos.

Primeiro, podemos verificar os arquivos named.conf.local e named.conf.options usando o comando named-checkconf. Uma vez que ambos os ficheiros são fonte pelo esqueleto named.conf ficheiro, irá testar a sintaxe dos ficheiros que modificámos.

sudo named-checkconf

Se isto regressar sem mensagens, significa que os ficheiros named.conf.local e named.conf.options são sintacticamente válidos.

Próximo, pode verificar os seus ficheiros de zona individuais passando o domínio que a zona trata e a localização do ficheiro de zona para o comando named-checkzone. Assim, para o nosso guia, pode verificar o ficheiro de zona de avanço digitando:

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

Se o seu ficheiro não tiver problemas, deve dizer-lhe que carregou o número de série correcto e dar a mensagem “OK”;

zone example.com/IN: loaded serial 5OK

Se se deparar com qualquer outra mensagem, significa que tem um problema com o seu ficheiro de zona. Normalmente, a mensagem é bastante descritiva sobre qual parte é inválida.

Você pode verificar a zona reversa passando o endereço in-addr.arpa e o nome do arquivo. Para a nossa demonstração, nós estaríamos digitando isto:

sudo named-checkzone 2.0.192.in-addr.arpa /etc/bind/zones/db.192.0.2

Again, isto deve lhe dar uma mensagem similar sobre o carregamento do número de série correto:

zone 2.0.192.in-addr.arpa/IN: loaded serial 5OK

Se todos os seus arquivos estiverem fazendo check out, você pode reiniciar o seu serviço Bind:

sudo service bind9 restart

Você deve verificar os logs digitando:

sudo tail -f /var/log/syslog

Cuidado com este log para ter certeza de que não há erros.

Configure the Secondary Bind Server

Agora que temos o servidor primário configurado, podemos ir em frente e configurar o servidor secundário. Isto será significativamente mais fácil que o servidor primário.

Configurando o Arquivo de Opções

Again, vamos começar com o arquivo named.conf.options. Abra-o com privilégios sudo no seu editor de texto:

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

Faremos as mesmas modificações exatas neste arquivo que fizemos no arquivo do nosso servidor primário.

options { directory "/var/cache/bind"; recursion no; allow-transfer { none; }; dnssec-validation auto; auth-nxdomain no; # conform to RFC1035 listen-on-v6 { any; };};

Guardar e fechar o arquivo quando terminar.

Configurando o arquivo de configuração local

Próximo, configuraremos o arquivo named.conf.local no servidor secundário. Abra-o com privilégios sudo no seu editor de texto:

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

Aqui, vamos criar cada uma das nossas especificações de zona como fizemos no nosso servidor primário. Entretanto, os valores e alguns dos parâmetros serão diferentes.

Primeiro, vamos trabalhar na zona de encaminhamento. Inicie-a da mesma forma que você fez no arquivo primário:

zone "example.com" {};

Desta vez, vamos definir o type para slave já que este servidor está atuando como secundário para esta zona. Isto significa simplesmente que ele recebe seus arquivos de zona através de transferência, ao invés de um arquivo no sistema local. Adicionalmente, vamos apenas especificar o nome do ficheiro relativo em vez do caminho absoluto para o ficheiro de zona.

A razão para isto é que, para zonas secundárias, o Bind armazena os ficheiros /var/cache/bind. O Bind já está configurado para procurar nesta localização de diretório, então não precisamos especificar o caminho.

Para a nossa zona forward, estes detalhes serão parecidos com isto:

zone "example.com" { type slave; file "db.example.com";};

Finalmente, ao invés da diretiva allow-transfer, vamos especificar os servidores primários, por endereço IP, dos quais este servidor aceitará transferências de zona. Isso é feito em uma diretiva chamada masters:

zone "example.com" { type slave; file "db.example.com"; masters { 192.0.2.1; };};

Isso completa nossa especificação de zona de encaminhamento. Podemos usar este mesmo formato exato para cuidar da nossa especificação de zona reversa:

zone "2.0.192.in-addr.arpa" { type slave; file "db.192.0.2"; masters { 192.0.2.1; };};

Quando você terminar, você pode salvar e fechar o arquivo.

Testing the Files and Restarting the Service

Na verdade não temos que fazer nenhuma criação de arquivo de zona real na máquina secundária porque, como mencionamos anteriormente, este servidor irá receber os arquivos de zona do servidor primário. Então estamos prontos para testar.

Again, devemos verificar a sintaxe do arquivo de configuração. Como não temos nenhum arquivo de zona para verificar, só precisamos usar a ferramenta named-checkconf tool:

sudo named-checkconf

Se isso retornar sem erros, significa que os arquivos que você modificou não têm erros de sintaxe.

Se este for o caso, você pode reiniciar o seu serviço Bind:

sudo service bind9 restart

Verifica os logs nos servidores primários e secundários usando:

sudo tail -f /var/log/syslog

Você deve ver algumas entradas que indicam que os arquivos de zona foram transferidos corretamente.

Delegate Authority to your Name Servers

Os seus servidores de nomes só com autoridade devem agora estar completamente configurados. Entretanto, você ainda precisa delegar autoridade para o seu domínio aos seus servidores de nomes.

Para fazer isso, você terá que ir ao site onde comprou o seu nome de domínio. A interface e talvez a terminologia será diferente dependendo do registrador de nomes de domínio que você usou.

Nas configurações do seu domínio, procure uma opção que lhe permita especificar os servidores de nomes que você deseja usar. Como nossos servidores de nomes estão dentro de nosso domínio, este é um caso especial.

Em vez de o registrador simplesmente delegar autoridade para a zona através do uso de registros NS, ele precisará criar um registro de cola. Um registro cola é um registro A que especifica os endereços IP para os servidores de nomes após especificar os servidores de nomes que está delegando autoridade para.

Usualmente, a delegação apenas lista os servidores de nomes que irão lidar com a autoridade do domínio, mas quando os servidores de nomes estão dentro do próprio domínio, um registro A é necessário para os servidores de nomes na zona mãe. Se isso não acontecesse, os resolvedores DNS ficariam presos em um loop porque nunca seria capaz de encontrar o endereço IP dos servidores de nomes do domínio para seguir o caminho da delegação.

Então você precisa encontrar uma seção do painel de controle do registrador do seu domínio que permita especificar os servidores de nomes e seus endereços IP.

Como uma demonstração, o registrador Namecheap tem duas seções diferentes de servidores de nomes.

Há uma secção chamada “Nameserver Registration” que lhe permite especificar os endereços IP dos servidores de nomes dentro do seu domínio:

>

Inside, poderá introduzir os endereços IP dos servidores de nomes que existem dentro do domínio:

>

Isto irá criar o registo A que servirá como os registos de cola que necessita no ficheiro da zona mãe.

Depois de ter feito isso, você deverá ser capaz de mudar os servidores de nomes ativos para os servidores do seu domínio. Em NameCheap, isto é feito usando a opção de menu “Domain Name Server Setup”:

>

Aqui, você pode dizer para usar os servidores de nomes que você adicionou como servidores autorizados para o seu site:

As mudanças podem levar algum tempo para se propagar, mas você deve ver os dados dos seus servidores de nomes sendo usados dentro das próximas 24-48 horas para a maioria dos registradores.

Conclusão

Você agora deve ter dois servidores DNS apenas autorizados configurados para server seus domínios. Estes podem ser usados para armazenar informação de zona para domínios adicionais à medida que você adquire mais.

Configurar e gerir os seus próprios servidores DNS dá-lhe o maior controlo sobre a forma como os registos DNS são tratados. Você pode fazer alterações e ter certeza de que todos os dados relevantes do DNS estão atualizados na fonte. Embora outras soluções DNS possam facilitar esse processo, é importante saber que você tem opções e entender o que está acontecendo em mais soluções empacotadas.