Esse artigo mostra os passos básicos para instalação e configuração do servidor de DNS BIND no CentOS 7.
Para esse tutorial vamos configurar um servidor master com os detalhes abaixo:
- Hostname: dns.exemplo.com.br
- Endereço IP: 172.16.10.10/24
- Sistema Operacional: CentOS 7 minimal server
Instalando pacotes
Primeiro passo é instalar os pacotes necessários, como root:
[root@dns ~]# yum install -y bind bind-utils
Configurando o BIND
O arquivo de configuração principal do BIND é o /etc/named.conf, vamos edita-lo modificando alguns poucos detalhes. Na sessão options procure por listen-on e adicione o endereço IP do servidor. Nesse exemplo a linha ficará:
listen-on port 53 { 127.0.0.1; 172.16.10.10; };
Também em options procurar por allow-query adicionando os endereços de rede que terão permissão para consultar o nosso servidor. Nessa configuração de exemplo vou permitir apenas a rede interna, então a linha ficará assim:
allow-query { localhost; 172.16.10.0/24; };
Se você deseja permitir que qualquer servidor consulte o seu DNS, basta colocar o valor any:
allow-query { any; };
Caso seja necessário resolver hostnames externos que não são administrados pelo servidor que você esta configurando, se faz necessário configurar servidores para onde o seu DNS server irá encaminhar esses hostnames. Ainda em options adicione a opção forwarders com a lista de servidores entre chaves e separados por ponto e vírgula. Abaixo um exemplo onde uso os servidores de DNS do Google e do OpenDNS como forwarders:
forwarders {
8.8.8.8;
208.67.222.222;
};
No final do arquivo, já fora da sessão options, devemos agora indicar as zonas que serão administradas pelo servidor. É necessário criar uma entrada de zona e também o reverso dessa zona. Para o dominío e endereço de rede do nosso tutorial as entradas ficam assim:
zone "exemplo.com.br" IN {
type master;
file "exemplo.com.br.db";
};
zone "10.16.172.in-addr.arpa" IN {
type master;
file "10.16.172.db";
};
O parametro type indica que esse servidor é master para essas zonas e file diz o nome do arquivo com detalhes da zona. Você pode indicar o caminho completo ou apenas o nome do arquivo, o que significa que ele estará no caminho padrão.
Encerramos aqui a edição do arquivo /etc/named.conf, abaixo a listagem completa do arquivo com as modificação feitas:
//
// named.conf
//
// Provided by Red Hat bind package to configure the ISC BIND named(8) DNS
// server as a caching only nameserver (as a localhost DNS resolver only).
//
// See /usr/share/doc/bind*/sample/ for example named configuration files.
//
options {
listen-on port 53 { 127.0.0.1; 172.16.10.10; };
listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; 172.16.10.0/24; };
/*
- If you are building an AUTHORITATIVE DNS server, do NOT enable recursion.
- If you are building a RECURSIVE (caching) DNS server, you need to enable
recursion.
- If your recursive DNS server has a public IP address, you MUST enable access
control to limit queries to your legitimate users. Failing to do so will
cause your server to become part of large scale DNS amplification
attacks. Implementing BCP38 within your network would greatly
reduce such attack surface
*/
recursion yes;
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
forwarders {
8.8.8.8;
208.67.222.222;
};
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
zone "exemplo.com.br" IN {
type master;
file "exemplo.com.br.db";
};
zone "10.16.172.in-addr.arpa" IN {
type master;
file "10.16.172.db";
};
Criando arquivos de zona
O segundo passo é criar os arquivos para as zonas indicados na configuração principal. Por padrão os arquivos ficam em /var/named, então como indicamos em /etc/named.conf vamos criar o arquivo /var/named/exemplo.com.br.db com o conteúdo abaixo:
$TTL 24h
@ IN SOA dns.exemplo.com.br. root.exemplo.com.br. (
2015083000 ; Serial
12h ; Refresh
15m ; Retry
3w ; Expire
2h ; Mininum TTL
)
@ IN NS dns.exemplo.com.br.
dns IN A 172.16.10.10
server1 IN A 172.16.10.20
www IN A 172.16.10.30
ftp IN CNAME www.exemplo.com.br.
A primeira linha com TTL indica o tempo padrão para essa zona que um registro DNS deve ser armazenado em cache. A segunda linha contém um registro do tipo SOA (Start of Authority) contendo os parametros globais para zona de domínio. Esse registro vai até o fechamento dos parenteses na oitava linha. O texto após o sinal de ponto e vírgula é comentário. Alguns detalhes sobre a primeira linha do registro SOA:
@- É um substituto para o nome da zona apontado na configuração feita em/etc/named.conf.dns.exemplo.com.br.- É o servidor master para essa zona, no nosso exemplo é o próprio servidor que estamos configurando.root.exemplo.com.br.- É o email do responsável por essa zona. Esse formato corresponde ao email root@exemplo.com.br.
A linha comentada como Serial contém um valor número de serial number para sincronismo dessa zona. Ele permite que um servidor secundário (slave) inicie uma atualização sempre que possuir esse valor menor do que o servidor master. Uma convenção usada para esse campo é a data no formato AAAAMMDDSS onde: AAAA = ano, MM = mês, DD = dia e SS é um número sequencial atualizado a cada modificação diária.
As quatro linhas seguintes possuem campos com registros de tempo para orientar servidores secundários. O primeiro campo (Refresh) indica o tempo que o servidor slave deve aguardar para fazer novas consultas de atualização ao servidor master. O segundo campo (Retry) indica o tempo que o slave deve aguardar para uma nova tentativa caso encontre falha na atualização. O terceiro campo (Expire) diz o tempo máximo que um slave pode responder pela zona sem conseguir contato com o master. O quarto campo (Mininum TTL) diz o tempo que um servidor slave deve aguardar antes de retornar a autoridade da zona para o master server. Os valores desses campos podem ser em segundos ou abreviados onde: w = semanas (weeks), d = dias (days), h = horas (hours) e m = minutos (minutes).
Exemplificando o comportamento com os valores que definimos. Um servidor slave irá a cada 12 horas tentar atualização com o master server, a atualização acontecerá se o valor de Serial no slave for menor do que no master. Caso a comunicação entre os servidores falhe, o slave aguardará 15 minutos antes de uma nova tentativa. Se não houver comunicação entre master e slave, o slave trabalhará nessa condição por 3 semanas até considerar seus dados ultrapassados e não mais responder pela zona. Quando a comunicação entre os servidores voltar, o slave aguardará duas horas até aceitar atualizações do master.
A linha 10 contém um registro NS que indica o nameserver, no caso o próprio servidor e a linha 11 um registro do tipo A com o endereço IP do servidor. As demais linhas são apenas exemplos onde declaro outros endereços e um alias.
Finalizado esse arquivo devemos criar o arquivo reverso em /var/named/10.16.172.db.
$TTL 24h
@ IN SOA dns.exemplo.com.br. root.exemplo.com.br. (
2015083000 ; Serial
12h ; Refresh
15m ; Retry
3w ; Expire
2h ; Mininum TTL
)
@ IN NS dns.exemplo.com.br.
10 IN PTR dns.exemplo.com.br.
20 IN PTR server1.exemplo.com.br.
30 IN PTR www.exemplo.com.br.
30 IN PTR ftp.exemplo.com.br.
O registro SOA é identico ao arquivo de zona. Na linha 10 temos um registro NS e na linha 11 um registro do tipo PTR (pointer) para o nosso servidor. O valor 10 é o ultimo octeto do endereço IP do servidor (172.16.10.10). Os registros do tipo PTR podem ser declarados apenas com o último octeto como nesse exemplo ou ser completos. Quando usado apenas o último octeto o restando é preenchido com o nome da zona declarado em /etc/named.conf. O endereço completo para o mesmo IP seria 10.10.16.172.in-addr.arpa.
As demais entradas são apenas outros exemplos de registro PTR para cada registro exemplo criado no arquivo anterior. Finalizada a edição, basta salvar esse arquivo.
Liberando o firewall e subindo o serviço
Com os arquivos de configuração necessários editados e salvos, basta liberar as portas no firewall e iniciar o serviço:
firewall-cmd --permanent --add-service=dns
firewall-cmd --complete-reload
systemctl enable named.service
systemctl start named.service
Validando o servidor
Se tudo deu certo até aqui o serviço esta no ar pronto para ser testado. Altere o arquivo /etc/resolv.conf do servidor como no exemplo abaixo:
search exemplo.com.br
nameserver 172.16.10.10
Teste com o comando:
$ dig dns.exemplo.com.br
; <<>> DiG 9.9.4-RedHat-9.9.4-18.el7_1.3 <<>> dns.exemplo.com.br
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18455
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dns.exemplo.com.br. IN A
;; ANSWER SECTION:
dns.exemplo.com.br. 86400 IN A 172.16.10.10
;; AUTHORITY SECTION:
exemplo.com.br. 86400 IN NS dns.exeplo.com.br.
;; Query time: 0 msec
;; SERVER: 172.16.10.10#53(172.16.10.10)
;; WHEN: Tue Sep 01 23:52:45 BRT 2015
;; MSG SIZE rcvd: 75
Resolva algum dos hostnames registrado para validação:
$ nslookup www.exemplo.com.br
Server: 172.16.10.10
Address: 172.16.10.10#53
Name: www.exemplo.com.br
Address: 172.16.10.30
Sucesso! :)
Qualquer dúvida, sugestão, correção ou problema entre em contato através dos comentários.