COMO FAZER DNS
Nicolai Langfeldt janl@math.uio.no
Traduzido e Revisado por Conectiva Informática,
info@conectiva.com.br, no dia 30 de Março de 1999.
v2.1.1, 12 de novembro de 1998
COMO FAZER para facilitar a vida do administrador do DNS.
______________________________________________________________________
Índice geral
1. Preâmbulo
1.1 Aspectos Legais
1.2 Créditos e Pedidos de Ajuda
1.3 Dedicatória
2. Introdução.
3. Um Servidor de Nomes Somente Para Cache.
3.1 Iniciando o named
4. Um Domínio
4.1 Mas primeiro um pouco de teoria
4.2 Nosso Próprio Domínio
4.3 A zona reversa
5. Um Exemplo de Domínio Real
5.1 /etc/named.conf (ou /var/named/named.conf)
5.2 /var/named/root.hints
5.3 /var/named/zone/127.0.0
5.4 /var/named/zone/land-5.com
5.5 /var/named/zone/206.6.177
6. Manutenção
7. Converter da versão 4 para versão 8
8. Perguntas e Respostas
9. Como tornar-se um administrador de DNS.
______________________________________________________________________
11.. PPrreeââmmbbuulloo
Palavras chaves: DNS, bind, bind-4, bind-8, servidor de nomes,
discagem, ppp, slip, isdn, Internet, domínio, nome de máquina,
máquinas, resolução, named.
11..11.. AAssppeeccttooss LLeeggaaiiss
(C)direitos autorais 1995 Nicolai Langfeldt. Não é permitido
modificar os direitos autorais. Pode ser distribuído livremente, desde
que seja preservada a indicação dos direitos autorais originais.
11..22.. CCrrééddiittooss ee PPeeddiiddooss ddee AAjjuuddaa
Gostaria de agradecer a Arnt Gulbrandsen, que leu o rascunho deste
trabalho inúmeras vezes e forneceu inúmeras sugestões úteis. Gostaria
de agradecer ainda às pessoas que têm mandado sugestões e notas via e-
mail.
Este nunca será um documento acabado dado à multiplicidade de detalhes
do assunto, então por favor envie-me mensagens descrevendo seus
problemas e seus sucessos e isto pode tornar este COMO FAZER melhor.
Ao enviar dinheiro, comentários e/ou perguntas, escreva para
janl@math.uio.no. Caso espere uma resposta, por favor seja cortês
_c_e_r_t_i_f_i_c_a_n_d_o_-_s_e que o endereço de retorno está correto e funcional.
Também, ppoorr ffaavvoorr leia a seção de ``Perguntas e Respostas'' antes de
enviar uma mensagem.
11..33.. DDeeddiiccaattóórriiaa
Este COMO FAZER é dedicado a Anne Line Norheim Langfeldt. Embora ela
provavelmente nunca o leia, pois afinal ela não é este tipo de garota.
22.. IInnttrroodduuççããoo..
OO qquuee éé ee oo qquuee nnããoo éé..
Para iniciantes, DNS é o Servidor de Nomes do Domínio. O DNS converte
os nomes das máquinas para números IP, que são os endereços das
máquinas, mapeando de nome para endereço e de endereço para nome. Este
COMO FAZER documenta como definir tais mapeamentos usando o sistema
Linux. Um mapeamento é simplesmente uma associação entre duas
informações, neste caso um nome de máquina, como ftp.linux.org, e o
número IP da máquina, como por exemplo 199.249.150.4.
DNS é, para os não iniciados (você), uma das áreas mais opacas da
administração de rede. Este COMO FAZER tentará clarificar alguns
conceitos e aspectos sobre este tema. Ele descreve como configurar um
nome do servidor DNS _s_i_m_p_l_e_s. Começando com um único servidor de cache
e seguindo até a configuração de um servidor primário DNS para um
domínio. Para configurações mais complexas pode-se checar a seção de
``Perguntas e Respostas'' deste documento. Caso não esteja lá
descrito, pode ser necessário _l_e_r a documentação que acompanha os
fontes. Esclareceremos em que consiste esta documentação no ``último
capítulo''.
Antes de começar, há que se configurar uma máquina para que ela possa
se conectar interna e externamente e assim permitir as conexões à
rede. Deve ser possível executar o comando telnet 127.0.0.1 e ter
acesso à máquina local (teste agora!). É necessário ainda ter-se
arquivos de exemplo /etc/nsswitch.conf (ou /etc/host.conf),
/etc/resolv.conf e /etc/hosts como ponto de partida, uma vez que não
explicaremos aqui a sua função. Caso ainda não se tenha tudo isso
configurado e operando, o documento NET-3 ou o COMO FAZER PPP explicam
como configurá-los.
Ao nos referirmos a 'máquina local', estamos referenciando à máquina
na qual se está tentando configurar o DNS e não a qualquer outra
máquina que se possa ter à disposição e que esteja conectada à rede.
Presumimos que esta máquina não está atrás de algum firewall que
bloqueie as pesquisas de nomes. Caso seja necessária alguma
configuração especial, por favor veja a seção de ``Perguntas e
Respostas''.
O serviço de nomes no Unix é feito por um programa servidor denominado
named. Ele é integrante do pacote de bind que é coordenado por Paul
Vixie para o Consórcio de Programas Para a Internet. O Servidor de
nomes está incluído na maioria das distribuições Linux e é usualmente
instalado como /usr/sbin/named. Caso se tenha um named à disposição
pode-se usá-lo; caso contrário é possível obter-se um binário a
partir de um site ftp Linux, ou conseguir os fontes mais recentes em
ftp.isc.org:/isc/bind/src/cur/bind-8/. Este COMO FAZER trata sobre o
bind em sua versão 8. A versão antiga do COMO FAZER, que tratava sobre
o bind 4, ainda está ainda disponível em
http://www.math.uio.no/~janl/DNS/ no caso de se necessitar utilizar o
bind 4. Caso a página do manual sobre o servidor de nomes fale sobre
named.conf então tem-se disponível o bind 8, caso mencione o
named.boot então trata-se do bind 4. Caso se tenha o 4 e se esteja
com problemas de segurança, deve-se atualizar para a versão 8 mais
recente.
O DNS é um banco de dados distribuído por toda a rede. É necessário
ter-se extremo cuidado com tudo o que for colocado nele. Ao se colocar
dados sem significado, outros utilizarão estes dados e certamente tudo
ficará um pouco "estranho". O DNS deve estar sempre atualizado e
arrumado, evitando-se assim problemas desagradáveis. Deve-se aprender
a usá-lo, administrá-lo, depurá-lo para tornar-se um bom administrador
da rede, evitando sobrecargas geradas por problemas de administração.
Neste documento são afirmadas categoricamente algumas coisas que não
são completamente verdadeiras (sendo então pelo menos meias verdades).
Tudo em nome da simplificação. As coisas (provavelmente!) funcionarão
quando o leitor acreditar no que está dito!
DDiiccaa:: Devem ser feitas cópias de segurança de todos os arquivos. É
aconselhável, ainda, que elas sejam alteradas de tempos em tempos.
Assim se depois de todas as tentativas, nada funcionar, pode-se
retornar à situação anterior.
33.. UUmm SSeerrvviiddoorr ddee NNoommeess SSoommeennttee PPaarraa CCaacchhee..
UUmmaa pprriimmeeiirraa aapprrooxxiimmaaççããoo àà ccoonnffiigguurraaççããoo ddoo DDNNSS,, qquuee ppooddee sseerr mmuuiittoo
úúttiill ppaarraa uussuuáárriiooss qquuee uuttiilliizzaamm lliinnhhaass ddiissccaaddaass..
Um servidor de nomes somente para cache deve ser capaz de encontrar as
respostas às pesquisas de nomes e endereços e deve ainda guardar as
respostas, para a próxima em que sejam necessárias. Isto diminuirá o
tempo de espera significativamente, especialmente quando se tem uma
conexão lenta.
Inicialmente é necessário ter-se um arquivo /etc/named.conf, o qual
será lido quando o servidor de nomes for inicializado. Por enquanto
ele pode conter simplesmente:
______________________________________________________________________
// Configuração do arquivo para um servidor de nomes somente para cache
options{
directory "/var/named";
// Não comentar isto pode ajudar caso se tenha um firewall presente
// e as coisas não estejam funcionando:
// endereço de pesquisa: porta 53;
};
zone "." {
type hint;
file "rott.hints ";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
______________________________________________________________________
A linha `directory' indica onde os arquivos devem estar localizados.
Todos os arquivos subseqüentes serão relativos a este. Assim pz é um
diretório sob /var/named, ou seja estará localizado em /var/named/pz.
/var/named é o diretório definido pelo _P_a_d_r_ã_o _d_e _S_i_s_t_e_m_a_s _d_e _A_r_q_u_i_v_o_s
_L_i_n_u_x.
O arquivo denominado /var/named/root.hints deve conter:
______________________________________________________________________
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
______________________________________________________________________
Este arquivo descreve o nome dos servidores raiz no mundo. Este
conteúdo pode mudar com o passar do tempo e _t_e_m _q_u_e ser atualizado
permanentemente. Veja a ``seção de manutenção'' para saber como
mantê-lo atualizado.
A próxima seção em named.conf é zone. Explicaremos o seu uso num
capítulo adiante. Por hora somente façamos deste um arquivo chamado
127.0.0 no subdiretório pz:
______________________________________________________________________
@ IN SOA ns.linux.bogus.hostmaster.linux.bogus. (
1 ; Serial
8H ; Atualização
2H ; Tentativas
1W ; Expiração
1D) ; TTL mínimo
NS ns.linux.bogus.
1 PTR localhost
______________________________________________________________________
Em seguida, será necessário um arquivo /etc/resolv.conf com o seguinte
conteúdo:
______________________________________________________________________
search subdomínio.seu\_domínio.edu.br seu\_domínio.edu.br
nome\_do\_servidor 127.0.0.1
______________________________________________________________________
A linha `search' especifica que o domínio deve ser pesquisado para
qualquer nome de máquina com a qual se queira conectar. A linha
`nameserver' especifica o endereço do servidor de nomes. Neste caso, a
própria máquina, uma vez que é nela que o programa named é executado
(já que 127.0.0.1 foi informado, não importando se a máquina tem
também outro endereço). Caso se queira indicar vários servidores de
nomes, deve-se criar uma linha `nameserver' para cada um deles. (Nota:
O programa named nunca lê este arquivo, e sim o resolvedor que
utilizar o named).
Vamos ilustrar um pouco mais a função deste arquivo: caso um cliente
tente procurar por itamaraca, então
itamaraca.subdomínio.seu_domínio.edu.br será a primeira tentativa,
então será tentado itamaraca.seu_domínio.edu.br e finalmente somente
itamaraca. Se um cliente tentar procurar metalab.unc.edu,
metalab.unc.edu.subdomínio.seu_domínio.edu.br será tentado
inicialmente (sim, não faz muito sentido, mas é o jeito que ele
funciona), então metalab.unc.edu.seu_domínio.edu.br, e finalmente
metalab.unc.edu. Caso se queira colocar muitos domínios na linha
search, isso pode provocar uma sobrecarga nos tempos de pesquisa.
O exemplo presume que a máquina pertence ao domínio
subdomínio.seu_domínio.edu.br, sendo provavelmente o servidor de nomes
nome_da_máquina.subdomínio.seu_domínio.edu.br. A linha de busca não
deve conter o TLD (Domínio Raiz `edu.br' neste caso). Caso seja
necessário conectar-se com freqüência a máquinas de outros domínios,
deve-se acrescentar aqueles domínios à linha de busca, como por
exemplo:
______________________________________________________________________
search subdomínio.seu_domínio.edu.br seu_domínio.edu.br outro_domínio.com.br
______________________________________________________________________
e assim por diante. Obviamente deve-se utilizar nomes reais de
domínios. Os aqui colocados servem somente como exemplos. Por favor
atente para a falta de pontos no final dos nomes dos domínios.
A seguir, dependendo da versão da biblioteca libc, tanto pode ser
necessário atualizar o /etc/nsswitch.conf ou o /etc/host.conf. Caso
se tenha o nsswitch.conf este será utilizado, caso contrário ,
atualizaremos o host.conf.
//eettcc//nnsssswwiittcchh..ccoonnff
Este é um arquivo longo que especifica onde podem ser obtidos
diferentes tipos de dados, de que arquivos e de qual base de dados.
Usualmente contém comentários úteis no topo, que podem ser lidos
agora. Depois disso, deve ser encontrada uma linha que comece com
`hosts:', onde se pode ler:
______________________________________________________________________
hosts: files dns
______________________________________________________________________
Caso não haja nenhuma linha iniciada com `hosts:' então deve ser
incluída a linha acima. Ela indica que os programas devem
primeiramente pesquisar o arquivo /etc/hosts, e após então verificar o
DNS de acordo com o configurado no arquivo resolv.conf.
//eettcc//hhoosstt..ccoonnff
Provavelmente contém várias linhas, uma delas deve começar com order e
deve ter o seguinte:
______________________________________________________________________
order hosts, bind
______________________________________________________________________
Se não houver nenhuma linha `order', então uma deve ser criada. Esta
linha indica que a resolução de nomes de máquinas deve pesquisar
inicialmente no arquivo /etc/hosts, e depois pesquisar junto ao
servidor de nomes (definido em resolv.conf como 127.0.0.1). Estes dois
últimos arquivos estão documentados na página de manual do utilitário
resolver(8) (para acessá-la execute man 8 resolv) na maioria das
distribuições Linux. Aquela página do manual é clara e em nossa
opinião, todos devem lê-la (especialmente os administradores de DNS).
Faça-o agora caso você seja um daqueles que diz para si mesmo: "Eu vou
ler mais tarde", mas nunca o faz.
33..11.. IInniicciiaannddoo oo nnaammeedd
Após tudo isto é hora de iniciar o servidor de nomes. Caso se esteja
usando uma conexão discada, primeiro deve-se estabelecer a conexão.
Deve-se digitar então `ndc start', sem opções. Caso isto não funcione,
pode-se tentar `/usr/sbin/ndc start'. Caso isto não funcione, deve-se
verificar a seção ``Perguntas e Respostas''. Agora é possível testar a
configuração. Ao se visualizar o arquivo de mensagens syslog
(usualmente chamado /var/adm/messages; podem ser examinados também o
diretório /var/log e o arquivo syslog) ao se iniciar o servidor de
nomes (executando-se tail -f/var/log/messages ) deve-se obter algo
como:
(linhas terminadas em \ continuam na linha seguinte)
Feb 15 01:26:17 roke named[6091]: starting. named 8.1.1 Sat Feb 14 \
00:18:20 MET 1998 ^Ijanl@roke.uio.no:/var/tmp/bind-8.1.1/src/bin/named
Feb 15 01:26:17 roke named[6091]: cache zone "" (IN) loaded (serial 0)
Feb 15 01:26:17 roke named[6091]: master zone "0.0.127.in-addr.arpa" \
(IN) loaded (serial 1)
Feb 15 01:26:17 roke named[6091]: listening [127.0.0.1].53 (lo)
Feb 15 01:26:17 roke named[6091]: listening [129.240.230.92].53 (ippp0)
Feb 15 01:26:17 roke named[6091]: Forwarding source address is [0.0.0.0].1040
Feb 15 01:26:17 roke named[6092]: Ready to answer queries.
Se houver alguma mensagem de erro, ela deve ser examinada. O named
indicará o arquivo onde o problema se encontra (ou named.conf. ou
root.hints, esperamos). O servidor de nomes deve ser finalizado e os
arquivos devem ser corrigidos.
Agora é hora de iniciar o nslookup para examinar o trabalho realizado
até aqui.
$ nslookup
default Server: localhost
Address: 127.0.0.1
>
Caso este seja o resultado obtido, parabéns, está funcionando.
Esperamos que sim. Caso se obtenha um resultado diferente, deve-se
retornar e verificar todos os passos. Cada vez que se altere o arquivo
named.conf será necessário reiniciar o servidor de nomes usando o
comando ndc restart.
Agora podemos fazer pesquisas no sistema. Podemos procurar por alguma
máquina próxima; A pat.uio.no está próxima a mim na Universidade de
Oslo:
> pat.uio.no
Server: localhost
Address: 127.0.0.1
Name: pat.uio.no
Address: 129.240.130.16
O nslookup agora perguntou ao seu servidor de nomes para procurar a
máquina pat.uio.no. Este contactou uma dos servidores de nomes
listados no arquivo root.hints , e perguntou a um deles qual o caminho
para a máquina desejada. Pode levar bem pouco tempo antes de se obter
o resultado, enquanto named procura todos os domínios definidos em
/etc/resolv.conf.
Ao se pesquisar novamente, tem-se:
> pat.uio.no
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: pat.uio.no
Address: 129.240.2.50
Note a linha `Non-authoritative answer:' que obtivemos desta vez. Isto
indica que o servidor de nomes não saiu pela rede para perguntar sobre
a máquina desejada. Ao invés disto procurou em seu cache e encontrou-o
lá. Mas a informação do cache _p_o_d_e estar desatualizada (antiga).
Então se está informado deste perigo (muito pequeno) quando o sistema
informa `resposta Não autorizada:'. Quando o nslookup disser isto pela
segunda vez para a mesma máquina, pode-se estar certo de que o cache
está funcionando e fornecendo a informação certa. Pode sair-se do
comando nslookup digitando-se `exit'.
Agora que sabemos como configurar um servidor de nomes de cache,
aproveite para tomar uma cerveja, leite, ou qualquer coisa que se
queira para comemorar este fato memorável.
44.. UUmm DDoommíínniioo SSiimmpplleess ..
CCoommoo ccoonnffiigguurraarr uumm ddoommíínniioo pprróópprriioo..
44..11.. MMaass pprriimmeeiirroo uumm ppoouuccoo ddee tteeoorriiaa
Antes de _r_e_a_l_m_e_n_t_e começarmos esta seção, forneceremos alguns
ensinamentos sobre o funcionamento do DNS; é preciso lê-los porque é
fundamental para um administrador de rede. Caso não se queira, deve-se
pelo menos pesquisá-los rapidamente, até chegar aonde se quer ir no
arquivo named.conf.
DNS é uma sistema hierárquico. O mais alto nível é representado por
`.' e denominado "raiz". Sob "." há diversos Domínios de Alto Nível
(TLDs), sendo os mais conhecidos ORG, COM, EDU e NET, mas existem
muitos mais.
Ao se procurar uma máquina, a pesquisa ocorre recursivamente dentro
da hierarquia, começando no topo. Caso se queira descobrir o endereço
de prep.ai.mit.edu, o servidor de nomes local tem que encontrar um
nome de servidor que responda pelo domínio edu. Ele pergunta a um
servidor . (ele já conhece os servidores ., a partir do arquivo
root.hints), e o servidor . fornecerá uma lista dos servidores do
domínio edu:
$ nslookup
Default Server: localhost
Address: 127.0.0.1
Começaremos perguntando por um servidor raiz:
> server c.root -servers.net.
Default Server: c.root -servers.net
Address: 192.33.4.12
A seguir definiremos o tipo de pesquisa que desejamos fazer. Neste
caso NS (registros de servidores de nomes):
> set q=ns
A seguir perguntaremos pelos servidores que respondem pelo domínio
edu:
> edu.
O ponto após edu é significativo. Ele indica ao servidor que estamos
pesquisando os servidores sob os quais o domínio edu está configurado
(isto de alguma maneira simplifica a busca):
edu nome do servidor = A.ROOT-SERVERS.NET
edu nome do servidor = H.ROOT-SERVERS.NET
edu nome do servidor = B.ROOT-SERVERS.NET
edu nome do servidor = C.ROOT-SERVERS.NET
edu nome do servidor = D.ROOT-SERVERS.NET
edu nome do servidor = E.ROOT-SERVERS.NET
edu nome do servidor = I.ROOT-SERVERS.NET
edu nome do servidor = F.ROOT-SERVERS.NET
edu nome do servidor = G.ROOT-SERVERS.NET
A.ROOT-SERVERS.NET endereço na internet = 198.41.0.4
H.ROOT-SERVERS.NET endereço na internet = 128.63.2.53
B.ROOT-SERVERS.NET endereço na internet = 128.9.0.107
C.ROOT-SERVERS.NET endereço na internet = 192.33.4.12
D.ROOT-SERVERS.NET endereço na internet = 128.8.10.90
E.ROOT-SERVERS.NET endereço na internet = 192.203.230.10
I.ROOT-SERVERS.NET endereço na internet = 192.36.148.17
F.ROOT-SERVERS.NET endereço na internet = 192.5.5.241
G.ROOT-SERVERS.NET endereço na internet = 192.112.36.4
A resposta nos indica que *.root-servers.net serve edu., podemos então
continuar perguntando, por exemplo ao servidor C.ROOT-SERVERS.NET.
Agora queremos saber quem serve o próximo nível do nome da máquina:
mit.edu.:
> mit.edu.
Server: c.root-servers.net
Address: 192.33.4.12
Non-authoritative answer:
mit.edu nameserver = W20NS.mit.edu
mit.edu nameserver = BITSY.mit.edu
mit.edu nameserver = STRAWB.mit.edu
Authoritative answers can be found from:
W20NS.mit.edu internet address = 18.70.0.160
BITSY.mit.edu internet address = 18.72.0.3
STRAWB.mit.edu internet address = 18.71.0.151
A resposta indica que strawb, w20ns e bitsy servem o domínio mit.
Vamos selecionar um deles e perguntar-lhe sobre ai.mit.edu:
> servidor W20NS.mit.edu.
Os nomes das máquinas não são sensíveis a maiúsculas e minúsculas, mas
sugerimos o uso do mouse para cortar e colar como estão na tela.
Servidor: W20NS.mit.edu
Endereço: 18.70.0.160
> ai.mit.edu.
Server: W20NS.mit.edu
Address: 18.70.0.160
Non-authoritative answer:
ai.mit.edu nameserver = ALPHA-BITS.AI.MIT.EDU
ai.mit.edu nameserver = GRAPE-NUTS.AI.MIT.EDU
ai.mit.edu nameserver = TRIX.AI.MIT.EDU
ai.mit.edu nameserver = MUESLI.AI.MIT.EDU
ai.mit.edu nameserver = LIFE.AI.MIT.EDU
ai.mit.edu nameserver = BEET-CHEX.AI.MIT.EDU
ai.mit.edu nameserver = MINI-WHEATS.AI.MIT.EDU
ai.mit.edu nameserver = COUNT-CHOCULA.AI.MIT.EDU
ai.mit.edu nameserver = MINTAKA.LCS.MIT.EDU
Authoritative answers can be found from:
AI.MIT.EDU nameserver = ALPHA-BITS.AI.MIT.EDU
AI.MIT.EDU nameserver = GRAPE-NUTS.AI.MIT.EDU
AI.MIT.EDU nameserver = TRIX.AI.MIT.EDU
AI.MIT.EDU nameserver = MUESLI.AI.MIT.EDU
AI.MIT.EDU nameserver = LIFE.AI.MIT.EDU
AI.MIT.EDU nameserver = BEET-CHEX.AI.MIT.EDU
AI.MIT.EDU nameserver = MINI-WHEATS.AI.MIT.EDU
AI.MIT.EDU nameserver = COUNT-CHOCULA.AI.MIT.EDU
AI.MIT.EDU nameserver = MINTAKA.LCS.MIT.EDU
ALPHA-BITS.AI.MIT.EDU internet address = 128.52.32.5
GRAPE-NUTS.AI.MIT.EDU internet address = 128.52.36.4
TRIX.AI.MIT.EDU internet address = 128.52.37.6
MUESLI.AI.MIT.EDU internet address = 128.52.39.7
LIFE.AI.MIT.EDU internet address = 128.52.32.80
BEET-CHEX.AI.MIT.EDU internet address = 128.52.32.22
MINI-WHEATS.AI.MIT.EDU internet address = 128.52.54.11
COUNT-CHOCULA.AI.MIT.EDU internet address = 128.52.38.22
MINTAKA.LCS.MIT.EDU internet address = 18.26.0.36
Desta forma, obtemos que museli.ai.mit.edu é um dos servidores de
nomes de ai.mit.edu:
> server MUESLI.AI.MIT.EDU
Default Server: MUESLI.AI.MIT.EDU
Address: 128.52.39.7
Agora mudaremos o tipo de pergunta. Já que encontramos o servidor de
nomes, agora podemos perguntar tudo o que quisermos sobre
prep.ai.mit.edu.
> set q=any
> prep.ai.mit.edu.
Server: MUESLI.AI.MIT.EDU
Address: 128.52.39.7
prep.ai.mit.edu CPU = dec/decstation-5000.25 OS = unix
prep.ai.mit.edu
inet address = 18.159.0.42, protocol = tcp
ftp telnet smtp finger
prep.ai.mit.edu preference = 1, mail exchanger = gnu-life.ai.mit.edu
prep.ai.mit.edu internet address = 18.159.0.42
ai.mit.edu nameserver = beet-chex.ai.mit.edu
ai.mit.edu nameserver = alpha-bits.ai.mit.edu
ai.mit.edu nameserver = mini-wheats.ai.mit.edu
ai.mit.edu nameserver = trix.ai.mit.edu
ai.mit.edu nameserver = muesli.ai.mit.edu
ai.mit.edu nameserver = count-chocula.ai.mit.edu
ai.mit.edu nameserver = mintaka.lcs.mit.edu
ai.mit.edu nameserver = life.ai.mit.edu
gnu-life.ai.mit.edu internet address = 128.52.32.60
beet-chex.ai.mit.edu internet address = 128.52.32.22
alpha-bits.ai.mit.edu internet address = 128.52.32.5
mini-wheats.ai.mit.edu internet address = 128.52.54.11
trix.ai.mit.edu internet address = 128.52.37.6
muesli.ai.mit.edu internet address = 128.52.39.7
count-chocula.ai.mit.edu internet address = 128.52.38.22
mintaka.lcs.mit.edu internet address = 18.26.0.36
life.ai.mit.edu internet address = 128.52.32.80
Assim começando por . fomos capazes de descobrir os nomes dos
servidores do próximo nível de domínio. Caso se esteja usando um
servidor DNS próprio ao invés de usar todos aqueles outros servidores,
o named certamente guardaria no cache todas as informações que tenha
encontrado, não sendo necessária toda esta pesquisa na próxima vez que
fosse realizada uma nova pesquisa de localização desta máquina.
Um tema muito menos comentado, mas também muito importante é in-
addr.arpa. Ele também está aninhado como um domínio 'normal'. in-
addr.arpa permite-nos conseguir os nomes das máquinas através de seus
endereços. Uma coisa importante aqui, é notar que ip#s são escritos ao
contrário no campo in-addr.arpa. Caso se tenha o endereço da máquina:
192.128.52.43, named procederá exatamente como no exemplo
prep.ai.mit.edu: encontrar servidores arpa., in-addr.arpa., 192.in-
addr.arpa., 128.192.in-addr.arpa., 52.128.192.in-addr.arpa.. Encontrar
então os registros necessários para 43.52.128.192.in-addr.arpa.
Engenhoso não? (Diga `Sim', por favor!.) Porém não se preocupe
endereços reversos somente são confusos nos dois primeiros anos.
Acabamos de contar uma mentira. O DNS não funciona exatamente da
maneira aqui descrita. Mas não tenha dúvida que é muito próximo disso.
44..22.. NNoossssoo PPrróópprriioo DDoommíínniioo
Agora vamos definir nosso próprio campo. Vamos criar o domínio
_l_i_n_u_x_._b_o_g_u_s e definir suas máquinas. Usaremos o nome de domínio bogus
para estarmos certos de não estarmos perturbando ninguém.
Mais uma coisa antes de começarmos: nem todos os caracteres são
permitidos nos nomes das máquinas. Estamos limitados ao caracteres do
alfabeto: a-z e ao números: 0-9, além do caracter '-' (hífen).
Devemos nos restringir àqueles caracteres. Os caracteres maiúsculos e
minúsculos são idênticos para o DNS, assim pat.uio.no é igual a
Pat.UiO.No.
Começaremos esta parte com uma linha em named.conf:
______________________________________________________________________
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
______________________________________________________________________
Por favor note a falta de `.' no final dos nomes dos campos neste
arquivo. Isto nos diz que podemos definir uma zona 0.0.127.in-
addr.arpa, na qual somos os servidores principais e que as informações
estão guardadas em um arquivo chamado pz/127.0.0. Nós já configuramos
este arquivo anteriormente com o seguinte conteúdo:
______________________________________________________________________
@ IN SOA ns.linux.bogus.hostmaster.linux.bogus. (
1 ; Serial
8H ; Atualização
2H ; Tentativas
1W ; Expiração
1D) ; TTL mínimo
NS ns.linux.bogus.
1 PTR localhost
______________________________________________________________________
Por favor note o `.' no final de todos os nomes completos de campo
neste arquivo, em contraste ao arquivo acima named.conf. Algumas
pessoas gostam de começar cada arquivo de zona com uma diretiva
$ORIGIN, mas isto é supérfluo. A origem (onde pertence o DNS na
hierarquia) de um arquivo de zona é especificado na seção de zona do
arquivo named.conf, a qual neste caso é 0.0.127.in-addr.arpa.
Este `arquivo de zona ' contém 3 `registros de recursos' (RRs): SOA,
NS e um PTR. SOA é a contração para Início de Autoridade. O `@' é
uma observação especial que significa origem e desde que a coluna do
campo para este arquivo diz 0.0.127.in-addr.arpa, a primeira linha
realmente quer dizer
0.0.127.in-addr.arpa. IN SOA ...
NS é o nome do servidor RR. Não há '@' no início desta linha, está
_i_m_p_l_í_c_i_t_o desde que a última linha começou com o caracter '@'.
Economiza-se assim alguma digitação e a possibilidade de cometer algum
erro. Assim na linha NS se lê
0.0.127.in-addr.arpa. IN NS ns.linux.bogus
Indicando ao DNS que a máquina é o servidor de nomes do domínio
0.0.127.in-addr.arpa é chamada ns.linux.bogus. 'ns' é um nome comum
para servidor de nomes, mas como em servidores web são costumeiramente
chamados www._d_o_m_í_n_i_o, este nome pode ser qualquer coisa.
E finalmente o registro PTR diz que a máquina no endereço 1 na subrede
0.0.127.in-addr.arpa, ou seja, 127.0.0,1 é denominado localhost.
O registro SOA é o preâmbulo para _t_o_d_o_s os arquivos de zona e deve
haver exatamente um em cada arquivo de zona, devendo necessariamente
ser o primeiro registro. Ele descreve a zona, sua origem (uma máquina
servidor de nomes ns.linux.bogus), quem é a responsável por seu
conteúdo (hostmaster@linux.bogus), qual a versão do arquivo de zona
(serial: 1) e outras coisas que têm a ver com guarda de dados em cache
e servidores secundários de DNS. Para os demais campos, Atualização,
Tentativas, Expiração e TTL, pode-se usar os valores aqui indicados e
se estará seguro.
Agora reinicializaremos o servidor de nomes (através do comando ndc
restart), e usaremos nslookup para examinar o que foi feito:
$ nslookup
Servidor Padrão: localhost
Endereço: 127.0.0.1
> 127.0.0.1
Servidor: localhost
Endereço: 127.0.0.1
Nome: localhost
Endereço: 127.0.0.1
observamos então que é possível chegar a localhost a partir do
endereço 127.0.0.1. Agora a nossa tarefa principal, no campo
linux.bogus, vamos inserir uma nova seção chamada 'zone' no
named.conf:
______________________________________________________________________
zone "linux.bogus" {
notify no;
type master;
file "pz/linux.bogus";
};
______________________________________________________________________
Note-se a ausência de `.' no nome do domínio no arquivo named.conf.
No arquivo de zona do domínio linux.bogus colocaremos alguns dados
totalmente inventados:
______________________________________________________________________
;
; Arquivo zona para linux.bogus
;
; O arquivo completo de zone
;
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, data de hoje + serial de hoje #
8H ; Atualização, segundos
2H ; Tentativa, segundos
1W ; Expiração, segundos
1D ) ; TTL, segundos
;
NS ns ; Endereço Internet do nome do servidor
MX 10 mail.linux.bogus ; Servidor de Correio Primário MX 20 mail.friend.bogus. ; Servidor de Correio Secundário
;
localhost A 127.0.0.1
ns A 192.168.196.2
mail A 192.168.196.4
______________________________________________________________________
Dois aspectos devem ser observados sobre o registro SOA.
ns.linux.bogus _d_e_v_e ser uma máquina real com um registro A. Não é
permitido ter um registro CNAME para a máquina mencionada no registro
SOA. O nome não precisa ser 'ns', pode ser qualquer nome de máquina
válido. Em seguida, a hostmaster.linux.bogus deve ser lido como
hostmaster@linux.bogus, o qual deve ser um nome alternativo de
correio, ou caixa postal, acessado pela(s) pessoa(s) que mantém o DNS
e leiam a correspondência freqüentemente. Qualquer correspondência
relativa ao domínio será enviada para o endereço relacionado aqui. O
nome não precisa ser 'hostmaster', pode ser qualquer endereço e-mail
válido, mas espera-se que o endereço e-mail 'hostmaster' _f_u_n_c_i_o_n_e bem.
Há um novo tipo RR neste arquivo, o MX, ou registro de recurso de
servidor de correio. Este arquivo diz aos sistemas de correspondência
para onde enviar a correspondência endereçada para alguém@linux.bogus,
ou seja no nosso caso mail.linux.bogus ou mail.friend.bogus. O número
antes de cada nome de máquina define a prioridade. O RR com o número
mais baixo tem prioridade. Caso ele não esteja ativo ou apresentar
algum erro, a mensagem pode ser enviada a um outro servidor de
mensagens com um número mais alto, um operador de correspondência
secundário, ou seja, no nosso caso, mail.friend.bogus que tem
prioridade 20.
Ao se reiniciar o servidor de nomes executando-se ndc restart
obteremos os seguintes resultados com o nslookup:
$ nslookup
> set q=any
> linux.bogus
Server: localhost
Address: 127.0.0.1
linux.bogus
origin = ns.linux.bogus
mail addr = hostmaster.linux.bogus
serial = 199802151
refresh = 28800 (8 horas)
retry = 7200 (2 horas)
expire = 604800 (7 dias)
minimum ttl = 86400 (1 dia)
linux.bogus nameserver = ns.linux.bogus
linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus
linux.bogus preference = 20, mail exchanger = mail.friend.bogus
linux.bogus nameserver = ns.linux.bogus
ns.linux.bogus internet address = 192.168.196.2
mail.linux.bogus internet address = 192.168.196.4
Com um exame mais apurado pode-se descobrir um pequeno problema. A
linha
linux.bogus preference = 10, mail exchanger = mail.linux.bogus.linux.bogus
deveria ser
linux.bogus preference = 10, mail exchanger = mail.linux.bogus
Deliberadamente cometemos o erro para que o leitor aprenda com ele:-)
Examinando o arquivo de zona, percebemos que na linha
MX 10 mail.linux.bogus ; Servidor primário de correio
está faltando um ponto. Ou seja há 'linux.bogus' demais. Caso um
nome de máquina não seja seguido por um ponto num arquivo de zona, a
origem será acrescentada ao final causando o duplo
linux.bogus.linux.bogus. Portanto
______________________________________________________________________
MX 10 mail.linux.bogus. ; Servidor primário de correio
______________________________________________________________________
ou
______________________________________________________________________
MX 10 mail ; Servidor primário de correio
______________________________________________________________________
estão corretos. Particularmente, sugerimos a última forma, por ser
mais econômica e menos sujeita a erros. Existem alguns bem conhecidos
usuários de bind que discordam e outros que concordam com isto. Num
arquivo de zona, o domínio pode tanto ser totalmente identificado e
terminado com um `.' ou não deve ser incluído de forma alguma,
utilizando então o padrão da origem.
Devemos salientar que em um arquivo named.conf _n_ã_o deve haver `.'
depois dos nomes dos domínios. Você não tem idéia de quantas vezes um
`.' gerou uma enormidade de problemas e confundiu um punhado de
administradores.
Agora que já expressamos nosso ponto de vista. Estamos com o novo
arquivo de zona e com informações extras:
______________________________________________________________________
;
; Arquivo de zona para linux.bogus
;
; O arquivo de zona completo
;
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; serial, data de hoje + serial de hoje #
8H ; Atualizar, segundos
2H ; Tentativas, segundos
1W ; Expiração, segundos
1D ) ; TTL, segundos
;
TXT "Linux.Bogus, os especialistas DNS "
NS ns ; Endereço Internet do servidor de nomes
NS ns.friend.bogus.
MX 10 mail ; Servidor de correio primário
MX 20 mail.friend.bogus. ; Servidor de correio secundário
localhost A 127.0.0.1
gw A 192.168.196.1
HINFO "Cisco" "IOS"
TXT "O roteador"
ns A 192.168.196.2
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "Pentium" "Linux 2.0"
www CNAME ns
donald A 192.168.196.3
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "i486" "Linux 2.0"
TXT "DEK"
correio A 192.168.196.4
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "386sx" "Linux 2.2"
ftp A 192.168.196.5
MX 10 mail
MX 20 mail.friend.bogus.
HINFO "P6" "Linux 2.0.36"
______________________________________________________________________
Há diversos RRs novos: HINFO (INFOrmação da Máquina) tem duas partes,
sendo aconselhável indicar os dois. A primeira parte é o hardware ou
CPU da máquina, e a segunda parte é o software ou OS da máquina. O
servidor de nomes 'ns' tem uma CPU Pentium e executa o Linux 2.0.
CNAME (NOME Canônico) é uma maneira de dar a uma mesma máquina vários
nomes. Assim www é um nome alternativo para o ns.
O uso do registro CNAME é um pouco controvertido. Mas é seguro seguir
a regra onde um registro MX, CNAME ou SOA _n_u_n_c_a deve referir-se a um
registro CNAME , e devem referir-se somente a um registro A, sendo
portanto incorreto ter-se:
______________________________________________________________________
itamaracabar CNAME www ; NÃO!
______________________________________________________________________
o correto seria:
______________________________________________________________________
itamaracabar CNAME ns ; SIM!
______________________________________________________________________
É também seguro supor que um CNAME não é um nome de máquina válido
para um endereço e-mail, por exemplo webmaster@www.linux.bogus é um
endereço ilegal, conforme a configuração acima. Não se deve esperar
que muito administradores de servidores de mensagens usem esta
configuração, mesmo se ela funcionar localmente. A maneira para evitar
isto é usar registros de tipo A ( e talvez alguns outros também, como
um registro MX):
______________________________________________________________________
www A 192.168.196.2
______________________________________________________________________
Um grande número de magos do DNS, sugerem que o CNAME _n_ã_o seja
utilizado. Por isso, devemos considerar esta sugestão _m_u_i_t_o
seriamente.
Mas como se pode perceber, este COMO FAZER e muitos sites não seguem
esta regra.
É possível carregar o novo banco de dados executando-se ndc reload, o
que fará com que o named leia seus arquivos novamente.
$ nslookup
Default Server: localhost
Address: 127.0.0.1
> ls -d linux.bogus
Isto significa que todos os registros devem ser apresentados. O
resultado será:
<tscreen><verb>
[localhost]
$ORIGIN linux.bogus.
@ 1D IN SOA ns hostmaster (
199802151 ; nro. serial
8H ; atualizar
2H ; tentativas
1W ; expiração
1D ) ; mínimo
1D IN NS ns
1D IN NS ns.friend.bogus.
1D IN TXT "Linux.Bogus, os consultores DNS"
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
gw 1D IN A 192.168.196.1
1D IN HINFO "Cisco" "IOS"
1D IN TXT "O roteador"
mail 1D IN A 192.168.196.4
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "386sx" "Linux 1.0.9"
localhost 1D IN A 127.0.0.1
www 1D IN CNAME ns
donald 1D IN A 192.168.196.3
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "i486" "Linux 1.2"
1D IN TXT "DEK"
ftp 1D IN A 192.168.196.5
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "P6" "Linux 1.3.59"
ns 1D IN A 192.168.196.2
1D IN MX 10 mail
1D IN MX 20 mail.friend.bogus.
1D IN HINFO "Pentium" "Linux 1.2"
@ 1D IN SOA ns hostmaster (
199802151 ; nro. serial
8H ; atualizar
2H ; tentativas
1W ; expiração
1D ) ; mínimo
Parece ótimo. Como se pode ver parece muito com o arquivo de zona.
Vamos verificar o que ele diz para www:
> set q=any
> www.linux.bogus.
Server: localhost
Address: 127.0.0.1
www.linux.bogus canonical name = ns.linux.bogus
linux.bogus nameserver = ns.linux.bogus
linux.bogus nameserver = ns.friend.bogus
ns.linux.bogus internet address = 192.168.196.2
Em outras palavras, o nome real de www.linux.bogus é ns.linux.bogus, e
ele fornece algumas informações adicionais que ele possua sobre ns, o
suficiente para um programa conectar-se a ele.
Agora estamos no meio do caminho.
44..33.. AA zzoonnaa rreevveerrssaa
Agora os programas podem converter os nomes em linux.bogus para
endereços com os quais eles podem se conectar. Porém é pedido também
uma zona reversa, que torne o DNS capaz de converter um endereço em um
nome. Este nome é usado por muitos servidores de espécies diferentes
(FTP, IRC, WWW e outros) para decidir se eles querem conversar com a
máquina local ou não, e em caso positivo, também qual a prioridade
que deve ser dada a esta máquina. Para o acesso completo a todos os
serviços da Internet, uma zona reversa é necessária.
Deve-se colocar o seguinte em named.conf:
______________________________________________________________________
zone "196.168.192.in-addr.arpa" {
notify no;
type master;
file "pz/192.168.196";
};
______________________________________________________________________
Estes parâmetros são exatamente iguais para 0.0.127.in-addr.arpa e os
conteúdos são semelhantes:
______________________________________________________________________
@ IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; Nro.Serial, data + nro. série
8H ; Atualizar
2H ; Tentativas
1W ; Expiração
1D) ; TTL mínimo
NS ns.linux.bogus.
1 PTR gw.linux.bogus.
2 PTR ns.linux.bogus.
3 PTR donald.linux.bogus.
4 PTR mail.linux.bogus.
5 PTR ftp.linux.bogus.
______________________________________________________________________
Agora ao reinicializar o servidor de nomes (ndc restart) e examinar o
trabalho realizado, utilizando-se o nslookup, teremos:
______________________________________________________________________
> 192.168.196.4
Server: localhost
Address: 127.0.0.1
Name: mail.linux.bogus
Address: 192.168.196.4
______________________________________________________________________
Então caso tudo pareça correto, vamos examinar todas as demais
informações:
______________________________________________________________________
> ls -d 196.168.192.in-addr.arpa
[localhost]
$ORIGIN 196.168.192.in-addr.arpa.
@ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; nro. serial
8H ; atualizar
2H ; tentativas
1W ; expiração
1D ) ; ttl mínimo
1D IN NS ns.linux.bogus.
1 1D IN PTR gw.linux.bogus.
2 1D IN PTR ns.linux.bogus.
3 1D IN PTR donald.linux.bogus.
4 1D IN PTR mail.linux.bogus.
5 1D IN PTR ftp.linux.bogus.
@ 1D IN SOA ns.linux.bogus. hostmaster.linux.bogus. (
199802151 ; nro. serial
8H ; atualizar
2H ; tentativas
1W ; expiração
1D ) ; ttl mínimo
______________________________________________________________________
Parece bom!
Há algumas coisas que devemos acrescentar. Os números IP usados nos
exemplos acima foram tirados dos blocos de 'redes privadas', ou seja,
eles não podem ser usados publicamente na Internet. Por isso eles são
seguros para serem usados em um exemplo de um COMO FAZER. A segunda
coisa é a linha notify no;, a qual indica que o servidor de nomes não
notificará o servidor secundário (escravo), quando houver uma
atualização para um dos arquivos de zona. No bind-8 o servidor de
nomes pode notificar os outros servidores relacionados nos registros
NS no arquivo de zona, toda vez que ela for atualizada. Isto é
conveniente para o uso diário e usual, mas em nossas experiências
particulares com zonas, esta característica deve ser desativada,
afinal não queremos que a experiência polua toda a Internet, queremos?
E claro, este domínio é totalmente inventado, assim como todos os
endereços que estão nele. Para um exemplo real de um domínio real,
veja a próxima seção.
55.. UUmm EExxeemmpplloo ddee DDoommíínniioo RReeaall
OOnnddee lliissttaammooss aallgguunnss aarrqquuiivvooss _d_e _z_o_n_a _r_e_a_i_s
Os usuários têm sugerido que seja incluído um exemplo real de um
domínio em operação, bem como um exemplo detalhado.
Usaremos este exemplo com a permissão de David Bullock da LAND-5.
Estes arquivos eram atuais em 24 de setembro de 1996 e foram então
editados para corresponder às restrições da bind-8 e às extensões
usadas pelo autor. Assim, o que se vê aqui, difere um pouco do que se
pode encontrar ao se perguntar aos servidores de nomes do LAND-5.
55..11.. //eettcc//nnaammeedd..ccoonnff ((oouu //vvaarr//nnaammeedd//nnaammeedd..ccoonnff))
Aqui encontramos as seções mestre de zona para as duas zonas reversas
necessárias: a rede 127.0.0 , bem como a rede LAND-5 206.6.177, além
de uma linha primária para o land-5.com. Note ainda que ao invés de
colocar os arquivos em um diretório chamado pz, como foi feito
anteriormente, eles foram colocados no diretório chamado zone.
______________________________________________________________________
// Arquivo de inicialização do servidor de nomes de LAND-5
options {
directory "/var/named";
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "zone/127.0.0";
};
zone "land-5.com" {
type master;
file "zone/land-5.com";
};
zone "177.6.206.in-addr.arpa" {
type master;
file "zone/206.6.177";
};
______________________________________________________________________
Caso este arquivo seja definido como o arquivo named.conf de uma
máquina local, _P_O_R _F_A_V_O_R use o parâmetro notify no; nas seções de zona
para as duas zonas land-5, a fim de evitar acidentes.
55..22.. //vvaarr//nnaammeedd//rroooott..hhiinnttss
Deve-se ter em mente que este é um arquivo dinâmico e o aqui descrito
pode não significar a realidade atual. É sugerido utilizar um modelo
atualizado, produzido pelo utilitário dig, conforme explicado
anteriormente.
______________________________________________________________________
; <<>> DiG 8.1 <<>> @A.ROOT-SERVERS.NET.
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13
;; QUERY SECTION:
;; ., type = NS, class = IN
;; ANSWER SECTION:
. 6D IN NS G.ROOT-SERVERS.NET.
. 6D IN NS J.ROOT-SERVERS.NET.
. 6D IN NS K.ROOT-SERVERS.NET.
. 6D IN NS L.ROOT-SERVERS.NET.
. 6D IN NS M.ROOT-SERVERS.NET.
. 6D IN NS A.ROOT-SERVERS.NET.
. 6D IN NS H.ROOT-SERVERS.NET.
. 6D IN NS B.ROOT-SERVERS.NET.
. 6D IN NS C.ROOT-SERVERS.NET.
. 6D IN NS D.ROOT-SERVERS.NET.
. 6D IN NS E.ROOT-SERVERS.NET.
. 6D IN NS I.ROOT-SERVERS.NET.
. 6D IN NS F.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
J.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.10
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
;; Total query time: 215 msec
;; FROM: roke.uio.no to SERVER: A.ROOT-SERVERS.NET. 198.41.0.4
;; WHEN: Sun Feb 15 01:22:51 1998
;; MSG SIZE sent: 17 rcvd: 436
______________________________________________________________________
55..33.. //vvaarr//nnaammeedd//zzoonnee//112277..00..00
Somente as informações básicas são obrigatórias, como o registro SOA e
um registro que mapeie 127.0.0.1 para localhost. Nenhuma outra
informação deve estar contida neste arquivo. Provavelmente ele nunca
precisará ser atualizado, a menos que o endereço do servidor de nomes
ou da máquina mestra seja alterado.
______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199909203 ; Nro. Serial
28800 ; Atualizar
7200 ; Tentativas
604800 ; Expiração
86400) ; TTL Mínimo
NS land-5.com.
1 PTR localhost.
______________________________________________________________________
55..44.. //vvaarr//nnaammeedd//zzoonnee//llaanndd--55..ccoomm
Aqui teremos um registro SOA obrigatório com os registros NS
necessários. Podemos ver que há um servidor secundário em ns2.psi.net.
Este é o procedimento correto, _s_e_m_p_r_e ter um site como servidor
secundário que esteja fora da rede local. Podemos verificar que ele
tem uma máquina mestra chamada land-5, o qual cuida de muitos serviços
diferentes da Internet, e que ele foi definido com diversos registros
CNAME (uma alternativa seria usar os registros de recursos do tipo A).
Como se pode verificar no registro SOA, o arquivo de zona tem origem
em land-5.com e a pessoa de contato é root@land-5.com. hostmaster é
outro endereço usado com freqüência na definição de pessoa de contato.
O número serial está no formato habitual ano-mês-dia com o números
seriais acrescentado, sendo esta provavelmente a sexta versão do
arquivo de zona datada de 20 de setembro de 1996. Lembre-se que o
número serial _d_e_v_e aumentar ordenadamente, onde hoje temos apenas _u_m
dígito para serial#; assim depois da nona alteração no dia de hoje ele
terá que esperar até amanhã antes de poder editar o arquivo novamente.
É aconselhável o de dois dígitos para evitar este tipo de problema.
______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609206 ; nro. serial, data de hoje + atualizações #
8H ; atualizar em segundos
2H ; tentativas em segundos
1W ; expiração em segundos
1D ) ; mínimo em segundos
NS land-5.com.
NS ns2.psi.net.
MX 10 land-5.com. ; Servidor primário de correio
Localhost A 127.0.0.1
Router A 206.6.177.1
land-5.com. A 206.6.177.2
ns A 206.6.177.3
www A 207.159.141.192
ftp CNAME land-5.com.
mail CNAME land-5.com.
news CNAME land-5.com.
funn A 206.6.177.2
@ TXT "Corporação LAND-5"
;
; Estações de Trabalho
;
ws-177200 A 206.6.177.200
MX 10 land-5.com. ;
ws-177201 A 206.6.177.201
MX 10 land-5.com. ; Servidor primário de correio
ws-177202 A 206.6.177.202
MX 10 land-5.com. ; Servidor primário de correio
ws-177203 A 206.6.177.203
MX 10 land-5.com. ; Servidor primário de correio
ws-177204 A 206.6.177.204
MX 10 land-5.com. ; Servidor primário de correio
ws-177205 A 206.6.177.205
MX 10 land-5.com. ; Servidor primário de correio
; {Definições repetitivas retiradas - SNIP}
ws-177250 A 206.6.177.250
MX 10 land-5.com. ; Servidor primário de correio
ws-177251 A 206.6.177.251
MX 10 land-5.com. ; Servidor primário de correio
ws-177252 A 206.6.177.252
MX 10 land-5.com. ; Servidor primário de correio
ws-177253 A 206.6.177.253
MX 10 land-5.com. ; Servidor primário de correio
ws-177254 A 206.6.177.254
MX 10 land-5.com. ; Servidor primário de correio
______________________________________________________________________
Ao examinarmos o servidor de nomes land-5, descobriremos que os nomes
das máquinas estão no formato ws__n_ú_m_e_r_o. Como nas versões recentes do
bind 4, o named começa a impor restrições nos caracteres que podem ser
usados como nomes das máquinas. Por isso, o original não funcionava
com bind-8 e foram substituídos então os '-'(travessões) por
'_'(sublinhados).
Uma outra coisa a ser notada é que as estações operacionais não
possuem nomes individuais, mas um prefixo seguido pelas duas últimas
partes dos números IP. Usando-se tal convenção, pode-se simplificar
significativamente a manutenção, mas pode ser um pouco impessoal, e na
verdade, se tornar uma fonte de descontentamento entre os usuários.
Vemos também que funn.land-5.com é um nome alternativo para
land-5.com, mas usando um registro A e não um registro CNAME.
55..55.. //vvaarr//nnaammeedd//zzoonnee//220066..66..117777
Comentaremos este arquivo em seguida.
______________________________________________________________________
@ IN SOA land-5.com. root.land-5.com. (
199609206 ; Nro. Serial
28800 ; Atualizar
7200 ; Tentativa
604800 ; Expiração
86400) ; TTL Mínimo
NS land-5.com.
NS ns2.psi.net.
;
; Servidores
;
1 PTR router.land-5.com.
2 PTR land-5.com.
2 PTR funn.land-5.com.
;
; Estações de trabalho
;
200 PTR ws-177200.land-5.com.
201 PTR ws-177201.land-5.com.
202 PTR ws-177202.land-5.com.
203 PTR ws-177203.land-5.com.
204 PTR ws-177204.land-5.com.
205 PTR ws-177205.land-5.com.
; {Muitas definições repetidas foram suprimidas - SNIP}
250 PTR ws-177250.land-5.com.
251 PTR ws-177251.land-5.com.
252 PTR ws-177252.land-5.com.
253 PTR ws-177253.land-5.com.
254 PTR ws-177254.land-5.com.
______________________________________________________________________
A zona reversa é o aspecto da configuração que parece causar a maior
dificuldade. É usada para se encontrar o nome da máquina, caso se
tenha o seu endereço IP. Por exemplo: caso a máquina seja um servidor
IRC que aceita conexões de clientes. No entanto este é um servidor
Norueguês e por isso, somente serão aceitas conexões de clientes na
Noruega e outros países escandinavos. Quando se obtém uma conexão de
um cliente, a biblioteca C é capaz de indicar o número IP da máquina
remota, porque o número IP do cliente está contido em todos os pacotes
que são enviados para a rede. Pode-se então usar uma função chamada
gethostbyaddr, a qual pesquisa o nome de uma máquina dado o número IP.
Gethostbyaddr perguntará a um servidor DNS, o qual procurará pela
máquina. Supondo-se que a conexão cliente foi originada por
ws-177200.land-5.com. O número IP que a biblioteca C fornece para o
servidor IRC é 206.6.177.200. Para descobrir o nome daquela máquina,
precisamos encontrar 200.177.6.206.in-addr.arpa. O servidor DNS
primeiramente encontrará os servidores arpa., então os servidores in-
addr.arpa. seguidos pelos servidores reversos de 206, então 6 e
finalmente é encontrando o servidor para a zona 177.6.206.in-addr.arpa
em land-5. A partir deste se obterá a resposta, ou seja o registro
'PTR ws-177200.land-5.com', que indica que o nome de 206.6.177.200 é
igual a ws-177200.land-5.com. Assim como com as explicações sobre a
forma de pesquisa de prep.ai.mit.edu, esta descrição também é um
pouco simplificada em relação ao que efetivamente ocorre.
Voltando ao exemplo do servidor IRC. O servidor IRC só aceita conexões
de países escandinavos, ou seja, *.no, *.se ou*.dk e o nome
ws-177200.land-5.com claramente não combina com qualquer uma delas,
sendo então negada a conexão. Caso _n_ã_o houvesse o mapeamento reverso
de 206.2.177.200 através da zona in-addr.arpa, o servidor estaria
incapacitado de encontrar o nome e teria que comparar 206.2.177.200
com *.no, *.se e *.dk, onde evidentemente nenhuma das opções
coincidiria.
Algumas pessoas afirmam que a pesquisa de mapeamentos reversos são
importantes apenas para os servidores, ou ainda que não são
importantes de forma alguma. A verdade nos parece bem diferente:
muitos servidores ftp, notícias, IRC e até mesmo alguns http (WWW) _n_ã_o
aceitarão conexões de máquinas das quais não seja possível encontrar o
nome. Por isso os mapeamentos reversos são na verdade _o_b_r_i_g_a_t_ó_r_i_o_s.
66.. MMaannuutteennççããoo
MMaanntteennddoo oo ssiisstteemmaa ffuunncciioonnaannddoo..
Há uma tarefa de manutenção que se deve executar no named, além de
mantê-los funcionando, que é manter o arquivo root.hints atualizado. A
maneira mais fácil é usar o utilitário dig, o qual deve ser executado
inicialmente sem argumentos, gerando um root.hints adequado ao
servidor. A seguir deve ser perguntado a um dos servidores
relacionados o seguinte: dig @rootserver. Pode-se notar que a saída se
parecerá muitíssimo como um arquivo root.hints. Ela deve ser salva em
um arquivo (dig @e.root-servers.net . ns >root.hints.new) que servirá
de substituto ao root.hints anterior.
O servidor de nomes deverá ser então reiniciado para substituir o
cache antigo.
Al Longyear enviou este programa, o qual pode ser executado
automaticamente para atualizar root.hints; basta configurar uma
entrada no crontab para executá-lo por exemplo uma vez ao mês. O
programa assume que se tenha um servidor de correio funcionando e que
o nome alternativo de endereço de correio eletrônico 'hostmaster' está
definido.
______________________________________________________________________
#!/bin/sh
#
# Atualiza as informações do cache do servidor de nomes uma vez ao mês
# É executado automaticamente uma vez ao mês através de uma entrada no cron
#
(
echo "To: hostmaster <hostmaster>"
echo "From: system <root>"
echo "Subject: Atualização automática do arquivo named.conf "
echo
export PATH=/sbin:/usr/sbin:/bin:/usr/bin:
cd /var/named
dig @rs.internic.net . ns >root.hints.new
echo "O arquivo named.conf foi atualizado, passando a conter a seguinte informações:"
echo
cat root.hints.new
chown root.root root.hints.new
chmod 444 root.hints.new
rm -f root.hints.old
mv root.hints root.hints.old
mv root.hints.new root.hints
ndc restart
echo
echo "O servidor de nomes foi reinicializado para garantir que a atualização foi completada".
echo "O arquivo root.hints anterior foi renomeado para /var/named/root.hints.old."
) 2>&1 | /usr/lib/sendmail -t
exit 0
______________________________________________________________________
Alguns dos leitores mais avançados podem saber que o arquivo
root.hints está também disponível via ftp na Internic. Por favor _n_ã_o
use ftp para atualizar root.hints, o método acima é muito mais
amigável para a rede.
77.. CCoonnvveerrtteerr ddaa vveerrssããoo 44 ppaarraa vveerrssããoo 88
Esta foi originalmente uma seção sobre o uso da bind 8 escrita por
David E. Smith (dave@bureau42.ml.org). Ela foi editada para conter o
novo nome da seção.
Não há muito a acrescentar. Exceto pelo uso do servidor named.conf ao
invés de servidor named.boot, tudo mais é idêntico; bind8 vem com um
programa perl que converte arquivos de estilo velho para o novo
formato. Exemplo de um named.boot (velho estilo) para um servidor de
nomes somente para cache:
______________________________________________________________________
directory /var/named
cache . root.hints
primary 0.0.127.IN-ADDR.ARPA 127.0.0.zone
primary localhost localhost.zone
______________________________________________________________________
Na linha de comando, no diretório bind8/src/bin/named (_p_r_e_s_u_m_e_-_s_e _a_q_u_i
_q_u_e _s_e _t_e_n_h_a_m _o_s _f_o_n_t_e_s _d_a _d_i_s_t_r_i_b_u_i_ç_ã_o_. _C_a_s_o _s_e _l_o_c_a_l_i_z_e _s_o_m_e_n_t_e _o
_p_a_c_o_t_e _b_i_n_á_r_i_o_, _o _p_r_o_g_r_a_m_a _e_s_t_a_r_á _p_o_r _p_e_r_t_o_. _-_e_d_.), digite:
______________________________________________________________________
./named-bootconf.pl < named.boot > named.conf
______________________________________________________________________
o qual criará o seguinte named.conf:
______________________________________________________________________
options {
directory "/var/named";
};
zone "." {
type hint;
file "root.hints";
};
zone "0.0.127.IN-ADDR.ARPA" {
type master;
file "127.0.0.zone";
};
zone "localhost" {
type master;
file "localhost.zone";
};
______________________________________________________________________
Funciona para tudo o que puder estar presente em um arquivo
named.boot, embora ele não acrescente todas as novas funcionalidades e
opções de configuração que o bind8 permite. Aqui está um named.conf
mais completo, o qual faz as mesmas coisas, mas de uma forma um pouco
mais eficaz.
______________________________________________________________________
// Este é um arquivo de configuração para o named (BIND 8.1 ou mais recente).
// Deve ser instalado em /etc/named.conf.
// A única mudança feita no named.conf (à parte deste comentário:) é que a linha // de diretório foi descomentada, desde que já se tinha os arquivos de zona em
// /var/named.
options {
directory "/var/named";
check-names master warn; /* padrão. */
datasize 20M;
};
zone "localhost" IN {
type master;
file "localhost.zone";
check-names fail;
allow-update { none; };
allow-transfer { any; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "127.0.0.zone";
check-names fail;
allow-update { none; };
allow-transfer { any; };
};
zone "." IN {
type hint;
file "root.hints";
};
______________________________________________________________________
bind8/src/bin/named/test tem este conteúdo e cópias dos arquivos de
zonas, que muitos podem simplesmente começar a usar.
Os formatos dos arquivos de zona e dos arquivos root.hints são
idênticos, assim como são os comandos para atualizá-los.
88.. PPeerrgguunnttaass ee RReessppoossttaass
Por favor leia esta seção com atenção antes de enviar mensagens ao
autor.
1. Meu named necessita de um arquivo named.boot.
Você está lendo o COMO FAZER errado. Por favor veja a versão antiga
deste COMO FAZER que faz a converção do bind 4 em:
http://www.math.uio.no/~janl/DNS/.
2. Como usar o DNS de dentro de um firewall?
Algumas dicas: `retransmissores', `escravo' e dê uma olhada na
lista de literatura no final deste COMO FAZER.
3. Como fazer para o DNS alternar através de diversos endereços
disponíveis para um serviço, digamos, www.busy.site para obter um
efeito de carga balanceada ou similar?
Faça vários registros AA para www.busy.site e use a bind 4.9.3 ou
posterior. Então o bind irá fornecer as respostas, porém _n_ã_o
funcionará com versões mais antigas do bind.
4. Gostaria de configurar o DNS em uma intranet (fechada). O que eu
faço?
Pode-se omitir o arquivo root.hints e construir somente os arquivos
de zona. Isto significa ainda que você não tem que conseguir um
novo arquivo hint o tempo todo.
5. Como configurar um servidor de nomes secundário (escravo)?
Caso o servidor primário/mestre tiver, por exemplo, o endereço
127.0.0.1, basta colocar uma linha no arquivo named.conf do
secundário:
___________________________________________________________________
zone "linux.bogus" {
type slave;
file "sz/linux.bogus";
masters { 127.0.0.1; };
};
___________________________________________________________________
Pode-se relacionar vários servidores mestres alternativos. O arquivo
de zona pode ser copiado de dentro de uma lista de mestres, separada
por ';' (ponto e vírgula).
6. Eu quero executar o bind quando estiver desconectado da rede.
Há aspectos relacionados com isto:
· Eu recebi esta mensagem de Ian Clark <ic@deakin.edu.au> onde ele
explica a sua maneira de fazer isto:
Eu executo named na minha máquina 'Masquerading', tendo dois arquivos root.hints, uma chamado root.hints.real que contém os nomes dos servidores de nomes raiz reais e o outro chamado root.hints.falso que contém...
----
; root.hints.falso
; este arquivo não contém informações
----
Ao desconectar-se da rede, eu copio o arquivo root.hints.falso para root.hints e reinicio o named.
Ao conectar-se novamente a rede, root.hints.real é copiado para root.hints e o named é reiniciado.
Isto é feito pelos programas ip-down & ip-up respectivamente.
A primeira vez que uma pergunta pesquisa é feita com a rede desconectada, o servidor de nomes não tem meios de obter o seu endereço e apresenta a seguinte mensagem:
28 de jan. 20:10:11 servidor de nomes hazchem [10147]: Nenhum servidor de nomes raiz foi localizado para a classe IN...
Com a qual eu posso viver.
Certamente parece funcionar para mim. É possível utilizar o servidor de nomes para máquinas locais, enquanto estiver desconectado da rede, sem o tempo de espera necessário para nomes de domínios externos e enquanto as pesquisas na rede por outros domínios "funcionam" a contento.
· Recebi de Karl-Max Wanger informações sobre como bind interage com
o NFS e o portmapper numa máquina fora da rede:
Eu executo meu próprio named em todas as máquinas que ocasionalmente estejam conectadas a Internet via modem. O servidor de nomes atua somente como um cache, ele não tem de autoridade e pergunta tudo aos servidores de nomes indicados no arquivo root.cache. Como de costume no Slackware, ele é iniciado antes em nfsd e mountd.
Com uma de minhas máquinas (um Libretto 30) eu tive o problema de algumas vezes poder montá-lo a partir de outro sistema conectado à rede local, mas na maior parte do tempo isso não ser possível. Obtive o mesmo resultado usando PLIP, um cartão Ethernet PCMCIA ou PPP sobre uma interface serial.
Depois de algum tempo de tentativas e experiências, descobri que aparentemente o named ficava confuso com o processo de registro do nfsd e mountd junto ao portmapper, após a sua inicialização (estes servidores sempre foram inicializados da forma usual). Inicializando o named após nfsd e o mountd eliminou este problema completamente.
Como não existem desvantagens em tal seqüência modificada de inicialização aconselho a todos que a utilizem para prevenir potenciais problemas.
7. Onde o nome do servidor somente de cache guarda seu cache? Há
alguma maneira de controlar o tamanho do cache?
O cache é mantido integralmente em memória, ele _n_ã_o é gravado em
disco em nenhum momento. Toda vez que se finaliza o named, o cache
é perdido. O cache _n_ã_o é controlável de nenhuma maneira. O named
administra-o de acordo com algumas regras simples e é isso. Não se
pode controlar o cache ou o tamanho do cache. Caso se deseje pode
se alterar o programa named, porém isto não é recomendado.
8. O named salva o cache? Posso fazer com que ele o salve?
Não, o servidor de nomes _n_ã_o salva o cache quando ele é finalizado.
Isto significa que o cache tem que ser construído de novo cada vez
que se reinicia o servidor de nomes. Não há nenhuma maneira de
fazer com que o servidor de nomes salve o cache em um arquivo. Caso
se deseje pode se alterar o programa named, porém isto não é
recomendado.
99.. CCoommoo ttoorrnnaarr--ssee uumm aaddmmiinniissttrraaddoorr ddee DDNNSS..
DDooccuummeennttaaççããoo ee FFeerrrraammeennttaass..
A documentação real existe, on-line e impressa. A leitura de várias
destas é necessária para tornar-se um administrador de DNS. Em
formato impresso, o livro padrão é _D_N_S _e _B_I_N_D por C. Liu e P. Albitz
de O'Reilly & Associates, Sebastopol, CA, ISBN 0-937175-82-X. Eu o li
e digo-lhes que é excelente. Há também uma seção sobre DNS em _T_C_P_/_I_P
_A_d_m_i_n_i_s_t_r_a_ç_ã_o _d_e _R_e_d_e, por Craig Huny da O'Reilly..., ISBN
0-937175-82-X. Uma outra sugestão para uma boa administração de DNS
(ou bom para qualquer coisa) é _Z_e_n _e _a _A_r_t_e _d_a _M_a_n_u_t_e_n_ç_ã_o _d_a
_M_o_t_o_c_i_c_l_e_t_a de Robert M. Prisig :-) Disponível em ISBN 0688052304 e
outros.
On-line pode-se encontrar material em <http://www.dns.net/dnsrd/>,
<http://www.isc.org/bind.html>; um FAQ, uma referência manual (BOG;
Guia de Operações de Bind) bem como documentos e definições de
protocolos e programas DNS (estes, e a maioria, se não todos, dos rfcs
mencionados abaixo, estão também contidos na distribuição de bind).
Eu não li a maioria destes, mas também não sou um grande administrador
de DNS. Arnt Gulbrandsen, por outro lado, leu o BOG e ficou
entusiasmado com ele :-). O grupo de notícias comp.protocols.tcp-
ip.domains também trata sobre DNS. Além disso há um número de RFCs
sobre DNS, sendo estes provavelmente os mais importantes:
RRFFCC 22005522
A. Gulbrandsen, P. Vixie, _U_m _D_N_S _R_R _p_a_r_a _a _e_s_p_e_c_i_f_i_c_a_ç_ã_o _d_a
_l_o_c_a_l_i_z_a_ç_ã_o _d_o_s _s_e_r_v_i_ç_o_s_(_D_N_S _S_R_V_), Outubro de 1996
RRFFCC 11991188
Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear,
_A_l_o_c_a_ç_ã_o _d_e _E_n_d_e_r_e_ç_o_s _p_a_r_a _I_n_t_e_r_n_e_t_s _P_a_r_t_i_c_u_l_a_r_e_s , 29/02/1996.
RRFFCC 11991122
D. Barr, _E_r_r_o_s _C_o_m_u_n_s _n_a _O_p_e_r_a_ç_ã_o _e _C_o_n_f_i_g_u_r_a_ç_ã_o _c_o_m _D_N_S,
28/02/1996.
RRFFCC 11991122 EErrrrooss
B. Barr _E_r_r_o_s _n_a _R_F_C _1_9_1_2, está disponível em
<http://www.cis.ohio-state.edu/~barr/rfc1912-errors.html>.
RRFFCC 11771133
A. Romao, _F_e_r_r_a_m_e_n_t_a_s _p_a_r_a _d_e_p_u_r_a_ç_ã_o _d_o _D_N_S , 03/11/1994.
RRFFCC 11771122
C. Farrell, M. Schulze, S. Pleitner, D. Baldoni,
_C_o_d_i_f_i_c_a_ç_ã_o _D_N_S _p_a_r_a _L_o_c_a_l_i_z_a_ç_ã_o _G_e_o_g_r_á_f_i_c_a, 01/11/1994.
RRFFCC 11118833
R. Ullmann, P. Mockapetris, L. Mamakos, C. Everhart, _N_o_v_a_s
_D_e_f_i_n_i_ç_õ_e_s _d_e _R_R _D_N_S, 08/10/1990.
RRFFCC 11003355
P. Mockapetris, _D_o_m_í_n_i_o_s _- _i_m_p_l_e_m_e_n_t_a_ç_ã_o _e _e_s_p_e_c_i_f_i_c_a_ç_ã_o,
01/11/1987.
RRFFCC 11003344
P. Mockapetris, _D_o_m_í_n_i_o_s _- _c_o_n_c_e_i_t_o_s _e _i_n_s_t_a_l_a_ç_õ_e_s, 01/11/1987.
RRFFCC 11003333
M. Lottor, _G_u_i_a _d_e _o_p_e_r_a_ç_õ_e_s _d_e _a_d_m_i_n_i_s_t_r_a_d_o_r_e_s _d_e _d_o_m_í_n_i_o_s,
01/11/1987.
RRFFCC 11003322
M. Stahl, _G_u_i_a _d_e _a_d_m_i_n_i_s_t_r_a_d_o_r_e_s _d_e _d_o_m_í_n_i_o_s , 01/11/1987.
RRFFCC 997744
C. Partridge, _R_o_t_e_a_m_e_n_t_o _d_e _c_o_r_r_e_i_o _e _d_o_m_í_n_i_o_s , 01/01/1986.