[GTER] DNS, era Re: Luta contra SPAM

[Frederico A C Neves]

Adriano,

On Thu, Jan 09, 2003 at 05:41:14PM -0200, Adriano Nagelschmidt Rodrigues wrote:
> Frederico,
> 
> Obrigado pela resposta e pelos pontos relevantes que você levantou. É claro
> que eu não vou resistir a comentá-la ;-)
> 
> Frederico A C Neves writes:
> > If recursive service is not requested or is not available, the non-
> > recursive response will be one of the following:
> > 
> >    - An authoritative name error indicating that the name does not
> >      exist.
> > 
> >    - A temporary error indication.
> > 
> >    - Some combination of:
> > 
> >      RRs that answer the question, together with an indication
> >      whether the data comes from a zone or is cached.
> > 
> >      A referral to name servers which have zones which are closer
> >      ancestors to the name than the server sending the reply.
> > 
> >    - RRs that the name server thinks will prove useful to the
> >      requester."
> 

...

> > 
> > Não interessa o bom motivo se ele não for standard.
> 
> Isso é altamente debatível. Vide acima.
> 

Não tenho tanta certeza assim. O trecho da RFC acima me parece muito
claro em relação a este aspecto. Ele não diz exatamente qual das
respostas enviar para este tipo de problema mas está muito claro que
deve-se responder.

Um referral para a raiz é algo intuitivo pois é o início de tudo. O
argumento da não necessidade do conhecimento da raiz, este sim é
amplamente discutível. Estamos falando de um sistema hierárquico e
distribuído e ter referência à raiz faz todo sentido.

O ponto aqui é que ele não precisa nem responder como as outras
implementações, basta que dele retorne uma resposta com o "answer
section" zerado e o bit aa não marcado, ou uma outra variação qualquer
disto e pronto, vai ser "standard compliant" e atende ao problema da
detecção de lame delegation. O que não pode é não responder.

> > > Existe mais algum exemplo de quebra de rfc por parte do tinydns?
> > 
> > Além deste e do "serial number" diferente no record SOA entre os
> > servidores autoritativos nada mais.
> 
> Ok. Não me parece grave.
>
> Não entendi exatamente qual o problema relativo ao serial # no SOA (pq eles
> seriam diferentes?), mas como você quer terminar esse thread, let it be.
> 

Não disse que um debate baseado em fatos é algo que deva parar. O
problema aqui é a sua aparente motivação em advogar a versão A em
detrimento a B de um software. A lá Linux x BSD, Postgres x Mysql,
Java x C++ e por ai vai.... Este tipo de debate em geral é "religioso"
, cheio de argumentos ad nauseum e não produz resultado prático.

Toda minha argumentação, é baseada na interpretação do standard de
problemas reais que enfrentamos diariamente. Não estou falando em
gosto por forma de operação e muito menos não estou me baseando em
citações ou simpatia.

Estou continuando a responder pois me parece uma oportunidade muito
boa para retirar o tabu de que esta lista não admite polêmica. Alguém
no passado já me disse isto. A lista é publica e esta aqui para
discutir aspectos de engenharia de redes. Filosofia, Marketing,
Religião etc.. tem outros lugares muito mais adequados aonde podem ser
discutidos.

Bem desculpe pelo desvio, voltando ao ponto do SOA,

Aparentemente a implementação do tinydns pega esta informação da date
de modificação do db de zona no file system.

> dig @a.ns.yp.to. cr.yp.to soa
yp.to.  42m40s IN SOA a.ns.yp.to. hostmaster.yp.to. (
                                        1033711957      ; serial

> dig @b.ns.yp.to. cr.yp.to soa
yp.to.  42m40s IN SOA a.ns.yp.to. hostmaster.yp.to. (
                                        1033711959      ; serial

Um problema muito comum e grave é o de erros intermitentes na
resolução DNS. Isto em geral ocorre devido a não sincronização entre
servidores autoritativos para uma zona. O serial do SOA é a forma que
existe para se verificar a sincronização entre servidores, e se
notificar o detentor da delegação para providenciar a correção.

Não me venha com o argumento de que com a solução utilizada por esta
versão de software para a sua replicação de zona este problemas não
existe pois ele existe. Qualquer software pode e é comumente
configurado de forma errada !

Para um resolver qualquer não existe distinção entre os servidores
delegados de uma zona. A resposta que ele deve obter deles deve ser
sempre a mesma.

...

Se vc vislumbra como resolver estes dois problemas, de alguma outra
forma que seja deterministica, por favor me indique, isto vai ser
muito bem vindo e ai este thread vai ter valido algo.

> 
> Abraço,
> 
> --
> Adriano

[]s
Frederico