Resumo

  • As tabelas combinadas de ARPANET e DCNET já tinham mais de 400 nomes e apelidos. Mills propôs domínios para não exigir que cada máquina guardasse uma lista plana de todos os futuros computadores.
  • Um único host podia operar encaminhadores para COMSAT e INTELPOST. Mills@HOST podia ser uma caixa diferente em cada domínio; o endereço do host não bastava para encaminhar a resposta. O nome completo e a rota de retorno precisavam conservar o domínio.

Imagine duas caixas de correio etiquetadas Mills@HOST no mesmo balcão. A primeira pertence a COMSAT, a segunda a INTELPOST. Quem tira o nome do domínio do envelope cria um pequeno concurso de adivinhação para o funcionário. Esse balcão é uma imagem; o problema técnico está na RFC 799, publicada por D. L. Mills em setembro de 1981. As tabelas de nomes de ARPANET e DCNET somadas já continham mais de quatrocentos nomes e apelidos. Dividir o catálogo parecia sensato. A pergunta era como fazer uma carta voltar à caixa certa depois da divisão.

Os domínios de nomes imaginados por Mills podiam corresponder a ARPA, UCL, COMSAT e outras instituições. Eles podiam se sobrepor e não precisavam abranger todos os endereços. O texto examinava só um nível de domínio, embora a forma padrão <user>.<host>@<domain> sugerisse três partes lidas da direita para a esquerda. Dentro de COMSAT, Mills@COMSAT-DLM podia bastar. Fora dali, Mills.COMSAT-DLM@COMSAT dizia também qual catálogo local dava sentido ao nome. Apelidos idênticos em domínios diferentes eram permitidos. A parte final do endereço não era decoração.

Cada domínio teria um ou mais processos encaminhadores de correio. Um encaminhador manteria a tabela de todos os hosts do próprio domínio e o nome de ao menos um encaminhador de cada outro domínio. Os hosts comuns guardariam esses pontos de contato e quaisquer nomes adicionais convenientes. Um mesmo host podia pertencer a vários domínios, ter vários endereços de Internet e abrigar vários processos de encaminhamento. Mills mencionou a possibilidade de duplicar encaminhadores para resistência a falhas, deixando a complexidade de roteamento gerada por isso para outra conversa.

O sistema concedia escolhas locais, contanto que o contexto chegasse vivo à fronteira.

Ter encaminhadores não transformava toda mensagem em encomenda de muitas paradas. Mills esperava que a maioria fosse diretamente do host remetente ao host destinatário. Um intermediário seria útil se os dois não estivessem conectados ao mesmo tempo, se o remetente não tivesse recursos para resolver todos os nomes, se o caminho direto enfrentasse limites regulatórios, econômicos ou de segurança, ou se os lados usassem transportes diferentes, como TCP e NCP. Um simples retransmissor podia armazenar e repassar sem a tabela completa de um encaminhador.

Era importante distinguir o funcionário com a lista de domínios de quem apenas guardava a mala durante a noite.

Os exemplos da RFC tornam o risco inequívoco: MRCP to:<@COMSAT,Mills@HOST> e MRCP to:<@INTELPOST,Mills@HOST> podem apontar para caixas distintas mesmo quando os dois serviços rodam no mesmo computador. Se esse computador se chama FORWARDER nos dois domínios, MRCP to:<@FORWARDER,Mills@HOST> perde a informação que separava as caixas. Consultar o endereço de Internet da máquina também não resolve: ele identifica o computador, não o papel COMSAT ou INTELPOST exercido por aquele processo para aquela mensagem.

A resposta corria o mesmo perigo. No procedimento de RFC 780 analisado por Mills, o destinatário deveria construir um nome para a rota de volta a partir do endereço de Internet do host que entregou a carta. Se o host era um encaminhador de múltiplos domínios, esse endereço não guardava a escolha original. Mills concluiu que o remetente teria de atualizar tanto a rota do destinatário quanto a rota do remetente, copiando a primeira entrada da rota recebida para o começo da rota de retorno. O recibo de entrega precisava dizer por qual guichê a mensagem tinha passado.

Os sistemas antigos ainda escreviam nomes curtos. Mills evitava uma série de edições do cabeçalho RFC 733 ao longo do caminho; isso exigiria análise invasiva. Sistemas novos podiam adotar desde o início o nome completo. Para o correio ARPANET existente, ele propôs reescrever na primeira entrada para o sistema de correio da Internet: um <anything>@<host> local passaria a <anything>.<host>@ARPA, enquanto um <anything>@<domain> reconhecido ficaria como estava. A origem de um apelido ainda é conhecida na porta por onde ele entra.

A RFC termina convidando à discussão. Era uma proposta para um problema de 1981, não o relato de uma implantação posterior do DNS. Seu caso de uma máquina com dois papéis, porém, é uma pequena aula de identidade: um endereço de 32 bits pode escolher a máquina e ainda deixar em aberto qual caixa postal ela representa. Mais de quatrocentos nomes pressionavam a lista plana; duas caixas no mesmo balcão expunham a dificuldade das respostas.