(M)  s i s t e m a   o p e r a c i o n a l   m a g n u x   l i n u x ~/ · documentação · suporte · sobre

  Página seguinte Página anterior Índice

100. Um Domínio Simples.

Como configurar um domínio próprio.

100.1 Mas primeiro um pouco de teoria

Antes de realmente 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.

100.2 Nosso Próprio Domínio

Agora vamos definir nosso próprio campo. Vamos criar o domínio linux.bogus 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á implícito 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.domínio, 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 todos 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 deve 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' funcione 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 nunca 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 muito 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.

100.3 A zona reversa

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.


Página seguinte Página anterior Índice