Informática Numaboa - Linux
BIND (DNS) na jaula
|
Qui 16 Mar 2006 01:00 |
- Detalhes
- Categoria: Como fazer instalações
- Atualização: Quarta, 15 Abril 2009 11:45
- Autor: vovó Vicki
- Acessos: 17998
Ao contrário do que muita gente pensa, quando digitamos um endereço no navegador, ou seja, quando pedimos que ele nos mostre uma página de um determinado domínio, a primeira coisa que o navegador faz é procurar o endereço IP do domínio. Se o cache do navegador ou a máquina não puderem fornecer este endereço, então um servidor DNS é acionado. Um DNS (Domain Name Server - Servidor de Nomes de Domínios) é um tradutor de nomes capaz de transformar um nome num número que corresponde ao endereço IP (Internet Protocol) da máquina que hospeda o domínio desejado. Somente depois de obter este número é que o navegador pode se comunicar com a máquina desejada e buscar a página solicitada. Por exemplo, quando você acessou esta página, você indicou o domínio www.numaboa.com que foi traduzido para o IP 200.195.184.106.
Um DNS também pode fazer um mapeamento reverso, ou seja, também é capaz de transformar um endereço IP num nome de domínio. É claro que os bilhões de domínios hospedados nos servidores que compõem a Internet não dependem apenas de um único DNS para fazer todas as traduções necessárias. Existem DNS especializados em países, em tipos (como .com, .org, .net, etc), assim como os chamados DNS autoritativos que dão a palavra final sobre domínios (indicam os responsáveis e o endereço IP).
Um dos maiores banco de dados do planeta
O conjunto de máquinas DNS que armazenam e fornecem os dados necessários para traduzir nomes de domínios em endereços IP e vice-versa formam um dos maiores bancos de dados do planeta e permitem que a Internet seja o que é hoje. Como cada uma das máquinas guarda uma parte das informações e todas elas trabalham em conjunto, este banco de dados é chamado de distribuído. Ser distribuído significa que cada servidor realiza uma parcela do trabalho e que cada responsável pelo servidor responde pelo correto funcionamento do serviço que disponibilizou. Lembre-se disto se você está pensando em instalar, configurar e disponibilizar um serviço de DNS. Um DNS mal comportado sobrecarrega o sistema e, falando Português claro, é o maior mico para o responsável! Então, antes de por a mão na massa, a melhor coisa que podemos fazer é planejar 
Planejamento
Na primeira vez em que resolvi instalar e configurar um servidor DNS próprio, saí catando informações pela Internet. Como com tudo referente ao Linux, tinha certeza de que encontraria farto material com explicações detalhadas... e encontrei, só que foi um pedaço em cada canto e muita coisa sem explicação. Penei um bocado, briguei com a máquina, com o soft, com os scripts e nada parecia dar certo. Também, era a primeira vez 
Conforme pesquisava, fui anotando tudo e mais alguma coisa (quase deu um livro!), testando várias configurações e quebrando a cara um sem número de vezes. Mas nem tudo foi em vão: tive a oportunidade de rever os conceitos de domínios e nomes de domínios no sistema, aprendi que o BIND é o software mais utilizado e de aprender que podemos colocar no ar quatro tipos diferentes de servidores de nomes - master (primário e autoritativo), slave (escravo ou secundário, também autoritativo), caching-only (sem autoridade, apenas um cache de informações) e forwarding (que remete a solicitação para outros servidores de nomes se não tiver a informação pedida). O mais importante, no entanto, foi descobrir que o BIND é vulnerável aos mais diversos ataques, o que me obrigou a tomar algumas precauções. Uma delas foi encarcerar (ou enjaular) o DNS.
Existem vários "sabores" Linux mas, por ser mais enxuto, mais próximo do Unix e funcionar 100%, costumo usar apenas o Slackware como sistema operacional. Por este motivo, todos os comandos e diretivas deste texto são para Slackware 10.2. Se você optou por uma distribuição diferente, faça as adaptações necessárias.
Como exemplo, vamos preparar a máquina "slack" como servidor primário de nomes. Seu endereço IP 10.20.30.40 é um endereço fixo (fictício), seu nome será ns1.numaboa.com.br e seu alias será DNSnumaboa. As etapas são:
- Instalação do BIND.
- Preparação da jaula.
- Configuração do servidor.
- Criação dos registros de recursos do servidor.
- Configuração do cliente.
- Definição das permissões.
- Ativação do sistema de nomes.
- Testes.
- Manutenção.
1. Instalando o BIND
Geralmente, quando instalamos o Slackware, o pacote do BIND também é instalado. Se você optou por não instalá-lo junto com o sistema, existem duas saídas: instalar o pacote BIND para Slackware ou compilar o daemon. Ambas são fáceis.
Instalando o pacote
Em http://www.slackware.com/packages/ procure a versão mais recente do BIND e faça o download. No momento em que estou escrevendo este artigo, é o bind-9.3.2-i486-3.tgz e costumo fazer os downloads do FTP do Slackware Brasil:
# cd /pacotes # wget ftp://ftp.slackware-brasil.com.br/slackware-current/slackware/n/bind-9.3.2-i486-3.tgz
Você pode usar o aplicativo pkgtool ou o comando installpkg bind-9.3.2-i486-3.tgz.
Compilando o daemon
O site oficial do BIND é o ISC (Internet Systems Consortium, Inc.), no endereço http://www.isc.org/index.pl?/sw/bind/. Faça o download dos fontes, compile e instale:
# cd /downloads # wget http://ftp.isc.org/isc/bind9/9.3.2/bind-9.3.2.tar.gz # gzip -d bind-9.3.2.tar.gz # tar xf bind-9.3.2.tar # cd bind-9.3.2 # ./configure # make # make install
2. Preparando a jaula
Uma "jaula" é um mecanismo que serve para limitar a capacidade de um processo acessar recursos fora de uma área muito limitada. Um servidor de nomes "fala" muito com o mundo exterior e este mundo exterior (a "Internet pública") já provou ser bastante hostil. Qualquer falha do BIND - as já conhecidas e as que ainda serão descobertas - podem ser exploradas por qualquer abelhudo mal intencionado. Pois bem, isolando este processo numa jaula, restringimos os estragos que eventualmente possam afetar o sistema.
Uma jaula é criada fazendo-se uma chamada do sistema a chroot() (o nome para "change root" - mudar a raiz) com um nome de diretório como parâmetro. Depois desta chamada, a raiz ou topo da árvore de diretórios deste processo muda de / para o diretório especificado e o processo não consegue mais sair desta área. O mais comum é confinar o servidor de nomes em /chroot/named, mas isto é apenas uma convenção: pode-se usar /jaula/named, jaula/nominado, /usr/local/named, etc.
É claro que a jaula não impede que o BIND seja detonado, mas o pior que pode acontecer é que apenas o servidor de nomes seja avariado e não todos os serviços da máquina.
Usuário e Grupo
Antes de mais nada é preciso criar um usuário e um grupo que serão os "donos" da jaula. Como exemplo, o grupo será domador e o usuário será roy. Escolhi estes nomes porque me lembrei da história do tigre que resolveu tirar seu domador do picadeiro e quase o matou. Isto aconteceu em Las Vegas, durante uma apresentação da dupla Siegfried & Roy.
# groupadd domador # useradd -g domador -d /jaula/named -s /bin/true roy # passwd -l roy
O comando passwd -l roy bloqueia a conta criada.
Os diretórios da jaula
# mkdir -p /jaula/named # cd /jaula/named
O último comando nos coloca no diretório /jaula/named para que possamos criar a hierarquia de diretórios. O nome destes diretórios NÃO podem ser alterados porque precisam corresponder ao que o BIND procura.
# mkdir -p dev # mkdir -p etc # mkdir -p logs # mkdir -p var/run # mkdir -p conf/secondaries
Todos estes comandos podem ser reduzidos a uma única linha se você usar a sintaxe a seguir. O resultado obtido é o mesmo.
# mkdir -p /jaula/named/{dev,etc,logs,var/run,conf/secondaries}
Verifique se os diretórios foram criados corretamente:
/--- jaula ---
|--- named ---
|--- conf ---
|--- secondaries
|--- dev
|--- etc
|--- logs
|--- var ---
|--- run
Os dispositivos (devices)
# mknod dev/null c 1 3 # mknod dev/zero c 1 5 # mknod dev/random c 1 8
Confira o resultado no diretório /jaula/named/dev. Tirando a data e a hora, você deve encontrar o seguinte:
crw-r--r-- 1 root domador 1, 3 2006-02-10 16:16 null crw-r--r-- 1 root domador 1, 8 2006-02-10 16:16 random crw-r--r-- 1 root domador 1, 5 2006-02-10 16:16 zero
A hora local
Finalmente, é preciso copiar o arquivo do fuso horário para acertar a hora local:
# cp /etc/localtime etc
Sobre os arquivos de configuração
O BIND é um servidor de DNS cliente/servidor. O cliente é chamado de resolvedor e é configurado por dois arquivos: o rndc.conf e o resolv.conf. O rndc.conf diz ao resolvedor (cliente) que serviço de nomes usar e em que ordem devem ser usados. O resolv.conf configura o resolvedor para que possa interagir com um servidor DNS.
O servidor tem um arquivo de configuração principal, o named.conf, no qual constam as zonas sobre as quais tem autoridade e os dados (registros) referentes a cada uma delas. Portanto, existem quatro tipos de arquivos de configuração:
- /etc/resolv.conf (cliente)
- /jaula/named/etc/rndc.conf (cliente).
- /jaula/named/etc/named.conf (servidor)
- Registros das zonas em /jaula/named/conf/ (servidor)
A chave de segurança
Para permitir o acesso ao serviço de nomes através do localhost ou de um host remoto, é preciso que os arquivos named.conf e rndc.conf possuam uma chave secreta em comum. Até o momento, o único algoritmo de encriptação aceito pelo BIND é o HMAC-MD5, um hash muito usado em sistemas seguros de senhas. O primeiro passo é gerar a chave que deverá ser incluída nos dois arquivos. Para isto, use o comando rndc-config:
# rndc-config
O resultado é o seguinte:
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-md5;
secret "MkdLsuBABoPi0T1x1An4VQ==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# End of rndc.conf
# Use with the following in nominado.conf, adjusting the allow list as needed:
# key "rndc-key" {
# algorithm hmac-md5;
# secret "MkdLsuBABoPi0T1x1An4VQ==";
# };
#
# controls {
# inet 127.0.0.1 port 953
# allow { 127.0.0.1; } keys { "rndc-key"; };
# };
# End of named.conf
Este comando gerou dois conteúdos: um deles será utilizado no arquivo /jaula/named/etc/rndc.conf e o outro no arquivo /jaula/named/etc/named.conf. O valor de secret muda de geração para geração, portanto, o secret que você obteve deve ser diferente ( :thumbup: assim espero).
3. Configuração do servidor
O arquivo /jaula/named/etc/named.conf é um verdadeiro mapa da mina. Além de guardar a chave que autoriza a comunicação com o cliente, é nele que definimos diversas opções, controlamos quem (e como) pode usar o servidor, declaramos as zonas sobre as quais temos autoridade e seus respectivos arquivos de registro.
#
# named.conf
# Arquivo de configuração do servidor BIND
#
options {
directory "/conf";
pid-file "/var/run/named.pid";
statistics-file "/var/run/named.stats";
dump-file "/var/run/named.db";
version "[bloqueada]";
allow-query { localhost; };
allow-recursion { localhost; };
};
key "rndc-key" {
algorithm hmac-md5;
secret "MkdLsuBABoPi0T1x1An4VQ==";
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
# Os servidores de nomes raiz
zone "." {
type hint;
file "db.rootcache";
};
# localhost - zona remetente
zone "localhost" {
type master;
file "db.localhost";
notify no;
};
# localhost - zona inversa
zone "0.0.127.in-addr.arpa" {
type master;
file "db.0.0.127";
notify no;
};
# host numaboa.com.br - zona remetente
zone "numaboa.com.br" IN {
type master;
file "numaboa.com.br.domain";
allow-query { any; };
}
# host - zona inversa
zone "30.20.10.in-addr.arpa" {
type master;
file "30.20.10.reverso";
allow-query { any; };
}
# host numaboa.org - zona remetente
zone "numaboa.org" IN {
type master;
file "numaboa.org.domain"
allow-query { any; };
}
# Fim de named.conf
Existem vários blocos no arquivo de configuração named.conf. Cada um deles será explicado em detalhes:
Bloco options
O bloco options define o comportamento default de todas as zonas listadas. A primeira coisa é definir os diretórios de trabalho. Lembre-se que, como definimos uma jaula para o BIND, ele enxerga o diretório raiz como sendo /jaula/named e todos os outros diretórios são relativos a este. É por isto que indicamos o diretório dos registros com directory "/conf"; e NÃO como /jaula/named/conf. A indicação da localização dos arquivos de identificação do processo (named.pid), de estatística (named.stats) e de dump (named.db) segue o mesmo princípio.
A declaração version indica a versão do BIND que estamos usando. Se não quisermos tornar pública esta informação (por motivo de segurança e para atrapalhar um pouco os possíveis abelhudos de plantão 
), podemos fornecer uma string qualquer. Bom seria indicar version "[vá lamber sabão]";, mas isto seria indelicado com outros administradores. Por isto optei por version "[bloqueada]";.
Para se proteger contra spoofing (ou seja, que o seu servidor de nomes seja usado para fornecer informações que não estejam sob a sua autoridade) e para reduzir o uso desnecessário da sua máquina, o melhor é bloquear todos os IPs com exceção do localhost. Para isto, use a declaração allow-query { localhost; } (permite solicitação) indicando APENAS o localhost. Lembre-se de que, se usar esta configuração, este será o comportamento default do seu servidor de nomes - ele fornece apenas informações a respeito do localhost. E como ficam as zonas declaradas no named.conf? Também ficam bloqueadas! É por este motivo que, para liberar uma zona listada, o bloco da zona precisa de uma declaração própria allow-query { any; }; (permite-solicitação { todas; };) para ficar acessível.
Além disso, bloqueando solicitações recursivas (novamente com exceção do localhost), reduzimos o risco de ataques do tipo cache poisoning (envenenamento do cache). A declaração allow-recursion { localhost; }; nos dá esta segurança.
Bloco key
O bloco key contém o nome e o valor da chave que o cliente DNS precisa apresentar para que seja autorizado a acionar o servidor de nomes. key é identificado pelo nome da chave "rndc-key" e as declarações algorithm e secret indicam o tipo de algoritmo (HMAC-MD5) e a chave propriamente dita. O nome da chave pode ser qualquer um da sua escolha. Para que cliente e servidor se entendam, não custa repetir que esta identificação e declarações precisam ser iguais tanto no arquivo named.conf quanto no arquivo rndc.conf (que veremos adiante).
Bloco controls
A declaração controls especifica os canais de controle usados pelos administradores para controlar o servidor de nomes. Estes canais de controle são usados pelo rndc (cliente) para enviar comandos e para obter resultados não-DNS do servidor de nomes.
Um canal de controle inet é um socket TCP escutando uma dada porta IP num determinado endereço IP (que pode ser IPv4 ou IPv6). Como usaremos o rndc apenas no localhost, indicamos o endereço loopback 127.0.0.1. Se não for especificada nenhuma porta, a 953 é usada.
Com allow { 127.0.0.1; } damos apenas permissão para o IP 127.0.0.1 utilizar a conexão disponibilizada e isto apenas se a chave keys { "rndc-key"; } conferir com a do servidor de nomes. Quando há mais de um administrador, pode-se definir mais de um endereço IP e mais de uma chave. Depois, é só adicionar os endereços e as chaves nas respectivas listas como, por exemplo, allow { 127.0.0.1; 10.20.30.0/24; } keys { "rndc-key"; "chave2"; };
Bloco zone "."
Este bloco declara a zona dos servidores de nomes raiz. De acordo com a nota técnica ISC-TN-2002-2, o mais correto é configurar o tipo da zona "." como sendo do tipo hint (sugestão) porque não temos autoridade sobre servidores raiz.
O arquivo que contém a lista dos servidores raiz que serão sugeridos se encontra no diretório /conf (indicado pela declaração directory "/conf";) e tem o nome db.rootcache (você pode escolher o nome que quiser não só para este arquivo como para todos os outros de todas as zonas).
Bloco localhost - zona remetente
A zona do localhost é do tipo master (pudera, se não temos autoridade sobre o localhost então estamos perdidos :roll: ) e o arquivo de registro chama-se db.localhost. Além disso, usamos a declaração notify no; para que não sejam enviadas mensagens de notificação DNS para outros servidores de nome listados em registros NS da zona quando houver alterações nesta zona (o default é yes). É que modificações no localhost só interessam ao próprio localhost.
Bloco localhost - zona inversa
Para que o servidor de nomes possa fazer a tradução inversa, ou seja, fornecer o nome da zona que corresponde a determinado endereço IP, é preciso declarar zonas inversas. Para o localhost, isto é feito com zone "0.0.127.in-addr.arpa". Note que o nome da zona é uma parte do endereço IP 127.0.0.1 virado ao contrário. O arquivo com os registros é o db.0.0.127 e, novamente, não queremos que as modificações sejam notificadas.
Bloco numaboa.com.br - zona remetente
Um dos domínios hospedados no meu servidor web/DNS é o numaboa.com.br. Este domínio está pegando uma carona no endereço IP do meu servidor de nomes e precisa ser declarado numa zona remetente com zone "numaboa.com.br" IN. O IN indica que se trata de uma zona de Internet e pode ser omitido.
O tipo da zona é type master; porque tenho autoridade sobre esta zona que contém o meu domínio. O arquivo com os registros é o file "numaboa.com.br.domain" e com allow-query { any; }; permito que você e todos os outros internautas que queiram visitar meu site obtenham a tradução do nome para o endereço IP.
Bloco host - zona inversa
As consultas à zona numaboa.com.br (e outros domínios virtuais que estejam hospedados no mesmo host) também precisam fornecer traduções inversas. No início do texto dei como exemplo um endereço IP fictício 10.20.30.40, o qual precisa ser invertido gerando a declaração zone "30.20.10.in-addr-arpa". O tipo é type master;, o arquivo de registros é file "30.20.10.reverso"; e qualquer tipo de solicitação é aceita com allow-query { any; };
Bloco numaboa.org - zona remetente
Existe mais um domínio hospedado na máquina 10.20.30.40 - é o numaboa.org. A zona remetente não é muito diferente da zona numaboa.com.br, apenas o nome do arquivo de registros muda: é file "numaboa.org.domain";
Como este domínio reside no IP cuja zona inversa já foi declarada, não há a necessidade de criar outro bloco de zona inversa.
4. Registros de Recursos
Para cada uma das zonas declaradas no arquivo de configuração named.conf será preciso criar um arquivo de registros correspondente que tenha o MESMO nome indicado na declaração file. Antes de exemplificar cada um deles, alguns conceitos importantes:
- $TTL - Time To Live (Tempo de Vida): a partir do BIND 9 esta diretiva é obrigatória e indica o tempo que os registros permanecem no cache sem atualização. É claro que $TTL indica uma medida de tempo e esta, assim como outras que veremos a seguir, pode ser em segundos, minutos, horas, dias e semanas. $TTL 86400 é o mesmo que $TTL 24H porque 86400 segundos correspondem a 24 horas.
- SOA - Start Of Authority (Início da Autoridade): o Registro de Recursos (RR - Resource Record) SOA é o preâmbulo de TODAS as zonas e possui cinco colunas.
- O nome da zona.
- IN indica que é da Internet e pode ser suprimida.
- SOA, o início da autoridade.
- Um valor MNAME, que é o nome do servidor DNS primário (master). Use de preferência o nome completo seguido por um ponto (.)
- Um valor RNAME, que é o e-mail do responsável no formato nome.domínio.com.br. (não esquecer do ponto no final!)
- Dentro do bloco SOA ficam as seguintes declarações (obedeça a ordem!)
- Número de série: geralmente no formato AAAAMMDDxx, onde AAAA é o ano, MM o mês, DD o dia e xx um valor sequencial. Toda vez que algum registro for alterado, não esqueça de atualizar o número de série incrementando o valor sequencial para avisar outros servidores de nomes que houve mudanças.
- Valor refresh: se não for usado o NOTIFY, indica a frequência de releitura dos RR servidor de nomes escravo (slave) ou secundário.
- Valor retry: caso haja alguma falha de comunicação/leitura, indica o tempo de espera antes de uma nova tentativa efetuada pelo servidor escravo ou secundário.
- Valor expire: indica quando a validade dos dados SOA expira, garantindo os RR durante o tempo indicado, mesmo se ocorrer algum erro. Só faz sentido para o servidor de nomes escravo ou secundário.
- Valor TTL mínimo: serve como valor default para todos os RRs sem TTL indicado. Atualmente o $TTL inicial é obrigatório e, a partir da versão 9 do Bind, funciona como tempo negativo de cache - o tempo que um NAME ERROR = NXDOMAIN fica no cache. O valor máximo deste parâmetro permitido pelo Bind 9 é de 3 horas (10800 segundos).
- O arquivo da zona ainda pode ter diversos outros RRs:
- A (address - endereço): endereço IP.
- NS (name server - servidor de nomes)
- PTR (pointer - ponteiro): usado principalmente em arquivos de zona inversa.
- MX (mail extended): serviço de e-mail e prioridade.
- CNAME (canonical name): apelidos de endereços (e SÓ de endereços).
- TXT (text): opcional, texto explicativo ou diretivas especiais (como, por exemplo, para identificar servidores de e-mail que não permitem spam).
Use seu editor de texto preferido para criar os arquivos a seguir no diretório /jaula/named/conf/:
O arquivo de registros do localhost
;
; db.localhost
;
$TTL 86400
localhost. IN SOA ns1.numaboa.com.br. webmaster.numaboa.com.br. (
2006030601 ; serial
24H ; refresh
2H ; retry
1000H ; expire
2D ) ; minimum
localhost. IN NS ns1.numaboa.com.br.
localhost. IN A 127.0.0.1
Este arquivo de registros indica que o tempo de vida (TTL) da zona localhost é de 86400 segundos (24 horas). Seu SOA informa que o nome da máquina servidora DNS é ns1.numaboa.com.br e que o responsável pelo registro é webmaster no domínio numaboa.com.br. O número de série é o primeiro criado em 06 de março de 2006; a releitura dos registros (refresh) deve ocorrer a cada 24 horas; caso haja falha, a releitura deve ser repetida após 2 horas; a validade dos dados expira após 1000 horas e o TTL mínimo é de 2 dias.
Depois de definido o SOA, seguem apenas mais dois registros de recursos (RR). O NS diz que os dados da zona localhost podem ser encontrados no servidor de nomes ns1.numaboa.com.br e o A diz que o endereço de localhost é 127.0.0.1.
Existe uma notação especial (@) que significa origem, ou seja, o nome da zona. Como no arquivo named.conf a zona está identificada como "localhost", @ = localhost. Neste caso, todas as referências a localhost podem ser substituídas por @. Mas existe mais uma particularidade: se não indicarmos o nome da zona na coluna da esquerda, vale o nome usado na linha anterior. Por isto, o arquivo abaixo funciona exatamente como o anterior:
;
; db.localhost
;
$TTL 86400
@ IN SOA ns1.numaboa.com.br. webmaster.numaboa.com.br. (
2006030601 ; serial
24H ; refresh
2H ; retry
1000H ; expire
2D ) ; minimum
IN NS ns1.numaboa.com.br.
IN A 127.0.0.1
Existe um utilitário do BIND que serve para checar a sintaxe de arquivos de registros de recursos. Deve ser usado após a criação de cada um dos arquivos. A sintaxe é named-checkzone <nome da zona> <arquivo de configuração>. Para o arquivo acima obtemos:
# named-checkzone localhost /chroot/named/conf/db.localhost zone localhost/IN: loaded serial 2006030601 OK
O arquivo de registros da zona inversa do localhost
A zona inversa do localhost foi definida no arquivo named.conf como zone "0.0.127.in-addr.arpa". Quando encontra um "in-addr.arpa", o BIND sabe que a parte fixa do endereço IP será o inverso de 0.0.127., ou seja, 127.0.0. e que apenas o último octeto será definido. Pode-se fixar de 1 a 3 octetos. Por exemplo, se a zona inversa fosse "0.127.in-addr.arpa", a parte fixa seria 127.0. e precisaríamos definir os dois octetos restantes. Mas vamos a um exemplo:
;
; db.0.0.127
;
$TTL 86400
@ IN SOA ns1.numaboa.com.br. webmaster.numaboa.com.br. {
2006030601 ; serial
86400 ; refresh (24 horas)
7200 ; retry (2 horas)
3600000 ; expire (1000 horas)
172800 ) ; minimum (48 horas)
IN NS ns1.numaboa.com.br.
1 IN PTR localhost.
A @, desta vez, é traduzida para 0.0.127.in-addr.arpa. Além disso, como não há referência de zona na segunda linha, é usada a anterior e a segunda linha se transforma em 0.0.127.in-addr.arpa IN NS ns1.numaboa.com.br.
Observe o ponto no final do ns1.numaboa.com.br. e de localhost.- é muito importante! Este ponto indica que o nome está completo, ou seja, o BIND não deve acrescentar o nome da zona no final destes nomes. Caso você esqueça do ponto, o localhost será transformado em localhost.0.0.127.in-addr.arpa e o ns1.numaboa.com.br em ns1.numaboa.com.br.0.0.127.in-addr.arpa.
A última linha começa com 1, que é o octeto faltante no endereço IP. Se você quiser definir, por exemplo, um IP 127.0.0.64, basta incluir mais uma linha de ponteiro como 64 IN PTR qualquernome.. Como estamos definindo apenas o localhost e o endereço IP padrão é 127.0.0.1, esta única linha de ponteiro é suficiente.
Confira com named-checkzone!
O arquivo de registros de numaboa.com.br
;
; numaboa.com.br.domain
;
$TTL 86400
@ IN SOA ns1.numaboa.com.br. webmaster.numaboa.com.br. {
2006030601 ; serial
86400 ; refresh (24 horas)
7200 ; retry (2 horas)
3600000 ; expire (1000 horas)
172800 ) ; minimum (48 horas)
TXT "Aldeia Numaboa"
NS ns1
NS ns2
MX 5 mail
localhost A 127.0.0.1
ns2 A 10.20.30.41
MX 10 mail
ns1 A 10.20.30.40
mail A 10.20.30.42
www CNAME ns1
ftp A 10.20.30.40
Usamos pela primeira vez um RR do tipo TXT para dizer simplesmente que os registros pertencem à Aldeia Numaboa - apenas um pouco de charme e para mostrar uma das utilidades deste RR. Deixando o charme de lado, este campo pode ser usado para fazer um registro SPF. No meu caso, ele contém "v=spf1 a mx ~all" para prevenir que spammers abusem do meu domínio. É uma precaução aconselhável e, para saber como configurar seu registro SPF, visite o link indicado.
Em seguida, indicamos que existem dois servidores de nomes com autoridade sobre esta zona, o ns1 e o ns2. Como não há ponto no final destes nomes, eles são transformados em ns1.numaboa.com.br e ns2.numaboa.com.br. Depois vem um RR do tipo MX indicando que endereços com o domínio numaboa.com.br serão aceitos com prioridade 5. Indicar a prioridade é obrigatório, mesmo quando se tem apenas um servidor de email. Caso seja indicado mais de um, eles devem ter prioridades diferentes. Por exemplo, o mail com prioridade 5 será acionado antes do mail2 com prioridade 10. Como mail também não tem ponto no final, ele será transformado em mail.numaboa.com.br.
Todo arquivo de domínio precisa especificar o endereço do localhost, o que é feito com um RR do tipo endereço, ou seja, localhost A 127.0.0.1.
O ns1 e ns2 precisam de endereços IP. No caso do ns2 (que também não possui ponto no final e é transformado em ns2.numaboa.com.br), o IP é 10.20.30.41, uma máquina diferente que está na mesma faixa de endereços que o ns1 (o certo seria ter um servidor de nomes numa faixa diferente... mas é melhor dois na mesma faixa do que apenas um ). Neste endereço também precisa haver um servidor de nomes rodando - o chamado servidor secundário, usado para contingências, praticamente uma cópia deste servidor que estamos configurando. Também aí existe um RR do tipo MX, o que torna válidos endereços @ns2.numaboa.com.br. Este é apenas um exemplo do que é possível configurar porque não tenho contas de email com este domínio.
Depois disto aparece pela primeira vez um RR do tipo CNAME. CNAME vem de canonical name e nada mais é do que um apelido para um nome que tenha um endereço definido. É o caso da linha www CNAME ns1, que é transformada em www.numaboa.com.br CNAME ns1.numaboa.com.br. Como o endereço de ns1.numaboa.com.br é 10.20.30.40, o do www.numaboa.com.br será o mesmo e esta URL poderá ser direcionada corretamente. Um erro bastante comum é criar CNAMEs usando nomes sem endereços, o que causa problemas no serviço DNS. Mais uma vez é só um exemplo do que é possível fazer. O melhor é esquecer os CNAMEs porque exigem uma consulta adicional ao DNS, o que atrasa o acesso inicial ao site e consome largura de banda. Por este motivo é aconselhável trocar CNAMEs por endereços específicos, por exemplo, www IN A 10.20.30.40.
Finalmente chegamos no nome mail que, como os outros sem ponto no final, será transformado em mail.numaboa.com.br. Já não era sem tempo, pois este nome já foi referenciado uma porção de vezes neste arquivo de configuração e ainda está sem endereço IP. Se esquecermos dele, o DNS vai pirar e o serviço de email vai ficar sem pai nem mãe O endereço IP 10.20.30.42 é mais uma máquina que faz parte da rede - só que esta oferece um serviço de email (assunto de outro texto).
O restante do arquivo não traz nada de novo. Ah! deixei de fora os IN porque, como disse anteriormente, são opcionais. Outro ah! Não deixe de conferir o arquivo com named-checkzone.
O arquivo de registros da zona inversa do IP 10.20.30
No arquivo de registros anterior usamos os IPs de três máquinas diferentes e o servidor de nomes precisa ser capaz de fornecer os nomes correspondentes. Seguindo o modelo do arquivo da zona inversa do localhost, crie o seguinte arquivo:
;
; 30.20.10.in-addr.arpa
;
$TTL 3D
@ IN SOA ns1.numaboa.com.br. webmaster.numaboa.com.br. {
2006030601 ; serial
86400 ; refresh (24 horas)
7200 ; retry (2 horas)
3600000 ; expire (1000 horas)
172800 ) ; minimum (48 horas)
NS ns1.numaboa.com.br.
NS ns2.numaboa.com.br.
40 PTR ns1.numaboa.com.br.
41 PTR ns2.numaboa.com.br.
42 PTR mail.numaboa.com.br.
O arquivo de registros de numaboa.org
Este arquivo de registros segue o mesmo padrão do arquivo de registros numaboa.com.br.domain. Como o servidor pode ter uma infinidade de domínios virtuais, basta colocar uma referência para cada um deles no named.conf e depois criar os arquivos de registros de acordo com as necessidades de cada um.
Lembrou de checar com o named-checkzone? Depois disso, para terminar a configuração do servidor de nomes, falta apenas um arquivo de registro: o da zona raiz.
O arquivo de registros da zona raiz
Este arquivo é apenas uma lista dos nomes e endereços dos servidores raiz. O arquivo oficial e mais atualizado pode ser obtido direto da Internic (ftp://ftp.internic.net/domain/named.cache). Para não sobrecarregar o site da Internic, existe um jeito bastante simples de obter as informações necessárias - acionando um dos servidores raiz. Existem 13 servidores de nomes deste tipo e seus nomes começam por uma letra de A a M seguida por .root-servers.net. Acionando o dig, um utilitário do BIND, pergunte, por exemplo, o que o e.root-server.net tem a informar:
# dig @e.root-servers.net
Você deve obter o seguinte resultado:
; <<>> DiG 9.3.1 <<>> @e.root-servers.net ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5154 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS F.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. . 518400 IN NS I.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS B.ROOT-SERVERS.NET. . 518400 IN NS C.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. ;; ADDITIONAL SECTION: A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4 B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201 C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12 D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90 E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10 F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241 G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4 H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53 I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17 J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30 K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129 L.ROOT-SERVERS.NET. 3600000 IN A 198.32.64.12 M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33 ;; Query time: 337 msec ;; SERVER: 192.203.230.10#53(192.203.230.10) ;; WHEN: Mon Mar 13 14:28:30 2006 ;; MSG SIZE rcvd: 436
Agora é só copiar e colar as seções ANSWER SECTION e ADDITIONAL SECTION no arquivo db.rootcache. Guarde bem este comando porque voltaremos a utilizá-lo num script de manutenção deste arquivo.
5. Configuração do cliente DNS
Depois de tanta trabalheira, agora falta pouco antes de colocar o serviço de nomes no ar porque a configuração do cliente não é tão cheia de nove horas quanto a do servidor.
O arquivo rndc.conf
Este é o arquivo da chave de segurança e fica junto com o named.conf no diretório /jaula/named/etc/. Use seu editor de texto preferido para criar o arquivo com o conteúdo obtido através do comando rndc-config:
key "rndc-key" {
algorithm hmac-md5;
secret "MkdLsuBABoPi0T1x1An4VQ==";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
O bloco key dá o nome rndc-key à chave, indica que o algoritmo usado é do tipo hmac-md5 e que o segredo é MkdLsuBABoPi0T1x1An4VQ==.
O bloco options diz que a chave default é a "rndc-key", que o servidor default tem o endereço IP 127.0.0.1 (localhost) e que a porta de comunicação default é a 953.
O arquivo resolv.conf
Se é que você ainda lembra, o arquivo resolv.conf não é enjaulado com os outros - fica no diretório /etc e configura o cliente (resolvedor) para que possa interagir com o servidor DNS. Quando você instalou o BIND (junto com o Slackware ou posteriormente), este arquivo foi criado. Use seu editor de texto e altere seu conteúdo para atender as suas necessidades:
search numaboa.com.br numaboa.org nameserver 10.20.30.40 nameserver 10.20.30.41
O comando search define uma lista de domínios que serão usados para ampliar um nome de domínio antes de ser enviado para o servidor de nomes. Esta lista pode ter até 6 nomes de domínio separados por um espaço em branco.
O comando nameserver define até 3 endereços IP de servidores de nomes que o cliente deve usar. Os servidores de nomes serão consultados na ordem dada caso algum não responda. Se não houver nenhum nameserver definido, o servidor de nomes do localhost é utilizado.
6. Verificando as permissões
Agora que os arquivos necessários foram criados dentro da jaula é preciso configurar seus proprietários e as permissões. Podemos fazer isto "na unha", mas isto não é muito confiável porque este método artesanal, além de ser muito trabalhoso, é propenso a erros. O melhor é criar um script que faça tudo automaticamente. Use seu editor de texto preferido e crie o arquivo named.perms no diretório /jaula:
# # /jaula/named.perms # Define a propriedade e as permissões do diretório named # cd /jaula/named # Como default, root é proprietário de tudo e apenas root pode escrever, chown -R root:domador # mas os diretórios também precisam executar find . -type f -print | xargs chmod u=rw,og=r find . -type d -print | xargs chmod u=rwx,og=rx # named.conf e rndc.conf precisam ser protegidos porque contém as chaves chmod o= etc/*.conf # É no diretório /conf/secondaries que ficam os arquivos dos servidores de nomes # principais (master) e o BIND precisa ser capaz de atualizar estes arquivos e # de criar novos. touch conf/secondaries/.empty find conf/secondaries/ -type f -print | xargs chown domador:domador find conf/secondaries/ -type f -print | xargs chmod ug=r,o= chown root:domador conf/secondaries chmod ug=rwx,o= conf/secondaries # O trabalho do var/run é para o arquivo PID chown root:root var/ chmod u=rwx,og=x var/ chown root:domador var/run chmod ug=rwx,o=rx var/run # O BIND precisa ser capaz de criar arquivos de log chown root:domador logs/ chmod ug=rwx,o=rx logs/
TODA VEZ que forem feitas mudanças em arquivos ou nos diretórios da jaula, é absolutamente necessário rodar este script!
Para que o script se torne executável, mude as permissões para
# chmod 755 /jaula/named.perms
Se você quiser observar o resultado do script, chame-o com:
# sh -x /jaula/named.perms
O resultado deve ser:
+ cd /jaula/named + chown -R root:domador . + find . -type f -print + xargs chmod u=rw,og=r + find . -type d -print + xargs chmod u=rwx,og=rx + chmod o= etc/named.conf etc/rndc.conf + touch conf/secondaries/.empty + find conf/secondaries/ -type f -print + xargs chown domador:domador + find conf/secondaries/ -type f -print + xargs chmod ug=r,o= + chown root:domador conf/secondaries + chmod ug=rwx,o= conf/secondaries + chown root:root var/ + chmod u=rwx,og=x var/ + chown root:domador var/run + chmod ug=rwx,o=rx var/run + chown root:domador logs/ + chmod ug=rwx,o=rx logs/
7. Levantando o sistema
Ativar ou levantar o BIND significa colocá-lo à disposição dos usuários para procurar os endereços IP necessários para navegar na Internet, mandar emails, etc. Também significa colocá-lo à disposição de outros servidores de nomes para fornecer os dados das zonas sobre as quais tem autoridade.
O daemon do BIND é chamado de named. No Slackware, os scripts de chamada dos daemons ficam no diretório /etc/rc.d. Acontece que o nosso named está enjaulado, o que nos obriga a definir usuários e permissões para termos acesso a ele. Para isto precisamos de um script especial e, só para lembrar que ele acessa um serviço enjaulado, será colocado no diretório /jaula.
ESTE, e APENAS ESTE script deve ser usado para levantar o serviço named. Crie o arquivo /jaula/named.start e não se esqueça de torná-lo executável usando o comando chmod 755.
#
# named.start
#
# Obs: o path dado para o parâmetro "-c" é relativo à raiz da jaula e
# não à raiz do sistema.
#
# Obs: adicionar "-n2" se houver múltiplas CPUs!
#
# uso: named [-c arqConf] [-d nívelDebug] [-f|-g]
# [-n nro_de_cpus] [-p porta] [-s]
# [-t chrootdir] [-u username]
cd /chroot/named
# Garantir que o arquivo de saída do debug possa ser escrito por domador
touch named.run
chown domador:domador named.run
chmod ug=rw,o=r named.run
PATH=/usr/local/sbin:$PATH named \
-t /jaula/named \
-u domador \
-c /etc/named.conf
Apenas para manter a coerência, podemos criar um script no diretório /etc/rc.d que, por sua vez, chama o script /jaula/named.start. Segue um exemplo:
#!/bin/sh
#
# rc.bind
#
export PATH=/usr/sbin:$PATH # necessário para o rndc
bind_start() {
echo -n "Levantando named (/jaula/named.start)... "
sh /jaula/named.start
echo "feito!"
}
bind_stop() {
echo -n "Baixando named (killall named)... "
killall named
echo "feito!"
}
case "$1" in
'levantar')
bind_start
;;
'baixar')
bind_stop
;;
'reiniciar')
bind_stop
sleep 1
bind_start
;;
*)
echo "uso $0 levantar|baixar|reiniciar"
esac
Agora, é rezar para tudo dar certo :unsure: Torne o script executável e levante o serviço:
# chmod 755 /jaula/named.start # chmod 755 /etc/rc.d/rc.bind # /etc/rc.d/rc.bind levantar
Se houver mensagens de erro indicando que um dos dois scripts está com problema, corrija o script (rc.bind e/ou named.start) que está causando erro.
8. Testando o sistema de nomes
E isto é tudo... por enquanto. Finalmente chegou a hora de testar o sistema para eliminar possíveis erros de configuração (erros de sintaxe, erros de digitação, falta de ponto e vírgula ou de ponto no final e CNAMEs mal comportados são os mais comuns). Verifique se o sistema realmente está no ar com:
# ps aux | grep named
Se tudo correu bem, o resultado deve ser algo parecido com
named 12513 0.0 1.3 8568 6592 ? Ss Feb26 1:40 named -t /jaula/named -u domador -c /etc/named.conf
Veja também o que diz o log do sistema (principalmente se deu zebra e você não obteve o resultado mostrado acima).
Mar 14 22:56:57 ns1 named[25779]: starting BIND 9.3.1 -t /jaula/named -u domador -c /etc/named.conf Mar 14 22:56:57 ns1 named[25779]: loading configuration from '/etc/named.conf' Mar 14 22:56:57 ns1 named[25779]: no IPv6 interfaces found Mar 14 22:56:57 ns1 named[25779]: listening on IPv4 interface lo, 127.0.0.1#53 Mar 14 22:56:57 ns1 named[25779]: listening on IPv4 interface eth0, 10.20.30.40#53 Mar 14 22:56:57 ns1 named[25779]: command channel listening on 127.0.0.1#953 Mar 14 22:56:57 ns1 named[25779]: zone 0.0.127.in-addr.arpa/IN: loaded serial 2006030601 Mar 14 22:56:57 ns1 named[25779]: zone 30.20.10.in-addr.arpa/IN: loaded serial 2006012201 Mar 14 22:56:57 ns1 named[25779]: zone numaboa.com.br/IN: loaded serial 2006022601 Mar 14 22:56:57 ns1 named[25779]: zone localhost/IN: loaded serial 2006030602 Mar 14 22:56:57 ns1 named[25779]: zone numaboa.org/IN: loaded serial 2006012202 Mar 14 22:56:57 ns1 named[25779]: running Mar 14 22:56:57 ns1 named[25779]: zone numaboa.com.br/IN: sending notifies (serial 2006022601) Mar 14 22:56:57 ns1 named[25779]: zone numaboa.org/IN: sending notifies (serial 2006012202) Mar 14 22:56:57 ns1 named[25779]: zone 30.20.10.in-addr.arpa/IN: sending notifies (serial 2006012201)
Se tudo tiver corrido como o esperado, este será o log. Se não, você poderá ver algumas mensagens de erro que servirão para você localizá-los e corrigi-los. Repita esta operação (corrigir erros, reiniciar o serviço) até que o log não mostre mais erro algum - aí o daemon realmente está no ar
Observe que os números de série das zonas são carregadas e notificadas. É por este motivo que, toda vez que algum arquivo de registros RR for alterado, o número de série PRECISA ser incrementado. Também é por este motivo que o servidor DNS também precisa ser reiniciado!
Testando as configurações
Com o daemon respondendo, podemos testar as configurações das zonas sob a nossa autoridade. Vamos começar com o localhost (127.0.0.1). Para isto, vamos acionar um dos utilitários do BIND, o dig, com o parâmetro -x para obter a zona inversa:
# dig -x 127.0.0.1 ; <<>> DiG 9.3.1 <<>> -x 127.0.0.1 ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31647 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;1.0.0.127.in-addr.arpa. IN PTR ;; ANSWER SECTION: 1.0.0.127.in-addr.arpa. 86400 IN PTR localhost. ;; AUTHORITY SECTION: 0.0.127.in-addr.arpa. 86400 IN NS ns1.numaboa.com.br. ;; ADDITIONAL SECTION: ns1.numaboa.com.br. 86400 IN A 10.20.30.40 ;; Query time: 14 msec ;; SERVER: 10.20.30.40#53(10.20.30.40) ;; WHEN: Tue Mar 14 23:20:42 2006 ;; MSG SIZE rcvd: 111
O dig reconhece uma porção de parâmetros. Para ver uma lista completa use
# dig -h
Para acompanhar o caminho percorrido por uma solicitação até encontrar o servidor autoritativo, vamos usar o parâmetro +norecurse porque não queremos que a solicitação seja passada adiante - nós é que comandamos passo a passo. Vamos começar com um servidor raiz. Se você não lembra dos nomes dos mesmos, basta dar um # dig para obter a lista. Escolha qualquer servidor raiz (eu escolhi o E) e pergunte por numaboa.com.br:
# dig +norecurse +noquestion +nostats +nocmd numaboa.com.br. @e.root-servers.net. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62936 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 6 ;; AUTHORITY SECTION: br. 172800 IN NS E.DNS.br. br. 172800 IN NS A.DNS.br. br. 172800 IN NS B.DNS.br. br. 172800 IN NS C.DNS.br. br. 172800 IN NS D.DNS.br. ;; ADDITIONAL SECTION: A.DNS.br. 172800 IN A 200.160.0.10 A.DNS.br. 172800 IN AAAA 2001:12ff::10 B.DNS.br. 172800 IN A 200.209.30.5 C.DNS.br. 172800 IN A 200.130.31.5 D.DNS.br. 172800 IN A 204.152.184.70 E.DNS.br. 172800 IN A 139.91.1.20
Foram usados outros parâmetros além do +norecurse apenas para diminuir o tamanho da listagem. Esta nos mostra que há 5 servidores para o domínio de primeiro nível .br. Novamente, escolha um deles (desta vez escolhi o A) e pergunte novamente por numaboa.com.br:
# dig +norecurse +noquestion +nostats +nocmd numaboa.com.br. @A.DNS.br. ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47785 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2 ;; AUTHORITY SECTION: numaboa.com.br. 86400 IN NS ns2.numaboa.com.br. numaboa.com.br. 86400 IN NS ns1.numaboa.com.br. ;; ADDITIONAL SECTION: ns1.aesaweb.com.br. 86400 IN A 10.20.30.40 ns2.aesaweb.com.br. 86400 IN A 10.20.30.41
Prontinho! Recebemos uma resposta autoritativa com o nome do domínio e os endereços IP dos seus dois servidores de nomes. O mesmo pode ser obtido com um único parâmetro, o +trace:
dig +trace numaboa.com.br ; <<>> DiG 9.3.1 <<>> +trace numaboa.com.br ;; global options: printcmd . 466022 IN NS g.root-servers.net. . 466022 IN NS h.root-servers.net. . 466022 IN NS i.root-servers.net. . 466022 IN NS j.root-servers.net. . 466022 IN NS k.root-servers.net. . 466022 IN NS l.root-servers.net. . 466022 IN NS m.root-servers.net. . 466022 IN NS a.root-servers.net. . 466022 IN NS b.root-servers.net. . 466022 IN NS c.root-servers.net. . 466022 IN NS d.root-servers.net. . 466022 IN NS e.root-servers.net. . 466022 IN NS f.root-servers.net. ;; Received 260 bytes from 10.20.30.40#53(10.20.30.40) in 0 ms br. 172800 IN NS B.DNS.br. br. 172800 IN NS C.DNS.br. br. 172800 IN NS D.DNS.br. br. 172800 IN NS E.DNS.br. br. 172800 IN NS A.DNS.br. ;; Received 224 bytes from 192.112.36.4#53(g.root-servers.net) in 201 ms numaboa.com.br. 86400 IN NS ns1.numaboa.com.br. numaboa.com.br. 86400 IN NS ns2.numaboa.com.br. ;; Received 108 bytes from 200.209.30.5#53(B.DNS.br) in 57 ms numaboa.com.br. 86400 IN SOA ns1.numaboa.com.br. webmaster.numaboa.com.br. 2006022601 86400 7200 3600000 172800 ;; Received 90 bytes from 10.20.30.40#53(ns1.numaboa.com.br) in 0 ms
Caminho percorrido sem erros e objetivo alcançado significa que o servidor de nomes está no ar e funcionando como o esperado. Se por acaso ocorreu algum erro, analise as mensagens de erro do dig e as do arquivo /var/log/messages para encontrar as falhas. Depois de corrigi-las, lembre-se da "santíssima trindade":
- Incrementar o número de série dos arquivos de registros que tiverem sido alterados.
- Executar o script /jaula/named.perms
- Reiniciar o serviço com /etc/rc.d/rc.bind reiniciar.
Controlando todos os registros
Para verificar todos os RRs referentes ao domínio numaboa.com.br, chame o dig com o tipo de solicitação axfr:
# dig axfr numaboa.com.br ; <<>> DiG 9.3.1 <<>> axfr numaboa.com.br ;; global options: printcmd numaboa.com.br. 86400 IN SOA ns1.numaboa.com.br. webmaster.numaboa.com.br. 2006022601 86400 7200 3600000 172800 numaboa.com.br. 86400 IN TXT "v=spf1 a mx ~all" numaboa.com.br. 86400 IN NS ns1.numaboa.com.br. numaboa.com.br. 86400 IN NS ns2.numaboa.com.br. numaboa.com.br. 86400 IN MX 5 mail.numaboa.com.br. ftp.numaboa.com.br. 86400 IN A 10.20.30.40 ftp.numaboa.com.br. 86400 IN MX 5 mail.numaboa.com.br. localhost.numaboa.com.br. 86400 IN A 127.0.0.1 mail.numaboa.com.br. 86400 IN A 10.20.30.42 mail.numaboa.com.br. 86400 IN MX 5 mail.numaboa.com.br. www.numaboa.com.br. 86400 IN A 10.20.30.40 www.numaboa.com.br. 86400 IN MX 5 mail.numaboa.com.br. numaboa.com.br. 86400 IN SOA ns1.numaboa.com.br. webmaster.numaboa.com.br. 2006022601 86400 7200 3600000 172800 ;; Query time: 31 msec ;; SERVER: 10.20.30.40#53(10.20.30.40) ;; WHEN: Wed Mar 15 14:23:14 2006 ;; XFR size: 13 records (messages 1)
Se você tem um domínio no registro.br, você pode alterar um dos DNS deste domínio de modo que aponte para o seu servidor de nomes. Sugiro que você utilize o DNS secundário porque ainda está em fase de teste. Se o seu servidor de nomes estiver ativo, o registro.br aceita a alteração depois de testar se ele está respondendo... exatamente o que você quer saber. Se o seu servidor foi aceito, os dados referentes ao seu domínio serão modificados na próxima atualização que o registro.br efetuar - até a última vez que verifiquei, isto ocorre diariamente às 5:00, 13:00 e 21:00 horas.
Aliás, vai aqui uma dica. Toda vez que você alterar alguma coisa, logo depois dos horários de atualização você pode usar o utilitário [url=registro.br/cgi-bin/nicbr/dnscheck]Verificação DNS[/url] do registro.br.
9. Manutenção de arquivos
O único arquivo que precisa ser checado periodicamente é o arquivo de registros dos servidores raiz. Apesar das alterações serem extremamente raras, ainda assim é bom checar se os IPs são válidos. Podemos incluir esta tarefa na nossa rotina de trabalho, mas, por ser uma tarefa periódica, o melhor é apelar para o cron e esquecer o assunto. Inclua o script abaixo no diretório /etc/cron.monthly e transfira a responsabilidade das atualizações para o Slack
#!/bin/sh
#
# /etc/cron.monthly/rootservers
# Atualiza o arquivo com os servidores raiz usados pelo Bind (named)
#
cd /jaula/named/conf
dig @e.root-servers.net . ns >db.rootcache.new 2> errors
case `cat db.rootcache.new` in
*NOERROR*)
;;
*)
echo "Arquivo de servidores raiz NÃO foi atualizado." >> /var/log/messages 2>&1
echo "O erro foi:" >> /var/log/messages 2>&1
cat `cat db.rootcache.new errors` >> /var/log/messages 2>&1
exit 1
;;
esac
chown root:domador db.rootcache.new
rm -f db.rootcache.old errors
mv db.rootcache db.rootcache.old
mv db.rootcache.new db.rootcache
echo "Arquivo de servidores raiz do Bind (named) atualizado:" >> /var/log/messages 2>&1
cat db.rootcache >> /var/log/messages 2>&1
exit 0
Referências e fontes de pesquisa
- BIND 9 Manual no site oficial do BIND.
- ISC-TN-2002-2 - Internet Systems Consortium, Inc.
- Como fazer DNS de Nicolai Langfeldt, Jamie Norris e outros
- DNS Stuff, excelente para testar suas configurações.