A Aldeia Numaboa ancestral ainda está disponível para visitação. É a versão mais antiga da Aldeia que eu não quis simplesmente descartar depois de mais de 10 milhões de pageviews. Como diz a Sirley, nossa cozinheira e filósofa de plantão: "Misericórdia, ai que dó!"

Se você tiver curiosidade, o endereço é numaboa.net.br.

Leia mais...

Informática Numaboa - Referências

SOA

Qui

19

Nov

2009


22:01
  • Imprimir
(3 votos, média 4.33 de 5) 
Detalhes
Categoria: Rede
Atualização: Domingo, 22 Novembro 2009 22:28
Autor: vovó Vicki
Acessos: 4629


Seja lá qual for o software que você usar para configurar um servidor de nomes, não tem como escapar de um arquivo que inclua um SOA, o acrônimo para Start of Authority. Eu mesma já coloquei no ar mais de um destes servidores e achava que dominava o assunto... até que descobri que muitos dos arquivos que criei não estavam 100% porque, pra variar, alguns conceitos básicos não estavam muito claros. Por este motivo resolvi criar este texto explicando as coisas da forma como as entendo hoje e a meu modo smile

O cenário

Resolvi criar um site e, para isto, preciso de um domínio. Escolhi o nome numaboa e o registrei no registro.br como numaboa.com.br. Depois de colocar meu site em trocentos serviços de hospedagem (nacionais e estrangeiros) e de sofrer todas as agruras de depender de terceiros, resolvi contratar um link exclusivo e configurar meu próprio servidor. Também rodei por vários links dedicados, os quais também deram muitos problemas, até encontrar um fornecedor confiável - a COPEL (se você for do Paraná, não hesite em contratá-los!).

Dito isto, vamos ao que interessa. Servidor web próprio significa também servidor de nomes próprio (por uma questão de princípio). É claro que eu poderia usar o servidor de nomes da própria COPEL ou um dos vários servidores de nomes gratuitos que existem, mas qual é a graça de fazer a coisa pela metade? Foi assim que entrei em contato com o SOA.

O que é o SOA

Um servidor de nomes (ou servidor DNS) nada mais é do que um serviço que traduz nomes de domínios (no meu caso numaboa.com.br) para um determinado endereço de rede (o endereço IP do meu servidor web ou do servidor de email). Para poder dar esta informação, meu servidor de nomes precisa ser incluído na rede mundial de servidores DNS de modo que, quando qualquer cidadão deste planeta (e também os robôs de pesquisa) procurarem pelo meu domínio, a pergunta vá se propagando de servidor em servidor até que chegue ao meu, o único que tem a autoridade de responder. Neste caso, autoridade significa que meu servidor de nomes assume a responsabilidade de dar os endereços IP corretos para o domínio solicitado.

Quando a pergunta bate no meu servidor, a fonte da informação é um arquivo que tem um formato específico. Este arquivo contém, entre outras coisas, o nome do domínio (numaboa.com.br), o endereço de email do responsável por ele (meu endereço de email), o nome do servidor de nomes com autoridade (o nome do meu servidor de nomes) e mais uma porção de coisas. Este arquivo deve incluir o SOA, o qual define parâmetros globais para um domínio (também chamado de zona). A definição do sistema de domínios você encontra na RFC 1035 (DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION).

Dissecando um arquivo de domínio

Só pode existir um único arquivo com SOA para determinado domínio. Este arquivo possui vários campos. Vou explorar cada um deles usando alguns exemplos.

TTL

TTL vem de Time to Live, ou seja, tempo de vida. O campo TTL, no contexto DNS, define o tempo em segundos que o registro pode ficar em cache antes da sua leitura ser renovada pelos outros DNS, ou seja, é o tempo que pode levar até que todo o sistema mundial esteja atualizado. Os valores definidos como aceitáveis estão especificados na RFC 2181 e variam de 0 a 2147483647 (231 - 1). O valor 0 significa ausência de cache, mas praticamente não é usado; o valor mais alto dá mais de 68 anos!

O BIND permite uma porção de notações diferentes para o tempo. Se for expresso em segundos, usa-se apenas o número de segundos desejado. As outras alternativas são:

  • m: para minutos (1m = 1 minuto = 60 segundos)
  • h: para horas (1h = 1 hora = 3600 segundos)
  • d: para dias (1d = 1 dia = 86400 segundos)
  • w: para semanas (1w = 1 semana = 604800 segundos)

A RFC 1912 recomenda que o valor do TTL seja de 1 dia ou mais e que arquivos que são alterados raramente tenham TTLs de 2 a 3 semanas. É bom lembrar que um valor 2d (2 dias) faz com que as alterações efetuadas possam demorar até 48 horas para se propagarem pelo sistema e também faz com que o caching dos servidores DNS solicite informações ao seu servidor de nomes a cada 48 horas (o que é uma sobrecarga que não deve ser esquecida). Muitos administradores de DNS costumam atribuir 2w ou 3w (2 a 3 semanas) ao TTL. Quando fazem uma alteração, reduzem este valor para 1d (1 dia) ou 12h (12 horas) até que a alteração tenha se estabilizado e depois voltam o TTL para 2w ou 3w.

Uma informação tão vital (já que indica o tempo de vida smile) com esta precisa ser a primeira coisa num arquivo de domínio. O Bind9 oferece a diretiva $TTL para especificar o valor desejado:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos

'Nome raiz' da zona (domínio)

O campo 'nome raiz' costuma ser expresso na notação ORIGIN ou @. Assim como para o TTL, o BIND oferece uma diretiva $ORIGIN para este caso:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.

Observe o ponto no final do nome do domínio. Este ponto impede que o BIND complemente o valor com o nome da zona especificada no arquivo named.conf. Só para lembrar, este arquivo do BIND pode ter o seguinte aspecto:

// fragmento do arquivo named.conf

zone "exemplo.com.br" in(
   type master;
   file "exemplo.com.br.db";
)

Neste exemplo, o nome do domínio (exemplo.com.br) vem logo após a diretiva zone e chama o arquivo de domínio exemplo.com.br.db. Se não colocarmos o ponto no fim do 'nome raiz', o BIND o transforma em exemplo.com.br.exemplo.com.br o que, logicamente, vai gerar um erro. Aliás, este é um dos erros mais comuns num arquivo de domínio.

O campo SOA

Finalmente chegou a hora de declarar nossa "otoridade". Para isto usamos o Registro de Recurso (Resource Record ou RR) SOA. Existem vários tipos de registros de recurso. Os mais comuns são:

  • A: um endereço de host (servidor)
  • NS: um servidor DNS autoritativo
  • CNAME: um nome canônico para um alias
  • SOA: marca o início de uma zona de autoridade
  • PTR: um ponteiro de nome de domínio
  • MX: um servidor de email

Para marcar o início de uma zona de autoridade começamos com o nome raiz, indicamos a classe IN (de Internet), usamos o SOA, informamos o nome do nosso servidor DNS e o endereço de email do responsável pelas informações:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.
exemplo.com.br.   IN   SOA   dns.exemplo.com.br.   webmaster.exemplo.com.br. (

Observe que o endereço de email tem apenas pontos de separação, ou seja, não usa a @. O motivo é que @ tem um significado especial para o BIND (veja abaixo). Observe também que tanto o nome raiz, quanto o nome do servidor de nomes e o endereço de email terminam com um ponto. O motivo você já sabe: se não fizer assim, o BIND gruda o nome do domínio no final destas informações. No fim desta linha abrimos um parêntese para indicar que, tudo o que vier depois, até o parêntese de fechamento, pertence à zona de autoridade.

Agora posso explicar o que é @ (citada quando falei do nome raiz e da ORIGIN). O BIND troca a @ pelo valor do parâmetro $ORIGIN e, na falta deste, pelo nome do domínio especificado no arquivo named.conf. Se é assim, podemos simplificar nosso arquivo de domínio da seguinte maneira:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.
@   IN   SOA   dns.exemplo.com.br.   webmaster.exemplo.com.br. (

Da mesma forma, como sabemos que, se não usarmos o ponto final no nome do servidor DNS e no endereço de email, o BIND gruda o nome do domínio no final, podemos simplificar nosso arquivo mais um pouco:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.
@   IN   SOA   dns   webmaster (

É claro que não podemos usar este expediente se o domínio do servidor DNS e/ou o endereço de mail forem de outro domínio (por exemplo, dns.exemplo.net.br ou webmaster.hotmail.com). Neste caso, estas informações são chamadas de fora-de-zona (out-of-zone ou out-of-bailiwick) e precisam ser referenciadas por completo.

Dentro da zona de autoridade existem vários campos. A seguir vamos analisar o número de série, refresh, retry e expiry.

Número de série

Cada arquivo de zona precisa ter um número de série que indica a versão do mesmo. Os servidores DNS que fazem leituras no nosso servidor para atualizar suas bases de dados procuram o número de série. Se este for maior do que o que eles possuem, é feita uma releitura dos dados. O formato convencionado é ano/mês/dia/número. No nosso exemplo, considerando a data em que este artigo foi escrito, fica assim:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.
@   IN   SOA   dns   webmaster (
         2009111900     ; número de série

O número de série nos indica a data em que a criação/modificação ocorreu (19.11.2009) e quantas vezes fizemos alterações neste dia: 00, 01, 02, etc. Um erro muito comum é esquecer de alterar o número de série quando o arquivo é modificado. Não se esqueça de fazê-lo, senão as informações não serão atualizadas. Existem outros erros com os quais também precisamos nos preocupar. Se for definido um número de série menor do que o anterior, a atualização também não ocorre. Este é fácil de corrigir: basta trocá-lo por um número de série maior que o anterior.

O que acontece se colocarmos um número de série bem maior, por exemplo 2019111900? Neste caso pode-se corrigir o erro em duas etapas. Para isto precisamos saber que o número de série é um número de 32 bits, portanto, seu valor pode variar de 0 a 4294967295 (232 - 1). Depois deste limite, quando adicionamos 1, "estouramos" o espaço disponível, o valor volta a ser zero e, apesar do resultado ser nulo, o novo serial é considerado maior do que o anterior. Sabendo disto, a correção pode ser feita em duas etapas.

Inicialmente calculamos a diferença entre o valor máximo e o valor errado e somamos 1 para obter o resultado nulo provocado pelo "estouro": 4.294.967.295 - 2.019.111.900 + 1 = 2.275.855.396. Trocamos o serial errado pelo calculado e esperamos até ter certeza de que o sistema foi atualizado. Na segunda etapa, troca-se o valor calculado pelo serial com a data correta e deixamos o barco correr smile

Refresh, Retry e Expiry

Estes valores andam de mãos dadas. Estes valores são expressos em segundos ou, como vimos acima, em m (minutos), h (horas), d (dias) ou w (semanas).

Refresh (atualizar) é o tempo que os servidores têm para fazer uma atualização depois de uma alteração (indicada por um número serial maior) feita num arquivo de zona. Preconiza-se valores de 1200 (20 minutos) a 43200 (12 horas). Se a tentativa de leitura falhar, entra em cena o Retry.

O Retry (tentar novamente) é o tempo que o servidor que não conseguiu fazer a leitura deve esperar para fazer uma nova tentativa. São recomendados valores entre 180 (3 minutos) e 900 (15 minutos). Se não houver um limite de tentativas, o(s) servidor(es) que não consegue(m) fazer contato vão ficar tentando fazer leituras indefinidamente. Agora entra em cena o Expiry.

O Expiry (prazo expirado) é o tempo em que podem ocorrer tentativas de leitura repetidas (retry). O valor preconizado fica entre 1209600 e 2419200 segundos (2 a 3 semanas). Atingido este limite, o nosso DNS não responde mais autoritativamente, ou seja, deixa de responder solicitações para o nosso domínio. Neste ponto, cuidado! O valor de expiry não pode ser menor do que o refresh ou o retry.

A esta altura do campeonato, nosso arquivo de zona fica assim:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.
@   IN   SOA   dns   webmaster (
         2009111900     ; número de série
         6h             ; refresh de 6 horas
         15m            ; retry a cada 15 minutos
         2w             ; expiry depois de 2 semanas

Minimum

O Minimum é o tempo em segundos que qualquer resolvedor pode deixar em cache um erro do tipo NAME ERROR = NXDOMAIN. O valor máximo permitido para este parâmetro é de 3 horas (10800 segundos). Vale a pena lembrar que isto vale a partir do BIND 9; nas versões anteriores, este parâmetro era usado para definir o TTL. Vamos incluir este parâmetro no nosso arquivo de zona:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.
@   IN   SOA   dns   webmaster (
         2009111900     ; número de série
         6h             ; refresh de 6 horas
         15m            ; retry a cada 15 minutos
         2w             ; expiry depois de 2 semanas
         1h30m          ; minimum
         )

Observe que, para encerrar o SOA, usamos o parêntese de fechamento. Na verdade, este texto deveria terminar neste ponto porque o SOA foi explicado na sua totalidade, mas não custa dar mais algumas dicas.

Servidores de nomes para nosso domínio

Quando registramos um domínio no registro.br (ou qualquer outro órgão responsável pelo controle de domínios), é preciso especificar pelo menos dois servidores de nomes com autoridade para este domínio. Se os servidores de nomes estiverem fora do nosso domínio, basta referenciá-los:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.
@   IN   SOA   dns   webmaster (
         2009111900     ; número de série
         6h             ; refresh de 6 horas
         15m            ; retry a cada 15 minutos
         2w             ; expiry depois de 2 semanas
         1h30m          ; minimum

    IN   NS   exemplo.net.br.
    IN   NS   dns.org.br.

Como ainda estamos nos referindo à Internet, começamos com IN. Para indicar que a informação se refere a servidores de nomes, usamos NS. Novamente não esqueça do ponto no final dos endereços, senão exemplo.net.br será transformado em exemplo.net.br.exemplo.com.br e dns.org.br será transformado em dns.org.br.exemplo.com.br pelo BIND. Lembra? smile

Se os servidores de nomes fizerem parte do nosso domínio, precisamos referenciá-los e, como autoridade que somos, precisamos informar o endereço IP dos ditos cujos:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.
@   IN   SOA   dns   webmaster (
         2009111900     ; número de série
         6h             ; refresh de 6 horas
         15m            ; retry a cada 15 minutos
         2w             ; expiry depois de 2 semanas
         1h30m          ; minimum

    IN   NS   ns1.exemplo.com.br.
    IN   NS   ns2.exemplo.com.br.

ns1.exemplo.com.br.     200.95.65.1
ns2.exemplo.com.br.     200.95.65.2

Como temos o ORIGIN para fazer a complementação do endereço e ainda estamos sob a @, podemos simplificar as informações da seguinte maneira:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.
@   IN   SOA   dns   webmaster (
         2009111900     ; número de série
         6h             ; refresh de 6 horas
         15m            ; retry a cada 15 minutos
         2w             ; expiry depois de 2 semanas
         1h30m          ; minimum

    IN   NS   ns1
    IN   NS   ns2

ns1     200.95.65.1
ns2     200.95.65.2

Servidores de email para o nosso domínio

Da mesma forma como indicamos servidores de nomes, se tivermos servidores de email e/ou nosso site usar o nosso domínio, estes precisam ser especificados:

; exemplo.com.br.db
; arquivo de zona para o domínio exemplo.com.br
;
$TTL 2d     ; TTL default para a zona = 2 dias ou 172800 segundos
$ORIGIN exemplo.com.br.
@   IN   SOA   dns   webmaster (
         2009111900     ; número de série
         6h             ; refresh de 6 horas
         15m            ; retry a cada 15 minutos
         2w             ; expiry depois de 2 semanas
         1h30m          ; minimum

    IN   NS   ns1
    IN   NS   ns2
    IN   MX   10 mail

ns1     200.95.65.1
ns2     200.95.65.2
mail    200.95.65.3
www     200.95.65.1
Вадим Логофет детиинтернет магазин кистей для макияжаооо полигон адреспланшет android полигонкупить столовуюдепутат лобановский

Informações adicionais