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

Fri Jan 10 09:53:00 -02 2003

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?

  Felix von Leitner <leitner at fefe.de> writes:
  > tinydns does not answer at all.
  > Isn't that a violation of RFC 1034?

  If it is, you can easily fix it by adding &::a.root-servers.net to
  your data.  IOW, tinydns leaves the choice up to you: do you want to
  be RFC-compliant, or do you want the simplest thing that works?

  paul

[snip]

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

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?

E falando em problemas de configuração, o dnstrace parece ser uma ferramenta
interessante para encontrá-los:

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

  dnstrace uses the standard DNS resolution algorithm, but follows all possible
  paths in the algorithm. It prints all responses it receives from DNS servers;
  it also prints warnings about slow servers, dead servers, misdelegated
  (``lame'') servers, and misformatted packets. dnstrace is similar in spirit to
  DOC and dnswalk but is much more effective than those tools at debugging
  resolution problems.

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

Ou a minha aparente paranóia com segurança e estabilidade.

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

DNS é infraestrutura básica da Internet. O bom funcionamento e a segurança da
Rede são importantes. Não concordo com as suas analogias e muito menos com
o adjetivo "religioso".

> Toda minha argumentação, é baseada na interpretação do standard de
> 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.

Ou como:

That's six hundred seventy-two bugs. Many of the recent bugs, like many of the
earlier bugs, indicate serious problems. For example, bug 1252 (``dig, host
and nslookup were not checking the address the answer was coming from'') means
that the BIND 9.2.1 lookup utilities were vulnerable to completely trivial
forgeries, and bug 1310 (``rndc stop failed to cause zones to be flushed
sometimes'') means that BIND 9.2.1 would sometimes destroy addresses.

> Não estou falando em gosto por forma de operação e muito menos não estou me
> baseando em citações [...]

Citações & referências são fundamentais.

> [...] ou simpatia.

Usei "simpatia" como um eufemismo. Eu não queria dizer com todas as letras,
mas não gosto muito da tática usada pelo pessoal do bind para promover o
produto, que não se baseia em argumentos técnicos e procedimentos totalmente
abertos.

[snip]

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

O serial number usado é o mtime do arquivo 'data'. Mas também é possível
definir um serial number manualmente.

O procedimento normal é espelhar o arquivo data.cdb, o que faz com que zonas
iguais tenham serial numbers iguais.

Mas isso não é uma regra.

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

Pela diferença de dois segundos, imagino que ele esteja espelhando o arquivo
'data' e recriando o cdb. Prerrogativa dele.

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

A configuração padrão sugerida faz com que os serial numbers sejam
iguais. Isso pode não ser importante, veja abaixo.

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

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

O master faz um push dos dados para o slave assim que eles são modificados, é
uma solução robusta. Em caso de problemas, você fica sabendo na hora.

O Makefile padrão é simples:

     remote: data.cdb
             rsync -az -e ssh data.cdb 1.8.7.201:/service/tinydns/root/data.cdb

     data.cdb: data
             /usr/local/bin/tinydns-data

É claro que um slave fazendo polling do master para atualizar seus dados é uma
solução muito mais frágil, que precisa de cuidadoso monitoramento.

> Qualquer software pode e é comumente configurado de forma errada !

E, no caso do bind, isso chega a ser um problema de uso. Atualizar um zone
file e esquecer de incrementar o serial number é um acontecimento freqüente.

[snip]

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

O problema do SOA não existe.

Abraço,

--
Adriano