Resumo

  • A RFC 849 separou o estado atual do arquivo mestre no NIC do estado das cópias que cada site realmente usava.
  • Sua opção preferida reservava o push de uma tentativa para a rapidez e usava versão, consulta na inicialização e polling periódico para reparar uma entrega perdida.

Uma máquina desligada não confirma nem rejeita um aviso. Ela simplesmente não participa daquele instante. Quando volta, pode retomar o serviço com a antiga tabela de nomes, sem saber que existe uma edição mais recente.

O arquivo mestre pode estar correto. O atraso nasce entre a publicação e o uso.

Foi esse espaço que Mark Crispin descreveu em maio de 1983, na RFC 849, Suggestions for Improved Host Table Distribution. O próprio texto avisa que nenhuma das soluções propostas era padrão. Tratava-se de uma solicitação de comentários, com a expectativa de que um consenso posterior pudesse levar a uma norma. Portanto, a RFC não é prova de implantação. Ela é valiosa por outro motivo: torna visíveis estados que a expressão “tabela atualizada” costuma misturar.

Um cadastro central gerava muitas cópias locais

A RFC 608 havia apresentado uma fonte mantida pelo NIC. Dela seria gerado periodicamente um arquivo ASCII com nomes, endereços e atributos dos hosts, semanalmente ou conforme a necessidade. O produto <NETINFO>HOSTS.TXT ficaria disponível por FTP.

Havia uma origem comum, mas não um relógio comum para todos os consumidores.

Em 1982, a RFC 810 redefiniu o formato para o Internet do DoD. A tabela passou a representar redes, gateways, hosts, sistemas operacionais e alguns protocolos. Podia ser obtida por FTP anônimo no SRI-NIC ou pelo Host Name Server. A especificação também colocou sobre o usuário a responsabilidade de traduzir a tabela para o formato exigido em seu ambiente.

Essa frase revela que o download não encerrava a atualização. Existiam o arquivo publicado, os bytes recebidos, a conversão local e a base efetivamente consultada. Uma etapa concluída não provava a seguinte.

A RFC 811 ofereceu acesso online pelo porto TCP 101. HNAME localizava pelo nome, HADDR pelo endereço e ALL devolvia a tabela inteira entre BEGIN e END. Isso ampliava as formas de obter o conteúdo do NIC, mas ainda não fornecia uma comparação leve entre a edição já instalada e a edição corrente.

A ausência de um número custava frescor ou tráfego

Crispin observou que os sites precisavam manter cópias locais porque SRI-NIC não era confiável o bastante para funcionar como o único serviço de nomes disponível o tempo todo. O NIC permitia descarregar todo o registro e oferecia FTP anônimo. Ainda assim, alguém precisava saber que chegara a hora de buscar uma nova versão; as mudanças nem sempre haviam sido anunciadas com cuidado.

Sem comparação automática, um administrador podia continuar com dados antigos. Ou podia baixar outra vez exatamente a tabela já instalada. A primeira falha consumia atualidade; a segunda consumia recursos. Ambas vinham da mesma pergunta sem resposta: a edição mudou?

A segunda proposta da RFC 849 era um protocolo que informasse a “versão” atual. Em Tenex e TOPS-20, o generation number do arquivo servia naturalmente como identidade. Crispin já conservava SYSTEM:HOSTS.TXT com a mesma geração vista no NIC e verificava de tempos em tempos se o número remoto havia mudado. Queria automatizar esse teste.

O número não atestava que cada linha fosse verdadeira. Não dizia que a conversão local terminara, nem que o resolvedor passara a usar o novo arquivo. Ele fazia uma afirmação pequena: é a mesma edição ou outra.

Justamente por ser pequena, a resposta era barata. Se a geração permanecesse igual, não havia motivo para transportar tudo. Se fosse diferente, o site recebia evidência de que sua cópia estava atrás antes que uma aplicação revelasse o problema.

O push rápido cobrava memória de quem enviava

A primeira solução proposta invertia o movimento. Cada site teria um processo escutando em um porto registrado e aceitaria atualizações de certos sites “trusted”, principalmente SRI-NIC. Para um host ligado, o novo cadastro poderia chegar quase imediatamente.

O caso difícil era o host fora do ar. Se o push puro prometesse alcançar todos, o NIC teria de lembrar quem não respondeu e tentar de novo. Além do registro de nomes, surgiria um registro operacional de assinantes, tentativas, indisponibilidade e dívida de reenvio. A velocidade do caso normal deslocava para o centro a história de falhas de cada ponta.

A RFC 849 sugeriu um checksum para confirmar que o registro atualizado chegara completo e intacto. É importante não alargar essa conclusão. O documento não especificou autenticação criptográfica da origem, resistência a substituição maliciosa ou validação do significado dos registros. O checksum observava a entrega. Autoridade, correção dos dados, conversão e ativação continuavam separados.

O correio entregava um objeto, não uma mudança de estado

Uma terceira alternativa enviaria a tabela por e-mail a uma lista de destinatários, deixando cada site organizar sua atualização. Era simples para o NIC. Mas a RFC 849 considerou o correio inadequado para remeter arquivos em massa a muitos receptores, sobretudo com o crescimento previsto do arquivo.

Havia ainda uma distância entre “mensagem aceita” e “tabela ativa”. Fila, caixa postal, extração, tradução e troca da base permaneciam depois da entrega. O canal podia encerrar sua contabilidade enquanto o sistema local continuava no passado.

A quarta proposta fazia da volta ao ar um ponto de recuperação

A escolha de Crispin combinava a primeira e a segunda propostas. O NIC enviaria a atualização uma vez aos hosts registrados e não manteria tentativas infinitas. Cada site consultaria o NIC durante a inicialização do sistema, recuperando a nova edição se ela existisse. Uma consulta periódica, talvez diária, serviria como proteção adicional.

O push era o caminho rápido para quem estivesse acessível. A inicialização era o momento em que a máquina sabia, com certeza local, que acabara de voltar e precisava comparar sua cópia. A verificação diária alcançava os sistemas que não receberam o push nem reiniciaram.

O número de versão tornava a recuperação econômica. O NIC não precisava administrar para sempre a indisponibilidade particular de cada host. O site também não precisava transportar o arquivo completo em toda consulta. Rapidez e reparo tinham donos diferentes.

Não havia promessa de sincronização instantânea. O NIC poderia estar inacessível na inicialização. A transferência podia quebrar, o checksum divergir, a tradução falhar ou o arquivo antigo permanecer em uso. A contribuição do desenho era outra: cada falha passava a ter uma fronteira observável e uma próxima ação. O rótulo “atualizado” deixava de esconder todo o percurso.

Distribuir o banco não aboliu o tempo de propagação

Em novembro de 1983, a RFC 881 ainda dizia que quase todos os hosts do Internet utilizavam alguma forma de tabela baseada no mestre HOSTS.TXT do NIC. Seu plano para nomes de domínio previa uma fase de convivência entre mecanismos.

A RFC 882 diagnosticou que o tamanho da tabela global e, principalmente, sua frequência de alteração se aproximavam do limite administrável. Era preciso um banco distribuído. A RFC 883 repartiu o espaço de nomes entre servidores, distinguiu dados autoritativos de dados em cache e definiu atualizações periódicas. Também reconheceu que uma mudança no mestre não atualizaria todas as cópias imediatamente; ela se espalharia de forma gradual.

Isso não transforma a RFC 849 em protótipo implementado do DNS. Suas sugestões não eram padrão e a arquitetura de domínios tratava de delegação, consulta e manutenção em outra escala. A continuidade é conceitual: onde há cópias, há idade, versão, regra de renovação e comportamento quando a renovação falha.

O estado real é o da última transição concluída

Um registro autoritativo pode declarar qual associação de nome e endereço reconhece agora. Não pode, apenas com essa declaração, atualizar uma máquina desligada. O aviso não executa a tradução. O checksum não ativa a base. O número de versão não muda o arquivo aberto pelo resolvedor.

A RFC 849 deixou uma gramática de evidência: edição de origem, tentativa de notificação, bytes recebidos, integridade aceita, conversão concluída, estado ativo observado e caminho de recuperação. Cada item sustenta uma afirmação diferente.

Na passagem histórica entre uma tabela central e o serviço distribuído de nomes, a lição é precisa. Publicação é um evento no produtor. Frescor é uma condição verificada no consumidor. O arquivo mestre podia estar em dia e a rede, silenciosamente, não.

Fontes