Resumo

  • A SINS da RFC 830 resolvia o domínio até o endereço do DNS/AIP de destino e, em seguida, fazia processos de interface negociarem transporte e serviço de aplicação.
  • Bases intermediárias guardavam apenas subdomínios imediatos, podiam ter formatos locais e deixavam cache a critério da implementação; o protocolo comum detalhava as conversas de fronteira.
  • As RFCs 882 e 883 escolheram recursos tipados e classificados, zonas, autoridade, referências, cache e atualização dentro de uma base distribuída padrão. O registro passou a escalar, não a provar execução.

O cache só lembrava a primeira metade

A RFC 830 reconhecia que refazer toda a resolução para cada transação custaria comunicação demais. Guardar resultados anteriores era a solução óbvia. Ainda assim, o cache não entrou como função padrão da SINS. Cada implementação decidiria se, como e por quanto tempo reutilizaria a resposta.

Essa escolha revela o que a resposta continha. O serviço de domínios não declarava necessariamente o endereço final da aplicação. Ele encontrava o DNS e o Application Interface Process associados ao domínio extremo. Reusar esse resultado acelerava o reencontro com o domínio. Não dizia se o serviço pretendido continuava disponível.

Para obter essa segunda informação, a origem precisava conversar novamente. O AIP de destino dizia quais combinações de transporte e aplicação podia oferecer. A memória do caminho e a capacidade atual eram estados diferentes.

A árvore distribuía jurisdição, não todas as decisões

A RFC 819 havia definido o domínio como uma região de autoridade para nomes e tradução, sem exigir correspondência com a topologia da rede. O filho tinha um nome simples único dentro do pai. A sequência de pais até a raiz produzia uma referência absoluta.

Uma convenção estrangeira podia continuar diferente por dentro e ingressar na árvore como domínio. O mecanismo comum não precisava reescrever cada ambiente. Precisava apenas preservar a interpretação no limite entre eles.

A RFC 830 associou logicamente um DNS a cada domínio. Redundância podia exigir vários servidores físicos, mas a função era uma só. Nos domínios com aplicações havia também um AIP, normalmente junto ao DNS. O servidor representava o domínio; o AIP representava a conversa de capacidades.

Essa separação impedia que uma delegação de nome se transformasse automaticamente em catálogo completo de aplicações. A autoridade do domínio organizava o caminho para perguntar. A resposta operacional vinha de outro componente.

A origem conservava o fio da resolução

O nome completo combinava uma parte local e domínios do mais específico ao mais geral. A resolução começava pelo rótulo mais à direita, que designava o domínio superior.

O DNS da origem conhecia os servidores superiores e atuava como centro de consulta. O servidor superior resolvia o filho imediato. O intermediário seguinte fazia o mesmo em sua própria jurisdição. Um intermediário podia devolver o próximo endereço ou encaminhar a pergunta uma vez, mas não assumia toda a função de centro.

O desenho mantinha pequeno o estado obrigatório. DNSs de origem guardavam as correspondências dos domínios superiores. Cada intermediário guardava apenas seus descendentes diretos. Os conjuntos eram separados e as atualizações locais.

Nem o formato interno precisava ser igual. A RFC 830 dispensava uma padronização de banco de dados. A interoperabilidade era medida pelas mensagens trocadas. Uma implementação podia mudar armazenamento sem obrigar seus vizinhos a mudar junto.

A negociação podia oferecer outra ferramenta

Depois da resolução, o AIP de origem enviava ao AIP de destino uma especificação de serviço. Ela podia incluir TCP ou UDP, um protocolo de aplicação e um tipo de função. A resposta afirmativa devolvia serviço e endereço; no exemplo TCP, endereço IP, número de protocolo e porta.

O caso de NIFTP explicava a ambição. O usuário queria transferência remota de arquivos por NIFTP. O destino oferecia apenas FTP para a mesma função. Se a origem também conhecesse FTP, os AIPs encontrariam uma alternativa compatível.

O sistema não confundia a falta de um protocolo com a inexistência do domínio. Também não obrigava uma substituição. A origem recebia a alternativa e mantinha a escolha local.

Uma resposta podia conter vários endereços para um destino multihomed. A RFC preferia apresentar as opções. Isso ainda não dizia que todas tinham o mesmo caminho, disponibilidade ou política. O resultado era uma lista de candidatos, não uma medição.

Uma resposta ao vivo também podia envelhecer

Negociar no momento da solicitação aproximava a resposta do estado corrente. Mas a conversa não carregava autenticação, autorização, reserva de capacidade ou confirmação da ação final. O destino podia anunciar FTP e negar o usuário. A conexão podia falhar depois de uma resposta compatível. O aplicativo podia iniciar e não concluir a transferência.

Havia, portanto, uma cadeia: delegação do nome, resolução do domínio, alcance do endpoint DNS/AIP, compatibilidade declarada, conexão, autorização e resultado. Cada elo tinha seu próprio proprietário e seu próprio relógio.

Transformar qualquer elo em prova dos demais seria um erro de autoridade. O administrador do domínio não era automaticamente o operador da aplicação. O servidor de nomes não era o concedente de acesso. O AIP não era o resultado do trabalho solicitado.

A conversa comum era mais rígida que a memória local

A SINS especificava uma estrutura única de comandos para aplicação/AIP, AIP/DNS e AIP/AIP. Itens tipados carregavam nome, serviço, endereço ou comentário. Uma resposta negativa podia devolver a parte não resolvida do nome e uma explicação.

O transporte era independente, embora a RFC normalmente desaconselhasse TCP para perguntas curtas por causa do custo de abrir e manter a conexão. UDP seria suficiente para a maioria das mensagens, e a solicitação reaparecia na resposta como apoio à confiabilidade.

Assim, o sistema tornava comum o diálogo necessário entre implementações, mas deixava formato de base e política de cache no domínio local. Era uma aplicação direta da especificação mínima: padronizar o encontro, não a oficina inteira.

O preço era operacional. Todos os domínios extremos precisariam sustentar AIPs capazes de falar uma linguagem comum de serviços. A negociação viva virava dependência adicional, justamente no caminho usado para descobrir como continuar.

A transição escolheu padronizar o dado

A RFC 881 propôs introduzir nomes de domínio em paralelo ao HOSTS.TXT, substituir depois a tabela antiga e, por fim, reduzir o arquivo central aos servidores dos domínios superiores. Um resolvedor poderia ocupar o lugar da função de biblioteca usada pelos programas, escondendo a mudança.

As RFCs 882 e 883 resolveram a generalidade por uma base distribuída. Um nome passou a apontar para um conjunto de informações. A consulta indicava o tipo de recurso e podia indicar uma classe. Servidores mantinham zonas autoritativas e referências; resolvedores seguiam as referências e guardavam respostas.

O cache deixou de ser apenas decisão vaga. Dados autoritativos e dados aprendidos tinham proveniências diferentes. Cópias eram atualizadas ou descartadas conforme temporizadores. A manutenção de zona, o formato dos recursos e as mensagens de consulta entraram no contrato comum.

A aplicação local não precisava negociar em rede com um AIP universal. Podia chamar o resolvedor por função ou serviço do sistema operacional. A rede padronizava o diálogo entre resolvedor e servidor, enquanto a aplicação mantinha sua própria negociação de uso.

O DNS ganhou escala e uma nova possibilidade de exagero

A RFC 1034 registrou a RFC 830 entre as propostas hierárquicas anteriores. Para o sistema que evoluiu ao DNS, apontou a base distribuída e os recursos generalizados das RFCs 882 e 883. Não foi uma simples troca de sigla: mudou o lugar da inteligência compartilhada.

O registro tipado podia ser replicado, consultado por muitas aplicações e auditado. Zonas delegadas preservavam administração distribuída. O resolvedor e o cache diminuíam o custo de cada pergunta.

Mas um registro publicado continuava sendo uma declaração. Uma resposta autoritativa dizia o que a zona mantinha. Uma resposta em cache dizia o que o resolvedor conservava dentro de sua regra temporal. Nenhuma provava que o processo estava ativo, que o cliente era compatível, que havia permissão ou que a transação terminaria.

A alternativa da RFC 830 torna essa lacuna visível. Localização e capacidade eram perguntas separadas. O DNS vencedor não eliminou a segunda pergunta; apenas deixou que aplicações e outros mecanismos a respondessem. A boa operação precisa guardar as duas respostas sem fingir que vieram da mesma autoridade.

Fontes