Esta página está em processo de tradução.
D. J. Bernstein
Internet publication
djbdns
Blurbs
BIND é como Microsoft Windows. A droga da coisa não funciona. Cada versão está cheia de bugs.
Eu preciso publicar o endereço do meu computador. Eu preciso buscar os endereços de outros computadores. Quando eu estava usando o BIND, freqüentemente via que estas funções eram interrompidas pelos bugs do BIND. Aargh!
Alguns dos bugs do BIND são tremendas falhas de projeto. A estrutura de dados do cache não é projetada para permitir operações FIFO; ficar sem memória é um desastre. A estrutura de dados de query não é projetada para lidar com as complicações de "reinicio de query"; buscas são atrasadas e às vezes falham. A estrutura de dados de registro não é projetada para lidar com tipos desconhecidos; cada novo tipo é um desastre de interoperação.
Mas a maioria dos bugs são pequenos erros estúpidos. O BIND às vezes envia SIGTERM para o lugar errado, acidentalmente matando a si mesmo. O BIND esquece de liberar a memória que alocou para nomes AR, comendo, assim, mais e mais memória até morrer. O cache do BIND esquece de verificar um comprimento de buffer no código que lida com NXT, permitindo que qualquer um na Internet assuma o controle da máquina. Estes bugs específicos foram esmagados, mas novos bugs ficam surgindo para substituí-los.
Durante a reescrita de um milhão de dólares do BIND 9, Paul Vixie caracterizou o código do BIND original como "trabalho mal feito produzido em uma fúria embriagada por um monte de alunos de graduação da U C Berkley". Jogar fora todo aquele código produziria um sistema "robusto": o BIND 9 foi "escrito por uma grande equipe de desenvolvedores de software profissionais que tinham tempo e dinheiro suficientes para "conseguir acertar" ".
Mas o BIND 9 não foi acertado. Ele trava ainda mais que o BIND 8. Há centenas de bugs listados no arquivo CHANGES do 9.1.0rc1. Muitos destes são problemas de confiabilidade sérios; por exeplo, o "dns_zone_dum() sobreescreveu arquivos de zonas existentes ao invés de escrever em um arquivo temporário e renomear" significa que uma falta de luz temporária pode destruir endereços. Alguns dos bugs, assim como alguns dos bugs do BIND 8 descritos na página web "BIND security" da empresa BIND, permitem qualquer um na Internet a desabilitar o BIND com um único pacote. É apenas uma questão de tempo antes que alguém veja como um destes bugs do BIND 9 abre um furo de segurança.
A questão dos bugs do BIND 9 não surpreendeu aqueles de nós que prestavam atenção aos bugs do BIND 8. Eram a maioria deles culpa daqueles estudantes de graduação embriagados? Não! Os "desenvolvedores profissionais de software" na empresa BIND adicionaram enormes blocos de código "bugado" ao BIND. Por que deveríamos acreditar que as 300000 linhas de código novo no BIND 9 foram escritas mais cuidadosamente que as 130000 linhas de código novo do BIND 8?
A empresa BIND diz que o BIND 9 é "auditável". Eles dizem que usaram um "paradigma de programação por contrato". Bla, Bla, Bla. A questão é: ele não funciona.
Eu escrevi o ensaio acima em meados de janeiro de 2001. Dez dias depois, a empresa BIND anunciou outro buraco de segurança enorme no BIND 8. O bug TSIG, como o bug NXT, perite que qualquer um na Internet assuma controle da máquina.
Podem os bugs TSIG e NXT ser rastreados até aqueles alunos de graduação embriagados? Não! Ambos apareceram como novas features no BIND 8.2.
O BIND 9 foi fundado em agosto de 1998. Houve uma declaração pública de que "foram enviados códigos (para testes) para organizações de fundos" em março de 1999. Adivinhe quando o BIND 8.2 foi lançado... Isso mesmo: março de 1999.
Paul Vixie vem dizendo às pessoas que a equipe de programação do BIND 9 é "completamente diferente" da equipe de programação do BIND 8.
No entanto, fui informado por uma fonte confiável que Michael Graff trabalhou em ambos o BIND 8 e BIND 9. A segunda parte disto está confirmado pela resposta "autores.bind" do BIND 9, que lista Bob Halley, David Lawrence, Danny Mayer, Damien Neil, Matt Nelson, Michael Sawyer, Brian Wellington, Mark Andrews, James Brister, Ben Cottrell, Michael Graff, e Andreas Gustafsson.
Pedi a Vixie uma explicação e julho de 2001. Também pedi a ele para declarar oficialmente quem trabalhou no BIND 8 e quem trabalhou no BIND 9. Ele não respondeu.
Eis um resumo do arquivo CHANGES do BIND 9.2.2rc1, publicado em 08/08/2002 pela empresa BIND:
9.0.0b2: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug
9.0.0b3: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug
9.0.0b4: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug
9.1.0b1: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug
9.1.0b2: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
"BIND9 é o *máximo*" ---Paul Vixie, 29/01/2002
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug
9.2.0a1: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug
9.2.0a2: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug
9.2.0a3: bug bug bug
9.2.0b1: bug bug bug bug
9.2.0b2: bug bug bug bug bug bug
9.2.0rc1: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug
9.2.0rc2: bug bug bug bug bug
9.2.0rc3: bug bug bug bug bug bug bug
9.2.0rc4: bug bug bug bug bug bug bug
9.2.0rc5: bug bug bug bug bug bug
9.2.0rc6: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug
9.2.0rc7: bug bug bug bug bug bug bug bug
9.2.0rc8: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug
9.2.0rc9: bug bug bug bug bug bug bug bug bug bug
9.2.0rc10: bug bug
9.2.0: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug
9.2.1rc1: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug
9.2.1rc2: bug bug bug
9.2.1: bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug
São seissentos e setenta e dois bugs. Muitos dos bugs recentes, como muitos dos bugs mais antigos, indicam problemas sérios. Por exemplo, o bug 1252 ("dig, host e nslookup não estavam verificando o endereço de onde vinha a resposta") significa que os utilitários de busca do BIND 9.2.1 eram vulneráveis a fraudes completamente triviais, e o bug 1310 ("rndc stop deixava de fazer com que zonas fossem gravadas no disco às vezes") significa que BIND 9.2.1 iria às vezes destruir endereços.
É isto que Paul Vixie chama de sistema "robusto"? Isto foi "escrito por uma grande equipe de desenvolvedores de software profissionais que tinham tempo e dinheiro suficiente para "conseguir acertar""? Aqueles programadores deveriam ter vergonha de si mesmos.