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:
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.