On Tue, 19 Jun 2001, Leonardo Costa wrote:

> Tenho instalado a vers�o atualizada do BIND8 no meu server.
> Recentemente tive que alterar a configura��o do mesmo na parte do
> MX.  o mx � o mail.meuservidor.com.br onde o mail era o cname da
> m�quina 200.x.x.2 e depois o mail virou cname na maquina 200.x.x.3


N�o coloque MX apontando para um nome que � um CNAME.  Isso � contra o
padr�o, apesar de funcionar.


> Esperei o tempo necess�rio para que a atualiza��o de DNS fosse feita(acho
> que dura normalmente 72hs) s� que isso n�o aconteceu corretamente.

O "normalmente" � o tempo do TTL default voc� programou em seu DNS,
veja com um DIG:

        dig meuservidor.com.br ns


> V�rios dominios reconhecem o novo (200.x.x.3) e outros v�rios ainda
> v�o para o antigo(200.x.x.2). O detalhe � que alguns desses que j�
> sabiam que o novo � 200.x.x.3 de uma hora para outra voltam para o
> 200.x.x.2.

Isso pode acontecer, at� esgotar o TTL a partir do momento em o �ltimo
servidor slave atualizar a informa��o conforme as novas informa��es no
master.  E a atualiza��o no slave s� acontece que voc� incrementou o
"serial" do SOA.

Quando se solicita uma informa��o qualquer de um dom�nio, ou quando o
servidor pega a informa��o num dos servidores que s�o a autoridade
naquele dom�nio, o servidor acrescenta informa��es adicionais (glued
information) que s�o normalmente necess�rias, no intuito de evitar uma
segunda solicita��o.

Por exemplo: um servidor deseja saber qual � o MX de yahoo.com.  Ao
obter essa informa��o diretamente num dos servidores do yahoo, a
informa��o vem com o MX e tamb�m com os NSs do dom�nio, e com os "A"
dos NSs.  Digamos que quem respondeu essa informa��o foi
NS1.yahoo.com, e o servidor do yahoo acrescentou os NSs:

      NS5.DCX.yahoo.com
      NS3.EUROPE.yahoo.com
      NS1.yahoo.com

nessa ordem.  Quando seu servidor for solicitado a obter a informa��o
"www.yahoo.com", ele vai pegar "no pr�ximo registro de NS" deste
dom�nio, NS5.DCX.yahoo.com, e vai "rodar" a lista, que fica
INTERNAMENTE ao seu servidor para:

      NS3.EUROPE.yahoo.com
      NS1.yahoo.com
      NS5.DCX.yahoo.com


Isso significa que mesmo que a informa��o em NS1.yahoo.com tenha sido
mudada, os outros servidores secund�rios podem estar fornecendo a
informa��o antiga, e quem obteve essa informa��o vai guarda-la por, no
m�ximo, o TTL desse registro.

Se por ventura o administrador alterar NS1.yahoo.com e esquecer de
incrementar o serial do SOA, ent�o os servidores NS3.EUROPE.yahoo.com
e NS5.DCX.yahoo.com N�O v�o fazer um dump das novas informa��es da
zona, e a� os servidores secund�rios v�o estar oferecendo informa��es
erradas.

O tempo que o secund�rio vem pegar informa��o no prim�rio � definido
no tempo "refresh" do SOA.  O prim�rio pode ser programado para
"cutucar" os secund�rios, para que estes verifiquem se � necess�rio
novo dump das informa��es da zona (comparando-se os serias do SOA)

Portanto, o tempo de total para expira��o das informa��es espalhadas
pela Internet pode chegar � "TTL+refresh".


> Gostaria de saber se o erro � no meu DNS ou nos DNS dos outros.

Raramente � problema dos outros.  Ou � caracter�stica do sistema, ou
problema no seu DNS, e muitas vezes � um problema que precisa "passar
o TTL" para ser corrigido.

O DNS � um banco de dados onde os registros tem prazo de validade e
n�mero de s�rie.  As informa��es emitidas pelo seu servidor s�o
consideradas verdadeiras e v�lidas pelo tempo do TTL a partir do
momento em que seu servidor forneceu a informa��o.

Existe uma rede complexa de servidores que pegam informa��es em outros
servidores, de forma que nunca se sabe qual � origem da informa��o que
um cliente obteve.

Entretanto, quando um servidor n�o � autoridade sobre uma informa��o
que ele est� repassando, do TTL fornecido j� � descontado do tempo
decorrido desde a obten��o da informa��o no servidor autoritativo.
Isto �, se um servidor pegar a informa��o em seu sistema, seu sistema
passa "TTL=72h", 10h depois este servidor vai fornecer essa informa��o
para um outro cliente com "TTL=62h".


--- Wagner                      [EMAIL PROTECTED]


Assinantes em 22/06/2001: 2318
Mensagens recebidas desde 07/01/1999: 119396
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista: 
            mailto:[EMAIL PROTECTED]

Responder a