Exibir código-fonte para Uma breve introdução à DNS

Uma breve introdução à DNS

Este texto foi retirado do site: http://www.unitednerds.org/thefallen/docs/?area=DNS&tuto=SlackwareShow

Deives Michellis "thefallen"
Revisão: $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 começa
3.2. Registros temperamentais: MX e PTR
3.3. O Anônimo: SRV
4. Estrutura de uma consulta
4.1. Hierarquia e Delegação
4.2. Root Servers e Glue record
4.3. O arquivo de Dicas/Hints
4.4. Recursão
4.5. Cache e TTL
4.6. Acompanhando uma consulta
5. Zonas DNS
5.1. in-addr.arpa
5.1.1. Delegações bizarras de reverso: como lidar com isso
5.2. Transferência/Sincronia de zonas: o AXFR/IXFR
6. RBLs
7. Balanceamento de carga via DNS
7.1. MX
7.2. Demais serviços
8. Servidores DNS mais conhecidos
8.1. Ferramentas úteis
8.2. dig, o amigo das horas difíceis
9. Dicas e truques com o BIND
9.1. Macros
9.2. ACLs
9.3. Views
9.4. Chaves de autenticação
9.5. Logs
10. Bibliografia

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;
  };

10. Bibliografia

BIND v9 Administrator Reference Manual (pdf disponível no site do ISC)
http://en.wikipedia.org/wiki/Dns

[[Category: TI]]