1. Por Eduardo Scarpellini
odraude@usa.com
Capitulo 4: DNS (BIND)
4.1 do HOSTS.TXT ao DNS
Na década de 70, a ARPAnet era uma pequena rede de algumas centenas de computadores.
Um único arquivo, chamado HOSTS.TXT, continha todas as informações necessárias sobre
estes hosts. Deste arquivo derivou-se o conhecido /etc/hosts.
A manutenção do HOSTS.TXT era feita pelo Network Information Center (NIC), que
‘compilava’ um novo arquivo uma ou duas vezes por semana e distribuída para todas as
maquinas conectadas a rede.
Com o crescimento da ARPAnet esse esquema se tornou impraticável.
A tabela de hosts cresceu muito e isso acarretou problemas como trafego, carga do servidor,
colisões de nomes e consistência da base de dados.
Os administradores da ARPAnet, então, começaram a buscar de um sucessor para o
HOSTS.TXT. O novo sistema poderia permitir um administrador de dados local e, ainda,
tornar os dados disponíveis globalmente.
A descentralização da administração pretendia eliminar o gargalo em um único host e
aliviar o problema de tráfego, manter os dados atualizados com muito mais facilidade e
garantir a unicidade dos nomes utilizando uma tabela hierárquica.
Paul Mockapetris, do USC's, foi responsável pelo desenho da arquitetura do novo sistema.
Em 1984, ele escreveu as RFCs 882 e 883, nas quais descrevia o 'Domain Name System'.
Estas RFCs foram substituídas pelas RFCs 1034 e 1035, que são as espeficicacões atuais.
Estas também foram incrementada por outras, descrevendo potenciais problemas de DNS,
problemas de implementação, mecanismos para atualização dinâmica de servidores de
nome e segurança de zonas e mais.
4.2 O DNS
O DNS é uma base de dados distribuída que permite o controle local dos segmentos de todo
o banco de dados.
Esses dados podem ser replicados ou cacheados, gerando maior robustez e performance.
Os servidores de nomes contem informações sobre alguns seguimentos da base-de-dados e
colocam isso a disposição dos clientes, chamados resolvers.
Resolvers são simplesmente algumas bibliotecas de rotinas que fazem perguntas e enviam
pela rede para um servidor de nomes.
A estrutura de uma base-de-dados de DNS é muito similar a estrutura de um sistema de
arquivos UNIX..
Toda a base de dados pode ser retratado como uma árvore invertida. com o nodo raiz no
topo.
Cada nodo na arvore tem um rótulo, identificando uma relação com seus pais e é, também,
raiz de todas arvores de uma sub-arvore que vem abaixo.
No DNS, o nome de domínio é a seqüência de rótulos de nodos partindo da raiz do domínio
para a raiz da arvore, separados por pontos (.)

2. No sistema de arquivos UNIX, temos o 'absolute pathname' que é a lista de nomes relativos
de um diretório partindo da raiz para os galhos (inverso ao DNS).
No DNS, cada domínio pode ser quebrado em varios subdomínios, e a responsabilidade por
esses subdomínios pode ser delegada a diferentes organizações.
Por exemplo, InterNIC tem autoridade sobre o domínio .com (comercial), mas delega a
responsabilidade sobre o domínio google.com a organização GOOGLE.
Assim GOOGLE tem a autonomia administrativa sobre esse espaço. A zona google.com é
agora independente de .com e contém todos nomes que terminam em google.com.
A zona .com contem somente os domínios que terminam em .com, mas não faz parte das
zonas delegadas como google.com
Da mesma maneira a zona .br foi delegada a FAPESP e abaixo desta pode existir zonas
como .com, .edu, .net, etc
Um exemplo com: google.com, amazon.com, hacker.net, berkeley.edu, fatectq.com.br
.
+ -- com
| + -- google
| + -- amazon
+ -- net
| + -- hacker
+ -- edu
| + -- berkeley
+ -- br
+ -- com
+ -- fatectq
4.3 BIND (Berkeley Internet Name Domain)
Para configurar nosso servidor de nomes, tomaremos como exemplo:
Zona: howto.com.br
Rede: 192.168.2.0
Netmask: 255.255.255.0
Os arquivos de configuração do BIND, por padrão ficam armazenados em /etc/namedb/.
Editando o arquivo named.conf veremos uma zona “.” do tipo hint fazendo referencia ao
arquivo named.root. Este arquivo contém informações sobre os RootServers com os quais
vamos nos conectar para eventuais pesquisas sobre domínios e, conseqüentemente, caching
de nomes.
Para nosso servidor responder pela nova zona (“howto.com.br”) devemos adicionar as
seguintes linhas ao final do arquivo named.conf:

3. &#!¢¢¨¦¤¢
% $ ¡ ¡ ¡ © § ¥ £ ¡
554220)¢
6 ¥ 3 1 ¥ ( '
6E$)¥¦£¤¡¢ D5#¢C¢¡¢)¦BA¥ @47
C ¡ ¡ © § 9 8
6 F
Note que temos um “type master”, isso especifica que temos autoridade sobre a zona.
A opção “file” referencia um arquivo de configuração para essa zona.
Para a configuração de zona reversa, utilizamos:
dc25aS2@X2¦!I@¦!S@¢!IG¢¤¦
% $ W b ` W ` Y Y W C V U H T P R Q P H § ¥ £ ¡
554220)' e
6 ¥ 3 1 ¥ (
dEqihDS¦¦!S¦¦A¥ @8 f
6 $ p ¥ g R Q P H T P § 9
6 F
Note que o nome da zona é nossa rede ao inverso: 192.168.2.0 2.168.192
Caso você possua outra netmask e não seja proprietário da rede toda, utilize:
sX25uI2@X2¦!S¦¦!t¦¢!Ss¤¢¤BG¢¤¦
% $ W b ` W ` Y Y W C V U H T P R Q P H r Q C g § ¥ £ ¡
No exemplo acima temos a rede 192.168.2.0 com netmask 255.255.255.192, portanto IPs
de 1 a 63.
É necessário que criemos o arquivo “howto-com-br.zone” que armazenará as configurações
da zona “howto.com.br”
Eis um exemplo:
E@e v
w e @r
g g Q
x V ¦U #!¢¢qƒ4¦X‚5)!¦¢D¦q©
¡ ¡ ¡ © ¡ ¡ ¡ ¡ ¡ qy
W € „
9 1 8 5¦†6
¥ y 2@B¦#¦@¦H
P g g r r g … g g
@4c 7 ¦†6
© 3 ¥ ¥ ` @r
g g Q
XE¦‡6
' ¥ ` ¦@¦P
g g … …
¥ 8 )B‡ˆ¦@¦@r
i (  ‰ 6 g g g g g Q
) 8 £ 8 ”6
• “ ’¦@r
‘ g g g Q
x V ¦U y @V !S—t@¦!–4¦P
P H R Q P H T
x V¦U ˜ “ ##¦—¦B! @8 2
¡ ¡ ¡ © 9 1 g P
x V¦U W !It@¢!I4¢P
P H R Q P H T
¢¦
™ 3 V¦U W !It@¢!I4¢P
H H R Q P H T
™¦¥¤¢£ 1 V¦U W !It@¢!I4¢P
P H R Q P H T
@¦
V¦U W 5#!ƒ¦¢ƒ¢!t¢¦
¡ ¡ ¡ © ™ 3
( 2 7 V¦U W !It@¢!I4¢P
H H R Q P H T
@8 4
9 1 V¦U W cIt@¢!I4¢P
d H R Q P H T
No exemplo acima temos:
$TTL: time to live
@ IN SOA: inicio da configuracao da zona “howto.com.br”. root.howto.com.br é o
proprietário da zona.
2004033001 ;Serial: Esse é o numero serial da nossa zona. Com base nesse numero os
servidores de nomes “sabem” se seu cachê esta atualizado ou não. A cada mudança na
configuracao de zona esse serial deve ser modificado. Por padrão usamos a data da ultima
modificação + numero da modificação. 01-30/03/2004 nesse exemplo.
3600 ; Refresh: É o tempo (em segundos) no qual os servidores secundários se baseiam
para perguntar ao servidor primário se as configurações de zona sofreram modificações.

4. 14400 ; Retry: Tempo de espera para uma nova tentativa de sincronização de
configuracao de zonas.
3600000 ; Expire: É o tempo para a configuração da zona expirar e uma nova
sincronização dos dados ser forçada.
36000 ) ; Minimum: É o valor mínimo padrão para o $TTL, ou seja, é o tempo mínimo de
vida de uma conexão. Esse valor é utilizado caso você não coloque um valor para $TTL.
@ IN NS 192.168.2.1: A entrada NS em IN referencia um servidor de nomes
para essa zona, 192.168.2.1 é a maquina que estará rodando o BIND.
@ IN MX 10 mail.howto.com.br. : A entrada MX (mail
exchanger) em IN referencia um servidor de email. Essa entrada exige um numero que
indica sua prioridade, em caso de mais de um servidor em nossas zonas. Quanto menor o
numero, maior a prioridade (10 no nosso caso). Note que a entrada MX aponta para
“mail.howto.com.br” seguida de um ponto (.). Esse ponto deve existir sempre que
especificarmos um nome ao invés de um IP. Um entrada IN A deverá existir para o
subdomínio “mail”.
@ IN A 192.168.2.1: Entradas IN A definem subdomínios/host.
Neste caso temos o IP respondendo por “howto.com.br” (sem subdomínio) já que o
primeiro campo (@) não foi preenchido.
bsd IN A 192.168.2.2: Nesta linha estamos apontando o subdominio
“bsd” (bsd.howto.com.br) para o IP 192.168.2.2.
named IN A 192.168.2.2: Subdomínio “named” apontando para
192.168.2.1, que é nosso servidor de nomes.
www IN A bsd.howto.com.br. : Aqui temos um subdominio “www” como um
alias para bsd.howto.com.br (note o ponto no final), portanto que respondera pelo
www.howto.com.br será o IP 192.168.2.2.
ftp IN A 192.168.2.2: Subdomínio “ftp” apontando para 192.168.2.2.
Poderíamos ter usado IN A bsd.howto.com.br, como em “www”
mail IN A 192.168.2.5: Uma entrada declarando o subdominio “mail”
que esta sendo apontado para o IP 192.168.2.5. Esta entrada vai ser usada pela IN MX.
Nossa zona “howto.com.br” está configurada, agora podemos configurar a zona reversa
para 192.168.2.0.
Para isso criamos o arquivo 192.168.2.rev.

5. Eis um exemplo:
E@e v
w e @r
g g Q
x V ¦U #!¢¢qƒ4¦X‚5)!¦¢D¦q©
¡ ¡ ¡ © ¡ ¡ ¡ ¡ ¡ qy
W € „
9 1 8 5¦†6
¥ y 2@B¦#¦@¦H
P g g r r g … g g
@4c 7 ¦†6
© 3 ¥ ¥ ` @r
g g Q
XE¦‡6
' ¥ ` ¦@¦P
g g … …
¥ 8 )B‡ˆ¦@¦@r
i (  ‰ 6 g g g g g Q
) 8 £ 8 ”6
• “ ’¦@r
‘ g g g Q
x V ¦U y @V !S—t@¦!–4¦P
P H R Q P H T
P V¦U ` e b #!¦¦)q!t¦2¢£
¡ ¡ ¡ © ™ ¥ 1
H V¦U ` e b 5#!ƒ¦¢ƒ¢!t¢¦
¡ ¡ ¡ © ™ 3
d V¦U ` e b 5#!¢¢) ¦8 4
¡ ¡ ¡ © 9 1
A entrada IN SOA é idêntica ao arquivo de configuração de zona.
Aqui a grande diferença é que não usamos entrada A, e sim PTR, além de mudança da
ordem dos campos.
Agora temos: numero-ip IN PTR nome.zona
Primeiro elegemos um servidor de nomes, que no caso é nossa própria máquina.
@ IN NS 192.168.2.1
1 IN PTR named.howto.com.br.: Nesse caso estamos relacionando o IP
1 (192.168.2.1) ao subdominio named.howto.com.br.
As outras entradas são praticamente idênticas a do IP 1, mudando apenas o IP e seu nome.
Assim nosso servidor de nomes será capaz de identificar o nome de cada endereço da rede,
fazendo o reverso da resolução de nomes.
Note que nesse arquivo é comum adicionarmos apenas entradas para os nomes reais de
cada máquina, então nosso IP 2 (192.168.2.2) fica apenas com o nome “bsd”, descartando,
assim, “www” e “ftp” que referenciam este mesmo endereço.
Nossa configuração parece estar ok. Para iniciarmos o BIND utilizamos o comando
“named” que pode ser utilizado a seguinte forma:
e
™ ¢£ 8 h2£ 8 ’¦¦¤£
• f ™ g f ™ ¥ 1
Deste modo o processo terá como owner o usuário “bind” (grupo “bind”), tornando sua
execução mais segura.
Para verificar a execução do BIND verifique se sua maquina esta atendendo a porta 53
(netstat –na)
Configure seu /etc/resolv.conf para usar o IP do seu servidor de nomes :
!S—t@¦I4¦‚#)i5¦@2¢¢£
P H R Q P H T P ¥ p ¥ 3 ¥ 1
Para testar sua configuração utilize o comando “nslookup”, que deverá retornar algo
parecido com:
#!¦¦)q!t¦2¢l#5)j¦¨ 9 21 7 @Y
¡ ¡ ¡ © ™ ¥ 1 £ k ¥ p ¥ y • ¥
St@¢S4¦mS@¦iE@)W
P H R Q P H T P k 3 3 ¥ ™ ™
Para testar a resolução de nomes, digitamos um host (completo) no prompt:

6. Serial)
OK. Senão analise seus logs e verifique as zonas que apresentam problemas (com base no
Se você obteve respostas parecidas ao utilizar o nslookup, suas configurações de zona estão
dXSt@¢S4¦mS@¦iE@)W
H R Q P H T P k 3 3 ¥ ™ ™
¡ ¡ ¡ © 9 1
!¢¢—¢ @8 @ k ¥ 1
t¤¢¢V
P H R P H T P k 3 3 ¥ ™ ™
St@Q¢S4¦mS@¦iE@)W
¦ƒ¦)¡t™¦¤¢p5)j5¢y
¡ ¡ © ¥ 1 £ k ¥ p ¥
d H R Q P H T
cS—t@¦!–4¦P n
Para fazer o reverso de nomes digitamos um IP no prompt:
Note que o nslookup mostra “www.howto.com.br” como um alias para “bsd.howto.com.br”
!¢¢—¢r@@qS421 @9 W
¡ ¡ ¡ © k 3 ¥ 3 8
H H R Q P H T P k 3 3 ¥ ™ ™
St@¢S4¦mS@¦iE@)W
#!¦ƒ¦q!ƒ¢¢
¡ ¡ ¡ © ™ 3 k ¥ 1
t¤¢¢V
3 £ 1 ¥ 1 ¡ © • 1 C £ ¡
k55¥i¦2h)p 8 @@ 8 d2¢@4¤V
P H R Q P H T P k 3 3 ¥ ™ ™
St@¢S4¦mS@¦iE@)W
¦ƒ¡¦)t¦¤¢p5)j5¢y
¡ ¡ © ™ ¥ 1 £ k ¥ p ¥
¡ ¡ ¡ ©
#!¢¢!o@@
n