1/9 www.unitednerds.org/thefallen/docs/?

area=DNS&tuto=SlackwareShow
Areas: Principal | Apache | DNS | FreeSWAN | giFT | LDAP | Mutt | Postfix | Sincronia | Vim | VNC
Uma breve introduo DNS
Deives Michellis "thefallen"
Reviso: $Id: Palestra.t2t,v 1.7 2005/08/19 14:55:44 thefallen Exp thefallen $
1. Objetivo
2. O que , pra que serve
3. Principais tipos de registros
3.1. SOA: aonde tudo comea
3.2. Registros temperamentais: MX e PTR
3.3. O Annimo: SRV
4. Estrutura de uma consulta
4.1. Hierarquia e Delegao
4.2. Root Servers e Glue record
4.3. O arquivo de Dicas/Hints
4.4. Recurso
4.5. Cache e TTL
4.6. Acompanhando uma consulta
5. Zonas DNS
5.1. in-addr.arpa
5.1.1. Delegaes bizarras de reverso: como lidar com isso
5.2. Transferncia/Sincronia de zonas: o AXFR/IXFR
6. RBLs
7. Balanceamento de carga via DNS
7.1. MX
7.2. Demais servios
8. Servidores DNS mais conhecidos
8.1. Ferramentas teis
8.2. dig, o amigo das horas difceis
9. Dicas e truques com o BIND
9.1. Macros
9.2. ACLs
9.3. Views
9.4. Chaves de autenticao
9.5. Logs
10. Bibliografia
1. Objetivo
Quando falamos de DNS, o assunto pode se estender por horas e horas, visto que a especificao do protocolo ampla e complexa em seus muitos
detalhes.
A inteno hoje que voc entenda o bsico da estrutura de funcionamento do seu DNS para poder "se virar" com seus probleminhas, entender porque o
Terra de repente passou a no 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 mnimo, bizarro.
2. O que , pra que serve
O DNS (Domain Name Server/Service) surgiu da necessidade de traduzir nomes mais fceis de serem lembrados (como minhafaculdade) para seus
respectivos endereos na rede, algo bem mais difcil de lembrar.
Para facilitar mais a identificao destes servios, criaram-se terminaes elucidativas, como .com para domnios comerciais, .net para empresas de
networking, .org para organizaes sem fins lucrativos, e assim por diante.
Foi criado em 1983 por Paul Mockapertris. A especificao original encontra-se nas RFCs 882 e 883.
Mais curiosidades histricas: http://en.wikipedia.org/wiki/Dns
3. Principais tipos de registros
Existem diversos tipos diferentes de registros DNS disponveis. A lista a seguir no pretende, de maneira alguma, ser extensa ou exaustiva, mas antes
2/9 www.unitednerds.org/thefallen/docs/?area=DNS&tuto=SlackwareShow
mostrar os mais comuns que vai encontrar por ai.
A - Address; especifica um endereo IP direto
AAAA - Address IPv6; especifica um endereo IPv6
NS - NameServer; especifica servidores DNS para o domnio ou subdomnio
CNAME - Canonical NAME; um apelido para outro hostname
MX - Mail eXchanger; o servidor de email
PTR - PoinTeR; aponta o hostname/domnio reverso a partir de um endereo IP
SOA - Start Of Authority; indica o responsvel por respostas autoritativas por um domnio
TXT - TeXT; permite incluir um texto curto em um hostname; usado para implementar o SPF
SRV - SeRVice; permite definir servios disponveis em um domnio
Estes so 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 comea
O SOA ou Start Of Authority indica o servidor e administrador responsvel por um domnio, alm de indicar outras informaes teis, como nmero
serial da zona DNS, tempo de vida do registro SOA, intervalo de replicao 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 memria do seu DNS
3 - tipo de registro
4 - DNS responsvel pela zona
5 - email do responsvel pelo DNS acima
6 - nmero serial da zona; recomenda-se o formato YYYYMMDDxx (ano com 4 dgitos, ms, dia e quantidade de alteraes 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 replicao
9 - TTL do SOA
10 - tempo mnino que a zona deve ser retida em memria
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 domnio dominio.com.br):
. IN MX 10 mail.dominio.com.br
. IN MX 50 mail2.dominio.com.br
O "." se refere ao domnio imediatamente superior, ou seja, a zona atual (no se trata de um subdomnio). O nmero define a preferncia do MX. Quanto
menor o nmero, maior sua preferncia 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 endereos IP. Embora esses
tipos de registros possam funcionar, no esto de acordo com as definies de melhores prticas de DNS publicadas em RFCs, e iro causar dores de
cabea ao administrador responsvel, uma vez que haver atrasos e falhas de entrega de email para seu domnio.
J os registros PTR devem estar colocados debaixo de uma zona especfica chamada "in-addr.arpa". Vamos considerar essa zona especial mais adiante.
O registro PTR deve ser colocado com os octetos do endereo IP invertidos, e o hostname indicado PRECISA existir e apontar para o mesmo endereo
IP. Por exemplo, se tivermos o endereo 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 vlido 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
No boa idia ter mltiplos destinos para um mesmo PTR, embora isso seja permitido. Tal comportamento pode causar confuso nas aplicaes
tentando consultar essa informao.
3.3. O Annimo: SRV
Registros SRV definem localizaes de servios 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.
3/9 www.unitednerds.org/thefallen/docs/?area=DNS&tuto=SlackwareShow
O servio 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 servio, com prioridades e portas no-convencionais.
Os servios que usam registros SRV mais conhecidos so o protocolo SIP de telefonia IP, o protocolo Jabber de Instant Messaging e, segundo dizem as
ms lnguas, 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 hierrquica. Isso facilita que cada corporao ou entidade cuide de maneira autnoma de seu
prprio 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 corporaes ainda faam isso, talvez por desconhecerem o manuseio correto do DNS, sempre h atrasos e
longas esperas para alteraes to simples. Aguardar 2 dias (sem receber emails) uma mudana 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 no concluiu seu chamado no uma
situao 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 no tem a informao que precisa, ele
pergunta ao seu amigo do lado pra ver se ele tem. Esse amigo pode dizer "olha, EU no 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 informao.
4.1. Hierarquia e Delegao
Como pudemos perceber no exemplo acima, vamos sempre consultar um amigo do lado pra ver se ele tem a informao que queremos ou se sabe nos
dizer quem tem. Forma-se uma hierarquia ou seqencia de consultas a serem feitas at chegarmos no objetivo final.
Um primeiro conceito a respeito da hierarquia que tudo comea no ".". O "domnio" 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 so os Root Servers/Servidores Raiz. Eles contem a zona DNS do "." da Internet,
que diz pra onde vo todas as consultas DNS das zonas "filhas" do ".".
Para delegarmos um subdomnio, 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, colocaramos 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 informaes 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
(...)
4/9 www.unitednerds.org/thefallen/docs/?area=DNS&tuto=SlackwareShow
Esses registros, que no fazem parte da zona que estamos consultando diretamente, so chamados de Glue Records, ou registros de "cola". Eles fazem
com que a informao e o caminho de pesquisa fique coeso no DNS. Imagine que eles no tivessem essa informao. Como descobriramos quem o
a.dns.br?
4.3. O arquivo de Dicas/Hints
O arquivo de "hints" do seu DNS diz a ele o endereo dos Root Servers na Internet, para que ele possa fazer a pesquisa inicial dos dominios. sempre
uma boa idia atualizar seu arquivo de Hints. Ele est disponvel em ftp://ftp.internic.net/domain/named.root
Uma otimizao 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 no 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 memria.
4.4. Recurso
Imagine esta situao: voc pergunta a um amigo seu "sabe aonde est o Joo?" 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 informaes estivesse um
pouco mais disposto, ele teria lhe respondido da primeira vez "est na casa do Pedro, ali na Rua Endereo IP, nmero 200.200.200.200"
Transportando isto para nossa situao 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 domnio 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 no faz parte de meu domnio
recurs.com.br, meu DNS estaria desobrigado a resolv-lo tambm, j que isto tarefa sua e no dele. Com a recurso habilitada, o prprio DNS que
resolve o www.recurs.com.br j lhe mandaria junto na MESMA resposta de DNS o endereo IP de www.recursivecorp.com, evitando que voc tivesse
que fazer uma segunda consulta DNS.
Parece bom, no ? Agora imagine se eu fizesse uma consulta em que o resultado passaria por inmeros CNAMEs/apelidos, pulando de um domnio para
o outro. Consegue imaginar o trfego intil que eu estaria causando em meu servidor DNS?
Recurso um recurso excelente, mas que deve ser usado com cautela em servidores expostos na Internet.
4.5. Cache e TTL
Notou os nmeros que aparecem ali ao lado dos registros de NS e A dos servidores de nome .br? Eles so os TTL's (Time to Live) ou tempo de vida
que aquele registro vlido aps uma consulta, e que pode ser armazenado em cache. Uma vez que o servidor que voc consulta resolva um nome, ele
guarda essa informao 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 pgina 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 trfego de DNS por padro tem prioridade sobre os outros. Teramos um desperdcio de recursos, no
concorda? Tente imaginar agora 50 navegadores abrindo essa pgina simultaneamente. Muito provavelmente algumas requisies DNS sero perdidas
em timeouts devido ao trfego intenso. Se eu disser que meu registro www.dominio.com.br valido por, digamos, 1 hora ou 1 dia, enquanto esse tempo
no expirar, quem j me perguntou isso no me perguntar mais.
Ento quanto mais alto o TTL, melhor n? At certo ponto sim. TTLs altos dificultam a mudana (s vezes emergencial) de hostnames e IPs. Algo muito
comum de acontecer fazer alterao de servidores de email e ficar dias sem receber email das empresas parceiras, fornecedoras ou clientes. Como so
pessoas que esto sempre em contato com voc, muito provavelmente esto com seus registros DNS em cache nos respectivos servidores de nomes.
Valores ideais mudam de situao para situao, de caso para caso; uma corporao 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
5/9 www.unitednerds.org/thefallen/docs/?area=DNS&tuto=SlackwareShow
;; 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 seqencia: 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 funes especiais dentro da hierarquia de DNS alm das consultas "diretas": a pesquisa de reversos e as transferncias de zona.
5.1. in-addr.arpa
Esta zona especial define os reversos. Normalmente, as delegaes 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 no se pode delegar todo esse range? Quando se precisa de intervalos menores? A comeam as dores de cabea 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
delegao.
5.1.1. Delegaes bizarras de reverso: como lidar com isso
As melhores prticas 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 servio, por exemplo,
preferem que voc crie uma zona com algum nome esquisito, como esses, e eles fazem transferncia para o servidor deles e incorporam na zona DNS da
sub-rede, ao invs de lhe delegar isso.
5.2. Transferncia/Sincronia de zonas: o AXFR/IXFR
Entre 2 DNS, podem haver zonas sincronizadas, um DNS sendo o Master que contm a zona original, e os outros seus slaves, que contm cpias da
zona original. Para manterem-se sincronizados automagicamente, eles usam essa "consulta" especial, o AXFR (transferncia "full" ou integral da zona) ou
IXFR (transferncia incremental, ou apenas alteraes, da zona). Ambos acontecem via TCP ao invs de UDP como o normal de DNS.
Permitir Zone Transfers para qualquer um que se interesse por seu DNS no uma idia muito boa. Entregar "de bandeja" a algum malicioso a
6/9 www.unitednerds.org/thefallen/docs/?area=DNS&tuto=SlackwareShow
localizao de todos os seus servidores e estaes no exatamente a coisa mais inteligente de sua vida :)
A melhor prtica limitar as transfers aos DNS slave, e, se a parania for um pouquinho mais longe, apenas permitir essas transferncias com assinaturas
digitas de DNS, para garantir que apenas o servidor DNS e ningum mais que possa estar mascarado no mesmo IP consiga a transferncia.
Se quiser testar transferncias 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) so zonas DNS especiais usadas para publicar listas negras de
endereos IPs em Tempo Real. Durante muito tempo foram nossa nica arma contra sistemas mal-configurados (os Open Relays) ou contra spammers. A
tcnica consiste em, de alguma forma, consultar uma lista que diz se o endereo IP pode ou no acessar o servio.
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 endereo 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 endereo 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 mltiplas definies para um mesmo registro DNS. A cada resposta do DNS, ele muda a ordem dos registros apresentados, fazendo com
que as aplicaes acessem, de maneira aleatria, 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 padro
tentar o de nmero menor, se falhar, o imediatamente acima dele, e assim por diante. Quando todos tem a mesma prioridade, eles tero a carga dividida
entre si. Pode acontecer de TODOS os hosts que se conectam resolverem usar o mx1 e ignorarem os outros, mas a tendncia 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 servios
Para balancear demais servios, como WWW e outros, basta adicionar vrios destinos dentro do host a ser balanceado. Ainda no exemplo do
hotmail.com, cada MX tem em sua definio, outro balano 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 definies de endereos 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 so o BIND e o DJBDNS. Ambos tem seus pontos
fortes e fracos, e acaba mais ficando uma questo de preferncia pessoal e necessidades especficas do que caractersticas intrinsecamente tcnicas. Tem
tambm 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 verso 9.3.1, ao passo que o DJBDNS desenvolvido por
7/9 www.unitednerds.org/thefallen/docs/?area=DNS&tuto=SlackwareShow
Daniel J. Bernstein (http://cr.yp.to/djbdns.html)
8.1. Ferramentas teis
Existem diversas ferramentas que so aquela aspirina na hora da dor de cabea 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 prticas e aponta
especificaes a seguir.
rbldnsd - um servidor de zonas RBL bastante robusto e funcional, com suporte a mltiplas 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 domnio grupogeo.com.br tem suas requisies 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 difceis
O dig merece um carinho todo especial. Ele o amigo das horas difceis, o super-heri que voc chama quando o arqui-vilo ataca seus pobres registros
DNS ou quando voc tem um chefe bastante insatisfeito que no consegue enviar emails pro fulano, porque um estpido configurou errado o DNS dele e
voc tem que provar que o erro est do outro lado, e no 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.
Tambm com ele que voc descobre se aquela sua migrao de servidor de email vai ser problemtica ou no, s por ver o TTL do registro MX.
Enfim, conhea-o! Vale gastar alguns minutos lendo a man page desse utilitrio fantstico!
9. Dicas e truques com o BIND
Neste ponto eu gostaria de apresentar algumas funes do BIND que me tem sido bastante teis durante minha convivncia com ele. Abaixo esto
alistados os melhores truques dele.
9.1. Macros
O BIND vem com diversas macros pra facilitar a manuteno das zonas. A mais conhecidas so 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 configurao das zonas, pra no 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 ao 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
informaes 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
informaes 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 no necessita de Views) junto com o dominio "dominio.com.br", eu obrigatoriamente teria
que coloc-la em ambas as Views tambm (se a quisesse publicada para ambas as origens).
Isto bastante til quando voc tem informaes na zona de sua empresa que no quer ver publicada para fora da empresa, ou para que seus usurios
acessem o servidor WWW direto na rede interna/DMZ sem ter que passar pelo firewall/proxy.
Um exemplo:
8/9 www.unitednerds.org/thefallen/docs/?area=DNS&tuto=SlackwareShow
# 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 autenticao
Podemos criar chaves de assinatura dentro do BIND para identificar servidores entre si, para autorizar um zone transfer ou uma atualizao dinmica de
DNS. Essas chaves so 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 especficos ou que gere estatsticas 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;
9/9 www.unitednerds.org/thefallen/docs/?area=DNS&tuto=SlackwareShow
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;
};
10. Bibliografia
BIND v9 Administrator Reference Manual (pdf disponvel no site do ISC)
http://en.wikipedia.org/wiki/Dns
A menos que especificado de outra maneira, todos os documentos e textos sao protegidos sob licenca BSD - Veja a licenca para mais detalhes
Leia tambem sobre o motivo de uso de licencas em documentacao.