[GTER] DNS, era Re: Luta contra SPAM

[Adriano Nagelschmidt Rodrigues]

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

Você tem razão:

[chianti:~] $ dnsq ANY registro.br 127.53.0.2
255 registro.br:
timed out

> Se isto pode ser atingido via uma configuração como diz o email do
> autor do servidor [...]

Pode:

[chianti:~] $ dnsq ANY registro.br 127.53.0.2
255 registro.br:
76 bytes, 1+0+1+1 records, response, noerror
query: 255 registro.br
authority: . 259200 NS a.root-servers.net
additional: a.root-servers.net 259200 A 198.41.0.4

> [...] estão seria muito prudente que ao menos ela fosse default.

É um assunto polêmico:

  http://marc.theaimsgroup.com/?l=djbdns&m=104164930221026&w=2

  The short answer is "rfc1034 was written with nameservers doing both
  recursive and nonrecursive service, and in today's Internet not giving out
  out-of-bailwick referrals is a completely reasonable behavior for an
  authoritative server".  And this opinion is shared by many---including
  Vixie.

  In particular, Vixie says this:

    it's certainly possible that since "authoritative only" name
    servers were not contemplated by the standard, that this is an
    obscure corner case and would have been resolved differently had
    such contemplation occurred.

  and, similarly, Yushin say this:

     Now it seems that nobody really knows how the resolvers would
     react yet we need to have a clear answer on what authorative only
     (non-recursive) nameserver should (must) do when it doesnt know
     anything about the query it has received. Current RFC's are not
     much of a help since apparently nobody thought back then that
     there will be name servers who wont do any recursion.

  Also, Austein points out that tinydns's response apparently is
  permitted by rfc1035; he says:

    ... and, the behavior of certain widely deployed software
	notwithstanding, there is nothing in RFC 1035 that requires
	a name server either to know where the root is or to supply
	a referal if it doesn't know.

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

Isso é altamente debatível. Vide acima.

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

[snip]

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

Pode ser um problema. Aqui está um usuário que concorda com você:

  http://marc.theaimsgroup.com/?l=djbdns&m=104171299027324&w=2

  ...allowed other nameservers to realize I was lame. This has nothing to
  do with outside admins, but nameservers marking me as lame and leaving
  me alone for whatever their delay is when they note that a nameserver
  lame. 

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

My mistake.

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

É uma postura razoável. Mas por tudo o que eu tenho observado (eg tentativa de
criar um fórum pago onde seria feita a divulgação preliminar de bugs do bind),
é claro que eu simpatizo muito mais com o DJB.

> 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

[snip do email]

A data de envio é recente.

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

É mais provável que o seu email esteja no backlog dele (que é bastante
grande). Ele deve demorar pelo menos um mês (estimativa conservadora) para
responder/processar emails da fila genérica. Vamos checar a página de novo
daqui algumas semanas.

Abraço,

--
Adriano