Entendendo ethernet
Pré-visualização34 páginas
de
O serviço de nomes 118
ED. CAMPUS \u2014 MELHORES PRÁTICAS PARA GERÊNCIA DE REDES DE COMPUTADORES \u2014 0700 \u2013 CAPÍTULO 23 \u2014 3ª PROVA
ns.exemplo relacionada aos dados que foram configurados, o servidor que armaze-
nou informações na cache só perceberá após no máximo o TTL default ter decorri-
do. Por essa razão, não é interessante que o TTL default seja muito grande \u2013 de mais
de um dia, por exemplo.
No registro SOA configuramos:
\ufffd O número de série do arquivo: este número de série vale como um controle
de versão. Um servidor secundário só transfere os dados do servidor princi-
pal caso o número de série do arquivo no servidor principal seja maior que o
número de série em seu arquivo correspondente;
\ufffd Tempo de renovação (refresh): indica de quanto em quanto tempo o servi-
dor precisa se comunicar com o servidor principal em busca de atualizações.
Esse tempo só é realmente utilizado por servidores secundários;
\ufffd Tempo de tentar novamente (retry): é possível que o secundário não consi-
ga se comunicar com o servidor principal quando necessário. Assim, ele ten-
tará estabelecer comunicação novamente em busca de atualizações após o
tempo de retry configurado. Esse tempo também só é utilizado por servido-
res secundários;
\ufffd Tempo de expiração: caso o servidor secundário não consiga falar com o
principal por um tempo maior ou igual ao de expiração, o servidor secundá-
rio deixar de responder pelo domínio desatualizado. Mais uma vez, este é um
parâmetro usado apenas pelos servidores secundários;
\ufffd TTL mínimo: é o TTL default para as respostas negativas (quando o servidor
responde que o nome pesquisado não existe).
Esse cabeçalho repete-se em todos os arquivos de configuração do DNS, exceto
no named.root.
Depois do cabeçalho, damos informações sobre os servidores de nomes. Quem
são os servidores de nomes deste domínio (registros IN NS), seus endereços IP (re-
gistros IN A) e seus servidores de correio eletrônico (registros IN MX).
Enfim, chegou a hora de dizer quem são os filhos imediatos de exem-
plo.com.br. Isso é feito através de registros de endereço (IN A). A seguinte linha in-
dica que pc-2.exemplo.com.br corresponde ao endereço IP 192.168.1.2:
pc-2 IN A 192.168.1.2
Note que após cada máquina existe um registro de correio eletrônico (IN MX).
Esse registro indica quem é o servidor de correio eletrônico da máquina. Assim, se
quisermos enviar um e-mail para maria@pc-2.exemplo.com.br, ns.exemplo saberá
indicar quem é o servidor de correio eletrônico que deverá ser contatado. Veremos
mais detalhes sobre isso no Apêndice 11.
No fim do arquivo, configuramos dois subdomínios usando o registro IN NS.
Nesse caso, ns.exemplo está repassando a responsabilidade de responder sobre as zo-
119 Melhores Práticas para Gerência de Redes de Computadores
ED. CAMPUS \u2014 MELHORES PRÁTICAS PARA GERÊNCIA DE REDES DE COMPUTADORES \u2014 0700 \u2013 CAPÍTULO 23 \u2014 3ª PROVA
nas livros e cds para ns.livros.exemplo.com.br e ns.cds.exemplo.com.br, respectiva-
mente. Assim, quando ns.exemplo receber alguma pesquisa sobre máquinas do do-
mínio livros.exemplo.com.br e cds.exemplo.com.br, ele informará o endereço do
servidor de nomes que realmente possa responder as consultas em questão.
10.6 Como mapear IPs em nomes
No início deste apêndice, dissemos que o DNS é capaz de mapear nomes em IPs e vi-
ce-versa. Mas, até o momento, falamos apenas no mapeamento nome \ufffd IP, que
chamamos mapeamento direto. E o mapeamento reverso, como é feito?
Para realizar essa tarefa, o domínio in-addr.arpa foi criado no espaço de nomes
de domínio. Abaixo desse domínio, os números são os rótulos dos nós da árvore.
Esse domínio é amplo o bastante para abrigar todos os endereços IPs da Internet.
Veja uma ilustração na Figura A10-4.
FIGURA A10-4: O domínio in-addr.arpa.
As raízes guardam informações sobre servidores que podem responder a ende-
reços IP existentes. Assim, as pesquisas são realizadas de forma semelhante às pes-
quisas diretas, no entanto, a raiz já indica um servidor que tenha autoridade para
O serviço de nomes 120
ED. CAMPUS \u2014 MELHORES PRÁTICAS PARA GERÊNCIA DE REDES DE COMPUTADORES \u2014 0700 \u2013 CAPÍTULO 23 \u2014 1ª PROVA
responder sobre o endereço consultado. Em outras palavras, a raiz sabe informa-
ções sobre o que está abaixo de in-addr.arpa, apesar de não serem seus filhos ime-
diatos. Para descobrir o nome correspondente a 200.168.1.80 pergunta-se à raiz
quem é 80.1.168.200.in-addr.arpa? A raiz diz que não sabe, mas sabe quem respon-
de por 1.168.200.in-addr.arpa. Esse servidor é, então, consultado e retorna a res-
posta correta: www.exemplo.com.br.
Quando um servidor recebe uma consulta de mapeamento reverso, ele busca
por informações configuradas através do registro IN PTR. No BIND um outro arqui-
vo, que costumamos chamar named.rev, traz informações para realização de mape-
amento reverso. Veja na Figura A10-5 um exemplo deste arquivo.
;; Arquivo de configuração do mapeamento reverso de exemplo.com.br
$TTL 43200
@ IN SOA ns.exemplo.com.br. root.exemplo.com.br. (
200201231 ; Serial
8h ; Refresh - 8H
2h ; Retry - 2H
2w ; Expire - 2 Sem.
2h) ; Minimum TTL - 2H
IN NS ns.exemplo.com.br.
1 IN PTR pc-1.exemplo.com.br.
2 IN PTR pc-2.exemplo.com.br.
3 IN PTR pc-3.exemplo.com.br.
4 IN PTR pc-4.exemplo.com.br.
5 IN PTR pc-5.exemplo.com.br.
25 IN PTR mail.exemplo.com.br.
53 IN PTR ns.exemplo.com.br.
54 IN PTR ns2.exemplo.com.br.
80 IN PTR www.exemplo.com.br.
FIGURA A10-5: Exemplo de arquivo de configuração de mapeamento reverso.
10.7 O arquivo de configurações gerais
Além dos arquivos de configuração já mencionados, na implementação BIND exis-
te um arquivo de configuração geral do servidor de nomes. Este arquivo é o /etc/na-
med.conf. No named.conf, dentre outras informações, dizemos as zonas (ou domí-
121 Melhores Práticas para Gerência de Redes de Computadores
ED. CAMPUS \u2014 MELHORES PRÁTICAS PARA GERÊNCIA DE REDES DE COMPUTADORES \u2014 0700 \u2013 CAPÍTULO 23 \u2014 3ª PROVA
nios) sobre as quais o servidor de nomes tem autoridade para responder. Nesse ar-
quivo, ligamos os domínios aos arquivos de configuração. Veja na Figura A10-6 um
exemplo desse arquivo.
#Arquivo de configuração de ns.exemplo.com.br
options {
directory \u201c/var/named\u201d;
pid-file \u201c/var/named/named.pid\u201d;
};
zone \u201c.\u201d {
type hint;
file \u201cnamed.ca\u201d;
};
zone \u201cexemplo.com.br\u201d{
type master;
file \u201cnamed.zone\u201d;
};
zone \u201c1.168.192.in-addr.arpa\u201d{
type master;
file \u201cnamed.rev\u201d;
};
zone \u201c0.0.127.in-addr.arpa\u201d{
type master;
file \u201cnamed.local\u201d;
};
FIGURA A10-6: O arquivo named.conf - exemplo simples.
Esse arquivo diz exatamente que domínios são representados pelo servidor de
nomes e onde estão os arquivos de configuração de cada um deles. Existem muitas
outras configurações de mais alto nível. Para mais informações, veja [DNS&BIND].
10.8 Dicas de segurança
O serviço de nomes é um dos mais importantes. Quando ele não está fun-
cionando, muitos outros serviços também ficam indisponíveis, pois são
acessados através do nome do servidor. Você precisa dedicar um pouco
mais de atenção aos servidores DNS de sua organização para que a probabilidade de
uma interrupção desse serviço seja bem pequena.
A primeira dica é: acompanhe sempre as novidades sobre a implementação de
seu servidor de nomes. Quando surgirem atualizações, faça-as o mais rapidamente
O serviço de nomes 122
ED. CAMPUS \u2014 MELHORES PRÁTICAS PARA GERÊNCIA DE REDES DE COMPUTADORES \u2014 0700 \u2013 CAPÍTULO 23 \u2014 3ª PROVA
possível. Procure se inscrever em listas de segurança relacionadas à sua implemen-
tação DNS. Se seu servidor DNS é uma implementação BIND, por exemplo, inscre-
va-se na lista de segurança do BIND em http://www.isc.org/services/public/lists/bind-
lists.html