GNU/Linux
 
 
DNS Server
(Domain Name System Server)

DNS Server é um servidor que transforma/traduz/resolve nome de host (ex: www.google.com.br) para um endereço IP (ex: 209.85.193.147). Quando é digitado em um browser o endereço "www.google.com.br", primeiramente é consultado um servidor DNS para saber qual é o IP da máquina "www.google.com.br". Só depois disso que o site do GOOGLE é acessado. A utilização de um servidor DNS é justificado, pois é muito mais fácil decorar/memorizar um nome (ex: www.google.com.br) do que um número (ex: 209.85.193.147). O DNS trabalha com a porta UDP 53 para consultas de resolução/tradução de nomes e TCP 53 para a troca de zonas (entre o DNS Primário e Secundário). Para um melhor entendimento clique aqui para visualizar a estrutura de rede que este artigo está baseado. A seguir tem-se uma lista com a significado de alguns termos bastante usados:




DNS Primário

Instalação DNS Primário
# apt-get update ; apt-get install bind9(no final da instalação será criado um diretório "/etc/bind/" com vários arquivos. A seguir se terá a descrição de cada um deles)

Obs1: ao instalar o BIND9, os serviços de DNS (resolução de nomes) já estarão prontos para serem usados, sendo que ele responderá por qualquer requisição de qualquer domínio. Contudo, isso só é válido para as requisições proviniente da mesma rede do servidor DNS ou dele mesmo (127.0.0.1). De outras redes será negada a recursão. Na verdade, o que a recursão faz é encaminhar as requisições DNS que chegam nele e repassar para outros servidores DNS conhecidos como "DNS ROOTs". A receber as respostas desses DNS ROOTs, este servidor DNS repassará para o cliente (requisitante) essas informações. Em outras palavras, ele ficará como intermediário entre o cliente e os DNS ROOT. Além disso, este DNS já comeca a fazer CACHE das requisições dos clientes, ou seja, se já tiver havido uma pergunta de resolução de nome (ex: google.com.br), na segunda vez que for feita a mesma pergunta (seja do mesmo cliente ou de outro cliente), este servidor DNS não perguntará mais aos DNS ROOT, e sim, ele mesmo responderá a essa requisição.

Obs2: já requisições sobre domínios configurados no próprio servidor será permitido de qualquer rede.


db.0(arquivo que faz a resolução reversa da zona de broadcast. Segundo o manual do Bind9: BIND reverse data file for broadcast zone. Não modifique este arquivo)
db.127(arquivo que faz a resolução reversa da zona local - da rede 127.0.0.0, ou seja, do endereço da interface de loopback local. Segundo o manual do Bind9: BIND reverse data file for local loopback interface. Não modifique este arquivo)
db.255(arquivo que faz a resolução reversa da zona de broadcast. Segundo o manual do Bind9: BIND reverse data file for broadcast zone. Não modifique este arquivo)
db.empty(não modifique este arquivo, ele servirá como exemplo para novos arquivos de zona. Então, quando for criar novas zonas, basta copiá-lo. Segundo o manual do Bind9: it is used for multiple zones)
db.local(arquivo que faz a resolução direta da zona local - domínio localhost, ou seja, do endereço da interface de loopback local. Segundo o manual do Bind9: BIND data file for local loopback interface. Não modifique este arquivo)
db.root(contém os endereços IP e os nomes de host dos servidores "root ou raiz" na hierarquia de DNS mundial. Não modifique este arquivo, pois os endereços IP e nomes dos DNS, que estão no topo da hierárquia mundial, geralmente não mudam. Esses IPs e seus respectivos servidores são mantidos por entidades como InterNIC, DoD, NASA etc)
named.conf(arquivo principal de configuração do BIND. Não modifique este arquivo. Ele contém todas zonas diretas e reversas padrão como localhost, broadcast, root e seus respectivos arquivos de configuração. Também, contém duas linhas que iniciam com "include". Essas linhas incluem dois arquivos externos na configuração: "/etc/bind/named.conf.options" e "/etc/bind/named.conf.local")
named.conf.local(a princípio está vazio, mas deve conter as zonas diretas e reversas que serão criadas com seus respectivos arquivos de configuração. Também é neste arquivo que se faz os "forwarders de zona", ou seja, quando uma consulta de uma determinada zona é repassada para outro DNS responder. Mais à frente será mostrado como configurá-lo)
named.conf.options(contém o local onde será armazenado o cache "/var/cache/bind". Pode-se acrescentar mais uma porta UDP que o Bind vai trabalhar. Neste arquivo, também, se pode definir qual IP pode realizar a transferência de zona (allow-transfer). Também é neste arquivo que se configura os "forwarders de DNS", ou seja, o repasse de consultas DNS para outro servidor DNS com exceção das zonas definas em "/etc/bind/". Tambem [e aqui que se devine em qual interface de rede (listen-on) o BIND ira trabalhar e ira fazer recursao (allow-recursion), ou seja, ira se preocupar com outros dominios da Internet. Mais à frente será mostrado como configurá-lo. Forwarders não faz cache.)
rndc.key(não modifique este arquivo. Ele é usado para autenticar comandos enviados entre os servidores DNS (troca de zona). Por padrão, usa o algoritmo HMAC-MD5 com chave secreta compartilhada entre os hosts finais da conexão TCP. Para isto, utiliza-se do comando "rndc". O comando "rndc-confgen" é uma ferramenta para gerar a chave rndc. Para maiores informações "man rndc-confgen", "man rndc" e "man rndc.conf")
zones.rfc1918(zonas configuradas de acordo com a RFC 1918. Não modifique este arquivo)

Em resumo os únicos dois arquivos que deverão ser modificados serão "named.conf.local" e "named.conf.options" ;-)


Instalação e Configuração do VIM para melhorar a visualização dos arquivos
# apt-get install vim
# vi /etc/vim/vimrc
syntax on (procure e descomente esse linha)
# vi /usr/share/vim/vimcurrent/filetype.vim
au BufNewFile,BufRead named.conf,rndc.conf setf named (procure esse linha e a modifique deixando assim "au BufNewFile,BufRead named.*,rndc.* setf named")
Obs: os procedimentos acima é para colorizar os arquivos de configuração do BIND.


Agora, vamos por a mão na massa. O domínio que será configurado, neste artigo, será "matrix.com.br" e o endereço de rede será "192.168.1.0/255.255.255.0". Os IPs do DNS Primário e Secundário serão "192.168.1.1" e "192.168.1.2", respectivamente.


Primeiramente entre no arquivo "named.conf.local" (comentários neste arquivo devem conter no inicio da linha "//")
# vi /etc/bind/named.conf.local(arquivo de configuração onde é colocado o domínio direto, reverso e seus respectivos arquivos de consulta. Digite as linhas seguir)


zone "matrix.com.br" {(nome da zona direta ou domínio da rede)
type master;(indica o tipo do DNS. Master significa que é um DNS Primário )
file "/etc/bind/db.matrix.com.br";(arquivo que contém as informações DNS da zona direta "matrix.com.br")
};(fechamento da configuração da zona direta)

zone "1.168.192.in-addr.arpa" {(nome da zona reversa da rede)
type master;(indica o tipo do DNS. Master significa que é um DNS Primário )
file "/etc/bind/db.192.168.1";(arquivo que contém as informações DNS da zona reversa "1.168.192.in-addr.arpa")
};(fechamento da configuração da zona reversa)

Obs0: vale ressaltar que para cada zona, uma entrada "zone" é necessária no arquivo de configuração acima.

Obs1: o procedimento para a escolha do domínio, deve está de acordo com a empresa. Neste artigo o domínio foi "matrix.com.br", pois a empresa fictícia se chama "Matrix", é comercial (com) e é brasileira (br).

Obs2: Já a escolha do nome da zona reversa como "1.168.192.in-addr.arpa" foi devido ao endereço de rede ser "192.168.1.0/24" deixando somente a parte de rede fica "192.168.1", colocando ele ao inverso fica "1.168.192" e acrescentando "in-addr.arpa" que representa o domínio reverso fica "1.168.192.in-addr.arpa". Mas isso foi somente para padronizar. Poderia ter sido escolhido outro nome como "168.192.in-addr.arpa" ou "192.in-addr.arpa", a diferença seria na hora de configurar o conteúdo do arquivo "db.192.168.1" que será visto mais a frente. Não é possível fazer range de zonas reversas como por exemplo "1-30.1.168.192.in-addr.arpa", pois 1-30 seria complementado pelo número colocado no arquivo "db.192.168.1" no PTR, não sendo assim um endereço IP válido.

Obs3: na linha inicia por "file" é colocado o caminho completo do arquivo que gerencia uma zona (ex: file "/etc/bind/db.matrix.com.br";). Contudo, alguns administradores colocam somente o nome do arquivo (ex: file "db.matrix.com.br";). Isso não é errado. Contudo, para esse último caso é utilizada a opção "directory" dentro do arquivo de configuração "named.conf.options" para saber em qual diretório o arquivo de zona ficará armazenado.



Criando e configurando o arquivo que conterá as informações da zona "matrix.com.br" para a resolução direta de endereços:

# vi /etc/bind/db.matrix.com.br(a seguir o conteúdo. Comentários neste arquivo devem conter no inicio da linha ";")


;--> (ponto e vírgula significa comentário)

$TTL 1D (TTL significa Time To Live, ou seja, é o tempo máximo em segundos que as informações de consultas DNS ficarão em cache nos clientes. Clientes podem ser estações, servidores e/ou outros DNS Servers. Quando é feita uma consulta DNS por uma estação MS-Windows se pode usar o comando "ipconfig /displaydns" para ver o cache e tempo que ficará em memória. O "$TTL 1D" significa que o tempo do cache será de 1D = 1 dia. Se o valor for 0, não fará cache. Toda diretiva que começa com "$" como o "$TTL" são padronizadas por uma RFC. Veja a RFC 1912. Outros exemplos "$ORIGIN" e "$INCLUDE")

Obs: Os clientes DNS MS-Windows fazem cache de DNS por padrão. Para ver o cache basta digitar o comando "ipconfig /displaydns" e para apagar esse cache use "ipconfig /flushdns". Já em clientes DNS GNU/Linux por padrão não fazem cache. Contudo, existe um pacote que pode provê essa funcionalidade que é "nscd". Ao instalar é necessário habilitar a função específica de cache de nomes que é "enable-cache hosts yes" em "/etc/nscd.conf". Cuidado ao usar esse pacote "nscd", pois ele faz cache também de passwd, group e services (o cache fica em /var/cache/nscd/).

@(significa este domínio, ou seja, "matrix.com.br". Quando é realizada uma consulta DNS, por exemplo, para o domínio "matrix.com.br", o arquivo "/etc/bind/named.conf.local" será consultado e lá será encontrada a linha zone "matrix.com.br" a qual especifica o arquivo "/etc/bind/db.matrix.com.br" que responde por tal domínio. A partir disso, é sabido que "@" é igual à "matrix.com.br")

IN(The INternet Data Class. Pode ser traduzido como "entrada", sempre que for entrar com um nome de host ou endereço IP se deve colocar o parâmetro "IN" antes)

SOA(Start Of Authority. Esta linha diz para o mundo que este DNS é reconhecido como o autoritativo para consultas sobre este domínio --> @ --> "matrix.com.br". É interessante registrar que é a partir dele que se sabe quem é o DNS primário e o seu administrador. Veja a próxima linha)

@ IN SOA ns1.matrix.com.br. root.matrix.com.br. ((a tradução desta linha pode ser a seguinte: este domínio "@" é regido pelo DNS primário "ns1.matrix.com.br" cujo e-mail do administrador é "root.matrix.com.br". No e-mail do administrador é usado o sinal de ponto final em vez do "@", para não confudir com domínio. Depois desta linha, mais especificamente o que está entre parênteses, se têm os dados de sincronismo)

Obs: nas configurações acima, pôde ser observado que no final do nome do DNS primário (ns1.matrix.com.br.) e do e-mail do administrador (root.matrix.com.br.) tem um sinal de ponto final. Isso também pode ser observado em outras linhas na figura acima. Esse sinal de ponto final é necessário, pois o DNS sempre completará com o domínio as entradas que não tiverem esse sinal. Caso não tivêssemos colocado o ponto final no nome do DNS primário, ele seria acrescido do domínio ficando dessa maneira: "ns1.matrix.com.br.matrix.com.br" . Então, nunca se esqueça do ponto final ;-)

;Serial(este número diz ao DNS Secudário se houve alteração no arquivo. Se este número for diferente quando o DNS Secundário o consultar, ele irá atualizar as informações. Toda vez que alterar este arquivo, se deve modificar manualmente o "Serial". Com isso, o DNS Secundário saberá que houve alteração e que deverá sincronizar as informações. Se pode adotar a data "20080515" mais um número serial "01" para este campo ficando "2008051501". Assim, sempre se saberá a data da última modificação e caso haja alterações no mesmo dia, basta modificar "01" para "02".)

2H ;Refresh(espaço de tempo que o DNS Secundário atualizará as informações de zonas com o Primário. Esta atualização só acorrerá quando o ";Serial" do DNS Primário for diferente. 2H é igual à 2 horas)

Obs: M=Minute=Minuto, H=Hour=Hora, D=Day=Dia, W=Week=Semana. Quando não for colada uma letra, o tempo é em segundos.

20M ;Retry(ao tentar atualizar as informações de zonas de acordo com o parametro "Refresh" e não conseguir, o DNS Secundário tentará novamente um tempo depois definido nesse parâmetro ";Retry". 20M é igual à 20 minutos)

1W ;Expire(caso o DNS Secundário consulte novamente o Primário no tempo definido em ";Retry" e ocorra novamente uma falha, o DNS Secundário assumirá as funções do Primário durante o tempo definido em ";Expire". 1W é igual a 1 semana. Depois desse tempo o DNS secundário pára de funcionar e o administrador terá que resolver o problema)

1D ) ;Negative Cache TTL or minimum(é o tempo máximo em segundos que as informações de consultas DNS que resultarem em "NXDomain" ficarão em cache nos clientes. Isso é válido a partir do BIND9, versões anteriores tinha outra função. "NXDomain" -> Non eXist Domain -> acontece quando um cliente pergunta a um DNS Server sobre um hostname que não existe (exemplo xxxxxxx.google.com.br não existe e o DNS Server retornará um "NXDomain"). Clientes podem ser estações, servidores e/ou outros DNS Servers.. Neste caso, o tempo será de 1D = 1 dia. Geralmente os administradordes colocam o mesmo valor para o "minimum" e para o "TTL")

NS(Name Server, ou seja, Servidor de Nomes. Toda entrada "IN" que for seguida por "NS" estará especificando o nome de um DNS)

@ IN NS ns1.matrix.com.br.(a tradução desta linha pode ser a seguinte: este domínio "@" tem um DNS "IN NS" chamado "ns1.matrix.com.br". No final do nome de DNS tem um sinal de ponto final. Para entender o porquê, leia a observerção "Obs" acima em vermelho )

@ IN NS ns2.matrix.com.br.(a tradução desta linha pode ser a seguinte: este domínio "@" tem um outro DNS "IN NS" chamado "ns2.matrix.com.br". No final do nome de DNS tem um sinal de ponto final. Para entender o porquê, leia a observerção "Obs" acima em vermelho )

Dica: para sabe qual dos dois DNS acima é o Primário, basta olhar a linha que tem a entrada "IN SOA".

MX (Mail eXchange, ou seja, Servidor de e-mail SMTP. Toda entrada "IN" que for seguida por "MX" estará especificando o nome de um Servidor de e-mail SMTP)

@ IN MX 1 mail1.matrix.com.br.(a tradução desta linha pode ser a seguinte: este domínio "@" tem um Servidor de e-mail SMTP "IN MX" chamado "mail1.matrix.com.br". O número "1" significa prioridade de utilização em relação a outros Servidores SMTP. Quanto menor for esse número, mais prioritário ele será. No final do nome do "MX" tem um sinal de ponto final. Para entender o porquê, leia a observerção "Obs" acima em vermelho)

@ IN MX 5 mail2.matrix.com.br.(a tradução desta linha pode ser a seguinte: este domínio "@" tem um Servidor de e-mail SMTP "IN MX" chamado "mail2.matrix.com.br". O número "5" significa prioridade de utilização em relação a outros Servidores SMTP. Quanto menor for esse número, mais prioritário ele será. No final do nome do "MX" tem um sinal de ponto final. Para entender o porquê, leia a observerção "Obs" acima em vermelho)

Obs: a prioridade que é colocada no registro "MX" é usada pelos MTA (agentes SMTP - ex: postfix) para selecionar o mais prioritário (com menor valor). Se o MTA (servidor de e-mail) estiver fora, o próximo com o menor será selecionado.

A(Address, ou seja, Endereço. Toda entrada "IN" que for seguida de "A" estará especificando o endereço IP de um servidor)

ns1 IN A 192.168.1.1(a tradução desta linha pode ser a seguinte: o equipamento que tem o nome "ns1" tem o endereço IP "192.168.1.1")

Obs1: todo nome, por exemplo, "ns1" que tem a entrada "IN A" e que não tem no seu final um sinal de ponto final, será completado pelo domínio desta zona. Assim, o DNS enxerga "ns1" como "ns1.matrix.com.br" . Então, isso significa dizer que "ns1" (sem ponto final) e "ns1.matrix.com.br." (com ponto final) é a mesma coisa.

Obs2: no arquivo de configuração acima, se poderia substinuir o "ns1" por "ns1.matrix.com.br."

ns2 IN A 192.168.1.2(a tradução desta linha pode ser a seguinte: o equipamento que tem o nome "ns2" tem o endereço IP "192.168.1.2")

www IN A 192.168.1.3(a tradução desta linha pode ser a seguinte: o equipamento que tem o nome "www" tem o endereço IP "192.168.1.3")

ftp IN A 192.168.1.4(a tradução desta linha pode ser a seguinte: o equipamento que tem o nome "ftp" tem o endereço IP "192.168.1.4")

mail1 IN A 192.168.1.11(a tradução desta linha pode ser a seguinte: o equipamento que tem o nome "mail1" tem o endereço IP "192.168.1.11")

mail2 IN A 192.168.1.12(a tradução desta linha pode ser a seguinte: o equipamento que tem o nome "mail2" tem o endereço IP "192.168.1.12")

web IN CNAME www(Canonical NAME pode ser entendido como um apelido que neste caso, "web" é o apelido de "www" que tem o IP "192.168.1.3". Em outras palavras, "web" e "www" são a mesma coisa, ao se realizar consultas DNS. Não se usa CNAME em zona reversa. Em vez do "CNAME", se pode usar várias entradas "IN A")


EXTRA - IP para o Domínio

@ IN A 192.168.1.254 (a tradução desta linha pode ser a seguinte: este dominio (@ = matrix.com.br) tem o endereço IP "192.168.1.11". Isso [e uma pratica comum, principalmente para servidores web o qual se pode acessar atraves de "http://www.matrix.com.br" e tambem "http://matrix.com.br" que caira na mesma pagina)


EXTRA - SPF

@ IN TXT "v=spf1 ip4:172.25.0.4/32 ip4:172.25.0.5/32 -all" (SPF - Sender Policy Framework. Informa quem pode enviar mensagens SMTP)
@ IN SPF "v=spf1 ip4:172.25.0.4/32 ip4:172.25.0.5/32 -all" (idem, só que não muito utilizado, tendo preferência o "TXT")


EXTRA - SRV

_http._tcp.matrix.com.br. 86400 IN SRV 0 5 80 www.matrix.com.br. (SRV - SeRVice é um registro especial que indica os serviços oferecidos por um determinado domínio. Segue o padrão "_service._protocol.domain. ttl IN SRV priority weight port target.". Exemplo de como se deve fazer uma pergunta à um domínio sobre o serviço HTTP "host -t SRV _http._tcp.matrix.com.br")


EXTRA - Hostname Oculto

sip.matrix.com.br. IN A 192.168.1.5 (a tradução desta linha pode ser a seguinte: o equipamento que tem o nome "sip.matrix.com.br." tem o endereço IP "192.168.1.5")
                   IN A 192.168.1.6 (quando não se especifica o hostname, é utilizado o hostname da linha anterior que nesse caso é o "sip". Esta linha é equivalente à "sip IN A 192.168.1.6")


EXTRA - IP Oculto

5 PTR smtp.matrinux.com.br. (a tradução desta linha pode ser a seguinte: o equipamento que tem o IP de final "5" tem o nome IP "smtp.matrinux.com.br")
  PTR imap.matrinux.com.br. (quando não se especifica o IP, é utilizado o IP da linha anterior que nesse caso é o de final "5". Esta linha é equivalente à "5 PTR imap.matrinux.com.br")


EXTRA - Forward de Subzona/Subdomínio

pabx IN NS ns3.matrix.com.br. (forward de subzona/subdomínio. Ver)
ns3.matrix.com.br. IN A 192.168.1.7





Criando e configurando o arquivo que conterá as informações da zona "1.168.192.in-addr.arpa" para a resolução reversa de endereços:
# vi /etc/bind/db.192.168.1(a seguir o conteúdo. Comentários neste arquivo devem conter no inicio da linha ";")

@(significa este domínio, ou seja, "1.168.192.in-addr.arpa". Quando é realizada uma consulta DNS (para saber o IP de um determinado nome), neste caso, o arquivo "/etc/bind/named.conf.local" será verificado e lá será encontrado o arquivo "/etc/bind/db.db.192.168.1" que responde por tal domínio reverso. A partir disso, é sabido que "@" é igual à "1.168.192.in-addr.arpa")
PTR(Point To Reverse. Toda entrada "IN" que for seguida por "PTR" estará especificando o nome de um Servidor)
1 IN PTR ns1(o número "1" representa "192.168.1.1", pois do mesmo jeito que na zona direta, o número "1" é completado pelo domínio reverso "1.168.192.in-addr.arpa", ficando desta maneira: "1.1.168.192.in-addr.arpa". Então, se tirássemos o dominio reverso ".in-addr.arpa" e invertêssemos "1.1.168.192", o resultado seria "192.168.1.1" que é o IP do ns1. A tradução da linha "1 IN PTR ns1" pode ser a seguinte: o equipamento que tem o endereço IP "192.168.1.1" tem o nome de host "ns1")
Obs1: todo nome, por exemplo, "ns1" que tem a entrada "IN PTR" e que não tem no seu final um sinal de ponto final, será completado pelo domínio desta zona. Assim, o DNS enxerga "ns1" como "ns1.1.168.192.in-addr.arpa." . Então, isso significa dizer que "ns1" (sem ponto final) e "ns1.1.168.192.in-addr.arpa." (com ponto final) é a mesma coisa.
Obs2: no arquivo de configuração acima, se poderia substinuir o "1" por "1.1.168.192.in-addr.arpa." e "ns1" por "ns1.1.168.192.in-addr.arpa."
2 IN PTR ns2(o número "2" representa "192.168.1.2", pois do mesmo jeito que na zona direta, o número "2" é completado pelo domínio reverso "1.168.192.in-addr.arpa", ficando desta maneira: "2.1.168.192.in-addr.arpa". Então, se tirássemos o dominio reverso ".in-addr.arpa" e invertêssemos "2.1.168.192", o resultado seria "192.168.1.2" que é o IP do ns2. A tradução da linha "2 IN PTR ns2" pode ser a seguinte: o equipamento que tem o endereço IP "192.168.1.2" tem o nome de host "ns2")
3 IN PTR www(A tradução desta linha pode ser a seguinte: o equipamento que tem o endereço IP "192.168.1.3" tem o nome de host "www")
4 IN PTR ftp(A tradução desta linha pode ser a seguinte: o equipamento que tem o endereço IP "192.168.1.4" tem o nome de host "ftp")
11 IN PTR mail1(A tradução desta linha pode ser a seguinte: o equipamento que tem o endereço IP "192.168.1.11" tem o nome de host "mail1")
12 IN PTR mail2(A tradução desta linha pode ser a seguinte: o equipamento que tem o endereço IP "192.168.1.12" tem o nome de host "mail2")
EXTRA
1 IN PTR matrix.com.br. (a tradução desta linha pode ser a seguinte: este dominio (@ = matrix.com.br) tem o endereço IP "192.168.1.11". Isso [e uma pratica comum, principalmente para servidores web o qual se pode acessar atraves de "http://www.matrix.com.br" e tambem "http://matrix.com.br" que caira na mesma pagina)
Obs3: no arquivo da zona reversa não é interessante colocar o MX, apesar de funcionar, apresenta erros ao usar o comando "named-checkzone".

Torne o DNS cliente dele mesmo
# vi /etc/resolv.conf
search matrix.com.br(especifica o domínio)
nameserver 127.0.0.1(especifica o IP local)
Salve e Saia

Verifique se o arquivo de configuração de interfaces de rede tem alguma entrada para DNS. Se tiver comente ou apague:
# vi /etc/network/interfaces
dns-nameservers(linha que define o DNS. Comente-a ou apague-a)

Faça os procedimentos a seguir para especificar qual o IP do DNS Secundário
vi /etc/bind/named.conf.options(adicione a linha "allow-transfer" conforme a figura a seguir)

O IP "192.168.1.2" é do DNS Secundário. Se não especificado, qualquer host pode solicitar a transferência de zona (falha de segurança). Caso não tenha um DNS Secundário, troque o "192.168.1.2" por "none". A transferência de zona utiliza o protocolo TCP. Quando se muda/atualiza um zona no DNS Primário, se deve mudar o "serial" desta zona e depois fazer um "rndc reload". Ao fazer isso, o DNS Primário notifica (NOTIFY), via UDP-53, o DNS Secundário informando que uma determinada zona foi mudada/atualizada e que o número "serial" também mudou. Só a partir daí que o DNS Secundário inicia a transferência de zona via TCP-53.

Salve e Saia do arquivo. Mais a frente será mostrado como configurar um servidor DNS Secundário.

Obs0: também se pode colocar a opção "allow-transfer" dentro de cada zonas configurada em "/etc/bind/named.conf.local". Com isso, se podería deixar mais específicas as transferências de zonas para servidores DNS secundários diferentes. Melhora a segurança.

Reinicie o serviço DNS
# /etc/init.d/bind9 restart(poderia ser também "rndc reload")

Dica: os registros (IP e nome de host) que devem constar no DNS (dentro de "/etc/bind/db.matrix.com.br" e "/etc/bind/db.192.168.1") vão depender da finalidade do DNS. No DNS que fica numa DMZ, se deve colocar somente os IPs e os nomes dos servidores que ficam na DMZ como: DNS Primário, DNS Secundário, servidor HTTP, servidor FTP, servidor de E-mail etc. Nunca coloque informações da rede interna, nome dos filtros de pacotes/estados e roteadores. Vale expor que os equipamentos da LAN terão como servidor DNS, o DNS Primário que fica na DMZ.

Importante: quando houver necessidade de colocar registros da rede interna (LAN) dentro do DNS, se deve instalar um DNS específico para isso dentro da LAN. Também, não se deve inserir todos os nomes de todas as máquinas da LAN neste DNS, somente os que houverem necessidade (ex: máquina com uma impressora compartilhada, uma máquina que compartilha arquivos etc). Vale lembrar que, neste caso, os equipamentos da LAN terão como servidor DNS, o DNS que fica na LAN.

EXTRA - IMPORTANTE
# vi /etc/bind/named.conf.options (adicione a linha "allow-transfer" conforme a figura a seguir)
listen-on { IP1; IP2; any; none; }; (especifica por qual interface o BIND ira trabalhar, ou seja, por qual IP o DNS Server vai responder as requisicoes de resolucao de nomes (UDP-53) e transferência de zona (TCP-53))
listen-on-v6 { IP1_v6; IP2_v6; any; none; }; (especifica se o BIND irá trabalhar com IPv6 e por qual interface, ou seja, por qual IP o DNS Server vai responder as requisições de resolução de nomes (UDP6-53) e transferência de zona (TCP6-53) de IPv6. Abre as portas UDP6-53 e TCP6-53)
allow-recursion { IP1; IP2; any; none; }; (especifica por qual interface o BIND ira fazer recursao, ou seja, por qual IP o DNS server vai responder as requisicoes de resolucao de nomes de outros dominios. Por padrao, o DNS Server responde por qualquer dominio para ele perguntado, repassando para os servidores ROOT as perguntas que não tiverem as zona(s) nele configurado. Para que isso nao ocorra, ou seja, para que o DNS Server responda somente as perguntas da(s) zona(s) que foram configuradas nele, se deve colocar o IP 127.0.0.1 ou none. Em servidores que estão na Internet, essa opção é imprecindível [se poderia usar algo do tipo "allow-recursion { 127.0.0.1/32; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };"])

# vi /etc/default/bind9 (adiciona algumas opções no daemon do "bind")
OPTIONS="-u bind" (linha padrão que especifica que o usuário será o "bind" para serviço do DNS Server)
OPTIONS="-4 -u bind" (desabilita o IPv6 no BIND, ou seja, não abre as portas UDP6-53, TCP6-53 e TCP6-953. Também torna as consultas DNS mais rápidas, pois não tentará usar o protocolo IPv6 com os DNS ROOT). Caso queira desabilitar totalmento o IPv6 dê preferência a essa opção no arquivo "/etc/default/bind9", do que a opção "listen-on-v6" do arquivo "/etc/bind/named.conf.options", pois essa última deixa a porta "TCP6-::1:953" aberta.




DNS Secundário

Um DNS Secundário é DNS sobresalente. Caso o DNS Primário falhe, o Secundário assumirá todas as funções de DNS. Em outras palavras, provê alta-disponibilidade ao esquema de DNS. Somente será exigido um DNS Secundário quando for necessário possuir alta-disponibilidade ou para registrar um domínio no "Registro .br" ( www.registro.br ). Quando se registra um domínio (ex: matrix.com.br ou hugoazevedo.eti.br), é exigida uma infra-estrutuda de dois DNS, um Primário e outro Secundário conectados à Internet (preferencialmente em uma DMZ). Além disso, eles já têm que estar configurados para o domínio solicitado. Ao solicitar um domínio, é necessário ser uma pessoa física (CPF) ou jurídica (CNPJ) representada ou estabelecida no Brasil.

Para facilitar e diminuir custo, muito domínios são registrados por terceiros. Isto pode ser observado em empresas de hospetagem de sites. Essas empresas, além de disponibilizar um servidor HTTP na Internet para hospedar as páginas (html, php, xml etc), também incluem no pacote de serviços, a sua infra-estrutura de DNS Primário e Secundário. Se não fosse por elas, toda vez que um pessoa ou empresa quisesse colocar sua página no ar (na Internet) teria que ter no mínimo um DNS Primário, um Secundário, um servidor de HTTP e dois IP públicos :-(. Algumas informações interessantes pode ser conseguidas em www.registro.br. Agora, chega de teoria e vamos ao que interessa, os procedimentos para instalar e configurar um DNS Secundário (rsrsrsrsrsrs):


Instalação DNS Server
# apt-get update ; apt-get install bind9(no final da instalação aparecerá a mensagem " Not creating home directory `/var/cache/bind' ")

Entre no arquivo "named.conf.local"
# vi /etc/bind/named.conf.local(arquivo de configuração onde é colocado o domínio direto, reverso e seus respectivos arquivos de consulta. Digite o conteúdo a seguir)
zone "matrix.com.br" {(nome da zona direta ou domínio da rede)
type slave;(indica o tipo do DNS. Slave significa que é um DNS Secundário )
file "/etc/bind/sec.matrix.com.br";(este arquivo será criado automaticamente e conterá as informações DNS da zona direta "matrix.com.br")
masters { 192.168.1.1; };(indica o IP do DNS Primário)
};(fechamento da configuração da zona direta)

zone "1.168.192.in-addr.arpa" {(nome da zona reversa da rede)
type slave;(indica o tipo do DNS. Slave significa que é um DNS Primário )
file "/etc/bind/sec.192.168.1";(este arquivo será criado automaticamente e conterá as informações DNS da zona reversa "1.168.192.in-addr.arpa")
masters { 192.168.1.1; };(indica o IP do DNS Primário)
};(fechamento da configuração da zona reversa)

Obs: na linha inicia por "file" é colocado o caminho completo do arquivo que gerencia uma zona (ex: file "/etc/bind/sec.matrix.com.br";). Contudo, alguns administradores colocam somente o nome do arquivo (ex: file "sec.matrix.com.br";). Isso não é errado. Contudo, para esse último caso é utilizada a opção "directory" dentro do arquivo de configuração "named.conf.options" para saber em qual diretório o arquivo de zona será gravado automaticamente ao se fazer uma transferência de zona do DNS Primário para o DNS Secundário.

Faça os procedimentos a seguir para bloquear troca de zonas
vi /etc/bind/named.conf.options(adicione a linha "allow-transfer" conforme a figura a seguir)

O "none" se não especificado, transfere a zona para qualquer host (falha de segurança).
Salve e Saia do arquivo

Torne o DNS cliente dele mesmo
# vi /etc/resolv.conf
search matrix.com.br(especifica o domínio)
nameserver 127.0.0.1(especifica o IP local. Não se deve especificar o IP do DNS Primário, pois caso o Secundário esteja com algum problema nunca se saberá)
Salve e Saia

Verifique se o arquivo de configuração de interfaces de rede tem alguma entrada para DNS. Se tiver comente ou apague:
# vi /etc/network/interfaces
dns-nameservers(linha que define o DNS. Comente-a ou apague-a)

Faça os comando a seguir:
# chmod g+w /etc/bind(muda a permissão para escrita do grupo "bind", pois serão criados, por esse grupo, os arquivos "sec.matrix.com.br" e "sec.192.168.1" dentro de "/etc/bind/")
# chmod .bind /etc/bind(este comando não é necessário, mas o coloquei, pois se o grupo não for o "bind", o DNS Secudário não funcionará)
/etc/init.d/bind9 restart(reinicia o serviço de DNS)

Verificação
ls /etc/bind/(verifique se os arquivos "sec.matrix.com.br" e "sec.192.168.1" foram criados)

Dica: Para que o esquema de DNS Primário e Secundário funcione, os dois DNS devem constar nos clientes. Assim, se o Primário não responder o Secundário responderá.





Atualização automática ou dinâmica do DNS

Atualização automática ou dinâmica do DNS significa que os IPs e nomes de host serão inseridos de maneira automática dentro do arquivos de configuração do DNS. Existem dois motivos para que um DNS faça isso:

Primeiro motivo, quando é necessário integrar o DNS com o DHCP. Isso que dizer que quando um cliente DHCP solicitar um IP ao servidor DHCP, este envia o nome do cliente para o DNS. Assim, o nome do cliente DHCP estará dentro do DNS de maneira automática, podendo usufruir de todos os benefícios de um DNS (também é necessário configurar o cliente e o servidor DHCP). Segundo motivo, quando se tem um Serviço de Diretório como o Active Directory que necessita inserir dados no DNS.

Vale ressaltar que o DNS que fica na DMZ não se deve habilitar a atulização automática, muito menos inserir dados da rede interna. Medida de segurança. Então, se realmente necessitar do recurso de atualização automática do DNS, se deve instalar um DNS específico dentro da rede interna (LAN) somente para isto. Sendo que este DNS servirá a todos os clientes da rede interna. Além disso, não se deve inserir todos os nomes de todas as máquinas neste DNS, somente os que houverem necessidade (ex: máquina com uma impressora compartilhada, uma máquina que compartilha arquivos etc).

Seria interessante, neste caso de um DNS dentro da LAN, utilizar o recurso de "forwarders de DNS". No próximo tópico esse "forwarders de DNS" é explicado. A seguir estão os procedimentos para que um DNS aceite atualizações automáticas:

# chmod g+w /etc/bind/(serão criados automaticamente arquivos com a extensão ".jnl" dentro de "/etc/bind/" quando atualizado algum registro no DNS. Devido a isto, é necessário mudar as permissões)
# chmod g+w /etc/bind/db.matrix.com.br(serão inseridos dados automaticamente dentro deste arquivo, por isso a mudança nas permissões)
# chmod g+w /etc/bind/db.192.168.1(idem. Agora edite o arquivo a seguir)
# vi /etc/bind/named.conf.local(insira as linhas "allow-update" nas zonas desejadas, conforme figura a seguir)

Explicação: a linha "allow-update" especifica qual é IP que terá o direito de fazer a atualização automática. Geralmente é o IP do DHCP Server ou do Serviço de diretório (AD - Active Directory, por exemplo). Se pode colocar mais de um IP, ficando desta maneira: "allow-update { 172.16.200.254; 172.16.200.3; };

Extra:
# nsupdate -v -k /etc/bind/key.private(entra em um ambiente para inserção e deleção de registro DNS. É necessário instalar o "dnsutils")
update delete www.matrix.com.br. 1 A(deleta um registro. "1" é igual à TTL 1D, "A" é igual a Address)
update add www.matrix.com.br. 1 A(adiciona um registro. "1" é igual à TTL 1D, "A" é igual a Address)
send - quit(valida os registros modificados e sai do ambiente de configuração)




Forwarders de DNS

Um "forward de DNS" é necessário quando as consultas DNS precisam ser repassadas para outro servidor. As únicas consultas que este DNS vai responder são as das zonas definas em "/etc/bind/". O DNS que faz "forward" não faz cache. Esse tipo de configuração pode ser utilizado quando se tem um DNS na LAN e outro na Internet. Assim, o DNS da LAN responde somente as consultas internas, ou seja, das zonas da própria LAN. Quando os clientes forem acessar outros domínios, o DNS da LAN redireciona as consultas para um DNS da WAN (geralmente o DNS Primário que está na DMZ). A seguir é mostrado como proceder:

# vi /etc/bind/named.conf.options(a figura a seguir significa o seguinte: que todas as consultas de zona que não tiverem definidas em "/etc/bind/" serão repassada para o endereço IP "72.233.23.3" que na verdade é um outro DNS. Repare na linha "forwarders")

Obs: o "forward de DNS" deve ser configurado tanto no DNS Primário, quanto no Secundário.




Forwarders de SubZona/SubDomínio
e
Forwarders de Zona/Domínio

Um "forward de subzona" é necessário quando uma consulta de uma determinada subzona precisa ser repassada para outro DNS responder. Isso, é bastante usado quando uma empresa tem uma filial em outro lugar e esta filal possui uma infra-estrutura de rede própria com servidores DNS, e-mail, HTTP, FTP etc, mas precisa está vinculada ao mesmo domínio da matriz. O DNS que faz "forward" não faz cache, ou seja, não são armazenadas as informações já consultados. Para esta configuração será necessário mais um DNS que deve ficar na DMZ da filial.

Tentarei contextualiza uma situação hipotética para uma melhor compreensão. Por exemplo, se existisse uma empresa chamada "Matrix" onde a sede principal ficasse em Brasília. O seu o domínio seria "matrix.com.br", sendo que para acessar o servidor HTTP bastaria digitar em um browser "www.matrix.com.br".

Só que esta empresa tem uma filial em São Paulo (poderia ser na mesma cidade, em outra cidade, estado, país ou até mesmo em outro planeta, galáxia etc - brincadeira). Não se poderia colocar outro domínio para a filial (ex: vitrix.com.br), pois ela não é uma empresa independente, é apenas uma filial que está sitiada em São Paulo cuja sede está em Brasília. Então, o mais certo seria criar um subdomínio em cima do domínio já existente como por exemplo "sp.matrix.com.br". Se está filial tivesse um servidor HTTP, ele seria acessado como "www.sp.matrix.com.br". Espero que esta contextualização clarei um pouco mais a função de um subdomíno. Agora chega de teoria e vamos ao que interessa, a prática:


No servidor DNS primário da empresa sede/principal/matriz/Brasília, que no caso da contextualização acima ficaria em Brasília, digite:
# vi /etc/bind/named.conf.local(na figura seguir veja que foi adicionada uma nova linha "zone" que contém o subdomínio "sp.matrix.com.br" a qual tem o seguinte significado: toda consulta para a subzona/subdomínio "sp.matrix.com.br" deve ser repassada para o endereço IP "72.233.13.3" que na verdade é um outro DNS que está localizado, de acordo com o exemplo contextualizado, na filial em São Paulo.)

# /etc/init.d/bind9 restart(poderia ser também "rndc reload")

Obs1: Vale lembrar que o DNS (72.233.13.3), que está na filial e resolverá as consultar para o subdomínio (sp.matrix.com.br), deverá ser configurado de acordo. Basta seguir os passos já mostrados neste artigo para configurar o DNS que está localizado na filial. A figura abaixo serve de exemplo para o arquivo "db.sp.matrix.com.br" que deverá ser criado no DNS da filial. Não é obrigatório possuir também um DNS Secudário na filial nesse caso, pois este subdomíno (sp.matrix.com.br) não está registrado no orgão que tem esta compentencia (Registro.br). Contudo, case se coloque um DNS Secudário teríasse todas as vantagens de um ambiente de alta-disponibilidade.

Obs2: Nada impede usar o que foi mostrado acima para realizar um "forward de zona" ao invés de um "forward de subzona". Por exemplo, se pode especificar que as consultas para um determinada zona/domínio (ex: hugoazevedo.eti.br) sejam repassadas para um DNS específico. Como pode ser observado, o domínio "hugoazevedo.eti.br" nada tem haver com o domínio "matrix.com.br", mas se necessitar desse tipo de configuração, é possível ser feito.
Obs3:
allow-query { any; }; e dnssec-validation no; vão ser necessário lá no named.local.options. O allow-query permite que clientes de outras redes possam fazer consultas nesse servidor.
Obs4: o "forward de zona ou subzona" deve ser configurado tanto no DNS Primário, quanto no Secundário (na sede/matriz).


Continua...

Existe uma outra maneira mais fácil e barata de fazer a mesma coisa, ou seja, um forward de zona ou subzona. A diferença é que não é necessário possuir mais um DNS (na filial). Bastaria configurar os DNSs já existentes, o Primário e o Secundário (na sede/matriz). A idéia é que tais DNSs que respondem pelo domínio (ex: matrix.com.br), respondam também pelo subdomínio (ex: sp.matrix.com.br). Então, no DNS Primário e Secundário (na sede/matriz/Brasília), siga os comandos a seguir:

Entre no arquivo, conforme comando abaixo:
 # vi /etc/bind/named.conf.local(na figura seguir veja que quase nada foi modificado em relação a configuração anteriormente mostrada. Como já feito, foi adicionada uma nova linha "zone" que contém o subdomínio "sp.matrix.com.br", só que toda consulta para a subzona/subdomínio "sp.matrix.com.br" deve ser repassada para o arquivo "/etc/bind/db.sp.matrix.com.br". E este arquivo que deve resolver o subdomínio/subzona)

# cp /etc/bind/db.matrix.com.br /etc/bind/db.sp.matrix.com.br(esta cópia serve para economizar tempo, pois será necessário modificar poucas coisas)
# vi /etc/bind/db.sp.matrix.com.br(faça as modificações necessárias para o subdomino/subzona que neste caso é "sp.matrix.com.br". A figura abaixo serve como exemplo)

# /etc/init.d/bind9 restart(poderia ser também "rndc reload")

Obs1: Nada impede usar o que foi mostrado acima para realizar um "forward de zona" ao invés de um "forward de subzona". Por exemplo, se pode especificar que as consultas para um determinada zona/domínio (ex: hugoazevedo.eti.br) sejam repassadas para um arquivo específico. Como pode ser observado, o domínio "hugoazevedo.eti.br" nada tem haver com o domínio "matrix.com.br", mas se necessitar desse tipo de configuração, é possível ser feito.
Obs2: o "forward de zona ou subzona" deve ser configurado tanto no DNS Primário, quanto no Secundário (na sede/matriz).


Continua... Continua...

Também existe uma outra maneira de fazer a mesma coisa, ou seja, um forward de zona ou subzona sem a necessidade de criar um subdomínio/subzona ou adicionar mais um DNS. A grande diferença em relação aos procedimentos anteriores é que não é necessário criar um subdomínio. Bastaria adicionar as respectivas linhas necessárias nos arquivos já existentes no DNS Primário e o Secundário (na sede/matriz). A idéia é a mesma do procedimento anterior, só que ainda mais fácil. Particularmente, não gosto desta solução que irei mostrar, pois muitos servidores, como os de e-mail, fazem checagem da existência do domínio através de consulta reversa (nslookup 72.233.13.3) ou direta (nslookup sp.matrix.com.br) ou de SPF/TXT, se o mesmo não existir, o servidor pensará que é algum tipo de fralde/ataque (spam no caso de uma servidor de e-mail). Apesar de tudo, para continuar a configuração, vá nos DNS Primário e Secundário (na sede/matriz/Brasília), siga os comandos a seguir:

# vi /etc/bind/db.matrix.com.br (na figura seguir veja que foram adicionadas linhas como "www.sp.matrix.com.br", "mail1.sp.matrix.com.br" etc. Assim, não há necessidade de criar uma subzona/subdomínio)

# /etc/init.d/bind9 restart(poderia ser também "rndc reload")




DNSSec (Extensões de Segurança)

DNSSec são extensões de segunrança para o ambiente DNS... . Algo importante para o DNSSec quando se usa 2 (dois) ou mais servidores DNS (como é o caso de um DNS Primário e um DNS Secundário) é as horas desses servidores estarem sincronizada. Por isso, é importante a instalação e configuração um cliente NTP. Ver o artigo NTPdate Client ou NTP Client para a instalação e configuração de um cliente NTP. Caso as horas não estejam sincronizadas os certificados usados no esquema de DNSSec falharão.



DNSSec (Transferência de Zona Segura)

Um dos aspectos do DNSSec é a transferência de Zona de maneira segura. Esse aspecto tem o intuito de que ninguém se passe pelo DNS Primário (enviando zonas) e nem pelo DNS Secundário (recebendo zonas). Perceba que as zonas não serão transmitidas de maneira criptografada, a intenção aqui é garantir a origem e o destino das transferência (autorização e autenticidade).

# mkdir -p /etc/bind/keys/zone_transfer (cria o diretório para armazenamento da chaves de transferência de zona)

# cd /etc/bind/keys/zone_transfer

# dnssec-keygen -a HMAC-MD5 -b 128 -n HOST ZONE_TRANSFER ("-a" especifica o algoritmo, "-b" o tamanho em bits das chaves criptográficas, "-n" especifica o tipo do proprietário das chaves e "ZONE_TRANSFER" é o nome que será dado às chaves criptográficas e totalmente case-insensitive. O comando gera duas chaves "Kzone_transfer.+aaa+iiiii.key" e "Kzone_transfer.+aaa+iiiii.private", onde "aaa" é um número representando o algoritmo usado e "iiiii" é o footprint, ou seja, identificador único do par de chaves. O "Kzone_transfer.+aaa+iiiii.key" é a chave pública e pode ser repassada para os interessados a fazerem a transferência de zona. Já a "Kzone_transfer.+aaa+iiiii.private" é a chave privada e não deve ser distribuída, precisando ter permissões de acesso restritas)

Obs: talvez o comando anterior fique estático (nada acontece), o prompt de comandos não é devolvido e as chaves (.key e .private) não são geradas. Isso ocorre porque o comando "dnssec-keygen" fica esperando e coletando mudanças que acontençam no computador (como acesso a arquivos, mudança de temperatura ou de voltagens, acesso a memória etc) para gerar entropia para as chaves criptográficas. Assim, caso o comando "dnssec-keygen" fique parado, digite em um outro terminal "find /" para gerar a entropia necessária. Para evitar esse problema de criar a entropia na mão, se pode usar o "/dev/urandom" da seguinte forma "dnssec-keygen -r /dev/urandom -a HMAC-MD5 -b 128 -n HOST ZONE_TRANSFER".

# cat Kzone_transfer.+aaa+iiiii.key (com esse comando se verá algo assim "ZONE_TRANSFER. IN KEY 512 3 157 AHbhhgvEUlEf4h+O0KPa6g==", sendo o "AHbhhgvEUlEf4h+O0KPa6g==" código criptografado que será compartilhado no DNS Primário e secundário)

No DNS Primário acesse o "/etc/bind/named.conf" faça, conforme a figura a seguir. Na linha "secret" se especifica a chave secreta vista anteriormente. Essas configurações da figura a seguir também poderiam ser feitas dentro de VIEWs (visões), inclusive ficaria mais seguro:



Ainda no DNS Primário acesse o "/etc/bind/named.conf.local" faça, conforme a figura a seguir. Veja que ao invés de por o endereço IP no "allow-transfer" se vai colocar o nome da chave que nesse caso é "ZONE_TRANSFER":



Já no DNS Secudário acesse o "/etc/bind/named.conf" faça, conforme a figura a seguir. O linha "server" se especifica o IP do DNS Primário que nesse caso é o "172.16.100.3". Essas configurações da figura a seguir também poderiam ser feitas dentro de VIEWs (visões), inclusive ficaria mais seguro:



Agora basta fazer um "rndc reload" DNS Primário e DNS Secundário que as zonas sejam transferidas de maneira segura, ou seja, sem que spooffing os IP dos DNS, tentando enganá-los.

# dig mysecuredomain.com @{master-dns-ip} axfr (teste que tem que falhar)
# dig mysecuredomain.com @{master-dns-ip} axfr -k /etc/bind/transfer.key (teste que tem que funcionar. -k aponta para o arquivo que tem a entrada "ZONE_TRANSFER")




VIEWs (VISÕES)

VIEWs no BIND significa que o DNS Server poderá responder as requisições de maneira diferente dependendo do IP de origem. Por exemplo, uma requisição perguntando qual o IP do endereço "www.matrix.com.br" chega ao DNS Server, caso a origem dessa requisição seja da LAN a resposta será "10.1.1.2", caso a origem seja da Internet (WAN) a resposta será "201.100.0.2". A seguir tem um exemplo simples de configuração de VIEWs, utilizando somente um DNS Server (master/primário)

# vi /etc/bind/named.conf.local (veja as linhas a seguir)


Na figura anterior foram criadas duas declarações de VIEWS (visões). Uma chamada "LAN" e outra chamada "WAN". Com a opção "match-clients" se define a origem das requisições. É nessa opção que o DNS Server vai fazer a distinção entre uma VIEW e outra. Caso IP de origem da requisição coincida com um dos endereços que está em "match-clients", será respondido com a zona daquela VIEW. Perceba que os arquivos das zonas (opção "file") da VIEW "LAN" e "WAN" são diferentes. A intenção da configuração anterior é caso a requisição seja proveniente dos endereços "127.0.0.1; 172.16.100.0/28; 172.31.200.0/30;", ela será respondida pela VIEW "LAN". Se for proveniente de qualquer outra (any;), será respondida pela VIEW "WAN". A seguir está uma breve explicação da opção "match-clients".

match-clients { IP_client1; IP_client2; any; }; (endereços IP de origem das requisições DNS que são aceitos pelos servidor DNS, ou seja, endereços IP dos clientes. É interessante especificar no "match-clients" em uma das VIEWs o endereço "127.0.0.1", pois geralmente em um DNS Server se usa o "127.0.0.1" como IP de origem de cosultas DNS. Isso não é uma questão de DNS, mais sim de rede, pois quando se faz consultas/requisições no IP de destino "127.0.0.1" é usado também o IP de origem "127.0.0.1". Na verdade isso mais especificamente é uma questão de rota (comando "route"). Assim, quando se faz consultas/requisições DNS no IP de destino "127.0.0.1" é usado também o IP de origem "127.0.0.1". É comum colocar no "/etc/resolv.conf" o "nameserver 127.0.0.1" como o primeiro da lista de servidores a serem consultados (destino). Por isso, é importante colocar no "match-clients" esse endereço "127.0.0.1". Também, comandos como "nslookup", "host" e "dig" usam o arquivo "/etc/resolv.conf" e além disso em testes com esses comandos é usado o "127.0.0.1" (pela independência da rede física). O "any" especifica qualquer IP de origem, inclusive os IP que foram especificados no "match-clients" em outras VIEWS)

Até este momento tudo tranquilo, configuração de VIEWs (visões) aparentemente fácil e funcional. Mas contudo, porém, embora, toda via, temos que lembrar que configuramos até agora somente o DNS Primário (master). E o DNS Secundário, como entra nessa histório de VIEWs? Agora vai fica mais complexo. Para a DNS Secundário poderíamos fazer algo simples da mesma forma que foi simples a configuração do DNS Primário (172.16.100.3), veja a figura a seguir. CONTUDO, A CONFIGURAÇÃO DA FIGURA A SEGUIR ESTÁ TOTALMENTE EQUIVOCADA:


A configuração acima de VIEWSs para o DNS Secundário está errada porquê? 1º, a porque o DNS Primário não saberia fazer a transferência de zona (IXFR) de maneira correta. Na VIEW "LAN" e na "WAN" se tem o mesma nome zona "matrinux.com.br" e seria transferida a zona "matrinux.com.br" da VIEW "LAN" do DNS Primário para as VIEWs "LAN" e "WAN" DNS Secundário. 2º, a zona "0.100.201.in-addr.arpa" não seria transferida para o DNS Secundário. Esse problemas tem a ver com os endereços IP do DNS Primário e DNS Secundário, pois as VIEW trabalham em cima deles para distinguir uma VIEW da outra.

Como resolve esse problema? Para resolver esse problema, é necessário que cada DNS tenha 2 IP, ou seja, o DNS Primário tenha dois IP e o DNS Secundário tenha dois IP. Nesse exemplo, o DNS Primário tem os IP 172.16.100.3 e 172.16.100.4. O DNS Secundário tem os IP 172.16.100.5 e 172.16.100.6. No DNS Primário o IP 172.16.100.3 será responsável pela VIEW "LAN" e o IP 172.16.100.4 pela VIEW "WAN". No DNS Secundário tem o IP 172.16.100.5 será responsável pela VIEW "LAN" e o IP 172.16.100.6 pela VIEW "WAN". A seguir estão as configurações para o DNS Primário (master):



A seguir estão as configurações para o DNS Secundário (slave):


Abaixo se tem as explições de cada opção adicionada para realmente conseguir fazer as VIEWs (visões) funcionarem, utilizando um DNS Primário e um DNS Secundário:

match-destinations { IP_1_server; IP_2_server; any; }; (endereços IP de destino das requisições do cliente que são aceitos pelo servidor DNS. Em outras palavras, endereços IP do servidor DNS os quais aceitam as requisições proviniente de clientes. É interessante especificar no "match-destinations" em uma das VIEWs o endereço "127.0.0.1", pois geralmente em um DNS Server se usa o "127.0.0.1" como IP de destino de cosultas DNS. É comum colocar no "/etc/resolv.conf" o "nameserver 127.0.0.1" como o primeiro da lista de servidores a serem consultados (destino). Por isso, é importante colocar no "match-destinations" esse endereço "127.0.0.1". Também, comandos como "nslookup", "host" e "dig" usam o arquivo "/etc/resolv.conf" e além disso em testes com esses comandos é usado o "127.0.0.1" (pela independência da rede física)

allow-notify { IP_DNS_Master; any; }; (essa opção é somente para o DNS Secundário [zonas slaves]. Essa opção diz que o DNS Secundário somente permitirá ser notificado [NOTIFY-UPDATE UDP-53] sobre atualizações/modificações de zonas que ocorrem no DNS Primário pelos IP definidos nessa opção, além é claro dos IP definidos na opção "masters" do DNS Secundário. Por padrão, é permitada atualizações/modificações de zona somente dos IP definos na opção "masters" do DNS Secundário. O "allow-notify" faz a adição de novos IP aceitos que notificarão o DNS Secundário sobre atualizações/modificações de zona que ocorrem lá no DNS Primário, sendo que o DNS Secundário buscará as atualizações/modificações de zonas nos IP definidos na opção "masters". Contudo, as notificações podem vierem dos IP definidos nas opções "masters" ou "allow-notify" que serão aceitas. Quando se usa VIEWs e o DNS Primário tem dois ou mais IP e ele não está usando a opção "notify-source", é impressidível colocar no "allow-notify" esses dois ou mais IP do DNS Primário. Não esquecer da opção que já foi explicada nesse artigo que se chamada "allow-transfer" que fica no arquivo "/etc/bind/named.conf.options" e que agora está localmente em cada zona de cada VIEW)

transfer-source IP_DNS_Slave; (somente válido para o DNS Secudário. Essa opção determina o endereço IP local do DNS Secundário que iniciará a transferência de zona via TCP com o DNS Primário. Muito usado quando se configura as VIEWs e os DNS de dois ou mais IP para que as zona de diferentes VIEWs possam ser transferida sem erros. Não esquecer da opção que já foi explicada nesse artigo que se chamada "allow-transfer" que fica no arquivo "/etc/bind/named.conf.options" e que agora está localmente em cada zona de cada VIEW)

notify-source IP_DNS_Master; (essa opção especifica qual o IP local do DNS Primário emitirá/enviará as notificações sobre as modificações/atualizações [NOTIFY-UPDATE UDP/53] de zonas para o DNS Secundário. Não esquecer da opção que já foi explicada nesse artigo que se chamada "allow-transfer" que fica no arquivo "/etc/bind/named.conf.options" e que agora está localmente em cada zona de cada VIEW)

also-notify { IP_DNS_Slave; }; (geralemnte usada no DNS Primário, essa opção especifica outros IP que o DNS Primário enviará as notificações de modificações/atualizações de zonas [NOTIFY-UPDATE UDP/53]. Por padrão, quando se muda/atualiza um zona no DNS Primário, se deve mudar também o "serial" desta zona e depois fazer um "rndc reload". Ao fazer isso, o DNS Primário notifica (NOTIFY), via UDP-53, o DNS Secundário informando que uma determinada zona foi mudada/atualizada e que o número "serial" mudou. A partir daí, o DNS Secundário inicia a transferência de zona via TCP-53. Mas aí vem a pergunta: Como o DNS Primário sabe quem é o DNS Secundário? Através dos registros "NS". Aí é que entra o "also-notify", essa opção é muito útil quando se usa VIEWs, quando uma das declarações de VIEWs especifica endereços IP públicos para os registros "NS" e quando os DNS Primário e Secundário estão numa rede com IP privados. Nesta situação, o DNS Primário não consiguirá notificar o DNS Secundário, pois o IP do DNS Secundário é público. Para contornar isso, basta usar essa opção "also-notify" adicionando o IP do DNS Secundário. Apesar disso tudo, o DNS Primário, além de enviar a notificação para o IP definido em "also-notify", também continuará enviando essas notificações para o IP público do registro NS [exceto o IP do SOA]. Para resolver isso, use a opção "notify explicit;" para que o DNS não envie notificação para IP públicos. A seguir tem a explicação de como a opção "notify explicit;" funciona. Não esquecer da opção que já foi explicada nesse artigo que se chamada "allow-transfer" que fica no arquivo "/etc/bind/named.conf.options" e que agora está localmente em cada zona de cada VIEW).

notify yes | no | explicit; (geralmente usado no DNS Primário, quando "yes" permite que o DNS Primário envie notificações sobre mudanças/atualizações [NOTIFY-UPDATE UDP/53] de zona para o DNS Secundário, quando "no" não envia notificações e quando "explicit" envia notificação somente para o(s) IP(s) definido(s) na opção "also-notify". Por padrão, as notificações são enviadas do DNS Primário para os NameServers [DNS] definidos nos registros "NS" da zona, com exceção do NameServer [DNS] definido no registro "SOA". Mas caso e opte pelo "explicit", os registros "NS" são ignorados e enviadas as notificações somente o(s) IP(s) definido(s) na opção "also-notify". Não esquecer da opção que já foi explicada nesse artigo que se chamada "allow-transfer" que fica no arquivo "/etc/bind/named.conf.options" e que agora está localmente em cada zona de cada VIEW)

Obs: Só para relembrar que as notificações usam o UDP e a transferência de zonas usam o TCP. As notificações são enviadas do DNS Primário para o DNS Secundário com a intenção de informar o DNS Secundário da existência de atualização de zona. A partir daí o DNS Secundário se conecta no DNS Primário e solicita a transferência de zona.

recursion yes | no; (permite ou não recursão. Por padrão permite "yes", mas é importante especificar o "no" quando a VIEW estiver referentiando a Internet "WAN", pois clientes da "LAN" poderão fazer recursividade no IP pertecente a VIEW "WAN". Não esquecer da opção que já foi explicada nesse artigo que se chamada "allow-recursion" que fica no arquivo "/etc/bind/named.conf.options")





JAIL (CHROOT)

O enjalaumento é uma medida de segurança para o DNS Server. A ídéia é enjaular o invasor dentro de um diretório especifico caso ele consiga invadir o servidor via o serviço do DNS. A raiz do sistema continuará o "/", mais para o serviço do BIND (que é o "named") a raiz será outra que nesse exemplo será o "/opt/chroot/named". Assim, se um invasor comprometer o servidor via o serviço do BIND, ficará somente dentro do "/opt/chroot/named", envitando prejudicar o resto do sistema.

# /etc/init.d/bind9 stop (para o serviço do bind)
# vi /etc/default/bind9 (arquivo padrão do bind. Modifique a linha iniciada com "OPTIONS", conforme a linha a seguir)
OPTIONS="-u bind -t /opt/chroot/named/" (a opção "-t" faz o enjaulamento)
# vi /etc/passwd (modifique a linha iniciada com "bind", conforme a linha a seguir)
bind:x:101:103::/opt/chroot/named/var/cache/bind:/bin/false (usuário bind que sobe o daemon named)
# mkdir -p /opt/chroot/named/{etc,dev,var/cache/bind,var/run/named} (criação de diretórios necessários)
# cp /etc/localtime /opt/chroot/named/etc/ (timezone. Verificar a necessidade)
# mknod /opt/chroot/named/dev/null c 1 3 (null)
# mknod /opt/chroot/named/dev/zero c 1 5 (zero. Verificar a necessidade)
# mknod /opt/chroot/named/dev/random c 1 8 (random)
# chmod 666 /opt/chroot/named/dev/* (permissões necessárias)
# mv /etc/bind /opt/chroot/named/etc/ (copia o diretório de configuração do bind para o novo diretório "enjaulado")
# ln -s /opt/chroot/named/etc/bind/ /etc/bind (evita problema com alguns comandos como o "rndc" e atualização que procuram dentro de "/etc/bind")
# chmod 775 /opt/chroot/named/var/{cache/bind,run/named} (permissões necessárias)
# chown .bind /opt/chroot/named/var/{cache/bind,run/named} (permissões necessárias)
# mv /var/cache/bind/* /opt/chroot/named/var/cache/bind/ (move os arquivos das zonas para o diretório enjaulado)

# /etc/init.d/bind9 start (inicia o serviço novamente)
# ls /var/run/named/ (perceba que esse diretório esta vazio)
# ls /opt/chroot/named/var/run/named/ (esse diretório tem arquivos de PID e de SESSÃO)

Obs: um dos motivos de criar, mover e configurar os diretórios e arquivos acima é devido ao script do BIND. Entre no "/etc/init.d/bind9" e veja que é especificados vários diretório (PID, /dev/null etc) que o BIND irá usar.






VERIFICAR A NECESSIDADE
# echo "\$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf
# /etc/init.d/rsyslog restart; /etc/init.d/bind9 restart





LOGs

# vi /etc/bind/named.conf.local ()
logging { ()
channel custom { ()
file "/var/log/bind/named.log"; ()
print-time yes; ()
print-category yes; ()
print-severity yes; ()
severity debug; ()
}; ()
category client { custom; }; ()
category config { custom; }; ()
category database { custom; }; ()
category default { custom; }; ()
category delegation-only { custom; }; ()
category dispatch { custom; }; ()
category dnssec { custom; }; ()
category general { custom; }; ()
category queries { custom; }; ()
category lame-servers { custom; }; ()
category network { custom; }; ()
category notify { custom; }; ()
category resolver { custom; }; ()
category security { custom; }; ()
category unmatched { custom; }; ()
category update { custom; }; ()
category update-security { custom; }; ()
category xfer-in { custom; }; ()
category xfer-out { custom; }; ()
};

# /etc/init.d/bind9 restart




Ambiente Gráfico

# apt-get install gbindadmin(ferramenta gráfica para o BIND)
# apt-get install gadmintools(ferramenta gráfica para o BIND, SAMBA, DHCP e PROFTP)




Extra

Caso ocorra algum problema digite:
tail -f /var/log/syslog | grep -i named (log do "bind")
named-checkconf (verifica possíveis erros de síntaxe nos arquivos de configuração do BIND)
named-checkzone matrinux.com.br /var/cache/bind/db.matrinux.com.br (verifica possíveis erros de síntaxe em arquivo de zona)

Comandos
# rndc flush (limpa o cache de DNS)
# rndc reload ("/etc/init.d/bind reload", "kill -1 PID_NAMED" ou "# killall -HUP named")
# rndc dumpdb (escreve o cache do DNS Server num arquivo em "/var/cache/bind/named_dump.db")
# rndc stats (gera estatíticas do DNS Server num arquivo em "/var/cache/bind/named.stats")
# rndc status (mostra informações importantes sobre o DNS Server)
# rndc managed-keys status (mostra informações da managed-keys)


Assuntos Relacionados
DNS Client no GNU/Linux.
DNS Client no MS Windows.
 
 




ETI - Especialista em Tecnologia
da Informação