[GTER] Re: Re: Re: Luta contra SPAM

[Frederico A C Neves]

Adriano,

On Thu, Jan 09, 2003 at 11:06:34AM -0200, Adriano Nagelschmidt Rodrigues wrote:
...
> Você tem certeza que esse é um requisito do rfc1034 e não
> simplesmente prática estabelecida do bind?

"4.3.1. Queries and responses

...

   - The simplest mode for the server is non-recursive, since it
     can answer queries using only local information: the response
     contains an error, the answer, or a referral to some other
     server "closer" to the answer.  All name servers must
     implement non-recursive queries.

...

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."

Se isto pode ser atingido via uma configuração como diz o email do
autor do servidor estão seria muito prudente que ao menos ela fosse
default.

> Se sim, pode existir algum bom motivo para o tinydns se comportar
> desse modo?

Não interessa o bom motivo se ele não for standard.

> 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.

Este é um problema conceitual. O registro faz parte da zona, e se é a
mesma zona replicada entre servidores então ele precisa ser
idêntico. Tem outras implicações além do A/IXFR só para deixar claro
que isto não tem nada a ver com o método de distribuição da zona que o
tinydns utiliza.

Estas são não conformidades que pode-se até advogar menores uma vez
que nos casos de configuração correta não trazem nenhum problema. Mas
nos casos de erro simplesmente elas impedem que alguém monitore/aponte
o problemas.

...

> > Bem de qualquer forma como disse o Dantom este assunto é totalmente
> > "off topic" e este thread deve morrer por aqui.
> 
> OK, mas é importante que as informações corretas sejam apresentadas. Existe
> muita anti-propaganda e FUD sobre o djbdns.
> 
> Só preciso responder o mail do Danton e "away I go"...
>
> > O local correto para isto é:
> > 
> > "To: namedroppers at ops.ietf.org
> >  Subject: list policy
> 
> Essa lista não me parece muito imparcial ;-)
> 

Leia a minha mensagem. Não indiquei a namedroppers mas sim uma lista
específica sobre implementações DNS.

weenie-war at ops.ietf.org.

Com relação aos possíveis problemas que vc cita isto é assunto para o
IETF e não para a lista do Grupo de trabalho de engenharia de redes no
Brasil. As listas são públicas e os arquivos também, as referências já
foram passadas e cada um que tome a sua decisão de ler e verificar os
fatos pelas duas partes e não somente pelo url que vc passou. É
prudente que se leia a namedroppres antes de advogar a posição de
qualquer uma das partes.

Somente para citar um outro caso verifique a URL a seguir e veja se o
que está descrito nela é verdade. http://cr.yp.to/djbdns/dot-br.html

"Date: Mon, 9 Dec 2002 10:26:02 -0200
 From: Frederico A C Neves <fneves at registro.br>
 Subject: Incorrect information at cr.yp.to

 Dear Mr. Bernstein,

 Regarding the .br delegation information at
 http://cr.yp.to/djbdns/dot-br.html

 The statement about the need of servers in distinct /24 blocks is
 completely wrong. This restriction have never been in place.

 The technical restriction is that all the delegated servers for a
 domain name be configured for it. At delegation time and during the
 domain name life this is continually checked and reported (at our
 whois server and to domain name owners every 2 weeks) according to our
 lame-delegation policy.

 Regards,
 Frederico Neves"

Parece que isto foi para o /dev/null da mesma forma que ele alega que
os outros o tratam.

O processo de standard do IETF é complexo e tem suas salvaguardas para
garantir a transparência e o "rough consensus". Para isto existe a
dependência de participação construtiva. Respeitar o que emana do IETF
é a única maneira com a qual vamos garantir o futuro funcionamento da
internet. O resto é fuxico !

...

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

[]s
Frederico