Resumo

  • A RFC 1101 propôs relacionar nomes de redes, números e sub-redes aninhadas com PTRs em nomes IN-ADDR.ARPA de host-zero; quando havia outro nível, um A carregava a máscara usada na continuação da busca.
  • O texto separou o nome escolhido localmente do registro de números atribuídos pelo NIC. Uma resposta DNS podia descrever uma associação limitada; não atribuía o número, não acompanhava automaticamente uma renomeação e não provava controle atual nem resultado de serviço.

A lacuna que o DNS não tinha herdado

O ponto de partida de P. Mockapetris na RFC 1101 é específico. O DNS era extensível e já absorvera muitas funções de HOSTS.TXT, mas a conversão entre nome de rede e número de rede ainda faltava. O memorando de abril de 1989 apresentou uma forma concreta de suprir essa necessidade e, em separado, ideias experimentais para índices mais gerais de identificadores e números. A primeira parte era um Proposed Standard; a família de Yellow Pages, uma experiência. Não havia a promessa de que cada número passaria a ter um sentido humano universal. Havia uma maneira de um administrador publicar, dentro de um escopo definido, uma ligação entre um rótulo escolhido e um número.

Um visor de diagnóstico poderia trocar uma sequência opaca por um nome reconhecível. Isso não fazia do rótulo uma concessão do número, nem prova de quem operava a rede, de qual rota seria tomada ou de qual serviço responderia. O mapa era útil porque não fingia responder a essas perguntas.

O nome ficava onde alguém podia mantê-lo

O problema da sintaxe era também um problema de governança. O espaço anterior de nomes de rede era plano, e por isso combinava com uma regulação central dos nomes, semelhante à dos números. A RFC registra que a maioria preferia controle local dos nomes. Ela assume a sintaxe ampliada dos nomes de host e permite ao administrador criar um nome de rede em qualquer domínio sob seu controle. O preço era que esses nomes se tornariam tão complexos quanto os de host. O ganho era deixar o cuidado do rótulo perto de quem conhecia seu contexto. ARPANET.ARPA. aparece no texto como exemplo histórico de uma escolha de nome, e não como definição eterna de um recurso ou outorga do número associado.

No sentido inverso, começar por um endereço IP exigia outro ponto de entrada. O nome local não dizia qual domínio consultar. A RFC reutilizou a árvore IN-ADDR.ARPA, já delegada de acordo com endereços, para que essa mesma distribuição de responsabilidade pudesse carregar a descrição inversa. Não era necessário criar outra hierarquia mundial para uma afirmação tão restrita.

Host-zero era uma ficha, não uma máquina

A forma proposta era <número-host-zero-invertido>.IN-ADDR.ARPA. PTR <nome-da-rede>. O nome da rede continha o PTR de volta. Caso a rede tivesse mais um nível de sub-rede, um A no mesmo ponto continha a máscara. 0.0.0.10.IN-ADDR.ARPA. e 0.0.2.128.IN-ADDR.ARPA. são os exemplos históricos usados para mostrar a forma.

O host-zero não se torna um host acessível. Ele é uma posição reconhecível na árvore DNS onde se pode anexar uma descrição e testar se ela foi publicada. O PTR junta uma entrada voltada para o número a um nome mantido localmente. Não configura roteador, não concede direito e não converte o nome em identidade legal ou operacional do número.

Também o A precisa ser lido no seu papel particular. Na proposta ele transportava uma máscara quando havia uma subdivisão seguinte. No procedimento classful descrito no RFC, aplica-se a máscara ao IP, invertem-se os octetos e consulta-se o PTR. Se a resposta inclui o A-máscara, aplica-se essa máscara ao IP original e repete-se a busca; sem A, o aninhamento acaba. Trata-se de uma receita histórica de leitura, não de evidência de topologia, rota ou alcance atuais.

Três direções de consulta não viram um único fato

A RFC também permitia que um nome de organização apontasse por PTR para uma ou mais entradas de host-zero. Assim, havia nome de rede para entrada numérica, entrada numérica para nome escolhido e nome de organização para registros de redes. As três setas são úteis exatamente por serem respostas diferentes. Uma associação publicada num domínio é um fato sobre aquela publicação. Um nome de rede é um fato sobre uma escolha de nome. Uma resposta é um fato sobre uma consulta, um algoritmo e um instante.

Nenhuma delas, sozinha ou somada sem evidência adicional, estabelece propriedade atual, relação societária, custódia física, autorização, rota BGP, recebimento de pacote ou sucesso de aplicação. O texto observa a tensão real: tabelas centrais podiam ser mais consistentes; dados distribuídos podiam ser mais oportunos e mantíveis. Um formato de registro não elimina o trabalho de manter fatos corretos; apenas deixa visíveis seu autor, escopo e limite.

A atribuição não decidia o nome posterior

A seção YP formula a fronteira de modo direto. A RFC imaginava árvores de domínio para pares como mnemônico de porta e número de porta, identificador de sistema autônomo e número, ou nome de rede atribuída e endereço IP. A chave precisava declarar o tipo de origem e o tipo de destino: um número sem contexto ainda não tinha o significado da correspondência.

Para redes atribuídas, o NIC poderia manter domínios YP que documentassem as próprias decisões de atribuição. Mas a RFC diz que eles mapeariam nomes e números atribuídos, não os nomes que as organizações escolhessem depois. Tampouco acompanhariam automaticamente a renomeação pelos novos donos. Histórico de atribuição e nome local foram desenhados como fatos distintos.

Uma lista central pode ser forte prova de uma decisão central. Uma zona local pode ser forte prova de um rótulo que publicou. Nenhuma é atalho para concluir sobre operador presente, serviço disponível, política de rota ou resultado de transação. O registro descreve uma realidade dentro de seu limite; não cria o restante da realidade que se deseja inferir.

Ler o documento na escala da sua época

A RFC 1101 é evidência de uma proposta de 1989. Seu procedimento classful, seus domínios YP e seus exemplos não descrevem por si o DNS contemporâneo. Ainda assim, deixa uma disciplina útil: tornar a correspondência inspecionável, declarar sentido, origem e alcance, e não exigir que o registro carregue decisões que nunca foram registradas. Nome publicado, número atribuído, rota observada e resultado demonstrado continuam sendo proposições diferentes.

Fontes e limite de evidência

Esta análise usa RFC 1101, RFC 1034 e RFC 1035. Elas sustentam a proposta de 1989 e suas formas de registro, não dados DNS atuais, controle, identidade, propriedade, rota, alcançabilidade, autoridade ou desempenho de serviço.