A tabela de hosts antes do mercado: quem autorizou o primeiro registro da Internet?

Resumo

• A primeira tabela de hosts adquiriu autoridade prática através de uma cadeia delimitada: a ARPA financiou o Network Information Center para ARPANET, o SRI manteve o registro comum, os sites entidades forneceram e consumiram as informações sobre os hosts, e a DCA posteriormente integrou o serviço em um ambiente operacional do DoD.
• A RFC 810 publicou uma condição prévia de registro para nomes e endereços usados em relação ao tráfego roteado pelos hosts do DoD, mas a especificação preservada não demonstra vigilância, rejeição de pacotes, sanções, taxas de conformidade ou comunicação bloqueada específica.
• O arquivo público não fornece os primeiros contratos completos, os arquivos de solicitação de tabela de hosts, as decisões contestadas, os resultados de correções, os registros de exceção, os relatórios de aplicação ou os recursos necessários para estabelecer seja um poder discricionário ilimitado do NIC, seja um mandato público que se estenda a todas as redes externas.

Em 8 de março de 1974, o Network Information Center solicitou a cada site ARPANET que modificasse uma tabela de hosts local. A instrução apareceu naRFC 620, « Solicitação de atualizações da tabela de hosts do monitor », publicada por Bill Ferguson do Centro de Pesquisa em Aumento do SRI. Os serviços do NIC haviam sido movidos paraOFFICE-1, no site de rede 53 em notação octal. O site 2 permaneciaSRI-ARC, mas seu apelido deveria se tornarARC; o apelido familiarNICdeveria agora apontar para o site 53. O aviso fornecia as entradas exatas para as tabelas de monitor TENEX e solicitava que sites usando outros sistemas operacionais fizessem modificações equivalentes.

A RFC 620 registra uma instrução, e não um caso de conformidade observada. Ela não identifica nenhum operador individual que tenha realizado o trabalho, nenhum site que não o tenha feito e nenhuma falha resultante. O operador é, no entanto, um papel necessário implicado pelo documento: alguém em cada site precisava modificar o mapeamento usado localmente de forma apropriada para aquele sistema operacional. Se uma tabela permanecesse desatualizada, ela continuaria associandoNICao site 2 e poderia desviar uma tentativa baseada no nome do serviço NIC pretendido. Essa consequência decorre da alteração do mapeamento, mas a RFC não relata falha de busca ou conexão mal direcionada real.

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 cada máquina remota. 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 dos nomes de hosts oficiais 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 mantinha o arquivo e incorporava adições ou modificações a cada semana. Cada host da rede era responsável por obter as novas informações via File Transfer Protocol. Modificações, adições, correções e comentários podiam ser endereçados a Elizabeth « Jake » Feinler por correio de rede, telefone ou através do sistema de identificação do NIC.

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

Em 1971, um host selecionava um nome formal preferido por meio de seu agente de ligação de acordo com o procedimento proposto naRFC 273. O agente de ligação transmitia a escolha; o documento não estabelece que um agente de ligação técnico possuía pessoalmente a autoridade para tomar todas as decisões organizacionais do site. O esquema de nomenclatura proposto esperava que os apelidos fossem únicos dentro da comunidade da rede e previa discussão se nomes duplicados ou excessivamente longos fossem selecionados. Ele não especificava um veto do NIC, um teste de rejeição, uma regra de decisão final, uma exceção ou um recurso.

Em janeiro de 1974, aRFC 608descrevia o nome de host oficial como uma string obtida por negociação entre o host e o NIC. Ela estabelecia restrições de caracteres e formato, identificava o arquivo fonte NLS de Feinler e propunha a geração periódica de uma edição ASCII legível por máquina. Ela não explicava como as negociações contestadas terminavam nem quem prevalecia em caso de falha da discussão.

Em março de 1974, a RFC 627 estabelecia o arquivo disponível, a incorporação semanal de atualizações, um canal de correção e a responsabilidade de cada host de obter as novas informações. Foi somente em 1982 que aRFC 810declarou explicitamente que o usuário da tabela de hosts do DoD era responsável por traduzi-la para o formato local exigido. Seria impreciso comprimir 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 agente de ligação. Convenções publicadas regiam a forma desse nome, a unicidade 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 obtinham o arquivo e incorporavam seu conteúdo nos sistemas locais. Em 1982, a responsabilidade do usuário pela tradução local foi expressamente enunciada.

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 reconstituído a partir apenas das RFCs processuais.

Esta é a primeira limitação da autoridade da tabela de hosts. O registro comum podia determinar qual nome um sistema entidade 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 nome, mas não eram idênticos ao controle de toda a conectividade.

Quatro tabelas divergentes e a necessidade de um arquivo comum

O arquivo de hosts online respondia a um problema de coordenação observado. Em dezembro de 1973, aRFC 606descrevia quatro sistemas TENEX acessíveis —SRI-ARC,BBN-TENEX,USC-ISIePARC-MAXC— cujos mapeamentos entre nomes de hosts e endereços diferiam. Nenhuma estava completa, e o autor acreditava que cada uma divergia em alguns aspectos da lista oficial.

Essa evidência não deve ser inflada para afirmar que todo site ARPANET tinha uma tabela imprecisa. Ela estabelece uma divergência em quatro sistemas nomeados. Mesmo essa constatação limitada era suficiente para demonstrar o custo de uma manutenção separada. Uma pessoa passando de uma máquina para outra podia encontrar respostas diferentes. Um programa escrito para um conjunto local podia falhar quando movido para outro. Um host recém-adicionado ou renomeado podia ser reconhecido em um site enquanto permanecia desconhecido em outro.

A RFC 606 propunha um arquivo legível por máquina gerado centralmente e mantido pelo NIC. Ela distinguia os dois fatos principais de uma entrada — o nome do host e o endereço do host — dos atributos opcionais como status do host, comportamento do protocolo e apelidos. Seu autor alertava que os atributos não precisavam necessariamente ser completos e não deveriam substituir a negociação de protocolo, o boca a boca ou outros meios de descobrir as propriedades de um host. A proposta era deliberadamente específica: visava resolver listas locais incompatíveis, e não estabelecer uma constituição global para a participação na rede.

A RFC 608 aceitou a ideia do arquivo central e relatou que tinha o 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 deveria gerar periodicamente o arquivo de distribuição ASCII. 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 se tornassem disponíveis.

O documento também permitia um prefixo de rede para hosts externos à ARPANET, mostrando que os autores já consideravam um conjunto de comparação mais amplo do que a população de hosts ARPANET. Ele não identifica todos os hosts externos efetivamente incluídos.

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. SRI-ARC era o contexto organizacional e computacional de onde várias dessas comunicações foram emitidas, enquantoOFFICE-1se tornou a máquina que servia os usuários do NIC e o arquivo de hosts publicado em março de 1974. Documentos posteriores usavamSRI-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 inalterada.

A RFC 627 converteu a proposta em um serviço anunciado. Ela incentivava os hosts a usar os nomes oficiais em seus monitores e tornava cada host responsável pela obtenção do arquivo. Os apelidos eram opcionais, e os sistemas que forneciam tradução nome-endereço eram incentivados, e 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 o recurso 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 obtê-lo e como instalá-lo. Um mestre recentemente corrigido podia coexistir com cópias locais desatualizadas. Um operador podia complementar um arquivo oficial com um alias local. Uma pessoa que conhecia um endereço numérico podia 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 errônea podia, no entanto, ter efeitos materiais. Um programa baseado em nome podia direcionar o tráfego para o endereço registrado em vez da máquina pretendida. Uma entrada ausente podia deixar o software incapaz de traduzir o nome solicitado. Uma atualização local atrasada podia preservar um resultado desatualizado. O comportamento exato dependia do sistema operacional e da aplicação locais. As RFCs não justificam uma afirmação universal de que toda omissão produzia uma desconexão ou que toda entrada imprecisa produzia o mesmo erro.

A movimentação de março ilustra a proposta mais restrita. Depois queNICfoi movido paraOFFICE-1, um site que implementava a mudança da RFC 620 associaria o apelido ao site 53. Um site desatualizado poderia continuar associando-o ao site 2. A movimentação do serviço do SRI ocorria 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 um desacordo substancial sobre a nomenclatura.

ARFC 226divulgou um conjunto proposto de mnemônicos e convidou a objeções. Sugestões concorrentes se seguiram. Algumas entidades favoreciam indicativos curtos; outras queriam nomes que preservassem identidades institucionais e de projeto. O debate não era meramente cosmético. Os nomes apareciam em comandos, documentos e hábitos dos usuários. Uma regra de nomenclatura distribuía, portanto, inconvenientes e reconhecimento junto com caracteres.

NaRFC 237, o NIC sustentava que era um órgão lógico para manter o padrão de nomenclatura e propunha atribuir nomes aos novos hosts assim que o Grupo de Trabalho de Rede resolvesse a sintaxe e a lista atual. Era uma proposta institucional do operador do serviço. Isso prova o que o NIC desejava que seu papel fosse, e não que toda organização conectada ou uma autoridade pública superior aceitasse a totalidade da reivindicação.

A RFC 273 respondeu ao fracasso das propostas anteriores em serem aceitas. Ela dizia que os hosts, por meio de seus agentes de ligação, deveriam escolher seus próprios nomes formais, possivelmente sujeitos a discussão se selecionassem nomes duplicados ou extra longos. Hosts da mesma instituição deveriam usar o mesmo mnemônico institucional. Um apelido deveria ser único dentro da comunidade da rede.

A linguagem estabelece a escolha local e a possibilidade de uma discussão central. Ela não define quem podia emitir uma recusa final. Um duplicado tornaria vão o objetivo de um apelido compartilhado, mas a incompatibilidade técnica por si só não revela o recurso administrativo. O NIC pode ter persuadido um site a escolher outro nome; um patrocinador pode ter intervindo; os sites podem ter aceitado uma convenção informal; ou um desacordo pode ter subsistido sem resolução. Um dossiê completo seria necessário para distinguir essas possibilidades.

ARFC 289, publicada em dezembro de 1971, relatava que quase todos os sites haviam respondido com os nomes desejados. Seu título, « O que esperamos ser uma lista oficial de nomes de hosts », preserva o caráter provisório do exercício. A lista emergente refletia uma solicitação e resposta dos sites dentro de uma comunidade ARPANET delimitada. Não era nem uma invenção privada unilateral nem o resultado de uma delegação pública mundial.

O papel do agente de ligação também requer cautela. A RFC 273 usava os agentes de ligação como canal pelo qual os hosts escolhiam e comunicavam os nomes. Umguia do Computer History Museum sobre os arquivos SRI ARC/NICindica que os agentes de ligação técnicos geralmente não tinham autoridade para falar em nome da administração do site. O guia de arquivos descreve a criação posterior de um papel de administrador de host cujo titular podia autorizar a ação do site. Como o guia cobre um período mais longo, ele não pode ser simplesmente projetado para trás em cada troca de 1971. Ele alerta, no entanto, contra tratar « agente 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 agente de ligação era o canal de comunicação, e o NIC mantinha o resultado compartilhado. A sintaxe e a unicidade esperada limitavam o que podia funcionar no espaço de nomes comum. Os documentos não revelam um sistema de arbitragem completo.

Esse poder discricionário limitado era, no entanto, significativo. Uma vez que um nome aparecia nos documentos e arquivos legíveis por máquina, usuários em outros lugares podiam confiar nele. Um host podia mudar de 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, e 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 Departamento de Defesa dos Estados Unidos. A ARPA financiou o programa de pesquisa, selecionou os contratantes e apoiou os centros de pesquisa entidades. A agência tornou-se a Defense Advanced Research Projects Agency em 1972. « ARPA » é, portanto, apropriado para o estabelecimento da rede e o debate inicial de nomenclatura, enquanto « DARPA » aparece nos registros do período posterior.

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

Isso estabelece uma relação patrocinador-contratante. A ARPA comprou um serviço de informação para a rede e a comunidade de pesquisa que apoiava. O SRI tinha a obrigação de executar tudo o que o contrato exigia, e a ARPA tinha o direito correspondente ao desempenho contratual. O relatório público não reproduz a declaração de trabalho inicial, as alterações, as normas de aceitação, as sanções, as cláusulas de dados ou as regras de decisão sobre nomes de hosts. Portanto, não pode estabelecer o conteúdo jurídico completo dessa obrigação.

Os sites conectados à ARPANET eram institucionalmente diversos. Incluíam universidades, institutos de pesquisa, laboratórios governamentais, instalações militares e empresas privadas. A diversidade de formas jurídicas não fazia de cada site um operador público não afiliado. Muitos participavam por meio de patrocínios federais, contratos ou relações de missão aprovadas. Ao mesmo tempo, a ausência dos instrumentos contratuais subjacentes impede afirmar que cada organização conectada tinha uma cláusula contratual idêntica exigindo conformidade com a tabela de hosts.

O relato direto mais sólido da transferência da ARPA para a Defense Communications Agency é escalonado e datado. O Relatório de Conclusão descreve um memorando ARPA-DCA pelo qual a gestão da ARPANET foi transferida para a DCA em 1º de julho de 1975. Ele também registra uma fase de transição de seis meses, até 31 de dezembro de 1975, durante a qual a ARPA continuou a auxiliar a DCA enquanto a DCA assumia o papel de gestora. Um plano de transição detalhado havia sido concluído em junho.

O relatório indica que a rede transferida deveria operar como uma instalação do DoD usada para atividades governamentais. A DCA financiaria a operação e manutenção por um acordo de rateio de custos envolvendo os patrocinadores da ARPANET. A DCA inicialmente contrataria a BBN e o SRI para operação da rede, manutenção e funções do NIC. O relatório diz que estava claramente implícito que a DCA poderia contratar outros contratantes posteriormente, certamente após o primeiro ano.

Isso é uma evidência da possibilidade de substituição institucional no nível da seleção de contratantes. Não prova que a DCA possuía uma cópia portável completa de cada registro do NIC, direitos ilimitados sobre os dados criados pelo contratante, um conjunto de transição testado ou um recurso executável para cada falha de serviço. Um cliente pode em princípio poder selecionar outro fornecedor, mas ainda enfrentar obstáculos práticos formidáveis para transferir conhecimento da equipe, software, arquivos, registros atuais e relações com os sites.

Uma publicação da DCA de 1978 indexada como aBrochura de Informações da ARPANETtambém dá 1º de julho de 1975 como data de transferência de gestão. O instrumento de pesquisa do Computer History Museum apresenta um relato retrospectivo contraditório: indica que a operação da ARPANET foi transferida para a DCA em 1973 e que o financiamento contratual da DCA apoiou o NIC do SRI após 1974.

O conflito deve permanecer visível. A cronologia formal do memorando no Relatório de Conclusão fornece uma data de transferência precisa e uma fase de transição. O instrumento de pesquisa fornece datas sumárias diferentes, mas não o instrumento subjacente que as reconciliaria. Ele também indica 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 pertinentes, a declaração operacional de 1973 e a declaração de financiamento posterior a 1974 não podem ser convertidas em uma cronologia única e contínua.

Após a transferência formal, a DARPA podia continuar a patrocinar pesquisas usando a ARPANET enquanto a DCA gerenciava a rede operacional. O DoD era o ambiente governamental pai; a DARPA e a DCA tinham funções diferentes dentro dele. O SRI permanecia um contratante executando os serviços do NIC, em vez de se tornar o próprio governo. Os sites entidades operavam hosts. Os agentes de ligação de hosts e papéis de contato posteriores transmitiam informações e instruções. Manter esses papéis distintos impede confundir o poder de contratação com um poder universal.

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

A tabela de hosts registrava as máquinas em um ambiente operacional, mas a manutenção do registro pelo SRI não fazia do SRI a única autoridade que decidia quem podia se juntar à ARPANET.

ODiretório ARPANET de dezembro de 1978descrevia as categorias de assinantes e o processo de obtenção do serviço. Seu quadro colocava a admissão e o patrocínio na estrutura de gerenciamento de rede da DCA. Um assinante em potencial precisava ter um objetivo 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 dos assinantes para a ARPANET. O SRI podia manter o diretório e as informações sobre os hosts usados após ou em torno da admissão. Uma entrada na tabela de hosts podia ser necessária para uso compartilhado prático, mas o registro do host não era o mesmo ato institucional que a aprovação da conexão da organização, a instalação de um processador de mensagem de interface, o fornecimento de um circuito ou a autorização de uma missão.

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

Em setembro de 1981, aRFC 790listava os números de rede da Internet atribuídos para muitas redes nomeadas, incluindo ARPANET, UCLNET, CYCLADES, TELENET, o EPSS do Correio Britânico, DATAPAC, TRANSPAC, LCSNET, TYMNET e uma variedade de sistemas de rádio por pacotes, satélite, locais e experimentais. Ela identificava Jon Postel, do Information Sciences Institute da Universidade do Sul da Califórnia, como o contato para atribuição 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 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 regida pelo processo da tabela de hosts do SRI. Um número aparecendo 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 misturam. O papel de Postel na atribuição de números na 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 do NIC. A DARPA continuava o patrocínio à pesquisa. Nenhum desses fatos faz de um ator o autor único de toda a Internet emergente.

A expressão « primeiro registro da Internet » requer, portanto, uma comparação definida. A tabela de hosts não era o primeiro diretório já mantido por uma organização de computação, e o arquivo de 1974 não era um registro para uma Internet pública global. Era uma referência precoce, compartilhada e legível por máquina de nomes e endereços na linhagem ARPANET-Internet. Em 1982, seu formato sucessor incorporava redes, gateways e endereços da Internet e era descrito por seus operadores como um banco de dados global de nomes e endereços de hosts.

Seu significado histórico reside no escopo crescente e na dependência interorganizacional dessa referência, e não em um mandato comprovado sobre cada rede.

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

A RFC 810 marcava uma mudança de escopo e linguagem institucional. Publicada em 1º de março de 1982 por Feinler, Ken Harrenstien, Zaw-Sing Su e Vic White do Network Information Center da SRI International, ela indicava que a antiga tabela de hosts ARPANET não atendia mais às necessidades da comunidade do DoD ou da interconexão. 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-NICvia FTP e via o Servidor de Nomes de Hosts. A RFC identificava o servidor como um serviço mantido pelo NIC ARPANET em nome da DCA. Ela também atribuía expressamente a responsabilidade da tradução ao usuário: quem consumisse a tabela deveria convertê-la no formato exigido 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 deviam ser negociados e registrados junto ao NIC antes de serem usados e antes que o tráfego fosse roteado por um host do DoD. Era uma condição prévia publicada que regia o comportamento do host do DoD. Ela vinculava o registro à operação mais diretamente do que o incentivo de 1974 para usar nomes de hosts oficiais.

A frase não documenta a aplicação. A RFC 810 não identifica um monitor inspecionando registros, uma regra de roteador rejeitando 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 é importante. Uma especificação pode definir uma conduta exigida sem provar com que consistência os operadores a implementaram.

O documento tratava as informações não-DoD de forma 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 necessário, aguardando servidores de nomes intercomunicantes. Ele não identificava cada entrada não-DoD efetivamente incluída nem impunha a mesma condição prévia expressa a todos os operadores externos.

O novo formato também tinha uma introdução escalonada. A RFC 810 especificava 1º de maio de 1982 como data de migração. Durante maio, o caminhoHOSTS.TXTexistente ainda continha a edição antiga, enquanto um arquivo de teste no novo formato estava disponível separadamente. Em junho e julho, o caminho principal continha o novo formato, enquanto o material no formato antigo permanecia acessível por outro caminho. Após 1º de agosto, o formato antigoHOSTS.TXTespecificado pela RFC 608 não seria mais suportado.

Essa sobreposição distinguia um design publicado de uma implementação universal imediata. Os programas tinham 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 cada host concluiu a conversão a tempo.

ARFC 811, publicada no mesmo dia, especificava o Servidor de Nomes de Hosts online. Um programa podia consultar um nome ou endereço de host ou solicitar a tabela inteira. O servidor podia retornar registros de host, gateway ou rede. Se um nome solicitado estivesse ausente, o erro definido assumia a formaERR: NAMNFD: Nome não encontrado:. Outros erros eram possíveis, incluindoTMPSYS, significando uma falha temporária do sistema e uma solicitação 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 usando uma cópia baixada. Uma busca local em uma tabela sem uma entrada podia falhar, usar um mapeamento adicional, solicitar o usuário ou se comportar de outra maneira dependente do sistema. A ausência de um nome de uma cópia local e uma respostaNAMNFDdo servidor eram condições relacionadas, não necessariamente eventos idênticos.

A RFC 811 descrevia seu banco de dados como uma extensão do antigo arquivoHOSTS.TXTda ARPANET e qualificava a administração central como uma solução provisória no caminho para um serviço de tradução nome-endereço descentralizado e distribuído. Essa afirmação institucional é importante por duas razões. 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 ARPANET original. Isso não prova independentemente uma cobertura universal.

No início dos anos 1980, o NIC estava cada vez mais associado ao ambiente da Rede de Dados de Defesa, e coleções históricas usam posteriormente o nome DDN-NIC para o serviço. Esse rótulo posterior não deve ser projetado de volta no contrato de 1969 ou no debate sobre nomes de hosts de 1971. SRI-ARC, o SRI NIC, SRI-NIC e DDN-NIC descrevem contextos organizacionais e de hosts conectados, mas temporalmente distintos.

O que os arquivos podem mostrar — e o que permanece faltando

A série de RFCs é excepcionalmente rica em propostas, especificações e anúncios. Ela é muito mais fraca como registro de casos administrativos individuais.

O instrumento de pesquisa do Computer History Museum identifica coleções pertinentes: propostas e contratos do NIC, relatórios de progresso, registros de nomenclatura e endereçamento, tabelas de hosts, documentação de serviço de referência, correspondência e registros sobre contatos oficiais da rede. Ele indica que o primeiro contrato do NIC não era decomposto em tarefas e que contratos posteriores se tornaram mais elaborados. Ele também descreve agentes de ligação técnicos, administradores de hosts, coordenadores de site de nó e outros contatos pelos quais mensagens de informação ou ação transitavam.

Um instrumento de pesquisa estabelece a existência, o assunto aproximado e a classificação dos registros. Ele não divulga 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 particular. Os documentos subjacentes precisariam ser abertos e comparados.

Nenhum dossiê de solicitação completo foi produzido aqui mostrando o nome proposto de um host, as perguntas do NIC, a resposta do site e a decisão final. Nenhum caso preservado demonstra uma recusa do NIC com base em duplicação, um recurso bem-sucedido, uma exceção de patrocinador ou um recurso de correção. Nenhum registro completo fornece os tempos de processamento ou as taxas de erro. As informações de contato da RFC 627 provam que um canal de correção existia; elas não provam os resultados obtidos por meio dele.

Os contratos ausentes importam por uma razão distinta. Um contrato federal pode conferir um direito ao desempenho sem conferir a propriedade de cada registro, o título de propriedade de um sistema técnico ou direitos ilimitados sobre os dados criados pelo contratante. Pode especificar entregáveis, licenças de dados, assistência à transição e recursos, mas essas consequências dependem de suas cláusulas reais.

Umaanálise do Government Accountability Office sobre os arranjos das funções federais da Internetmuito posterior distinguiu cuidadosamente os direitos de desempenho, os direitos de uso de dados, o título de propriedade e a propriedade. Essa opinião de 2016 dizia respeito a arranjos posteriores de DNS e IANA e não fornece os termos ausentes dos contratos do SRI dos anos 1970. Seu valor aqui é metodológico. O financiamento federal por si só não pode ser usado para inferir cada propriedade ou direito de transição.

O Relatório de Conclusão apoia uma conclusão mais restrita: a DCA inicialmente pretendia manter o SRI para a função do NIC e podia posteriormente usar outro contratante. Isso mostra a possibilidade de substituição do fornecedor considerada. Não estabelece que a substituição podia ocorrer sem atraso, disputas sobre dados, conversão de software, perda de memória institucional ou interrupção de serviço.

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

O silêncio deve operar em ambos os sentidos. A ausência de procedimento de recurso publicado não prova que nenhuma escalada informal existia. Chamadas telefônicas, correio de rede, trocas NLS e intervenção de patrocinadores podem ter resolvido disputas sem RFC. Inversamente, a ausência de reclamações publicadas não prova que cada entidade considerava o processo legítimo ou que cada atualização era oportuna.

A incerteza resultante é institucional, em vez de meramente antiquária. Se as solicitações fossem regularmente corrigidas por uma confirmação transparente do site, o serviço pareceria mais clerical e cooperativo. Se o NIC pudesse recusar entradas sem explicação e nenhuma revisão de patrocinador existisse, o mesmo arquivo teria um significado de governança diferente. As evidências públicas não apoiam nenhum dos extremos como 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 as mudanças por comunicação pessoal e traduzia as informações remotas em seu próprio sistema operacional.

Com quatro sites, isso podia ser gerenciável. Os administradores se conheciam, os projetistas de protocolos se reuniam regularmente, e uma correção podia circular 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 comunicavam com frequência, podiam manter suas informações compartilhadas atualizadas mesmo quando uma máquina central estava indisponível.

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

Uma adição ou mudança de endereço de host precisaria alcançar vários administradores. Cada um a aplicaria em um cronograma distinto e em um formato local. Uma correção podia ser reconhecida por um site, perdida por outro e transformada incorretamente por um terceiro. Os operadores precisariam identificar a edição que tinham, comparar relatos conflitantes e determinar se uma falha de serviço aparente vinha da rede, do host remoto ou de um mapeamento desatualizado.

A RFC 606 fornece o alerta 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 um canal reconhecido. O SRI podia gerar uma edição única. Os sites podiam obter o mesmo arquivo e comparar seu estado local com uma referência datada. Um operador de suporte investigando uma anomalia tinha um ponto focal para começar.

O arquivo comum não eliminava todos os custos de distribuição. Cada site ainda precisava de armazenamento, software de obtenção, conversão local e uma rotina de atualização. A publicação semanal introduzia um atraso entre uma mudança relatada e sua aparição na edição seguinte. A obtenção podia falhar quando o host servidor ou um caminho de rede estava indisponível. A instalação local podia ficar para trás após uma obtenção bem-sucedida. A arquitetura centralizava a compilação, não todas as tarefas operacionais.

Uma fonte comum também não garantia a verdade. O SRI dependia dos hosts e contatos para fornecer informações precisas. Um endereço errôneo fornecido por um site podia entrar no mestre. Uma atualização central correta podia ser prejudicada por uma implantação local desatualizada. Um conflito podia persistir se o procedimento para resolvê-lo não fosse claro. A referência tornava o desacordo visível e reduzia a duplicação, mas não abolía a necessidade de verificação.

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

Um registro comum com mais de um distribuidor

Uma segunda alternativa viável na época teria preservado um arquivo canônico único enquanto distribuía armazenamento e obtenção mais amplamente.

A ideia aparecia em documentos contemporâneos. ARFC 623propunha que o NIC mantivesse o mestre enquanto outro host mantivesse uma cópia secundária frequentemente atualizada. Seu autor se voluntariou para a UCSB e sugeriu sincronização diária. O objetivo era a disponibilidade: se o host do NIC não pudesse servir 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 secundária potencial. Ela discordava da substituição do FTP por um protocolo de obtenção dedicado. A RFC 627, publicada posteriormente em março, ainda convidava qualquer host que desejasse manter uma cópia secundária a contatar o NIC.

Esses registros estabelecem um design 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, um log de servidor, um arquivo secundário arquivado, um manual de host ou um relatório posterior. A proposta não deve ser reescrita como uma implantação.

Se um tal secundário tivesse funcionado, teria exigido recursos apropriados na época. O site precisava de armazenamento para o arquivo, pessoal ou procedimentos automatizados para obter as 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 última versão canônica. O secundário precisava de uma regra para saber o que fazer quando sua cópia local diferisse da do SRI.

Uma falha podia tornar a reconciliação difícil. Suponha que o secundário perca duas atualizações enquanto o SRI permanecia disponível, e depois retorne com uma edição mais antiga. Uma convenção de timestamp ou sequência seria necessária para impedir que os usuários confundissem disponibilidade com atualidade. Se o SRI estivesse indisponível enquanto uma correção contestada chegava, o secundário precisaria saber se podia publicar a mudança ou simplesmente continuar servindo o último mestre confirmado.

A replicação também deixava a autoridade de modificação não resolvida. Um espelho podia distribuir o arquivo canônico sem decidir sobre 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 atesta seus fatos, o centro reconciliando o espaço de nomes compartilhado, o distribuidor servindo cópias e qualquer revisor lidando com disputas.

A confirmação do site poderia ter sido reforçada sem infraestrutura moderna. Antes da publicação semanal, o NIC poderia ter enviado uma mudança proposta ao agente de ligação relevante ou ao contato autorizado do site. Um aviso de mudança datado poderia ter acompanhado o arquivo gerado. Os guardiões secundários poderiam comparar as mudanças anunciadas com o arquivo que recebiam. Os sites poderiam relatar anomalias 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 podiam aguardar confirmação. A equipe precisava manter logs e reconciliar solicitações não respondidas. Um host que mudava rapidamente poderia achar um ciclo semanal muito lento, enquanto uma distribuição mais frequente aumentava o cálculo, o uso da rede e a carga de trabalho do operador. Uma revisão formal poderia melhorar a responsabilidade enquanto atrasava correções urgentes.

A mudança de contratante apresentava um problema maior. A capacidade da DCA de selecionar outro fornecedor não garantia a substituição suave 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 pendentes, do histórico de correções, das listas de contatos, do conhecimento da equipe e do acesso ao ambiente de serviço. Se o contrato não especificasse a entrega ou os direitos de uso dos dados, a transferência podia se tornar juridicamente 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 outro contratante era considerado, não que um mecanismo de transferência testado estava em vigor. A possibilidade de substituição no papel e a continuidade na operação eram realizações distintas.

Essa alternativa esclarece a escolha de governança. Uma resposta lógica única não exigia um distribuidor físico único. Uma edição canônica podia coexistir com espelhos, confirmação de site, modificações preservadas e um provedor de serviços substituto. Cada adição teria deslocado custos e responsabilidades 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 se acumulou através de uma série de relações diferentes.

Em 1969, a ARPA financiou um Network Information Center para ARPANET. Isso estabelecia um cliente federal, um contratante SRI e uma população de serviço definida. Isso não fazia do SRI o representante de cada rede de computadores.

Em 1971, os hosts foram convidados a escolher nomes por meio de agentes de ligação no âmbito de convenções publicadas. O debate e a resposta entre as entidades da ARPANET forneceram uma aceitação pelos pares delimitada. O papel proposto do NIC foi restringido pela escolha local, enquanto o espaço de nomes 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 design da fonte. As RFCs 620 e 627 documentaram uma instrução específica de mudança em todo o site, o arquivo ASCII disponível, as atualizações semanais, a responsabilidade de obtenção local e os canais de correção. Elas não documentaram um veto geral do NIC ou um sistema completo de resolução de disputas.

Em 1º de julho de 1975, de acordo com o memorando ARPA-DCA descrito no Relatório de Conclusão, a gestão da ARPANET foi transferida para a DCA, seguida por uma fase de transição até 31 de dezembro. A DCA inicialmente manteve o SRI para as funções do NIC e podia considerar outro contratante. A declaração contraditória de transferência operacional de 1973 do instrumento de pesquisa e o relato de financiamento posterior a 1974 permanecem não resolvidos.

Em 1978, o quadro de assinantes da DCA colocava a admissão à ARPANET na gestão da rede governamental, em vez da manutenção da tabela de hosts do SRI. Isso separava a autoridade de admitir um assinante do serviço que registrava e distribuía as informações sobre os 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 na USC-ISI. O aparecimento nessa lista não estabelecia que cada rede compartilhava uma relação jurídica ou operacional única com a DCA ou o NIC.

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

O servidor da RFC 811 tornava a resposta mantida disponível por consultas online e descrevia o banco de dados central como uma ponte provisória para uma nomenclatura distribuída. Esse serviço aumentava a dependência do SRI-NIC enquanto reconhecia que a arquitetura não foi projetada para permanecer centralizada permanentemente.

A tabela de hosts exercia, portanto, sua autoridade demonstrada mais forte em três lugares. O SRI devia desempenho ao seu cliente federal no âmbito 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 entidades dependiam do registro comum para uma comunicação consistente baseada em nomes.

Fora dessas relações, o escopo da tabela resultava de interoperabilidade e adoção. Uma rede externa podia contribuir com informações ou usar o arquivo comum porque isso tornava a comunicação mais fácil. Essa dependência era consequente, mas a RFC 810 não a descrevia como equivalente à condição prévia do DoD. Nenhum registro examinado mostra uma circunscrição 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; os contratantes e sites forneciam as máquinas e software; os circuitos e comutadores de pacotes transportavam o tráfego; outras autoridades gerenciavam os 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 cada atribuição numérica.

Sua autoridade prática era, no entanto, substancial. Um registro compartilhado consumido por muitas máquinas pode restringir a conduta mesmo que nenhum legislador ou órgão público seja membro dele. Um host desejando reconhecimento previsível tinha interesse em seguir as convenções de nomenclatura. Um site desejando respostas atualizadas tinha interesse em obter o arquivo comum. Um host do DoD era alvo de uma condição prévia 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 uma rede externa à vontade, impunha sanções a cada site não conforme ou convertia cada entrada ausente em desconexão física. Elas não revelam uma estrutura de recurso completa, um recurso de correção ou uma hierarquia de exceção. Elas não estabelecem a propriedade governamental portável de todos os dados do NIC.

A primeira tabela de hosts era autoritária onde as compras, a gestão de rede e a dependência de máquinas se encontravam. Ela resolvia 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 realização explica por que o registro adquiriu força antes que nomes e endereços se tornassem ativos de mercado.

Ela não prova que o operador do registro recebeu autoridade sobre cada rede que o registro podia descrever. A cadeia histórica apoia uma conclusão mais restrita: o SRI mantinha uma referência encomendada pelo governo federal para uma rede patrocinada, essa referência se tornou integrada às operações da Internet do DoD, e uma dependência mais ampla estendeu seu alcance prático. A utilidade do registro o tornou poderoso. Seu mandato público permaneceu não estabelecido.