DNS

De Biblioteca Unix

Conteúdo

DNS

Sobre

O DNS (Domain Name System - Sistema de Nomes de Domínios) é um sistema de gerenciamento de nomes hierárquico e distribuído operando segundo duas definições:

  • Examinar e atualizar seu banco de dados;
  • Resolver nomes de domínios em endereços de rede (IPs);
  • Manter uma infraestrutura de auxílio a: resolução reversa, textos públicos (TXT).

Existem diversos programas que cumprem esta função em servidores Unix Like, o mais famoso e conhecido é o BIND, também nomeado como NAMED em alguns sistemas. Vamos discutir a configuração e instalação do Bind em nossos sistemas preferidos.

Testes de Resolução de Nomes

A ferramenta dig é bem conhecida por possibilitar testes em DNSs, assim como a ferramenta nslookup, por questões de comodidade, vamos utilizar os exemplos com o dig. Os seguintes testes geralmente são feitos para saber se nosso serviço de DNS ou um servidor externo estão funcionando bem.

Verificando a Resolução de Nomes

Para checar a resolução de IP por exemplo, usando como servidor de DNS o ns.exemplo.com.br usamos o comando:

# dig @ns.exemplo.com.br bibliotecaunix.org

e o retorno deve ser conter algo como:

;; QUESTION SECTION:
;bibliotecaunix.org.            IN      A

;; ANSWER SECTION:
bibliotecaunix.org.     86400   IN      A       67.18.208.175

a pergunta realizada e a resposta, existem outros campos que trazem outras informações, mas com isso, temos os dados que nos interessam neste momento.

Verificando a Resolução Reversa de Nomes

É interessante sempre manter as informações reversas dos IPs para os servidores que os contém, isso é importante principalmente quando estamos montando um servidor de e-mail, em que uma das checagens é com relação ao reverso do servidor que cuida dos e-mails de um domínio. Veja como checar o reverso de um servidor de e-mail público conhecido:

# dig +short legacymail.ufms.br
200.129.192.67

com o IP em mãos:

# dig -x 200.129.192.67

e a resposta esperada:

;; QUESTION SECTION:
;67.192.129.200.in-addr.arpa.   IN      PTR

;; ANSWER SECTION:
67.192.129.200.in-addr.arpa. 86400 IN   PTR     legacymail.ufms.br.

veja que o IP aponta para o nome correto resolvido quando consultamos o nome, quer dizer que o IP e o seu reverso apontam para o local correto.

Verificando quem são os Servidores de E-mail de um Domínio

Muitas vezes desejamos saber qual o servidor de e-mail de determinado domínio, na verdade existem várias combinações que poderíamos usar com o dig, contendo os tipos que desejamos, como último exemplo, vamos ver quais os servidores de e-mail do Google:

# dig -t mx google.com

poderíamos substituir por qualquer domínio desejado e a reposta deve ser algo como:

;; QUESTION SECTION:
;google.com.                    IN      MX

;; ANSWER SECTION:
google.com.             900     IN      MX      400 google.com.s9b2.psmtp.com.
google.com.             900     IN      MX      100 google.com.s9a1.psmtp.com.
google.com.             900     IN      MX      200 google.com.s9a2.psmtp.com.
google.com.             900     IN      MX      300 google.com.s9b1.psmtp.com.

contendo valores com as prioridades dos servidores.

Ativando o DNS-BH para evitar acesso a sites conhecidos com Malware

Primeiro vamos criar um diretório para armazenar a lista de sites maliciosos:

# mkdir /etc/bind/blackhole

Agora vamos baixar as zonas dentro deste diretório:

# cd /etc/bind/blackhole
# wget http://www.malwaredomains.com/files/spywaredomains.zones

Este arquivo de zonas aponta o domínio para o arquivo blockeddomain.hosts, que é um arquivo que vamos ter que criar, mas temos um pequeno problema aqui, este arquivo de spyware é um arquivo preparado para o FreeBSD, por isso devemos modificar o diretório /etc/namedb/ para /etc/bind/, podemos usar o comando sed para isso:

# sed -i 's/\/nameddb/\/bind/g' spywaredomains.zones

Vai alterar corretamente o caminho. Agora vamos editar o arquivo de domínios bloqueados:

# vim /etc/bind/blockeddomain.hosts
; This zone will redirect all requests back to the blackhole itself.
$TTL    86400   ; one day
@       IN      SOA     dns.exemplo.com.br. dns.exemplo.com.br. (
                         1
                         28800   ; refresh  8 hours
                         7200    ; retry    2 hours
                         864000  ; expire  10 days
                         86400 ) ; min ttl  1 day
                 NS      dns.exemplo.com.br.
                 A       127.0.0.1
*               IN      A       127.0.0.1

poderia apontar para qualquer lugar, até por exemplo, para um servidor web que informasse do porque o usuário não conseguiu acessar determinado site.

Para que tudo funcione corretamente, você deve incluir a seguinte entrada no seu arquivo de configurações:

# vim /etc/bind/named.conf
...
include "/etc/bind/blackhole/spywaredomains.zones";
...

Reinicie o bind para ter certeza que está tudo funcionando:

# /etc/init.d/bind9 restart

Para automatizar o processo podemos criar um script que faça isso:

# vim /usr/local/bin/dnsbhupdate.sh
#!/bin/bash
cd /etc/bind/blackhole
wget http://www.malwaredomains.com/files/spywaredomains.zones
sed -i 's/\/nameddb/\/bind/g' spywaredomains.zones
/etc/init.d/bind9 restart

E colocar isso no cron:

# crontab -e
0    *       *       *       /usr/local/bin/dnsbhupdate.sh > /dev/null 2>&1

Poderíamos usar o IP de domínios do blockeddomain.hosts para um IP público, por exemplo: 200.129.192.35. E depois disso ativar o servidor WEB para entender as requisições, por exemplo, criar uma página com o seguinte conteúdo:

# vim /var/www/index.html
 <!DOCTYPE html>
 <html>
 <head>
 <title>Nome da Sua Organização - TI</title>
 <script type="text/javascript">url = parent.window.location.href;</script>
 </head>
 <body> 
 <h3>Notícia de Segurança</h3>      
 
 Você foi redirecionado para esta página pois tentou acessar um site que reconhecidamente
 distribui <i>spyware</i>, <i>virus</i> ou outros softwares considerados maliciosos.
 <br><br>
 
 Como parte da Política de Segurança da Informação nós mantemos uma lista de sites potencialmente prejudiciais para ajudar na proteção dos
nossos recursos computacionais. Isso também ajuda a proteger os usuários evitando a divulgação de informações pessoais para fins ilícitos como
Spam ou fraudes.
 <br><br>
 Se você precisa acessar este site como um requisito, entre em contato com o departamento de TI responsável.
 
 </body> 
 </html>
 

Agora toda vez que um usuário tentar se conectar em um site potencialmente perigoso, ele será redirecionado para o seu servidor WEB contendo a mensagem.


Debian Squeeze 6.0/Ubuntu Server 10.04 LTS

Instalando os Pacotes necessários

O bind9 no Debian e no Ubuntu tem uma característica interessante, assim como no FreeBSD, por padrão ele não vem enjaulado em chroot, é possível fazer isso, mas por enquanto, não vamos adicionar uma área para mostrar como fazer.

Primeiro vamos instalar os softwares necessários:

# apt-get install bind9

a versão no Debian é a 9.7.3 e no Ubuntu Server 10.04 é a 9.7, depois de instalado o pacote, será criado o usuário e grupo bind que vai gerenciar o serviço de dns e é gerado também, o arquivo /etc/bind/rndc.key

wrote key file "/etc/bind/rndc.key"

contendo a chave rndc. O serviço inicializado não contém qualquer domínio configurado.

Configurando como Servidor Master de: exemplo.com.br

Agora vamos configurar um domínio de exemplo com alguns serviços atrelados, eis a estrutura:

  • Servidor de DNS: ns.exemplo.com.br (200.129.200.3)
  • Servidor de WEB: www.exemplo.com.br (200.129.200.4)
  • Servidor de E-mail: mail.exemplo.com.br (200.129.200.5)

para este domínio nosso servidor será primário. Primeiro vamos dizer ao nosso bind que ele é master para esta zona, além de ativar as zonas da rfc1918. Edite o arquivo /etc/bind/named.conf.local:

include "/etc/bind/zones.rfc1918";

zone "exemplo.com.br" {
        type master;
        file "/etc/bind/db.exemplo";
};

apenas incluímos as redes privadas descritas na rfc1918 e dissemos para o bind que para a zona exemplo.com.br ele é do tipo master e o arquivo que contém suas regras é o db.exemplo. Vamos editar o arquivo e deixá-lo com o seguinte conteúdo:

$TTL    86400
@       IN      SOA     ns.exemplo.com.br. root.exemplo.com.br. (
                        2010061501      ; Serial: yyyy/mm/dd/nn [00..99]
                        10800           ; Refresh every 3 hours: 3h*60m*60s
                        900             ; Retry every 15 minutes: 15m*60s
                        604800          ; Expire after a week: 7d*24h*60m*60s
                        3600 )          ; Minimum ttl of 1 hour: 1h*60m*60s
        IN      NS      ns.exemplo.br.
        IN      MX      10      mail.exemplo.br. 

@               IN      A       200.129.200.3
www             IN      A       200.129.200.4
mail            IN      A       200.129.206.5

quando você for configurar este arquivo, este exemplo mostra como funciona a criação de um domínio simples, mas sugerimos ler a documentação do BIND para entender algumas entradas. Por exemplo:

  • NS: nameserver (servidor de nomes)
  • A: entrada do tipo A (resolução direta)
  • CNAME: alias para uma entrada do tipo A
  • MX: MaileXchange (servidor de e-mail)

vamos reiniciar o serviço para carregar nossas alterações:

# /etc/init.d/bind9 restart

quando o serviço reiniciar, nos logs do sistema (/var/log/syslog) vai aparecer uma linha semelhante a abaixo:

Jun 15 20:00:07 vware01 named[10525]: zone exemplo.com.br/IN: loaded serial 2010061501

que significa que seu domínio foi carregado. Mas note que cometemos um pequeno erro, o servidor de e-mail ficou com o IP errado, deveria ser 200.129.200.5 não 200.129.206.5, vamos reeditar nosso arquivo para corrigir o problema:

$TTL    86400
@       IN      SOA     ns.exemplo.com.br. root.exemplo.com.br. (
                        2010061502      ; Serial: yyyy/mm/dd/nn [00..99]
                        10800           ; Refresh every 3 hours: 3h*60m*60s
                        900             ; Retry every 15 minutes: 15m*60s
                        604800          ; Expire after a week: 7d*24h*60m*60s
                        3600 )          ; Minimum ttl of 1 hour: 1h*60m*60s
        IN      NS      ns.exemplo.br.
        IN      MX      10      mail.exemplo.br.  

@               IN      A       200.129.200.3
www             IN      A       200.129.200.4
mail            IN      A       200.129.200.5

este erro foi proposital e teve um objetivo, note que o Serial foi modificado, ou seja, toda vez que o arquivo do BIND for alterado, você deve alterar o serial para que os outros servidores entendam que ouve uma alteração nas configurações da sua zona.

Como exercício teste as consultas de DNS sugeridas no seu novo servidor e verifique se as resoluções estão acontecendo normalmente.

Configurando o Reverso do Domínio: exemplo.com.br

Para configurar o reverso de um domínio você deve ter em vista 2 coisas:

  1. A delegação do reverso foi realizada pelo seu ISP
  2. A faixa de IPs deve estar corretamente configurada

Para que o reverso funcione corretamente, vamos supor que a nossa rede pública seja:

  • 200.129.192.0/25

Ou seja, todos os IPs deste range devem ter seus reversos corretamente configurados. Vamos supor o seguinte:

  • email.exemplo.com.br tem o IP 200.129.192.130

Com isso, vai existir uma entrada do tipo A de email para o IP que escolhemos. Geralmente servidores de email precisam que o reverso esteja configurado corretamente, por isso vamos criar uma nova zona para o reverso:

# vim /etc/bind/named.conf.local
...
zone "192.129.200.in-addr.arpa" {
        type master;
        file "/etc/bind/db-reverso.exemplo";
};
...

note que a rede desejada aparece invertida e o nome in-addr.arpa foi adicionado ao final, isso é importante e necessário, pois este é o caminho utilizado pelos root servers para resolução reversa. Agora o conteúdo do arquivo db-reverso.exemplo:

$TTL    86400
@       IN      SOA     ns.exemplo.com.br. root.exemplo.com.br. (
                        2010061501      ; Serial: yyyy/mm/dd/nn [00..99]
                        10800           ; Refresh every 3 hours: 3h*60m*60s
                        900             ; Retry every 15 minutes: 15m*60s
                        604800          ; Expire after a week: 7d*24h*60m*60s
                        3600 )          ; Minimum ttl of 1 hour: 1h*60m*60s
        IN      NS      ns.exemplo.br.
        IN      MX      10      mail.exemplo.br. 

1       IN      PTR     reverso01.exemplo.com.br.
...
130     IN      PTR     email.exemplo.com.br.
...
254     IN      PTR     reverso254.exemplo.com.br.

É uma boa prática definir todos os valores dos reversos com nomes padronizados e só modificar aqueles que forem utilizados, como foi feito com o email.exemplo.com.br. Um erro muito comum é quando esquecemos o ponto no final do nome que será apontado, se você esquecer isso, ele irá completar com o domínio FQDN e o nome pode ser resolvido de forma bem estranha ao esperado.

Agora basta reiniciar o bind para que as configurações entrem em atividade.

Configurando como Servidor Slave de: exemplo.com.br

Agora vamos ativar um segundo servidor de DNS que vai servir como slave do servidor primário, ou seja, toda vez que uma informação for atualizada no master, o slave será notificado e atualizado.

Para isso primeiro precisamos alterar a nossa configuração anterior:

zone "exemplo.com.br" {
       type master;
       file "/etc/bind/db.exemplo";
};

e adicionar as informações de transferência e notificação:

zone "exemplo.com.br" {
       type master;
       file "/etc/bind/db.exemplo";
       allow-transfer { IP_DO_SLAVE; };
       allow-query { any; };
       also-notify { IP_DO_SLAVE; };
       notify yes;
};

Ou seja, quando o master for modificado e o servidor bind for reinicializado, ele notificará o IP_DO_DNS_SLAVE e se tiveram mudanças, o slave vai puxar estas mudanças.

A instalação do slave é a mesma do servidor master, a diferença é que para o mesmo domínio exemplo.com.br vamos ter a entrada definida como:

zone "exemplo.com.br" {
       type slave;
       file "/etc/bind/db.exemplo";
       masters { IP_DO_DNS_MASTER; }
       allow-query { any; };
       allow-notify { IP_DO_DNS_MASTER; };
};

A diferença aqui é que o tipo foi definido como slave, quem é o DNS master e de quem este servidor slave pode receber notificações. Pronto, reinicialize ambos os servidores de DNS:

# /etc/init.d/bind9 restart

Se você realizou alguma mudança no DNS master vai ver uma entrada parecida com esta nos logs:

May 23 08:24:47 ns named[9998]: transfer of 'exemplo.com.br/IN/public' from IP_DO_DNS_MASTER#53: connected using IP_DO_DNS_MASTER#60450
May 23 08:24:47 ns named[9998]: zone exemplo.com.br/IN/public: transferred serial 154
May 23 08:24:47 ns named[9998]: transfer of 'exemplo.com.br/IN/public' from IP_DO_DNS_SLAVE#53: Transfer completed: 1 messages, 78 records, 2460 bytes, 0.203 secs (12118 bytes/sec)

O que quer dizer que sua zona for corretamente transferida entre os servidores de DNS.

Configurando como Servidor Cache/Forward

Quando você quer criar um DNS local que vai funcionar apenas como forwarder, ou seja, ele somente vai encaminhar requisições de resolução (e não vai necessariamente ser DNS de nenhuma zona/domínio), a configuração é muito simples, basta instalar o bind/named e depois configurar na seção de options dentro do named.conf:

# vim /etc/bind/named.conf
options {
       ...
       forward only;
       forwarders { 208.67.222.222; 208.67.220.220; };
       ...
       };

As 2 configurações que interessam neste caso é a diretiva para encaminhar sempre (forward only) e os IPs dos DNS que receberam o encaminhamento destas requisições, no caso os 2 IPs acima são do OpenDNS.

Configurando Visões de Subredes

Podemos fazer com que as requisições sejam vistas na rede de forma diferenciada, por exemplo, podemos criar zonas públicas que serão utilizadas para publicação de fato na Internet e zonas privadas, que somente a sua rede local poderá utilizar. As configurações serão feitas no arquivo named.conf, primeiro vamos criar ACLs contendo as subredes (vamos fazer isso somente para facilitar a criação das visões):

# vim /etc/bind/named.conf
...
acl rede_privada {
       10.0.0.0/8;
       172.16.0.0/12;
       192.168.0.0/16;
};

acl rede_publica_dmz {
       200.129.192.0/24;
       200.129.193.0/24;
};
...

Ainda dentro do arquivo de configuração do named.conf, vamos agora criar as visões:

...
view "private" {
       match-clients { localhost; rede_privada; rede_publica_dmz; };
       allow-query { localhost; rede_privada; rede_publica_dmz; };
       allow-recursion { localhost; rede_privada; rede_publica_dmz; };
       recursion yes;

       zone "exemplo.com.br" {
               type master;
               file "/etc/bind/master/private.exemplo.com.br";
               allow-update { none; };
               allow-transfer { none; };
       };

       include "/etc/bind/exemplo.default.zones";
       include "/etc/bind/exemplo.master.zones";
       include "/etc/bind/exemplo.slave.zones";
       include "/etc/bind/exemplo.private.zones";
       include "/etc/bind/blackhole/spywaredomains.zones";
};

view "public" {
       match-clients { any; };
       recursion no;

       zone "exemplo.com.br" {
               type master;
               file "/etc/bind/master/public.exemplo.com.br";
               allow-update { none; };
               allow-transfer { slaves; };
       };

       include "/etc/bind/exemplo.default.zones";
       include "/etc/bind/exemplo.master.zones";
       include "/etc/bind/exemplo.slave.zones";
};
...

Temos 2 diferenças críticas aqui, a primeira é que as zonas privadas só foram adicionadas na visão privada e a segunda é que as zonas de spyware só foram adicionadas também na privada, pois não faria sentido resolver este tipo de zona na visão pública.


FreeBSD 8.0

Instalando os Pacotes necessários

Um dos sistemas mais simples de configurar o DNS é o FreeBSD, pois ele já faz parte dos programas default do sistema, então para ativá-lo, basta rodar o comando abaixo:

# /etc/rc.d/named rcvar >> /etc/rc.conf

editar o arquivo /etc/rc.conf mudando o named_enable=NO para:

named_enable="YES"

e depois inicializar o serviço:

# /etc/rc.d/named start

a primeira vez que ele executar vai gerar o arquivo rndc.key

wrote key file "/var/named/etc/namedb/rndc.key"

e já estará funcionando com as configurações padrões. Nenhum domínio foi configurado até o momento. Uma detalhe interessante é que no FreeBSD todos as configurações ficam alocadas em /etc/namedb e em uma estrutura bem polida.


CentOS/RedHat 5.6

Instalando os Pacotes necessários

O CentOS/RedHat 5.5 tem um diferencial aqui, por padrão ele já vem preparado e facilita o uso de um ambiente chroot para o BIND (neste sistema chamado de named). Vamos instalar o software necessário:

# yum install bind bind-chroot

a versão do Bind utilizada é a 9.3.6. Feito isso precisamos configurar nosso ambiente.

Configurando como Servidor Master de: exemplo.com.br

Vamos configurar o serviço para atender ao seguinte ambiente:

  • Servidor de DNS: ns.exemplo.com.br (200.129.200.3)
  • Servidor de WEB: www.exemplo.com.br (200.129.200.4)
  • Servidor de E-mail: mail.exemplo.com.br (200.129.200.5)

primeiro precisamos criar nosso arquivo de configuração de zonas, vamos copiar o exemplo que vem no pacote do BIND:

# cp /usr/share/doc/bind-9.3.6/sample/etc/named.conf /var/named/chroot/etc/

diferente dos outros pacotes, este exemplo já vem preparado para trabalhar com visões, onde a visão internal se refere a como as máquinas na sua rede privada (LAN) enxergam as resoluções de nome e a visão external que são para os clientes fora da sua rede. É claro que é possível fazer as mesmas configurações em outros sistemas e vocês verão como, mas a priori o fato de já estar pronto para uso facilita um pouco.

Primeiro vamos copiar as outras entradas necessárias:

# cp /usr/share/doc/bind-9.3.6/sample/etc/named.root.hints /var/named/chroot/etc/
# cp /usr/share/doc/bind-9.3.6/sample/etc/named.rfc1912.zones /var/named/chroot/etc/

e os arquivos de configurações adicionais

# cp -r /usr/share/doc/bind-9.3.6/sample/var/named/* /var/named/chroot/var/named/

apenas para testar se tudo está ok, execute o comando abaixo e verifique que nenhum erro retornou:

# service named configtest

se tudo retornou certo, vamos configurar nosso ambiente. Vamos editar o arquivo

/var/named/chroot/var/named/exemplo.zone:

$TTL    86400
@       IN      SOA     ns.exemplo.br. root.exemplo.com.br. (
                        2010061502      ; Serial: yyyy/mm/dd/nn [00..99]
                        10800           ; Refresh every 3 hours: 3h*60m*60s
                        900             ; Retry every 15 minutes: 15m*60s
                        604800          ; Expire after a week: 7d*24h*60m*60s
                        3600 )          ; Minimum ttl of 1 hour: 1h*60m*60s
        IN      NS      ns.exemplo.br.
        IN      MX      10      mail.exemplo.br. 

@               IN      A       200.129.200.3
www             IN      A       200.129.200.4
mail            IN      A       200.129.200.5

um detalhe muito importante é que como estamos trabalhando em um ambiente enjaulado, antes de realmente colocar em produção seu sistema, altere o dono e grupo dos arquivos:

# chown -R root:named /var/named/chroot

como nossa zona contém IPs públicos, vamos editar dentro da visão external no arquivo /var/named/chroot/etc/named.conf:

zone "exemplo.com.br" {
        type master;
        file "exemplo.zone.db";
};

execute novamente o configtest:

# service named configtest

e veja que agora está carregando a nossa nova zona:

zone exemplo.com.br/IN: loaded serial 2010061501

não esquecendo que toda vez que modificar o arquivo de configurações da zona é preciso atualizar o Serial. Vamos reiniciar o serviço:

# service named restart

note que ele vai falhar, e o erro no log será:

/etc/named.conf:99: configuring key 'ddns_key': bad base64 encoding

isso aconteceu, porque precisamos criar a chave secreta com o comando dns-keygen:

# dns-keygen
Lmo2itzWnMMga3umirGHfbgbAW43M2SJYI1o0BoUiIyjPVmQuGorYiamgPGK

e copiamos essa chave gerada na entrada secret do ddns_key, no named.conf. Agora podermos reinicializar o serviço sem problemas:

# service named restart

Sugerimos como exercício testar a resolução de nomes, lembrando que como foi apenas configurada a visão externa, somente máquinas remotas conseguiram testar a resolução de nomes, o que por padrão é bloqueado, então não esqueça de liberar a porta 53 UDP para acesso externo.


CentOS 6.0/RHEL 6.0

Pacotes Necessários

Para instalar o serviço de DNS no CentOS 6 é necessário instalar o pacote do BIND, e mais alguns pacotes importantes, vamos lá:

# yum install bind bind-chroot

Instalamos o chroot para enjaular o bind para evitar que se um invasor conseguir quebrar o bind de alguma forma, ele vai ficar isolado somente ao ambiente do serviço.

Configurações Básicas

Configurar o BIND no CentOS 6 ficou muito mais fácil que nas versões anteriores, pois agora está tudo unido em um pequeno número de pacotes. Ao instalar ele vai colocar todas as configurações em /var/named . Ele já vem com um arquivo de exemplo utilizando duas visões: interna e externa, e com suporte ao DNSSEC. Nossa configuração vai ativar o DNS tanto para IPv4, quanto para IPv6. Primeiro vamos copiar o arquivo de configuração do exemplo para o diretório correto:

# cp /usr/share/doc/bind-9.7.0/sample/etc/named.* /var/named/chroot/etc
# cp -r /usr/share/doc/bind-9.7.0/sample/var/named/* /var/named/chroot/var/named/

com isso vamos ter os arquivos básicos de DNS dentro do ambiente enjaulado. O próximo passo é configurar o named.conf:

# vim /var/named/chroot/etc/named/named.conf
options
{
       dump-file               "data/cache_dump.db";
       statistics-file         "data/named_stats.txt";
       memstatistics-file      "data/named_mem_stats.txt";

       listen-on port 53       { any; };
       listen-on-v6 port 53    { any; };

       allow-query             { localhost; 10.0.1.0/24; };
       allow-query-cache       { localhost; 10.0.1.0/24; };
       recursion yes;
       dnssec-enable yes;
       dnssec-validation yes;
       dnssec-lookaside auto;
};

logging
{
       channel default_debug {
               file "data/named.run";
               severity dynamic;
       };
};

view "localhost_resolver"
{

       match-clients           { localhost; };
       recursion yes;
       zone "." IN {
               type hint;
               file "/var/named/named.ca";

       include "/etc/named.rfc1912.zones";
};

view "internal"
{
       match-clients           { localnets; };
       recursion yes;
       zone "." IN {
               type hint;
               file "/var/named/named.ca";
       };

       include "/etc/named.rfc1912.zones";

       zone "my.internal.zone" {
               type master;
               file "my.internal.zone.db";
       };
       zone "my.slave.internal.zone" {
               type slave;
               file "slaves/my.slave.internal.zone.db";
               masters { /* put master nameserver IPs here */ 127.0.0.1; } ;
       };
       zone "my.ddns.internal.zone" {
               type master;
               allow-update { key ddns_key; };
               file "dynamic/my.ddns.internal.zone.db";
       };
};

key ddns_key
{
       algorithm hmac-md5;
       secret "use /usr/sbin/dnssec-keygen to generate TSIG keys";
};

view "external"
{
       match-clients           { any; };
       zone "." IN {
               type hint;
               file "/var/named/named.ca";
       };
       recursion no;
       zone "my.external.zone" {
               type master;
               file "my.external.zone.db";
       };
};

feito isso, basta inicializar o serviço que vai funcionar corretamente:

# service named start
Iniciando o named:                                         [  OK  ]

Se você quiser adicionar alguma zona, basta criar a zona e inseri-lá na visão correta, se a zona for interna (somente sua rede interna pode enxergar), você deve incluí-la na visão internal, se for externa na external, não esquecendo que agora com o IPv6 ativo, você deve ter entradas do tipo AAAA. Não esqueça de mudar o padrão para ler as configurações do chroot, pois por padrão ele vai ler o arquivo /etc/named.conf e não vai carregar nossas novas configurações.


--Brivaldo 22h08min de 5 de agosto de 2011 (AMT)

Ferramentas pessoais