A Tabela de Hosts Antes do Mercado: Quem Autorizou o Primeiro Livro-Razão da Internet?

Resumo

• A tabela de hosts inicial adquiriu autoridade prática por meio de uma cadeia limitada: a ARPA contratou o Network Information Center para a ARPANET, o SRI manteve o registro comum, os sites participantes forneciam e consumiam informações de hosts, e a DCA posteriormente incorporou o serviço em um ambiente operacional do DoD.
• A RFC 810 publicou uma pré-condição de registro para nomes e endereços usados em relação ao tráfego transmitido por hosts do DoD, mas a especificação remanescente não demonstra monitoramento, rejeição de pacotes, sanções, taxas de conformidade ou qualquer comunicação bloqueada em particular.
• O registro público não fornece os contratos iniciais completos, arquivos de solicitação da tabela de hosts, decisões contestadas, resultados de correções, registros de sobreposição, relatórios de fiscalização ou soluções necessárias para estabelecer uma discrição irrestrita do NIC ou um mandato público que se estendesse a todas as redes externas.

Em 8 de março de 1974, o Network Information Center solicitou que todos os sites da ARPANET alterassem uma tabela de hosts local. A instrução apareceu naRFC 620, “Request for Monitor Host Table Updates”, emitida por Bill Ferguson do Augmentation Research Center do SRI. Os serviços do NIC haviam se mudado paraOFFICE-1, no site de rede 53 em notação octal. O site 2 permaneceuSRI-ARC, mas seu apelido passou a serARC; o apelido conhecidoNICpassou a apontar para o site 53. O aviso forneceu entradas exatas para as tabelas de monitoramento do TENEX e instruiu os sites que executavam outros sistemas operacionais a fazerem alterações equivalentes.

A RFC 620 registra uma instrução, não um caso de conformidade observado. Ela não identifica nenhum operador individual que tenha realizado o trabalho, nenhum site que tenha deixado de fazê-lo e nenhuma interrupção resultante. O operador é, no entanto, uma função necessária implícita no documento: alguém em cada site precisava alterar o mapeamento usado localmente da maneira apropriada para aquele sistema operacional. Se uma tabela permanecesse desatualizada, ela continuaria associandoNICao site 2 e poderia direcionar uma tentativa baseada em nome para longe do serviço NIC pretendido. Essa consequência decorre da alteração do mapeamento, mas a RFC não relata uma falha real de consulta ou conexão mal direcionada.

O aviso expõe a estrutura administrativa por trás de um nome aparentemente simples. O SRI podia anunciar a nova associação, mas o anúncio não reescrevia todas as máquinas remotas. Um site precisava receber a instrução, interpretá-la e modificar seu próprio sistema. A nomenclatura compartilhada funcionava quando o registro mantido, o canal de distribuição e a implementação local convergiam.

Em 25 de março de 1974, aRFC 627anunciou um mecanismo de distribuição mais regular. O arquivo ASCII online de nomes oficiais de hosts estava disponível emOFFICE-1, cujo endereço aparecia como 43 em notação decimal, equivalente ao 53 octal usado na RFC 620. O NIC manteria o arquivo e incorporaria adições ou alterações semanalmente. Cada host da rede era responsável por recuperar novas informações por meio do File Transfer Protocol. Mudanças, adições, correções e comentários poderiam ser enviados a Elizabeth “Jake” Feinler por correio eletrônico de rede, telefone ou pelo sistema de identificação do NIC.

Esses dois documentos de março não preservam uma transação completa de solicitação até a decisão. Eles podem, no entanto, ser combinados com registros anteriores e posteriores para estabelecer uma reconstrução composta mínima, desde que suas datas permaneçam separadas.

Em 1971, um host escolhia um nome formal preferido por meio de seu oficial de ligação, sob o procedimento proposto naRFC 273. O oficial de ligação transmitia a escolha; o documento não estabelece que um oficial de ligação técnico possuísse autoridade pessoal para tomar todas as decisões organizacionais do site. O esquema de nomenclatura proposto previa que os apelidos fossem únicos na comunidade da rede e contemplava discussão se nomes duplicados ou excepcionalmente longos fossem escolhidos. Ele não especificava veto do NIC, teste de rejeição, regra de decisão final, sobreposição ou recurso.

Em janeiro de 1974, aRFC 608descreveu o nome de host oficial como uma string obtida por negociação entre o host e o NIC. Ela estabeleceu restrições de caracteres e formatação, identificou o arquivo fonte NLS de Feinler e propôs a geração periódica de uma edição ASCII legível por máquina. Ela não explicou como as negociações contestadas terminavam ou quem prevalecia quando a discussão falhava.

Em março de 1974, a RFC 627 estabeleceu o arquivo disponível, a incorporação semanal de atualizações, um canal de correção e a responsabilidade de cada host de buscar novas informações. Somente em 1982 aRFC 810afirmou explicitamente que o usuário da tabela de hosts do DoD era responsável por traduzi-la para qualquer formato local necessário. Seria impreciso compactar essas declarações de 1971, 1974 e 1982 em uma única rotina observada ou atribuir cada etapa ao mesmo responsável.

O composto defensável é, portanto, modesto. Um host comunicava seu nome preferido por meio de um oficial de ligação. As convenções publicadas governavam a forma desse nome, a exclusividade dos apelidos era esperada e escolhas duplicadas ou longas podiam gerar discussão. O SRI mantinha uma fonte a partir da qual gerava um arquivo comum. Os sites recuperavam o arquivo e incorporavam seu conteúdo nos sistemas locais. Em 1982, a responsabilidade do usuário pela tradução local foi expressamente declarada.

O que acontecia quando um nome proposto permanecia contestado, quando uma correção era contestada ou quando um site rejeitava uma instrução não pode ser recuperado apenas das RFCs procedimentais.

Esta é a primeira fronteira na autoridade da tabela de hosts. O registro comum podia determinar que nome um sistema participante reconhecia sem decidir se o computador subjacente existia, se uma linha física havia sido instalada ou se uma organização havia sido admitida na rede. Seus efeitos eram operacionais e, às vezes, graves para o uso baseado em nomes, mas não eram idênticos ao controle sobre toda a conectividade.

Quatro tabelas divergentes e o caso a favor de um arquivo comum

O arquivo de hosts online abordou um problema de coordenação observado. Em dezembro de 1973, aRFC 606descreveu quatro sistemas TENEX acessíveis —SRI-ARC,BBN-TENEX,USC-ISIePARC-MAXC— cujos mapeamentos entre nomes de hosts e endereços diferiam. Nenhum era completo, e o autor acreditava que cada um divergia em algum aspecto da lista oficial.

Essa evidência não deve ser inflada em uma alegação de que todos os sites da ARPANET tinham uma tabela imprecisa. Ela estabelece divergência em quatro sistemas nomeados. Mesmo essa descoberta limitada foi suficiente para demonstrar o custo da manutenção separada. Uma pessoa que se movesse entre essas máquinas poderia encontrar respostas diferentes. Um programa escrito para um conjunto local poderia falhar quando movido para outro. Um host recém-adicionado ou renomeado poderia ser reconhecido em um site enquanto permanecia desconhecido em outro.

A RFC 606 propôs um arquivo legível por máquina gerado centralmente e mantido pelo NIC. Ela distinguiu os dois fatos essenciais em uma entrada — nome do host e endereço do host — de atributos opcionais como status do host, comportamento de protocolo e apelidos. Seu autor alertou que os atributos não precisavam ser completos e não deveriam substituir a negociação de protocolo, comunicação verbal ou outras formas de descobrir as propriedades de um host. A proposta era deliberadamente específica: buscava resolver listas locais incompatíveis, não estabelecer uma constituição abrangente para a participação na rede.

A RFC 608 aceitou a ideia do arquivo central e relatou que tinha apoio do escritório de Técnicas de Processamento de Informação da ARPA. Feinler mantinha a fonte no formato NLS do SRI, enquanto um programa geraria o arquivo de distribuição ASCII periodicamente. Inicialmente, as entradas geradas conteriam o nome oficial, o endereço decimal do host e o status. Outras informações poderiam ser adicionadas à medida que os dados ficassem disponíveis. O documento também permitia um prefixo de rede para hosts fora da ARPANET, mostrando que os autores já contemplavam um conjunto de comparação mais amplo do que a população de hosts da ARPANET.

Ele não identifica cada host externo realmente incluído.

A distinção entre fonte e distribuição era importante. O NLS era um sistema do SRI usado para manter informações estruturadas. A edição ASCII foi projetada para recuperação e processamento por hosts heterogêneos. O SRI-ARC era o contexto organizacional e computacional a partir do qual vários desses avisos foram emitidos, enquanto oOFFICE-1tornou-se a máquina que atendia os usuários do NIC e o arquivo de hosts publicado em março de 1974. Documentos posteriores usaramSRI-NICpara o host que fornecia a tabela do DoD e o serviço de nomes. Esses rótulos marcam mudanças técnicas e organizacionais; não devem ser tratados como nomes intercambiáveis para uma máquina imutável.

A RFC 627 converteu a proposta em um serviço anunciado. Ela encorajava os hosts a usarem os nomes oficiais em seus monitores e tornava cada host responsável por recuperar o arquivo. Os apelidos eram opcionais, e os sistemas que forneciam tradução de nome para endereço eram encorajados, mas não obrigados, a usá-los. O documento fornecia canais para adições e correções, mas a existência de um canal não prova o tempo necessário, as evidências exigidas ou a solução disponível quando uma solicitação era recusada.

A arquitetura permanecia distribuída no ponto de uso. O SRI mantinha o arquivo de referência, mas os sites remotos decidiam quando buscá-lo e como instalá-lo. Um mestre corrigido recentemente podia coexistir com cópias locais desatualizadas. Um operador podia complementar um arquivo oficial com um alias local. Uma pessoa que conhecesse um endereço numérico poderia contornar um nome ausente. A tabela reduzia a inconsistência sem se tornar a própria sub-rede de comutação de pacotes.

Uma entrada errada ainda poderia ter efeitos materiais. Um programa baseado em nome poderia direcionar o tráfego para o endereço registrado em vez da máquina pretendida. Uma entrada ausente poderia deixar o software incapaz de traduzir o nome solicitado. Uma atualização local atrasada poderia preservar um resultado obsoleto. O comportamento exato dependia do sistema operacional e do aplicativo local. As RFCs não justificam uma alegação universal de que toda omissão produzia desconexão ou que toda entrada imprecisa produzia o mesmo erro.

A realocação de março ilustra a proposição mais restrita. Depois que oNICse mudou para oOFFICE-1, um site que implementasse a alteração da RFC 620 associaria o apelido ao site 53. Um site desatualizado poderia continuar associando-o ao site 2. A mudança de serviço do SRI ocorreu independentemente da tabela remota, enquanto a utilidade do apelido compartilhado dependia da adoção remota. O registro era consequente porque outras máquinas agiam com base nele.

Os nomes começaram com os hosts, não com um veto ilimitado do NIC

O arquivo comum não surgiu de uma regra estabelecida que permitia ao NIC atribuir qualquer nome que desejasse. A discussão da RFC de 1971 registra divergências substanciais sobre a nomenclatura.

ARFC 226circulou um conjunto proposto de mnemônicos e convidou objeções. Sugestões concorrentes se seguiram. Alguns participantes preferiam indicativos curtos; outros queriam nomes que preservassem identidades institucionais e de projeto. O debate não era meramente estético. Os nomes apareciam em comandos, documentos e hábitos dos usuários. Portanto, uma regra de nomenclatura distribuía inconveniência e reconhecimento, assim como caracteres.

NaRFC 237, o NIC argumentou que era um órgão lógico para manter o padrão de nomenclatura e propôs atribuir nomes a novos hosts uma vez que o Network Working Group tivesse resolvido a sintaxe e a lista atual. Essa foi uma proposta institucional do operador do serviço. É evidência do que o NIC queria que seu papel fosse, não evidência de que cada organização conectada ou uma autoridade pública superior aceitasse toda a reivindicação.

A RFC 273 respondeu ao fracasso das propostas anteriores em obter aceitação. Ela afirmou que os hosts, por meio de seus oficiais de ligação, deveriam escolher seus próprios nomes formais, possivelmente sujeitos a discussão se nomes duplicados ou excessivamente longos fossem selecionados. Esperava-se que os hosts de uma mesma instituição usassem o mesmo mnemônico institucional. Um apelido deveria ser único na comunidade da rede.

A linguagem estabelece a escolha local e a possibilidade de discussão central. Ela não define quem poderia emitir uma recusa final. Uma duplicata frustraria o propósito de um apelido compartilhado, mas a incompatibilidade técnica por si só não revela a solução administrativa. O NIC poderia ter persuadido um site a escolher outro nome; um patrocinador poderia ter intervindo; os sites poderiam ter aceitado uma convenção informal; ou alguma discordância poderia ter permanecido sem solução. Um arquivo de caso completo seria necessário para distinguir essas possibilidades.

ARFC 289, emitida em dezembro de 1971, relatou que quase todos os sites haviam respondido com os nomes desejados. Seu título, “What We Hope Is An Official List of Host Names” (O Que Esperamos Ser uma Lista Oficial de Nomes de Hosts), preserva o caráter provisório do exercício. A lista emergente refletia a solicitação e a resposta dos sites dentro de uma comunidade limitada da ARPANET. Não foi uma invenção privada unilateral nem o resultado de uma delegação pública mundial.

O papel do oficial de ligação também requer cuidado. A RFC 273 usava os oficiais de ligação como o canal pelo qual os hosts escolhiam e comunicavam os nomes. Um guia posterior doComputer History Museum para os registros do SRI ARC/NICafirma que os oficiais de ligação técnicos geralmente não tinham autoridade para falar pela administração do site. O guia de arquivo descreve a criação posterior de uma função de Administrador de Host cujo titular poderia autorizar ações do site. Como o guia abrange um período mais longo, ele não pode ser simplesmente projetado retroativamente para todas as trocas de 1971. No entanto, ele adverte contra tratar “oficial de ligação” como sinônimo de executivo institucional.

O máximo que se pode dizer com segurança é que o host era o escolhedor original no procedimento publicado de 1971, o oficial de ligação era o canal de comunicação e o NIC mantinha o resultado compartilhado. A sintaxe e a exclusividade esperada restringiam o que poderia funcionar no namespace comum. Os documentos não revelam um sistema abrangente de adjudicação.

Essa discrição limitada ainda era significativa. Uma vez que um nome aparecia em documentos e arquivos legíveis por máquina, os usuários em outros lugares podiam confiar nele. Um host podia mudar seu nome, mas isso impunha custos ao software, à documentação e ao conhecimento local. A estabilidade tornou-se uma fonte de autoridade prática. O centro não precisava de um amplo poder legal para tornar sua resposta mantida difícil de ignorar.

O contrato de serviço da ARPA e a transferência para a DCA

A cadeia institucional começou com um programa de pesquisa federal, não com a Internet mais ampla.

A ARPANET era uma rede de comutação de pacotes específica estabelecida pela Advanced Research Projects Agency dentro do United States Department of Defense. A ARPA financiou o programa de pesquisa, selecionou contratados e apoiou centros de pesquisa participantes. A agência tornou-se a Defense Advanced Research Projects Agency em 1972. Portanto, “ARPA” é apropriado para o estabelecimento da rede e o debate inicial de nomenclatura, enquanto “DARPA” aparece nos registros do período posterior.

OARPANET Completion Report, preparado em 1978, afirma que o Stanford Research Institute recebeu um contrato para desenvolver e operar um Network Information Center para a ARPANET. O trabalho começou junto com a implementação da rede em 1969. O relatório descreve um serviço que mantinha listas de participantes e distribuição, arquivava documentos técnicos, fornecia informações sobre recursos de hosts, oferecia acesso ao sistema NLS do SRI e mantinha as especificações dos protocolos da ARPANET.

Isso estabelece uma relação patrocinador-contratado. A ARPA adquiriu um serviço de informação para a rede e a comunidade de pesquisa que apoiava. O SRI tinha o dever de executar o que o contrato exigia, e a ARPA tinha o direito correspondente ao desempenho contratado. O relatório público não reproduz a declaração de trabalho inicial, emendas, padrões de aceitação, sanções, cláusulas de dados ou regras de decisão sobre nomes de hosts. Portanto, ele não pode estabelecer o conteúdo legal completo desse dever.

Os sites conectados à ARPANET eram institucionalmente diversos. Eles incluíam universidades, institutos de pesquisa, laboratórios governamentais, instalações militares e contratados privados. A diversidade de forma jurídica não tornava todos os sites operadores públicos não afiliados. Muitos participavam por meio de patrocínio federal, contratos ou relações de missão aprovadas. Ao mesmo tempo, a ausência dos instrumentos subjacentes dos sites impede a alegação de que cada organização conectada tinha uma cláusula contratual idêntica exigindo conformidade com a tabela de hosts.

O relato direto mais forte da transferência da ARPA para a Defense Communications Agency é encenado e datado. O Completion Report descreve um memorando ARPA-DCA sob o qual a gestão da ARPANET foi transferida para a DCA em 1º de julho de 1975. Ele também registra uma transição gradual de seis meses, até 31 de dezembro de 1975, durante a qual a ARPA continuou auxiliando a DCA enquanto a DCA assumia a função de gestão. Um plano de transição detalhado havia sido concluído até junho.

O relatório afirma que a rede transferida operaria como uma instalação do DoD usada para negócios governamentais. A DCA financiaria a operação e manutenção por meio de um arranjo de alocação de custos envolvendo os patrocinadores da ARPANET. Inicialmente, a DCA contrataria a BBN e o SRI para operação de rede, manutenção e funções do NIC. O relatório afirma que ficava claramente implícito que a DCA poderia contratar outros contratados posteriormente, certamente após o primeiro ano.

Isso é evidência de substituibilidade institucional no nível de seleção de contratados. Isso não prova que a DCA possuía uma cópia portátil completa de todos os registros do NIC, direitos ilimitados sobre dados criados por contratados, um pacote de transição testado ou uma solução executável para cada falha de serviço. Um cliente pode ser capaz de selecionar outro fornecedor em princípio enquanto enfrenta obstáculos práticos formidáveis na transferência de conhecimento da equipe, software, arquivos, registros atuais e relacionamentos com os sites.

Uma publicação da DCA de 1978, indexada como oARPANET Information Brochure, também fornece 1º de julho de 1975 como a data de transferência de gestão. O guia de arquivo posterior do Computer History Museum apresenta um relato retrospectivo conflitante: ele afirma que a operação da ARPANET foi entregue à DCA em 1973 e que o financiamento do contrato da DCA apoiou o NIC do SRI após 1974.

O conflito deve permanecer visível. A cronologia formal do memorando no Completion Report fornece uma data de transferência precisa e uma transição gradual. O guia de arquivo fornece datas sumárias diferentes, mas não o instrumento subjacente que as reconciliaria. Ele também afirma que o NIC se tornou um projeto separado em 1973, o que é uma mudança institucional diferente da transferência da gestão da ARPANET. Sem os contratos e registros administrativos relevantes, a declaração operacional de 1973 e a declaração de financiamento pós-1974 não podem ser convertidas em uma cronologia única e perfeita.

Após a transferência formal, a DARPA poderia continuar patrocinando pesquisas que usassem a ARPANET enquanto a DCA geria a rede operacional. O DoD era o ambiente governamental pai; a DARPA e a DCA tinham funções diferentes dentro dele. O SRI permaneceu como contratado realizando serviços do NIC, em vez de se tornar o próprio governo. Os sites participantes operavam hosts. Os oficiais de ligação de host e, posteriormente, outras funções de contato transmitiam informações e instruções. Manter essas funções distintas impede que a autoridade de aquisição seja confundida com autoridade universal.

A admissão na ARPANET não era uma decisão da tabela de hosts

A tabela de hosts registrava máquinas dentro de um ambiente operacional, mas a manutenção do registro pelo SRI não tornava o SRI a única autoridade que decidia quem poderia ingressar na ARPANET.

OARPANET Directory de dezembro de 1978descreveu as categorias de assinantes e o processo para obtenção de serviço. Sua estrutura colocava a admissão e o patrocínio dentro da estrutura de gerenciamento de rede da DCA. Um possível assinante precisava de um propósito governamental aceitável, patrocínio e instalações disponíveis. Essas decisões diziam respeito ao acesso a uma rede gerenciada específica.

A distinção é fundamental. A DCA podia administrar a elegibilidade de assinantes da ARPANET. O SRI podia manter o diretório e as informações de host usadas após ou durante a admissão. Uma entrada na tabela de hosts poderia ser necessária para o uso compartilhado conveniente, mas registrar o host não era o mesmo ato institucional que aprovar a conexão da organização, instalar um Processador de Mensagens de Interface, fornecer um circuito ou autorizar uma missão.

A população da ARPANET também não deve ser equiparada à Internet do DoD. A ARPANET era uma rede. A Internet do DoD era um ambiente de interconexão de redes no qual a ARPANET, sistemas de rádio de pacotes, sistemas de satélite e outras redes podiam usar protocolos da Internet e informações de coordenação comuns. A Internet emergente mais ampla era ainda mais ampla: um conjunto mutável de redes, experimentos e operadores cujos relacionamentos legais, contratuais e técnicos não eram uniformes.

Em setembro de 1981, aRFC 790listou números de rede da Internet atribuídos para várias redes nomeadas, incluindo ARPANET, UCLNET, CYCLADES, TELENET, o British Post Office EPSS, DATAPAC, TRANSPAC, LCSNET, TYMNET e uma variedade de sistemas de rádio de pacotes, satélite, locais e experimentais. Ela identificava Jon Postel, do Information Sciences Institute da University of Southern California, como o contato para atribuições de números de rede.

A lista prova que o ambiente de números atribuídos se estendia além de uma lista de hosts da ARPANET. Ela não estabelece, por si só, que cada rede nomeada estava operacionalmente interconectada naquele momento, independente de patrocínio governamental, comercial, não-DoD ou governada pelo processo da tabela de hosts do SRI. Um número que aparece em um documento de atribuição não é um relato completo do status contratual da rede ou do tráfego real.

Ela também separa funções que histórias posteriores às vezes confundem. O papel de números atribuídos de Postel no USC-ISI dizia respeito a parâmetros de rede e protocolo. O SRI mantinha a tabela de hosts e o serviço de nomes. A DCA geria a ARPANET e contratava o serviço NIC. A DARPA continuava o patrocínio de pesquisas. Nenhum desses fatos torna um único ator o autor exclusivo de toda a Internet emergente.

A frase “primeiro livro-razão da Internet”, portanto, precisa de uma comparação definida. A tabela de hosts não foi o primeiro diretório mantido por uma organização de computadores, nem o arquivo de 1974 era um registro para uma Internet pública mundial. Foi uma referência inicial compartilhada e legível por máquina de nomes e endereços na linhagem da ARPANET para a Internet. Em 1982, seu formato sucessor incorporava redes, gateways e endereços da Internet e foi descrito por seus operadores como um banco de dados global de nomes e endereços de hosts.

Sua importância histórica reside no escopo cada vez mais amplo e na dependência interorganizacional dessa referência, não em um mandato comprovado sobre todas as redes.

A regra do DoD de 1982: uma pré-condição publicada, não uma aplicação comprovada

A RFC 810 marcou uma mudança no escopo e na linguagem institucional. Emitida em 1º de março de 1982 por Feinler, Ken Harrenstien, Zaw-Sing Su e Vic White do Network Information Center do SRI International, afirmou que a tabela de hosts anterior da ARPANET não atendia mais às necessidades da comunidade DoD ou da interconexão de redes. O novo formato incluía entradas de rede, gateway e host, endereços da Internet, sistemas operacionais e informações de protocolo.

A tabela estava disponível no hostSRI-NICpor FTP e por meio do Servidor de Nomes de Host. A RFC identificou o servidor como um serviço mantido pelo NIC da ARPANET em nome da DCA. Ela também atribuiu expressamente a responsabilidade de tradução ao usuário: quem consumisse a tabela precisava convertê-la para o formato necessário localmente.

Sua sétima suposição continha a linguagem operacional mais forte no registro da tabela de hosts. Nomes e endereços para redes, gateways e hosts do DoD deveriam ser negociados e registrados no NIC antes de serem usados e antes que o tráfego fosse transmitido por um host do DoD. Essa era uma pré-condição publicada que regia o comportamento dos hosts do DoD. Ela conectava o registro à operação de forma mais direta do que o incentivo de 1974 para usar nomes oficiais de hosts.

A frase não documenta a aplicação. A RFC 810 não identifica um monitor que inspecionasse os registros, uma regra de roteador que rejeitasse tráfego não registrado, uma sanção por não conformidade, uma taxa de conformidade ou uma comunicação específica que foi bloqueada. A diferença importa. Uma especificação pode definir a conduta exigida sem provar quão consistentemente os operadores a implementaram.

O documento tratava as informações não-DoD de maneira diferente. Por um período provisório, o NIC tentaria manter informações semelhantes para redes e hosts não-DoD se essas informações fossem fornecidas e enquanto fossem necessárias, aguardando servidores de nomes intercomunicantes. Ele não identificava cada entrada não-DoD realmente incluída nem impunha a mesma pré-condição expressa a todos os operadores externos.

O novo formato também teve uma introdução gradual. A RFC 810 especificou 1º de maio de 1982 como a data de transição. Durante maio, o caminhoHOSTS.TXTexistente ainda mantinha a edição antiga, enquanto um arquivo de teste do novo formato estava disponível separadamente. Durante junho e julho, o caminho principal mantinha o novo formato, enquanto o material do formato antigo permanecia acessível por outro caminho. Após 1º de agosto, o formatoHOSTS.TXTantigo especificado pela RFC 608 não seria mais suportado.

Essa sobreposição distinguia um projeto publicado de uma implementação universal imediata. Os programas tiveram tempo para se adaptar. Os sistemas locais podiam permanecer em edições diferentes durante a transição. O cronograma mostra um gerenciamento ativo do risco de compatibilidade, mas não prova que todos os hosts concluíram a conversão no prazo.

ARFC 811, emitida no mesmo dia, especificou o Hostnames Server online. Um programa podia consultar um nome de host ou endereço ou solicitar a tabela inteira. O servidor poderia retornar registros de host, gateway ou rede. Se um nome solicitado estivesse ausente, o erro definido assumia a formaERR: NAMNFD: Name not found:. Outros erros eram possíveis, incluindoTMPSYS, significando uma falha temporária do sistema e um pedido para tentar novamente mais tarde.

Essas semânticas pertencem ao protocolo do servidor SRI-NIC. Elas não devem ser projetadas em cada resolvedor local que usava uma cópia baixada. Uma consulta local em uma tabela sem uma entrada poderia falhar, usar um mapeamento suplementar, solicitar ao usuário ou se comportar de outra maneira dependente do sistema. A ausência de um nome em uma cópia local e uma respostaNAMNFDdo servidor eram condições relacionadas, não necessariamente eventos idênticos.

A RFC 811 descreveu seu banco de dados como uma extensão do antigo arquivoHOSTS.TXTda ARPANET e chamou a administração central de uma solução provisória a caminho de um serviço descentralizado e distribuído de tradução de nomes e endereços. Essa alegação institucional é importante por duas razões. Ela mostra que o SRI entendia o serviço como um mecanismo de transição, em vez de uma arquitetura permanente, e confirma que a população e o propósito da tabela haviam se expandido além da lista original da ARPANET. Ela não prova independentemente uma cobertura universal.

No início da década de 1980, o NIC estava cada vez mais associado ao ambiente da Defense Data Network, e coleções históricas posteriores usam o nome DDN-NIC para o serviço. Esse rótulo posterior não deve ser levado retroativamente para o contrato de 1969 ou o debate de nomes de hosts de 1971. SRI-ARC, o NIC do SRI, SRI-NIC e DDN-NIC descrevem contextos organizacionais e de host conectados, mas temporalmente distintos.

O que o arquivo pode mostrar — e o que permanece em falta

A série RFC é extraordinariamente rica em propostas, especificações e anúncios. É muito mais fraca como um registro de casos administrativos individuais.

O guia de arquivo do Computer History Museum identifica coleções relevantes: propostas e contratos do NIC, relatórios de progresso, registros de nomenclatura e endereçamento, tabelas de hosts, material de serviço de referência, correspondência e registros sobre contatos oficiais da rede. Ele afirma que o contrato inicial do NIC não era detalhado em tarefas e que contratos posteriores se tornaram mais elaborados. Ele também descreve oficiais de ligação técnicos, Administradores de Host, Coordenadores de Site de Nó e outros contatos por meio dos quais informações ou mensagens de ação circulavam.

Um guia de arquivo estabelece a existência, o assunto aproximado e a organização dos registros. Ele não revela o conteúdo de cada contrato, carta ou decisão. Suas descrições não podem provar que uma solicitação de nome de host foi concedida, recusada ou escalada de uma maneira específica. Os documentos subjacentes precisariam ser abertos e comparados.

Nenhum arquivo de solicitação completo foi produzido aqui mostrando o nome proposto de um host, as perguntas do NIC, a resposta do site e a disposição final. Nenhum caso preservado demonstra uma recusa do NIC com base em duplicação, um recurso bem-sucedido, uma sobreposição de patrocinador ou uma solução de correção. Nenhum registro abrangente fornece tempos de processamento ou taxas de erro. Os detalhes de contato da RFC 627 provam que um canal de correção existia; eles não provam os resultados entregues por meio dele.

Os contratos ausentes são importantes por uma razão separada. Um contrato federal pode conferir um direito ao desempenho sem conferir a propriedade de todos os registros, o título de um sistema técnico ou direitos irrestritos sobre dados criados pelo contratado. Ele pode especificar entregáveis, licenças de dados, assistência na transição e soluções, mas essas consequências dependem de suas cláusulas reais.

Uma análise posterior doGovernment Accountability Officesobre arranjos federais de funções da Internet distinguiu cuidadosamente direitos de desempenho, direitos de uso de dados, título e propriedade. Esse parecer de 2016 dizia respeito a arranjos posteriores de DNS e IANA e não fornece os termos ausentes dos contratos do SRI da década de 1970. Seu valor aqui é metodológico. O financiamento federal por si só não pode ser usado para inferir todos os direitos de propriedade ou transição.

O Completion Report apoia uma conclusão mais restrita: a DCA pretendia inicialmente manter o SRI para a função do NIC e poderia posteriormente usar outro contratado. Isso mostra uma substituibilidade de fornecedor contemplada. Não estabelece que a substituição poderia ocorrer sem atraso, disputas de dados, conversão de software, perda de memória institucional ou interrupção do serviço.

Registros de implementação também estão ausentes para a condição de tráfego da RFC 810. Para passar da regra publicada à aplicação demonstrada, seriam necessárias diretivas da DCA, software de host, logs de auditoria, relatórios de incidentes, sanções ou um fluxo bloqueado documentado. Sem esse material, o artigo pode identificar o alcance declarado da regra, mas não sua força observada.

O silêncio deve operar em ambas as direções. A falta de um procedimento de recurso publicado não prova que não existia escalação informal. Chamadas telefônicas, correio de rede, trocas no NLS e intervenção do patrocinador podem ter resolvido disputas sem uma RFC. Inversamente, a falta de reclamações publicadas não prova que todos os participantes consideravam o processo legítimo ou que todas as atualizações eram oportunas.

A incerteza resultante é institucional, e não meramente antiquária. Se as solicitações fossem rotineiramente corrigidas por meio de confirmação transparente do site, o serviço pareceria mais clerical e cooperativo. Se o NIC pudesse recusar entradas sem explicação e não existisse revisão do patrocinador, o mesmo arquivo teria um significado de governança diferente. As evidências públicas não apoiam nenhum dos extremos como um relato geral.

A alternativa da lista local e seus custos reais

Uma alternativa historicamente viável ao arquivo comum não era o Sistema de Nomes de Domínio moderno. Era a prática já visível antes da RFC 606: cada site mantinha seus próprios mapeamentos, obtinha alterações por comunicação pessoal e traduzia informações remotas em seu próprio sistema operacional.

Em quatro sites, isso poderia ser gerenciável. Os administradores se conheciam, os projetistas de protocolo se reuniam regularmente, e uma correção podia viajar por telefone, documento ou correio de rede. Um site podia adotar um alias local sem esperar por uma publicação central. Se duas organizações se comunicassem com frequência, podiam manter suas informações compartilhadas atualizadas mesmo quando uma máquina central estivesse indisponível.

A carga de manutenção crescia rapidamente. Com dez sites, cada um mantendo entradas para os outros nove, poderia haver até 90 mapeamentos locais direcionados. Com cem sites, poderia haver até 9.900. Esses números descrevem cópias direcionadas mantidas nos sites, não 90 ou 9.900 relacionamentos bilaterais distintos. O número de mapeamentos realmente necessários dependeria dos padrões de comunicação, mas cada novo destino criava mais lugares onde as informações poderiam se tornar obsoletas.

Uma adição de host ou alteração de endereço teria que alcançar vários administradores. Cada um aplicaria em um cronograma separado e em um formato local. Uma correção poderia ser reconhecida por um site, perdida por outro e transformada incorretamente por um terceiro. Os operadores precisariam identificar qual edição tinham, comparar relatórios conflitantes e determinar se uma falha de serviço aparente vinha da rede, do host remoto ou de um mapeamento obsoleto.

A RFC 606 fornece o aviso observado: os quatro sistemas TENEX nomeados já tinham tabelas incompletas e divergentes. Ela não quantifica as falhas causadas por essas diferenças. A divergência em si demonstra manutenção duplicada e respostas inconsistentes.

Uma fonte comum reduzia essa carga. O host afetado podia comunicar informações por meio de um canal reconhecido. O SRI podia gerar uma edição. Os sites podiam buscar o mesmo arquivo e comparar seu estado local com uma referência datada. Um operador de suporte que investigasse uma discrepância tinha um ponto focal a partir do qual começar.

O arquivo comum não eliminava todos os custos de distribuição. Cada site ainda exigia armazenamento, software de recuperação, conversão local e uma rotina de atualização. A publicação semanal introduzia atraso entre uma alteração relatada e seu aparecimento na próxima edição. A busca podia falhar quando o host servidor ou um caminho de rede estivesse indisponível. A instalação local podia atrasar após a recuperação bem-sucedida. A arquitetura centralizava a compilação, não todas as tarefas operacionais.

Nem uma fonte comum garantia a verdade. O SRI dependia dos hosts e contatos para fornecer informações precisas. Um endereço errado fornecido por um site poderia entrar no mestre. Uma atualização central correta poderia ser minada por uma implantação local obsoleta. Um conflito poderia persistir se o procedimento para decidi-lo não fosse claro. A referência tornava a discordância visível e reduzia a duplicação, mas não abolia a necessidade de verificação.

A alternativa da lista local explica por que as organizações adiavam para o arquivo do NIC sem exigir uma teoria de comando ilimitado. Uma resposta mantida era mais barata de consumir do que muitas reconstruídas independentemente. Software e documentação se tornavam mais confiáveis quando usavam nomes comuns. A dependência resultante dava ao registro mantido força operacional.

Um livro-razão comum com mais de um distribuidor

Uma segunda alternativa viável no período teria preservado um arquivo canônico enquanto distribuía o armazenamento e a recuperação de forma mais ampla.

A ideia apareceu em documentos contemporâneos. ARFC 623propôs que o NIC retivesse o mestre enquanto outro host mantivesse uma cópia secundária frequentemente atualizada. Seu autor se ofereceu como UCSB e sugeriu sincronização diária. O propósito era a disponibilidade: se o host do NIC não pudesse fornecer o arquivo, os usuários poderiam tentar o secundário.

ARFC 625aceitou o princípio de que mais de um host deveria manter uma cópia e recebeu a UCSB como um secundário em potencial. Ela discordou da substituição do FTP por um protocolo de recuperação dedicado. A RFC 627, emitida posteriormente em março, ainda convidava qualquer host que desejasse manter uma cópia secundária a entrar em contato com o NIC.

Esses registros estabelecem um projeto de replicação proposto e aceito. Eles não provam que a UCSB ou outro host operou um espelho funcional. A confirmação exigiria um aviso operacional, log do servidor, arquivo secundário arquivado, manual do host ou relatório posterior. A proposta não deve ser reescrita como implantação.

Se tal secundário tivesse operado, teria exigido recursos apropriados para o período. O site precisava de armazenamento para o arquivo, equipe ou procedimentos automatizados para recuperar atualizações e um cronograma frequente o suficiente para manter sua edição útil. Os usuários precisavam saber qual host contatar e como reconhecer a versão canônica mais recente. O secundário precisava de uma regra sobre o que fazer quando sua cópia local diferisse da do SRI.

Uma interrupção poderia dificultar a reconciliação. Suponha que o secundário perdesse duas atualizações enquanto o SRI permanecia disponível e depois voltasse com uma edição mais antiga. Uma convenção de carimbo de data/hora ou sequência seria necessária para evitar que os usuários confundissem disponibilidade com atualidade. Se o SRI estivesse indisponível enquanto uma correção contestada chegasse, o secundário precisaria saber se poderia publicar a alteração ou meramente continuar servindo o último mestre confirmado.

A replicação também deixava a autoridade de emenda sem solução. Um espelho poderia distribuir o arquivo canônico sem decidir as entradas. Dar a ele poder de edição independente criaria a possibilidade de mestres concorrentes. Evitar esse problema exigia uma divisão clara entre a organização que atestava seus fatos, o centro que reconciliava o namespace compartilhado, o distribuidor que fornecia cópias e qualquer revisor que tratasse de disputas.

A confirmação do site poderia ter sido fortalecida sem infraestrutura moderna. Antes da publicação semanal, o NIC poderia ter enviado uma alteração proposta ao oficial de ligação afetado ou contato autorizado do site. Um aviso de alteração datado poderia ter acompanhado o arquivo gerado. Os mantenedores secundários poderiam comparar as alterações anunciadas com o arquivo que recebiam. Os sites poderiam relatar discrepâncias em relação a uma edição específica, em vez de uma cópia local não datada.

Esses procedimentos teriam imposto custos. Os contatos precisavam responder. As correções poderiam esperar pela confirmação. A equipe precisava manter logs e reconciliar solicitações não respondidas. Um host que mudasse rapidamente poderia achar um ciclo semanal muito lento, enquanto uma distribuição mais frequente aumentava a computação, o uso da rede e a carga de trabalho do operador. A revisão formal poderia melhorar a prestação de contas, mas também atrasar as correções urgentes.

A transição de contratado apresentava um problema maior. A capacidade da DCA de selecionar outro fornecedor não garantia a substituição perfeita do SRI. Um sucessor precisava do arquivo canônico atual, do software que o gerava, da documentação dos formatos e cronogramas de publicação, das solicitações em aberto, do histórico de correções, das listas de contatos, do conhecimento da equipe e do acesso ao ambiente de atendimento. Se o contrato não especificasse a entrega ou os direitos de uso de dados, a transferência poderia se tornar legal e operacionalmente difícil.

Os documentos públicos sobreviventes não estabelecem se esses materiais de transição existiam como entregáveis executáveis. Eles mostram que um contratado diferente foi contemplado, não que um mecanismo de transferência testado estava em vigor. A substituibilidade no papel e a continuidade na operação eram conquistas separadas.

Esta alternativa esclarece a escolha de governança. Uma única resposta lógica não exigia um único distribuidor físico. Uma edição canônica poderia coexistir com espelhos, confirmação do site, alterações preservadas e um provedor de serviço substituto. Cada adição teria mudado o custo e a responsabilidade sem eliminar a necessidade de coordenação final.

Uma cadeia de autoridade datada, não um mandato universal

Entre 1969 e 1983, a autoridade da tabela de hosts acumulou-se por meio de uma série de relacionamentos diferentes.

Em 1969, a ARPA contratou um Network Information Center para a ARPANET. Isso estabeleceu um cliente federal, um contratado SRI e uma população de serviço definida. Isso não tornou o SRI o representante de todas as redes de computadores.

Em 1971, os hosts foram convidados a escolher nomes por meio de oficiais de ligação dentro das convenções publicadas. O debate e a resposta entre os participantes da ARPANET forneceram uma aceitação limitada dos pares. O papel proposto do NIC foi restringido pela escolha local, enquanto o namespace compartilhado ainda exigia resultados compatíveis.

Em 1973 e início de 1974, tabelas locais divergentes levaram a um arquivo comum legível por máquina. As RFCs 606 e 608 documentaram a proposta e o projeto da fonte. As RFCs 620 e 627 documentaram uma instrução de alteração específica para todo o site, o arquivo ASCII disponível, atualizações semanais, responsabilidade de recuperação local e canais de correção. Elas não documentaram um veto geral do NIC ou um sistema completo de disputas.

Em 1º de julho de 1975, de acordo com o memorando ARPA-DCA descrito no Completion Report, a gestão da ARPANET foi transferida para a DCA, seguida por uma transição gradual até 31 de dezembro. A DCA manteve o SRI inicialmente para funções do NIC e poderia contemplar outro contratado. A declaração conflitante do guia de arquivo sobre a transferência operacional em 1973 e o relato de financiamento pós-1974 permanecem sem solução.

Em 1978, a estrutura de assinantes da DCA colocou a admissão na ARPANET dentro do gerenciamento de rede governamental, em vez da manutenção da tabela de hosts do SRI. Isso separou a autoridade para admitir um assinante do serviço que registrava e distribuía informações de hosts.

Em 1981, o ambiente de números atribuídos listava muitas redes além da ARPANET, enquanto a atribuição de números de rede era identificada com Postel no USC-ISI. A aparição nessa lista não estabelecia que todas as redes compartilhavam uma relação legal ou operacional com a DCA ou o NIC.

Em março de 1982, a RFC 810 especificou uma tabela de hosts mais ampla para a Internet do DoD e publicou o registro prévio como condição para nomes e endereços usados em relação ao tráfego transmitido por hosts do DoD. Seu tratamento provisório separado para informações não-DoD marcou uma fronteira. A regra era explícita; sua aplicação permanece não comprovada. A transição de maio a agosto mostrou ainda mais que especificação, transição e implementação local concluída eram estágios diferentes.

O servidor da RFC 811 tornou a resposta mantida disponível por meio de consultas online e descreveu o banco de dados central como uma ponte provisória para a nomenclatura distribuída. Esse serviço aumentou a dependência do SRI-NIC, embora reconhecesse que a arquitetura não pretendia permanecer permanentemente central.

Portanto, a tabela de hosts exerceu sua autoridade demonstrada mais forte em três lugares. O SRI devia desempenho ao seu cliente federal dentro do escopo de um contrato cujos termos completos não estão disponíveis. A DCA podia emitir requisitos operacionais para o ambiente do DoD que geria. As máquinas e usuários participantes dependiam do registro comum para uma comunicação consistente baseada em nomes.

Fora desses relacionamentos, o alcance da tabela surgiu da interoperabilidade e adoção. Uma rede externa podia contribuir com informações ou usar o arquivo comum porque isso facilitava a comunicação. Essa dependência era consequente, mas a RFC 810 não a descrevia como equivalente à pré-condição do DoD. Nenhum registro revisado mostra uma base eleitoral mundial delegando autoridade geral ao SRI.

A tabela também não criava tudo o que registrava. O patrocinador aprovava a participação na rede; contratados e sites forneciam máquinas e software; circuitos e comutadores de pacotes transportavam o tráfego; outras autoridades tratavam dos números de rede; os sistemas locais consumiam os mapeamentos publicados. O registro do NIC ajudava a tornar um nome comumente reconhecível, mas não criava a organização subjacente, a conexão física ou todas as atribuições numéricas.

Sua autoridade prática era, no entanto, substancial. Um registro compartilhado consumido por muitas máquinas pode restringir a conduta mesmo quando nenhum corpo legislativo ou de associação pública o criou. Um host que desejava reconhecimento previsível tinha razões para seguir as convenções de nomenclatura. Um site que desejava respostas atuais tinha razões para recuperar o arquivo comum. Um host do DoD era endereçado por uma pré-condição de registro publicada. Um operador não-DoD podia achar o desvio custoso porque outros sistemas esperavam a resposta mantida.

O que permanece não comprovado é igualmente importante. As evidências públicas sobreviventes não mostram que o NIC possuía os endereços que listava, podia excluir qualquer rede externa à vontade, impunha sanções a todos os sites não conformes ou convertia todas as entradas ausentes em desconexão física. Elas não revelam uma estrutura completa de recurso, solução de correção ou hierarquia de sobreposição. Elas não estabelecem a propriedade governamental portátil de todos os dados do NIC.

A tabela de hosts inicial era autoritativa onde a aquisição, o gerenciamento de rede e a dependência da máquina se encontravam. Ela resolveu um problema concreto: mapeamentos locais incompatíveis tornavam os nomes compartilhados não confiáveis. A compilação central tornava uma resposta mais fácil de distribuir, comparar e usar. Essa conquista explica por que o registro adquiriu força antes que nomes e endereços se tornassem ativos de mercado.

Isso não prova que o operador do registro recebeu autoridade sobre todas as redes que o registro poderia descrever. A cadeia histórica apoia uma conclusão mais restrita: o SRI manteve uma referência contratada pelo governo federal para uma rede patrocinada, essa referência tornou-se incorporada às operações da Internet do DoD, e a dependência mais ampla expandiu seu alcance prático. A utilidade do livro-razão o tornou poderoso. Seu mandato público permaneceu não estabelecido.