DNS – Criando Zonas no BIND
vagnerfonseca
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | 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:
root@debian# named-checkconf /etc/named.conf
ou
root@debian# 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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | <em>$TTL 28800</em> ; tempo de vida das respostas fornecidas pelo DNS <em>@ IN SOA ns1.empresa.net. dns-admin.empresa.net. (</em> <em>2011102701</em> ; serial para controle de atualizações entre master e slave <em> 3600</em> ; tempo de atualizações entre master e slave (refresh) <em> 1800</em> ; tempo de atualizações caso o refresh falhe <em>604800</em> ; tempo de expiração do slave caso não se contate com o master <em>3600 )</em> ; 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</em> <strong></strong> |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | <em>$TTL 28800</em> ; tempo de vida das respostas fornecidas pelo DNS <em>@ IN SOA ns1.exemplo.net. dns-admin.exemplo.net. (</em> <em>2011102701</em> ; serial para controle de atualizações entre master e slave <em> 3600</em> ; tempo de atualizações entre master e slave (refresh) <em> 1800</em> ; tempo de atualizações caso o refresh falhe <em>604800</em> ; tempo de expiração do slave caso não se contate com o master <em>3600 )</em> ; tempo de vida das repostas negativas do servidor <em>@ 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</em> |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | <em>$TTL 28800</em> ; tempo de vida das respostas fornecidas pelo DNS <em>@ IN SOA ns1.exemplo.net. dns-admin.exemplo.net. (</em> <em>2011102701</em> ; serial para controle de atualizações entre master e slave <em> 3600</em> ; tempo de atualizações entre master e slave (refresh) <em> 1800</em> ; tempo de atualizações caso o refresh falhe <em>604800</em> ; tempo de expiração do slave caso não se contate com o master <em>3600 )</em> ; tempo de vida das repostas negativas do servidor <em>@ 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.</em> |
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):
root@debian# named-checkzone empresa.net db.empresa.net
root@debian# named-checkzone exemplo.net db.empresa.net
root@debian# 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:
root@debian# /etc/init.d/named restart
Em Debian:
root@debian# /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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | <em>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.
Desse jeito ficarei especialista em Linux !! rsrsrsrsrs
Amem!!!
Vagner… tava realmente precisando dessa dica cara… preciso incluir um registro no Bind e estava desesperado pois ainda nao tinha ideia de como fazer…
Cara… obrigado… vou testar e digo o que rolou….
Vagner blz, acho qye só um detalhe que para teste local, acrescente no arquivo /etc/resolv.conf, na primeira linha, –> nameserver 127.0.0.1.
reinicie, e ping http://www.empresa.net
valeu
Vagner, poderia me ajudar, estou tentando instalar o Bind atual 9.8.1 pelo source, porem não estou conseguindo, teria como fazer um tuto desse passo tbém, ou saberia informa onde acho um pacote .deb dessa versão., eu uso Debian Squeeze
Junior,
Você já tentou usar o backports do Debian?
Ola vagner, muito bom esse tutorial, obrigado por compartilhar seu grande conhecimento, porem tenho uma duvida, no arquivo db do dominio na linha abaixo
@ IN SOA ns1.exemplo.net. dns-admin.exemplo.net.
onde esta ns1.exemplo.net creio eu que ns1 seria o nome do host ok?
agora esse dns-admin no final da linha eu nao entendi, poderia me tirar essa duvida?
Obrigado.
Rodrigo,
Respondendo pelo Vagner. ns1.exemplo.net é o servidor de nome primário e com autoridade sobre essa zona (exemplo.net) e dns-admin.exemplo.net é o email do administrador dessa zona, o formato utilizado pelo Bind pode confundir um pouco, portanto para enviar email para o administrador envie para [email protected].
Espero ter esclarecido suas dúvidas.
Abraços
valeu cara!!!! resposta muito rapida!
so mais uma coisa, en alguns servidores de dns nesse campo dns-admin.exemplo.net utilizei root.ns1.exemplo.net, e nao vi diferenças , resumindo isso serve apenas para quando alguem consultar o dominio ja vai saber o email do ADMIN?
abs
Rodrigo,
Exatamente, e no seu caso você está informando que o usuário root é o responsável.
Abraços
Olá Amigos,
A zona reversa vai com o ip privado ou o ip publico?
Sempre o IP pelo qual o serviço vai ser acessado.