Resumo

  • A RFC 897 permitiu que a forma do nome mudasse antes de a fonte da resolução: um nome com .ARPA ainda podia ser encontrado em uma cópia local de HOSTS.TXT.
  • A RFC 921 manteve o cronograma anterior visível e marcou o que saiu no prazo, o que atrasou e o que continuava pendente.
  • Servidor, base carregada, biblioteca instalada, aplicativo convertido e retirada da tabela eram estados separados, inclusive dentro do mesmo host.

O sistema anterior já dependia de várias entregas. A RFC 810 definia uma tabela de hosts mantida no NIC e preparada para tradução por máquina. O site receptor ainda precisava obtê-la, convertê-la para sua representação local e ativá-la. A RFC 811 descrevia um Hostnames Server capaz de responder a uma consulta ou enviar a tabela inteira. Um registro correto na origem não dizia qual versão um aplicativo estava usando.

A RFC 881 expôs o impasse. Nomes com pontos, usados por poucos grupos, apareceriam rapidamente em mensagens destinadas a programas não preparados. Esperar que todos estivessem prontos impediria o começo. O plano usou coexistência: uma tabela em estilo de domínio ao lado da tabela comum, depois a substituição da principal e, por fim, um resolver ocupando o lugar da chamada de biblioteca antiga para que o aplicativo não precisasse conhecer o mecanismo.

As RFC 882 e RFC 883 forneciam nomes, dados tipados, zonas, servidores, referências, resolvers e caches. Publicar esse desenho não revelava se o mailer de uma máquina ainda fazia uma varredura local. A política precisava governar a passagem entre a especificação e cada execução.

A aparência e o motor mudaram em dias diferentes

A RFC 897, de fevereiro de 1984, separou duas alterações. Uma trocava strings globais planas por nomes hierárquicos. A outra levava a tradução nome–endereço de cópias locais de uma tabela central completa para consultas dinâmicas a servidores que mantinham partes da base.

O caminho tinha quatro degraus. Primeiro, acrescentar .ARPA ao nome antigo. Segundo, criar poucos domínios. Terceiro, trocar tabelas por servidores. Quarto, admitir muitos domínios. Um nome pontuado, portanto, não comprovava o uso de DNS. A velha tabela era capaz de transportar a nova forma.

Manter o nome antigo como apelido amortecia o impacto, mas só no ponto que aceitava o alias. Não consertava a agenda de outra pessoa, o remetente de uma mensagem antiga, um campo Cc já enviado ou uma lista mantida longe dali. Quando o identificador era copiado, parte do estado da migração passava a ter donos externos.

A base distribuída também deveria conservar a descoberta do nome principal a partir do endereço. Isso exigia coordenação entre administradores. Não transformava o nome em autenticação nem a resposta reversa em prova de alcance.

Duas comunidades podiam exibir o mesmo padrão e operar de outro modo

O cronograma previa nomes de domínio como principais em 14 de março de 1984, retirada dos nomes antigos em 2 de maio, domínios gerais e multinível em 6 de junho, nomes de organizações em 18 de julho, fim da tabela completa para a comunidade de pesquisa ARPA em 5 de setembro e um plano DDN em 3 de outubro.

A comunidade de pesquisa ARPA faria a transição completa. A comunidade operacional DDN mudaria os nomes no mesmo calendário, mas não teria de abandonar a tabela ao mesmo tempo. Seu escritório definiria a etapa posterior, e o NIC continuaria mantendo dados centrais para ela.

Assim, o namespace comum escondia duas obrigações de implementação. A existência de .ARPA dizia como o host era chamado, não qual autoridade havia respondido.

A revisão publicou o placar

A RFC 920 apareceu em outubro com os requisitos para novos domínios e uma organização revista dos domínios superiores. A RFC 897 a esperava em fevereiro. A regra de entrada ainda estava sendo decidida enquanto a migração corria.

A RFC 921 preservou a tabela antiga com comentários. A tabela inicial de nomes de domínio e a mudança do nome principal em março ocorreram no prazo. Os servidores do domínio ARPA funcionaram, mas só em setembro, e não em abril. A tabela de domínios superiores, novos domínios, nomes multinível, nomes de organizações, aposentadoria da tabela e o plano DDN ainda não estavam prontos.

O documento dividiu o restante em três fases. Machinery era a existência de servidores e resolvers. Database era a instalação efetiva dos dados. User programs eram mailers, Telnet, FTP e outros consumidores usando os novos procedimentos. Em outubro de 1984, as máquinas e parte da base avançavam; os programas de usuário quase não.

O novo calendário estendeu metas até outubro de 1985. Essas datas continuavam sendo intenção. O valor probatório estava no passado classificado sem eufemismo: feito, atrasado ou não feito.

O modo misto entrou no interior do host

Em novembro de 1987, a RFC 1031 previa três estágios simultâneos no MILNET: só tabela, tabela mais DNS e só DNS. Telnet e FTP podiam migrar antes do correio, ou o correio podia ser o primeiro. Um host tinha vários últimos quilômetros.

O documento dizia que a maioria ainda estava no estágio de tabela. Arquiteturas antigas ou software imutável talvez nunca fossem convertidos. Encerrada a tabela comum, esses sistemas precisariam de um acordo bilateral, repositório comunitário ou tabela local. A exceção deixava de ser um serviço compartilhado e passava a exigir uma relação própria de confiança e atualização.

A RFC 1034 registrou o custo de escala de HOSTS.TXT e descreveu uma interface de resolver parecida com a função antiga. Essa compatibilidade permitia trocar a origem sem reescrever todos os chamadores, mas escondia o estado de transição de quem observava apenas a aplicação.

A RFC 1401 reproduziu cartas de 1992 nas quais o IAB considerava incompleta a transição do MILNET e associava mapas divergentes a falhas de alcance. É correspondência de política, não uma medição neutra de adoção. Ainda assim, documenta a longa cauda criada por calendários diferentes.

Fontes e limites

A reconstrução usa as RFCs 810, 811, 881, 882, 883, 897, 920, 921, 1031, 1034 e 1401. Elas comprovam desenhos, obrigações, datas, auditoria e observações atribuídas. Não comprovam uma virada universal, conformidade de cada site, identidade autenticada, alcance atual ou comportamento de produto contemporâneo.