Summary

  • O relatório de Berkeley de 1984 descreveu o BIND como um serviço de nomes para ambientes Unix distribuídos; não afirmou que Berkeley inventou o DNS nem escreveu seu primeiro servidor.
  • Em 1987, a documentação operacional registrava o BIND entre os programas distribuídos com o 4.3BSD. Dois anos depois, um guia da Internet o descrevia como integrado ao Unix e capaz de substituir consultas baseadas em /etc/hosts.
  • A mudança foi operacional: as especificações definiam o comportamento comum, enquanto a distribuição do software e as zonas mantidas localmente permitiam que administradores publicassem os nomes de suas redes.

Não bastava especificar o protocolo

Um sistema de nomes pode ser elegante no papel e ainda deixar intacto o trabalho diário. Alguém precisa instalar o servidor, fornecer os dados, mantê-los atualizados e fazer os programas locais consultarem o resolvedor. A contribuição de Berkeley ao DNS nascente foi acomodar esse trabalho no ambiente Unix.

Em 1984, Douglas Terry, Mark Painter, David Riggle e Songnian Zhou publicaram um relatório técnico sobre o servidor Berkeley Internet Name Domain. O resumo descreve uma forma comum de nomear recursos em ambientes Unix distribuídos, armazenar e recuperar informações e organizar um espaço hierárquico dividido em domínios que refletiam entidades administrativas. É um modelo de software e operação, não uma reivindicação de autoria do DNS. Paul Mockapetris já havia escrito um servidor anterior, o Jeeves, para USC-ISI e SRI-NIC; o histórico posterior do ISC distingue aquele trabalho do projeto de Berkeley.

A pergunta prática do BIND era como um host Unix participaria de um sistema cujos dados estavam divididos entre vários domínios administrativos. A resposta combinava um servidor, arquivos locais e o caminho de resolução já usado pelo host. O administrador do domínio mantinha os registros de sua parte da árvore; o resolvedor consultava os servidores responsáveis e armazenava as respostas em cache. O espaço era distribuído porque dados e responsabilidades também eram, não porque cada usuário precisasse memorizar onde cada máquina ficava.

A rede em operação também alterou as especificações

A sequência importa. As primeiras descrições do DNS apareceram nas RFCs 882 e 883, em 1983. Em janeiro de 1986, a RFC 973 de Paul Mockapetris já registrava mudanças, orientações operacionais, problemas observados e limitações do sistema em uso. O documento diz que mudanças amplamente adotadas deveriam ser consideradas parte da especificação. A experiência de implementadores e operadores voltava ao texto do protocolo enquanto o sistema funcionava.

As especificações revisadas, RFC 1034 e RFC 1035, saíram em novembro de 1987. Elas definiam conceitos do DNS e detalhes de implementação. Regras comuns para nomes, registros, consultas, cache e delegação eram necessárias para a interoperabilidade. Mas as RFCs não eram um programa que o administrador pudesse instalar. Também eram necessários software e instruções operacionais.

O relatório de Berkeley de 1984 apresenta o BIND como serviço para recursos Unix distribuídos. O histórico do BIND publicado pelo ISC identifica a equipe inicial e afirma que o Computer Systems Research Group manteve o software até a versão 4.8.3. Esse relato retrospectivo mostra a trajetória do projeto, mas não quantas máquinas usaram cada versão.

A distribuição BSD colocou o serviço ao alcance dos administradores

Uma pista contemporânea está na RFC 1033, o guia operacional de domínios publicado em novembro de 1987. Seu apêndice trata explicitamente do BIND “distribuído com 4.3 BSD UNIX”. Ele explica arquivos próprios de inicialização e cache, como named.boot, e dá exemplos de dados de zona. Não diz que toda instalação BSD executava um servidor de nomes. Mostra que o administrador podia receber o BIND em uma distribuição Unix familiar e consultar instruções para configurá-lo.

Esse empacotamento reduziu o custo de experimentar. O administrador não precisava escrever um servidor DNS antes de criar um domínio. Podia iniciar o serviço com um arquivo de configuração, carregar dados de zona, responder a consultas locais e procurar outros servidores quando o nome estivesse fora de sua autoridade. Ainda precisava manter registros corretos, respeitar a delegação do domínio pai e acompanhar atualizações. O BIND oferecia uma ferramenta funcional, não garantia que os dados estivessem certos.

A descrição contemporânea mais concreta veio dois anos depois. Na RFC 1118, Ed Krol descreveu o BIND como integrado ao 4.3BSD e usado para consultar e armazenar nomes de hosts, endereços, agentes de e-mail e outras informações. Segundo o guia, ele substituía a busca baseada em /etc/hosts. O exemplo da Universidade de Illinois em Urbana-Champaign mostra a diferença de escala: poucos computadores apareciam na tabela de hosts distribuída pela SRI, enquanto a maioria dos nomes do domínio universitário ficava em tabelas BIND locais. Outros hosts com BIND ou qualquer resolvedor DNS podiam consultar esses nomes.

Não era uma escolha entre um único banco de dados e nenhuma coordenação. A SRI continuava distribuindo uma tabela de hosts; o DNS acrescentou um modo de cada instituição manter um espaço local maior e publicá-lo por regras de consulta comuns. A RFC 1118 também diz que o BIND podia fornecer dados de encaminhamento de e-mail para hosts internos sem acesso direto por IP, inclusive máquinas alcançadas por UUCP. O nome de um serviço podia permanecer estável mesmo quando mudava a localização física ou de rede do host.

O que ficou local e o que continuou compartilhado

A fronteira operacional era mais concreta do que a palavra “distribuído” costuma sugerir. Berkeley e seus sucessores distribuíam o software. Os documentos de protocolo descreviam o comportamento comum. Os administradores de cada domínio controlavam seus próprios registros. Resolvedores e servidores processavam as consultas. Nenhuma dessas partes substituía as demais. Uma zona desatualizada ainda podia responder de forma coerente e errada; uma delegação inconsistente podia impedir a resolução mesmo com o BIND funcionando.

A ênfase posterior de Heng Lu em código em execução serve aqui como pergunta de análise, não como afirmação sobre a intenção dos autores do BIND: o que o administrador recebia e fazia? As fontes mostram uma sequência que vai do relatório de projeto a um sistema ajustado à experiência operacional, depois ao software distribuído com o 4.3BSD e, por fim, aos nomes locais mantidos pelos próprios operadores. Publicar era importante, mas não preenchia a zona de uma universidade nem respondia às consultas de seus usuários.

As fontes também têm limites. A RFC 1033 comprova a distribuição com o 4.3BSD; a RFC 1118 documenta a integração e um exemplo universitário. Elas não comprovam instalação universal, uma causa única para a adoção do DNS nem o desaparecimento de todos os arquivos de hosts. O ponto histórico que se sustenta é mais específico: o BIND ajudou a tornar o DNS um serviço Unix que um administrador podia operar. Cada domínio passou a manter sua parte sem perder interoperabilidade com o restante da árvore.

Fontes