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

[Adriano Nagelschmidt Rodrigues]

Frederico A C Neves writes:

[snip]

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

http://cr.yp.to/djbdns/killa6.html

Out-of-bailiwick pointers destroy DNS lookups in three ways:

    * Every out-of-bailiwick pointer means more queries and more opportunities
      for delay: packets are lost and have to be resent. The chance of finding
      an answer before client timeout decreases exponentially with the number
      of out-of-bailiwick pointers.

    * Caches have to limit the number of queries and the amount of memory that
      they dedicate to a single lookup. When these limits are exceeded,
      lookups fail.

    * As illustrated by the AOL suicide example, every out-of-bailiwick
      pointer is another opportunity to create a loop. When a loop appears,
      lookups fail. 

  These problems are not new. Lookups occasionally fail because system
  administrators have used too many out-of-bailiwick NS records, for
  example. (I tell my users to select in-bailiwick server names. My software
  automatically uses a.ns.fqdn, b.ns.fqdn, etc. as the default server names
  for fqdn. I also tell my users to avoid CNAME records.)

> Analise o contexto.

O contexto é o pacote inteiro (djbdns x bind). Um dos problemas do bind é que
ele é monolítico: o cache e o servidor são o mesmo programa.

http://cr.yp.to/djbdns/separation.html

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

Os problemas não param na parte de segurança:

  http://cr.yp.to/djbdns/blurb/unbind.html

  The cache data structure isn't designed to allow FIFO operations; running out
  of memory is a disaster.

  The query data structure isn't designed to handle the complications of
  ``query restart''; lookups are delayed and sometimes fail.

  The record data structure isn't designed to handle unrecognized types; every
  new type is an interoperability disaster.

  BIND sometimes sends SIGTERM to the wrong place, accidentally killing itself.

  BIND forgets to free memory it has allocated for AR names, so it chews up
  more and more memory until it dies.

E a lista continua, ad nauseam (literalmente).

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

Ok, mas eu gostaria de saber quais são os seus argumentos contra o
_tinydns_. Você citou dois:

1) 'O tinydns não respeita a rfc1034 com relação a referências'

2) 'Além deste e do "serial number" diferente no record SOA entre os
    servidores autoritativos nada mais.'

O problema # 2 não existe, era isso que eu estava tentando mostrar no meu
último email, e talvez eu não tenha sido claro.

O problema # 1 pode ser contornado, o tinydns pode ser configurado para ter o
mesmo comportamento do bind nesse caso. E por que isso não é default?
Sinceramente, não sei. Talvez pelos motivos citados acima (qv Out-of-bailiwick
pointers...).

Mudando de assunto, aqui vão algumas coisas que o tinydns oferece e que podem
reduzir bastante o número de erros cometidos num zone file:

http://cr.yp.to/djbdns/run-server-bind.html

Automatic TTLs, Automatic colons, Combined A and PTR records, Combined MX and
A records, Automatic MX preferences, Automatic final dots, Combined NS and A
records, Automatic SOA timers, More automatic SOA information, Combined SOA,
NS, and A records.

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

http://cr.yp.to/djbdns/axfr-clarify.html

[snip]

Abraço,

--
Adriano