DNS – Criando Zonas no BIND

Continuando nosso assunto sobre DNS, vou mostrar no artigo de hoje sobre como criar domínios (zonas) no BIND e colocar nossos domínios para funcionar.

Criaremos dois domínios e as máquinas que fazem parte dessas zonas.

Primeiro devemos instalar os pacotes necessários para o funcionamento do serviço, o nome do pacote é bind tanto em distribuições baseadas em Debian quanto em Red Hat.

As diferenças entre as distribuições está na localização dos arquivos, as variáveis e comandos são os mesmos. As diferenças são as seguintes:

Red Hat:
Script de inicialização: /etc/init.d/named
Arquivos de Configuração: /etc/named.conf (Opções e domínios) /etc/named.rfc1912.zones (zonas padrão)
Diretório de database de zonas: /var/named

Debian:
Script de inicialização: /etc/init.d/bind9
Arquivos de Configuração: /etc/bind/named.conf.options (opções) /etc/bind/named.conf.local (domínios) /etc/named.conf.default.zones (zonas padrão)
Diretório de database de zonas: /var/cache/bind

Os domínios (direto e reverso) devem ser criados no arquivo /etc/named.conf (Red Hat) ou /etc/bind/named.conf.local (Debian), e as máquinas de cada domínio devem ser criadas nos arquivos de database de cada distribuição. Nos arquivos com nome named os caracteres de // são os comentários, nos arquivos db. o caracter de ; é o comentário.

No DNS master edite o arquivo named correspondente, usando como exemplo os domínios empresa.net e exemplo.net (domínios que existem, mas aqui serão usados como exemplo) e sendo nossa rede externa 172.16.1.10 a 172.16.1.20(eu sei que é um endereço inválido mas usaremos para exemplo), com o seguinte conteúdo ao final:

zone "empresa.net" {
     type master;
     file "db.empresa.net";
     allow-transfer { 172.16.1.11; };
};

zone "exemplo.net" {
    type master;
    file "db.exemplo.net";
    allow-transfer { 172.16.1.11; };
};

zone "1.16.172.in-addr.arpa" {
    type master;
    file "db.172.16.1";
    allow-transfer { 172.16.1.11; };
};

Onde:
zone – é o nome do domínio que será criado neste servidor
type – tipo de servidor DNS (master ou slave)
file – arquivo de database desta zona
allow-transfer – diretiva que permite transferência do arquivo de zona para o servidor slave.

As zonas diretas devem ser criadas uma para cada domínio, mas como a zona reversa é baseada na rede onde os hosts existem, assim sendo, podemos ter uma única zona reversa em nosso DNS atendendo a vários domínios, desde que os hosts destes domínios estejam na mesma rede.

Para checar se não houve erro na configuração usaremos o comando named-checkconf:
[email protected]# named-checkconf /etc/named.conf
ou
[email protected]# named-checkconf /etc/bind/named.conf

Com os arquivos named devidamente configurados, devemos criar agora o database de cada zona e da reversa.
Criaremos nos respectivos diretórios de database os arquivos com os seguintes conteúdos:

db.empresa.net

$TTL 28800 ; tempo de vida das respostas fornecidas pelo DNS
@ IN SOA ns1.empresa.net. dns-admin.empresa.net. (
      2011102701 ; serial para controle de atualizações entre master e slave
       3600 ; tempo de atualizações entre master e slave (refresh)
       1800 ; tempo de atualizações caso o refresh falhe
      604800 ; tempo de expiração do slave caso não se contate com o master
      3600 ) ; tempo de vida das repostas negativas do servidor
@    IN NS ns1.empresa.net.
@    IN MX 10 mail.empresa.net.
ns1  IN A  172.16.1.10
ns2  IN A  172.16.1.11
mail IN A  172.16.1.12
ftp  IN A  172.16.1.13
www  IN A  172.16.1.20

db.exemplo.net

$TTL 28800 ; tempo de vida das respostas fornecidas pelo DNS
@ IN SOA ns1.exemplo.net. dns-admin.exemplo.net. (
      2011102701 ; serial para controle de atualizações entre master e slave
       3600 ; tempo de atualizações entre master e slave (refresh)
       1800 ; tempo de atualizações caso o refresh falhe
      604800 ; tempo de expiração do slave caso não se contate com o master
      3600 ) ; tempo de vida das repostas negativas do servidor
@    IN NS ns1.exemplo.net.
@    IN MX 10 mail.exemplo.net.
ns1  IN A  172.16.1.10
ns2  IN A  172.16.1.11
mail IN A  172.16.1.12
ftp  IN A  172.16.1.14
www  IN A  172.16.1.20

db.172.16.1

$TTL 28800 ; tempo de vida das respostas fornecidas pelo DNS
@ IN SOA ns1.exemplo.net. dns-admin.exemplo.net. (
      2011102701 ; serial para controle de atualizações entre master e slave
       3600 ; tempo de atualizações entre master e slave (refresh)
       1800 ; tempo de atualizações caso o refresh falhe
      604800 ; tempo de expiração do slave caso não se contate com o master
      3600 ) ; tempo de vida das repostas negativas do servidor
@  IN NS  ns1.exemplo.net.
;empresa.net
10 IN PTR ns1.empresa.net.
11 IN PTR ns2.empresa.net.
12 IN PTR mail.empresa.net.
13 IN PTR ftp.empresa.net.
20 IN PTR www.empresa.net.

;exemplo.net
10 IN PTR ns1.exemplo.net.
11 IN PTR ns2.exemplo.net.
12 IN PTR mail.exemplo.net.
14 IN PTR ftp.exemplo.net.
20 IN PTR www.exemplo.net.

 

Assim teremos um arquivo para cada domínio direto e um arquivo para todos os reversos.

Vamos testar os arquivos com o seguinte comando (estando no diretório onde os arquivos foram criados):

[email protected]# named-checkzone empresa.net db.empresa.net

[email protected]# named-checkzone exemplo.net db.empresa.net

[email protected]# named-checkzone 1.16.172.in-addr.arpa db.172.16.1

Se não houver nenhum erro, basta iniciar o serviço:

Em Red Hat:
[email protected]# /etc/init.d/named restart

Em Debian:
[email protected]# /etc/init.d/bind9 restart

Monitore por erros no log do sistema /var/log/syslog (Debian) ou /var/log/messages (Red Hat).

No slave faremos a seguinte configuração no arquivo named correspondente:

zone "empresa.net" {
    type slave;
    file "db.empresa.net";
    masters { 172.16.1.10; };
};

zone "exemplo.net" {
    type slave;
    file "db.exemplo.net";
    masters { 172.16.1.10; };
};

zone "1.16.172.in-addr.arpa" {
    type slave;
    file "db.172.16.1";
    masters { 172.16.1.10; };
};

Assim ao reiniciar o serviço o slave irá procurar o master (172.16.1.10) e irá fazer download (porta 53 TCP) dos arquivos db. existentes no master e se manterá sincronizado, verificando a cada ciclo de tempo (refresh) se houve atualizações nos arquivos no master.

Espero ter ajudado e no próximo post colocaremos uma zona interna respondendo apenas para rede local e faremos otimizações do DNS.

Não esqueçam de votar no TopBlog, de assinar nosso Portal e de recomendar para mais profissionais de TI.