[GTER] Re: DNS, era Re: Luta contra SPAM

[Frederico A C Neves]

Adriano,

On Fri, Jan 10, 2003 at 09:52:27AM -0200, Adriano Nagelschmidt Rodrigues wrote:
> Frederico A C Neves writes:
> > 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.
> 
> Esse é um detalhe acadêmico. Vamos deixá-lo assim?
> 

Isto não tem nada de acadêmico. É um problema real e passa da casa dos
milhares. Mesmo o dnstrace que vc cita não consegue diferenciar um
descarte por política de acesso, uma perda de pacote na rede ou um
servidor com a configuração "default" desta forma. Este tipo de
comportamento é um dos principais a contribuir para a percepção de que
a "internet é lenta".

...

> 
> Acho que responder com um empty answer section e aa bit ! set, isso sim seria
> complicado. Como reagiriam os clientes? Existe algum exemplo disso no RFC
> 1034?
> 

Um resolver corretamente implementado sempre verifica se o "answer
section" contem algo relevante a sua consulta e vai saber diferenciar
e tomar a atitude correta, isto em milissegundos caso receba a
resposta e não em meio minuto como é o resultado devido a esta forma
de ação.

...

> > problemas reais que enfrentamos diariamente.
> 
> Você levantou algumas curiosidades sobre o tinydns que eu não conhecia. Em
> compensação, imagino que entre seus problemas reais diários estejam coisas
> como:
> 
> IQUERY buffer overflow in BIND before 8.1.2-T3B (1998); NXT bufer overflow in
> BIND before 8.2.2-P4 (1999); nslookupcomplain buffer overflow in BIND before
> 4.9.8 (2001); TSIG buffer overflow in BIND before 8.2.3 (2001); CNAME buffer
> overflow in libresolv before 4.9.9/8.2.6/8.3.3/9.2.2 (2002); SIG buffer
> overflow in BIND before 4.9.11/8.3.4 (2002); getnetbyname buffer overflow in
> libresolv before 4.9.11 (2002). All of these allowed attackers around the
> Internet to seize control of the program.
>

Analise o contexto. Praticamente tudo isto que vc cita (salvo o TSIG
que o tinydns não implementa) está relacionado a cache server, até
onde eu sei todos os meus comentários são em relação a servidores
autoritativos. Apesar disto não ter a menor importância, eu já falei
da implementação que vc está advogando, como sendo a melhor existente
hoje para cache servers, estamos concordando violentamente aqui.

...

>
> Uma solução melhor não é argumento válido?
>

Existem muito exemplos que comprovam que esta solução, out-of-band,
one-size-fits-all, como na maioria das vezes, não serve para todos os
casos. Veja o thread sobre este draft na namedroppers
(draft-ietf-dnsext-axfr-clarify-05.txt).

> 
> O problema do SOA não existe.
>

Realmente não, no nosso caso, é somente um delírio de milhares de
delegações que se comportam desta
forma. (http://registro.br/estatisticas.html , canto inferior
direito). Esta implementação é bem popular hoje em dia !

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

[]s
Frederico