lael
(usa Fedora)
Enviado em 04/12/2009 - 18:02h
ai vai alguma coisa util....
*********************************************************************************************************
Configurando o named.conf
Agora vamos aos arquivos de configuração. Todos os arquivos se encontram no diretório /etc/bind.
Primeiro você deve editar o arquivo named.conf, onde estão todas as zonas que no caso são os endereços de sites pela qual a máquina vai responder.
Você deverá incluir a seguinte linha no arquivo named.conf:
zone "seusite.com.br" {
type master;
file "db.seusite.com.br";
};
Exemplo:
zone "luis.com.br" {
type master;
file "db.luis.com.br";
};
**************************************************************************************************************
1. Objetivo
Quando falamos de DNS, o assunto pode se estender por horas e horas, visto que a especificação do protocolo é ampla e complexa em seus muitos detalhes.
A intenção hoje é que você entenda o básico da estrutura de funcionamento do seu DNS para poder "se virar" com seus probleminhas, entender porque o Terra de repente passou a não gostar mais dos seus emails, porque seu amigo lá da Conchichina te manda um email e demora bastante pra chegar até você, ou que você possa dar respostas à altura ao pessoal da Embratel que lhe manda criar uma zona de reverso com um nome, no mínimo, bizarro.
2. O que é, pra que serve
O DNS (Domain Name Server/Service) surgiu da necessidade de traduzir nomes mais fáceis de serem lembrados (como minhafaculdade) para seus respectivos endereços na rede, algo bem mais difícil de lembrar.
Para facilitar mais a identificação destes serviços, criaram-se terminações elucidativas, como .com para domínios comerciais, .net para empresas de networking, .org para organizações sem fins lucrativos, e assim por diante.
Foi criado em 1983 por Paul Mockapertris. A especificação original encontra-se nas RFCs 882 e 883.
Mais curiosidades históricas:
http://en.wikipedia.org/wiki/Dns
3. Principais tipos de registros
Existem diversos tipos diferentes de registros DNS disponíveis. A lista a seguir não pretende, de maneira alguma, ser extensa ou exaustiva, mas antes mostrar os mais comuns que vai encontrar por ai.
* A - Address; especifica um endereço IP direto
* AAAA - Address IPv6; especifica um endereço IPv6
* NS - NameServer; especifica servidores DNS para o domínio ou subdomínio
* CNAME - Canonical NAME; um apelido para outro hostname
* MX - Mail eXchanger; o servidor de email
* PTR - PoinTeR; aponta o hostname/domínio reverso a partir de um endereço IP
* SOA - Start Of Authority; indica o responsável por respostas autoritativas por um domínio
* TXT - TeXT; permite incluir um texto curto em um hostname; usado para implementar o SPF
* SRV - SeRVice; permite definir serviços disponíveis em um domínio
Estes são os principais, e que você provavelmente vai achar por aí. Vamos agora considerar alguns deles que requerem carinho especial dos administradores.
3.1. SOA: aonde tudo começa
O SOA ou Start Of Authority indica o servidor e administrador responsável por um domínio, além de indicar outras informações úteis, como número serial da zona DNS, tempo de vida do registro SOA, intervalo de replicação de zonas, etc. Veja um exemplo:
thefallen@Sardine:~$ dig -t soa uol.com.br
(...)
;; ANSWER SECTION:
uol.com.br. 3575 IN SOA eliot.uol.com.br. root.uol.com.br. 2005081804 7200 3600 432000 3600
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10)
(...)
* 1 - nome da zona consultada
* 2 - TTL do registro na memória do seu DNS
* 3 - tipo de registro
* 4 - DNS responsável pela zona
* 5 - email do responsável pelo DNS acima
* 6 - número serial da zona; recomenda-se o formato YYYYMMDDxx (ano com 4 dígitos, mês, dia e quantidade de alterações durante o dia)
* 7 - refresh ou tempo em que um servidor com a zona replicada tenta replica-la de novo
* 8 - intervalo entre tentativas de replicação
* 9 - TTL do SOA
* 10 - tempo mínino que a zona deve ser retida em memória
3.2. Registros temperamentais: MX e PTR
Os registros MX e PTR merecem carinho especial dos seus administradores. O formato do registro MX é (imaginando o domínio dominio.com.br):
. IN MX 10 mail.dominio.com.br
. IN MX 50 mail2.dominio.com.br
O "." se refere ao domínio imediatamente superior, ou seja, a zona atual (não se trata de um subdomínio). O número define a preferência do MX. Quanto menor o número, maior sua preferência ou prioridade de receber emails.
Note que os hostnames mail.dominio.com.br e mail2.dominio.com.br DEVEM ser registros "A", jamais "CNAMEs" nem endereços IP. Embora esses tipos de registros possam funcionar, não estão de acordo com as definições de melhores práticas de DNS publicadas em RFCs, e irão causar dores de cabeça ao administrador responsável, uma vez que haverá atrasos e falhas de entrega de email para seu domínio.
Já os registros PTR devem estar colocados debaixo de uma zona específica chamada "in-addr.arpa". Vamos considerar essa zona especial mais adiante.
O registro PTR deve ser colocado com os octetos do endereço IP invertidos, e o hostname indicado PRECISA existir e apontar para o mesmo endereço IP. Por exemplo, se tivermos o endereço 201.202.203.204, seu registro PTR seria: -- 204.203.202.201 IN PTR meureverso.sardine.com.br
E, obrigatoriamente, para que seu registro PTR seja válido e funcional, o host meureverso.sardine.com.br PRECISA apontar de volta para 201.202.203.204.
Para consultarmos se nosso reverso está ok, basta rodarmos o seguinte comando:
dig -t ptr 204.203.202.201.in-addr.arpa
Não é boa idéia ter múltiplos destinos para um mesmo PTR, embora isso seja permitido. Tal comportamento pode causar confusão nas aplicações tentando consultar essa informação.
3.3. O Anônimo: SRV
Registros SRV definem localizações de serviços publicados, inclusive seus protocolos e portas. Um exemplo de registro SRV pra Jabber:
_jabber._tcp.grupogeo.com.br. 3600 IN SRV 5 0 5269 jabber.grupogeo.com.br.
O serviço chama-se "jabber", protocolo tcp, 3600 segundos de TTL, Prioridade 5, Peso 0 (para registros com mesma prioridade), porta 5269, hostname jabber.grupogeo.com.br.
Dentro dos SRVs, pode-se definir diversos servidores para o mesmo serviço, com prioridades e portas não-convencionais.
Os serviços que usam registros SRV mais conhecidos são o protocolo SIP de telefonia IP, o protocolo Jabber de Instant Messaging e, segundo dizem as más línguas, o Active Directory daquele outro sistema ali.
4. Estrutura de uma consulta
Entender como uma consulta vai trafegar pela Internet é o primeiro passo pra entender os problemas que você pode ter.
O sistema de DNS trabalha com uma estrutura fortemente hierárquica. Isso facilita que cada corporação ou entidade cuide de maneira autônoma de seu próprio DNS sem ter que recorrer à terceiros. Imagine se cada vez que você quisesse adicionar um host em sua zona DNS você tivesse que contatar o registro.br ou seu provedor. Embora muitas corporações ainda façam isso, talvez por desconhecerem o manuseio correto do DNS, sempre há atrasos e longas esperas para alterações tão simples. Aguardar 2 dias (sem receber emails) uma mudança de MX porque seu servidor atual deu problemas e você precisa colocar outro (emergencial) para receber os emails temporariamente porque o fulano do provedor ainda não concluiu seu chamado não é uma situação confortavel para nenhum administrador de rede.
Por ora, vamos pensar que os servidores DNS formam uma grande e feliz rede de amigos. Quando um deles não tem a informação que precisa, ele pergunta ao seu amigo do lado pra ver se ele tem. Esse amigo pode dizer "olha, EU não tenho, mas o fulano pode te dizer quem tem". Você solicita ao fulano, e ele lhe responde "da ultima vez que eu vi, quem estava com isso era o ciclano. Ele que estava cuidando dessa parte". E assim vai até que finalmente chegamos ao amigo que tem nossa informação.
4.1. Hierarquia e Delegação
Como pudemos perceber no exemplo acima, vamos sempre consultar um amigo do lado pra ver se ele tem a informação que queremos ou se sabe nos dizer quem tem. Forma-se uma hierarquia ou seqüencia de consultas a serem feitas até chegarmos no objetivo final.
Um primeiro conceito a respeito da hierarquia é que tudo começa no ".". O "domínio" da Internet, a raiz, é o "."; um hostname completo seria, por exemplo, "www.slackwarezine.com.br."
No ambiente real da Internet, os primeiros amigos a serem consultados são os Root Servers/Servidores Raiz. Eles contem a zona DNS do "." da Internet, que diz pra onde vão todas as consultas DNS das zonas "filhas" do ".".
Para delegarmos um subdomínio, basta colocarmos uma linha NS com o nome desejado. Por exemplo, para delegarmos toda a sub-árvore sp.empresa.com.br para o respectivo DNS da filial em Sao Paulo, colocaríamos na zona empresa.com.br:
sp IN NS ns1-sp.empresa.com.br.
Vamos entender agora um pouquinho mais dos Root Servers e do seu papel como "pais" da Internet
4.2. Root Servers e Glue record
Os Root Servers contem uma zona chamada "." que diz mais ou menos o seguinte a respeito das outras zonas:
thefallen@Sardine:~$ dig -t ns br.
(...)
;; QUESTION SECTION:
;br. IN NS
;; ANSWER SECTION:
br. 172724 IN NS d.dns.br.
br. 172724 IN NS e.dns.br.
br. 172724 IN NS a.dns.br.
br. 172724 IN NS b.dns.br.
br. 172724 IN NS c.dns.br.
(...)
Esses servers tambem contem informações de como chegar até os referidos DNS indicados.
thefallen@Sardine:~$ dig a.dns.br @c.root-servers.net
(...)
;; QUESTION SECTION:
;a.dns.br. IN A
;; ADDITIONAL SECTION:
a.dns.br. 172800 IN A 200.160.0.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
a.dns.br. 172800 IN AAAA 2001:12ff::10
(...)
Esses registros, que não fazem parte da zona que estamos consultando diretamente, são chamados de Glue Records, ou registros de "cola". Eles fazem com que a informação e o caminho de pesquisa fique coeso no DNS. Imagine que eles não tivessem essa informação. Como descobriríamos quem é o a.dns.br?
4.3. O arquivo de Dicas/Hints
O arquivo de "hints" do seu DNS diz a ele o endereço dos Root Servers na Internet, para que ele possa fazer a pesquisa inicial dos dominios. É sempre uma boa idéia atualizar seu arquivo de Hints. Ele está disponível em
ftp://ftp.internic.net/domain/named.root
Uma otimização que pode-se fazer para acelerar as consultas DNS é incluir os "hints" dos controladores .br dentro do seu arquivo de hints, evitando ter que consultar um Root Server para obtê-lo. Bast fazer a consulta "dig -t ns br @a.root-servers.net" e incluir no arquivo. Ficaria assim:
br. 172800 IN NS A.DNS.br.
A.DNS.br. 172800 IN AAAA 2001:12ff::10
A.DNS.br. 172800 IN A 200.160.0.10
br. 172800 IN NS B.DNS.br.
B.DNS.br. 172800 IN A 200.209.30.5
br. 172800 IN NS C.DNS.br.
C.DNS.br. 172800 IN A 200.130.31.5
br. 172800 IN NS D.DNS.br.
D.DNS.br. 172800 IN A 204.152.184.70
br. 172800 IN NS E.DNS.br.
E.DNS.br. 172800 IN A 139.91.1.20
Uma peculiaridade do BIND é que ele não depende do arquivo de Hints para o seu funcionamento (depois do boot). Quando ele é iniciado, ele conecta-se a um dos Root Servers especificados no arquivo de Hints e baixa a lista atualizada para a memória.
4.4. Recursão
Imagine esta situação: você pergunta a um amigo seu "sabe aonde está o João?" e ele lhe responde "está na casa do Pedro". Mas aonde será que fica a casa do Pedro? Você novamente teria que perguntar ao seu amigo como chegar na casa desta pessoa. Se este que lhe passa as informações estivesse um pouco mais disposto, ele teria lhe respondido da primeira vez "está na casa do Pedro, ali na Rua Endereço IP, número 200.200.200.200"
Transportando isto para nossa situação de DNS, um DNS pode lhe responder uma consulta sem lhe fornecer a resposta completa. Pode lhe passar, por exemplo, só o "apelido" de um hostname sem resolvê-lo para você. Por exemplo, tenho um domínio chamado "recurs.com.br", e seu
www.recurs.com.br é um "apelido" (CNAME ou CANONICAL NAME) para
www.recursivecorp.com. Uma vez que o destino do apelido não faz parte de meu domínio recurs.com.br, meu DNS estaria desobrigado a resolvê-lo também, já que isto é tarefa sua e não dele. Com a recursão habilitada, o próprio DNS que resolve o
www.recurs.com.br já lhe mandaria junto na MESMA resposta de DNS o endereço IP de
www.recursivecorp.com, evitando que você tivesse que fazer uma segunda consulta DNS.
Parece bom, não é? Agora imagine se eu fizesse uma consulta em que o resultado passaria por inúmeros CNAMEs/apelidos, pulando de um domínio para o outro. Consegue imaginar o tráfego inútil que eu estaria causando em meu servidor DNS?
Recursão é um recurso excelente, mas que deve ser usado com cautela em servidores expostos na Internet.
4.5. Cache e TTL
Notou os números que aparecem ali ao lado dos registros de NS e A dos servidores de nome .br? Eles são os TTL's (Time to Live) ou tempo de vida que aquele registro é válido após uma consulta, e que pode ser armazenado em cache. Uma vez que o servidor que você consulta resolva um nome, ele guarda essa informação em seu bando de dados interno até que o TTL expire (ou que ele precise dos recursos pra outra coisa ou que você limpe o cache manualmente).
Imagine uma página com 20 imagens. Cada imagem corresponde a um novo "download" do servidor. Pense em 1 único navegador fazendo a MESMA consulta 21 vezes ao seu DNS. Lembre-se que o tráfego de DNS por padrão tem prioridade sobre os outros. Teríamos um desperdício de recursos, não concorda? Tente imaginar agora 50 navegadores abrindo essa página simultaneamente. Muito provavelmente algumas requisições DNS serão perdidas em timeouts devido ao tráfego intenso. Se eu disser que meu registro
www.dominio.com.br é valido por, digamos, 1 hora ou 1 dia, enquanto esse tempo não expirar, quem já me perguntou isso não me perguntará mais.
Então quanto mais alto o TTL, melhor né? Até certo ponto sim. TTLs altos dificultam a mudança (às vezes emergencial) de hostnames e IPs. Algo muito comum de acontecer é fazer alteração de servidores de email e ficar dias sem receber email das empresas parceiras, fornecedoras ou clientes. Como são pessoas que estão sempre em contato com você, muito provavelmente estão com seus registros DNS em cache nos respectivos servidores de nomes. Valores ideais mudam de situação para situação, de caso para caso; uma corporação pode necessitar do TTL em 5 minutos, outra pode tê-lo em 1 hora, outra usa 1 dia, ainda outra, 1 semana.
4.6. Acompanhando uma consulta
thefallen@Sardine:~$ dig +trace
www.uol.com.br
;; global options: printcmd
. 474379 IN NS K.ROOT-SERVERS.NET.
. 474379 IN NS L.ROOT-SERVERS.NET.
. 474379 IN NS M.ROOT-SERVERS.NET.
. 474379 IN NS A.ROOT-SERVERS.NET.
. 474379 IN NS B.ROOT-SERVERS.NET.
. 474379 IN NS C.ROOT-SERVERS.NET.
. 474379 IN NS D.ROOT-SERVERS.NET.
. 474379 IN NS E.ROOT-SERVERS.NET.
. 474379 IN NS F.ROOT-SERVERS.NET.
. 474379 IN NS G.ROOT-SERVERS.NET.
. 474379 IN NS H.ROOT-SERVERS.NET.
. 474379 IN NS I.ROOT-SERVERS.NET.
. 474379 IN NS J.ROOT-SERVERS.NET.
;; Received 356 bytes from 192.168.0.1#53(192.168.0.1) in 4 ms
br. 172800 IN NS a.dns.br.
br. 172800 IN NS c.dns.br.
br. 172800 IN NS b.dns.br.
br. 172800 IN NS d.dns.br.
br. 172800 IN NS e.dns.br.
;; Received 224 bytes from 193.0.14.129#53(K.ROOT-SERVERS.NET) in 244 ms
uol.com.br. 86400 IN NS borges.uol.com.br.
uol.com.br. 86400 IN NS eliot.uol.com.br.
;; Received 105 bytes from 200.160.0.10#53(a.dns.br) in 20 ms
www.uol.com.br. 300 IN A 200.221.2.45
uol.com.br. 3600 IN NS borges.uol.com.br.
uol.com.br. 3600 IN NS eliot.uol.com.br.
;; Received 121 bytes from 200.147.255.105#53(borges.uol.com.br) in 20 ms
Note a seqüencia: consultamos os Root Servers, eles nos encaminharam para os servidores dns.br, estes nos remeteram aos 2 name servers do UOL, eliot e borges, e estes nos resolveram o hostname
www.uol.com.br.
5. Zonas DNS
Existem algumas zonas e funções especiais dentro da hierarquia de DNS além das consultas "diretas": a pesquisa de reversos e as transferências de zona.
5.1. in-addr.arpa
Esta zona especial define os reversos. Normalmente, as delegações acontecem em ranges de IP /24, /16 ou /8. No DNS ficaria assim:
200.in-addr.arpa. 86400 IN NS NS.LACNIC.NET.
168.200.in-addr.arpa. 86400 IN NS B.DNS.BR.
Mas e quando não se pode delegar todo esse range? Quando se precisa de intervalos menores? Aí começam as dores de cabeça dos administradores e os acontecimentos bizarros com os provedores. Cada um resolve fazer de um jeito, normalmente usando uma macro dentro do BIND, para fazer essa delegação.
5.1.1. Delegações bizarras de reverso: como lidar com isso
As melhores práticas do BIND v9 Adiministrator Reference Manual sugerem que se faca o seguinte para, por exemplo, a zona 50.100.200.in-addr.arpa:
1-20.50.100.200.in-addr.arpa. IN NS ns1.empresa.com.br.
100-115.50.100.200.in-addr.arpa. IN NS ns1.outraempresa.com.br.
$GENERATE 1-20 $ CNAME $.1-20.50.100.200.in-addr.arpa.
$GENERATE 100-115 $ CNAME $.100-115.50.100.200.in-addr.arpa.
Se fossemos delegar, por exemplo, 200.100.50.32/28, poderia ficar assim:
32/28.50.100.200.in-addr.arpa. IN NS ns3.delegacao.com.br.
$GENERATE 32-47 $ CNAME $.32/28.50.100.200.in-addr.arpa.
A maioria dos provedores costuma delegar dessas 2 maneiras. Alguns outros, como a Embratel e outros grandes provedores de serviço, por exemplo, preferem que você crie uma zona com algum nome esquisito, como esses, e eles fazem transferência para o servidor deles e incorporam na zona DNS da sub-rede, ao invés de lhe delegar isso.
5.2. Transferência/Sincronia de zonas: o AXFR/IXFR
Entre 2 DNS, podem haver zonas sincronizadas, um DNS sendo o Master que contém a zona original, e os outros seus slaves, que contém cópias da zona original. Para manterem-se sincronizados automagicamente, eles usam essa "consulta" especial, o AXFR (transferência "full" ou integral da zona) ou IXFR (transferência incremental, ou apenas alterações, da zona). Ambos acontecem via TCP ao invés de UDP como é o normal de DNS.
Permitir Zone Transfers para qualquer um que se interesse por seu DNS não é uma idéia muito boa. Entregar "de bandeja" a alguém malicioso a localização de todos os seus servidores e estações não é exatamente a coisa mais inteligente de sua vida :)
A melhor prática é limitar as transfers aos DNS slave, e, se a paranóia for um pouquinho mais longe, apenas permitir essas transferências com assinaturas digitas de DNS, para garantir que apenas o servidor DNS e ninguém mais que possa estar mascarado no mesmo IP consiga a transferência.
Se quiser testar transferências de zona, pode brincar com o comandinho:
dig -t axfr dominio.com.br @nameserver_do_dominio.dominio.com.br
6. RBLs
RBLs (Real-time Black List - criadas em 1997 por Paul Vixie no projeto MAPS) são zonas DNS especiais usadas para publicar listas negras de endereços IPs em Tempo Real. Durante muito tempo foram nossa única arma contra sistemas mal-configurados (os Open Relays) ou contra spammers. A técnica consiste em, de alguma forma, consultar uma lista que diz se o endereço IP pode ou não acessar o serviço.
A forma mais comum de RBL sao as DNSRBL (DNS RBL), onde a consulta eh feita via DNS. Por exemplo, supondo que estamos usando a RBL "relays.ordb.org" para saber se o IP 127.0.0.2 esta bloqueado ou nao. O endereço IP deve ser invertido para a consulta. Isso facilita termos no servidor DNS algo do tipo *.0.0.127. Fariamos uma consulta assim:
$ host -t A 2.0.0.127.relays.ordb.org
2.0.0.127.relays.ordb.org has address 127.0.0.2
Se o comando retornar um endereço IP, isso significa que o host esta bloqueado. Adicionalmente, pode haver tambem um registro TXT que informa o motivo do bloqueio. Por exemplo:
$ host -t txt 2.0.0.127.relays.ordb.org
2.0.0.127.relays.ordb.org text "Listed by ORDB - for testing purposes only"
7. Balanceamento de carga via DNS
Podem haver múltiplas definições para um mesmo registro DNS. A cada resposta do DNS, ele muda a ordem dos registros apresentados, fazendo com que as aplicações acessem, de maneira aleatória, um servidor diferente. Isso nos permite implementar um balanceamento de carga bastante simples apenas usando DNS. Vamos considerar o balanceamento de carga do Hotmail.com para ver como isso é implementado.
7.1. MX
Pode-se fazer balanceamento de MX colocando diversos MX com a mesma prioridade. Se tiverem prioridades diferentes, o procedimento padrão é tentar o de número menor, se falhar, o imediatamente acima dele, e assim por diante. Quando todos tem a mesma prioridade, eles terão a carga dividida entre si. Pode acontecer de TODOS os hosts que se conectam resolverem usar o mx1 e ignorarem os outros, mas a tendência é que fiquem iguais.
thefallen@Sardine:~$ dig -t mx hotmail.com
(...)
;; ANSWER SECTION:
hotmail.com. 3600 IN MX 5 mx4.hotmail.com.
hotmail.com. 3600 IN MX 5 mx1.hotmail.com.
hotmail.com. 3600 IN MX 5 mx2.hotmail.com.
hotmail.com. 3600 IN MX 5 mx3.hotmail.com.
(...)
7.2. Demais serviços
Para balancear demais serviços, como WWW e outros, basta adicionar vários destinos dentro do host a ser balanceado. Ainda no exemplo do hotmail.com, cada MX tem em sua definição, outro balanço de carga.
thefallen@Sardine:~$ dig mx4.hotmail.com
(...)
mx4.hotmail.com. 3528 IN A 65.54.167.230
mx4.hotmail.com. 3528 IN A 65.54.190.179
mx4.hotmail.com. 3528 IN A 65.54.190.230
mx4.hotmail.com. 3528 IN A 65.54.253.230
(...)
O mesmo host mx4.hotmail.com tem diversas definições de endereços IP, e a cada consulta eles podem se apresentar em ordem diferente.
8. Servidores DNS mais conhecidos
Existem basicamente 2 servidores DNS utilizados em larga escala dentro do ambiente Unix-like, que são o BIND e o DJBDNS. Ambos tem seus pontos fortes e fracos, e acaba mais ficando uma questão de preferência pessoal e necessidades específicas do que características intrinsecamente técnicas. Tem também o Servidor DNS daquele outro sistema lá, mas esse a gente desconsidera :)
O BIND é desenvolvido pela ISC - Internet Software Consortium (www.isc.org), e está na versão 9.3.1, ao passo que o DJBDNS é desenvolvido por Daniel J. Bernstein (http://cr.yp.to/djbdns.html)
8.1. Ferramentas úteis
Existem diversas ferramentas que são aquela aspirina na hora da dor de cabeça com DNS. Aqui listo algumas que acho particularmente úteis:
*
http://www.dnsreport.com - um site que faz um check-up completo em zonas DNS, exibe problemas, avisa sobre melhores práticas e aponta especificações a seguir.
* rbldnsd - um servidor de zonas RBL bastante robusto e funcional, com suporte a múltiplas RBLs (http://www.corpit.ru/mjt/rbldnsd.html)
* dnrd - domain name relay daemon - agiliza o cache de zonas DNS e permite que um mesmo IP tenha diversos servidores DNS redirecionados. Por exemplo, o domínio grupogeo.com.br tem suas requisições redirecionadas para o IP 192.168.0.2, ao passo que a zona rbl.grupogeo.com.br é redirecionada para o servidor 192.168.0.6 (http://dnrd.sourceforge.net)
8.2. dig, o amigo das horas difíceis
O dig merece um carinho todo especial. Ele é o amigão das horas difíceis, o super-herói que você chama quando o arqui-vilão ataca seus pobres registros DNS ou quando você tem um chefe bastante insatisfeito que não consegue enviar emails pro fulano, porque um estúpido configurou errado o DNS dele e você tem que provar que o erro está do outro lado, e não no seu DNS.
Uma das flags mais úteis dele é +trace. Essa flag ativa o modo "trace", ou seja, você vai rastrear todo o caminho que sua consulta DNS percorre até chegar ao DNS final do outro lado.
Também é com ele que você descobre se aquela sua migração de servidor de email vai ser problemática ou não, só por ver o TTL do registro MX.
Enfim, conheça-o! Vale gastar alguns minutos lendo a man page desse utilitário fantástico!
9. Dicas e truques com o BIND
Neste ponto eu gostaria de apresentar algumas funções do BIND que me tem sido bastante úteis durante minha convivência com ele. Abaixo estão alistados os melhores truques dele.
9.1. Macros
O BIND vem com diversas macros pra facilitar a manutenção das zonas. A mais conhecidas são a $GENERATE e $INCLUDE.
Como vimos nos exemplos acima, a $GENERATE cria hosts em massa, ao passo que a $INCLUDE permite incluir um arquivo como se fosse parte da zona.
9.2. ACLs
Podemos definir acls para facilitar nossa vida na configuração das zonas, pra não precisarmos repetir sequencias de IPs, por exemplo.
acl "intranet" {
10.0.0.0/8;
192.168.0.0/16;
};
acl "internet" {
200.200.200.200;
100.100.100.100;
};
Você vai ve-las em ação nos exemplos abaixo.
9.3. Views
Podem-se definir "views" dentro do BIND, ou seja, se você estiver consultando a zona dominio.com.br a partir do IP 192.168.0.1, você verá as informações do arquivo em disco /var/lib/named/intranet/dominio.com.br.zone, e se você estiver vindo do ip 200.200.200.200, vai enxergar as informações do arquivo /var/lib/named/internet/dominio.com.br.zone.
O inconveniente das Views do BIND é que, quando se usa Views, TODAS as suas zonas tem que estar presentes em todas as views. Por exemplo, no exemplo acima, se eu tivesse ainda a zona "empresa.net" (que não necessita de Views) junto com o dominio "dominio.com.br", eu obrigatoriamente teria que colocá-la em ambas as Views também (se a quisesse publicada para ambas as origens).
Isto é bastante útil quando você tem informações na zona de sua empresa que não quer ver publicada para fora da empresa, ou para que seus usuários acessem o servidor WWW direto na rede interna/DMZ sem ter que passar pelo firewall/proxy.
Um exemplo:
# MACRO/ACL
acl "intranet" {
10.0.0.0/8;
192.168.0.0/16;
};
view "internal" {
match-clients { "intranet"; };
recursion yes;
(...)
Zonas aqui
(...)
};
view "external" {
match-clients { any; };
recursion yes;
(...)
Zonas aqui
(...)
};
9.4. Chaves de autenticação
Podemos criar chaves de assinatura dentro do BIND para identificar servidores entre si, para autorizar um zone transfer ou uma atualização dinâmica de DNS. Essas chaves são criadas com o rndc-keygen, por exemplo.
key "XFER" {
algorithm hmac-md5;
secret "eaadASDjAHSDkAASDjahsdaksjdha==";
};
# Seu server
server 127.0.0.1 {
keys XFER;
};
# Server do outro lado
server 200.200.200.200 {
keys XFER;
};
Criadas as chaves, basta colocar na zona a ser controlada:
acl "intranet" {
200.200.200.200;
100.100.100.100;
};
zone "grupogeo.com.br" {
type master;
file "internal/grupogeo.zone";
allow-transfer { "nameservers"; key XFER; };
};
9.5. Logs
Podemos solicitar ao BIND que gere log de eventos específicos ou que gere estatísticas de consultas das zonas DNS. Veja o exemplo abaixo
options {
directory "/var/named";
pid-file "named.pid";
statistics-file "/var/log/statistics.log";
};
logging {
category lame-servers { null; };
category cname { null; };
channel update_debug {
file "/var/log/named-update.log";
severity debug 5;
print-time yes;
print-severity yes;
};
channel security_info {
file "/var/log/named-auth.log";
severity info;
print-time yes;
print-severity yes;
};
channel ztransfer {
file "/var/log/named-xfer.log";
print-time yes;
print-severity yes;
};
category update { update_debug; };
category security { security_info; };
category xfer-in { ztransfer; };
category xfer-out { ztransfer; };
};
zone "grupogeo.com.br" {
type master;
file "internal/grupogeo.zone";
allow-transfer { "nameservers"; key XFER; };
zone-statistics yes;
};
