Resumo

  • A RFC 1123 tornou válido iniciar um nome de host com dígito; a RFC 1178 ainda desaconselhou a escolha porque programas instalados podiam confundir uma cadeia numérica com um endereço.
  • A RFC 1178 tratou nomes como etiquetas arbitrárias: pessoa, projeto, lugar e função mudavam, enquanto referências técnicas e humanas ficavam presas ao rótulo.
  • Um label permitido não demonstrava como a aplicação o classificou, qual domínio completou o nome curto, que registro foi consultado, qual sistema respondeu ou se a troca de nome alcançou todas as dependências.

A gramática aceitava; o ambiente ainda precisava interpretar

A RFC 1178 saiu em agosto de 1990 como FYI 5. Era a republicação de um ensaio e não especificava padrão. O registro do RFC Editor e a página no IETF Datatracker comprovam publicação e status, não a ocorrência independente das histórias usadas como exemplos.

A RFC 1123 tinha objetivo normativo. Ela alterou a regra anterior para permitir letra ou dígito na primeira posição e exigiu que o software de host suportasse a forma liberalizada. O registro oficial mantém esse papel no Host Requirements.

Mesmo assim, a RFC 1178 recomendou não começar com dígito. Alguns programas aceitavam tanto nome quanto endereço numérico na mesma interface e não os distinguiam corretamente. Nomes formados apenas por caracteres hexadecimais também podiam ganhar leitura numérica. Uma regra descrevia o que software conforme deveria aceitar; a outra reduzia ambiguidade em instalações com versões e hábitos diferentes.

Logo, “válido” não quer dizer “o DNS resolveu”. O programa podia classificar a entrada antes da consulta. O evento observável era a decisão daquele parser naquela versão.

O rótulo não acompanhava o cargo da máquina

Para a RFC 1178, o nome não era currículo do computador. Uma máquina batizada com o projeto inicial poderia ganhar companheiras, dividir o trabalho e depois ser deslocada. O rótulo continuava igual quando a função deixava de ser verdade. Acrescentar 2 ou 3 apenas transformava a semântica em série numérica.

Usar o nome do dono confundia conversa e custódia. Quando a pessoa recebia outro equipamento, a antiga etiqueta poderia permanecer na máquina errada. Um programa que procurava um periférico ou banco no host anterior não encontraria esse recurso no “novo” referente apenas porque o nome foi reaproveitado.

O hostname pode provar que alguém configurou ou publicou uma etiqueta. Não prova o uso presente, o responsável, o hardware, o serviço, a posse nem continuidade temporal. Cada propriedade precisa de fonte própria.

A entrada passava por uma decisão antes do resolvedor

A RFC 1123 recomendava aceitar nome de domínio de host ou IP decimal pontuado. A aplicação deveria testar sintaticamente a forma numérica antes de procurar no DNS. Esse passo criava uma bifurcação anterior à resolução.

A RFC 952 tinha exigido letra inicial na tabela DoD. Seu registro aponta a atualização posterior. O contrato de software mudou de modo explícito; programas antigos e referências locais mudaram em ritmos próprios.

Uma análise precisa guardar a cadeia original, aplicativo e versão, resultado da classificação, consulta produzida, tipo de RR, configuração do resolvedor, cache, resposta, endereço escolhido e conexão. A conformidade da cadeia cobre só a primeira pergunta.

O nome curto dependia do lugar de onde era dito

A RFC 1034 separa nome absoluto de relativo. O relativo recebe uma origem ou lista de pesquisa local, e sua interpretação na interface varia entre implementações. O registro do RFC Editor identifica a especificação, não a configuração usada por um usuário em certo momento.

RFC 1178 usa o correio para mostrar o efeito. Uma palavra depois de @ poderia ganhar o domínio local ou ser tratada como nome em outro domínio. O texto visível era o mesmo; o destino efetivo dependia do programa e do local.

Também é lícito repetir o mesmo label sob pais diferentes. DNS exige unicidade entre irmãos, não na árvore inteira. Assim, nome curto não é identidade global. O FQDN identifica um nó de informações tipadas; ainda não comprova máquina, proprietário, operador, serviço nem disponibilidade.

Nomes percorriam pessoas, telas e papel

Os conselhos sobre tamanho, ortografia, caixa e temas não são novos limites de protocolo. Eles descrevem o custo de ditar um nome, encontrá-lo num alarme, lembrá-lo sob pressão e explicá-lo a outra equipe. Uma grafia “criativa” pode ser aceita e continuar ruim para resposta a falhas. Maiúsculas não sustentam identidade distinta. Tema finito acaba antes da expansão do parque.

Essa ergonomia tinha efeito técnico porque o nome cruzava conversa, ticket, shell, email, log, etiqueta e documentação. Cada passagem era uma chance de divergência.

Renomear significava descobrir quem ainda lembrava o nome antigo

RFC 1178 prevê referências escondidas em software, correspondentes externos e rótulos de mídia de backup. A zona autoritativa não possui essas cópias e não as reescreve quando muda.

A RFC 952 já desaconselhava apelidos comuns, mas permitia manter nomes antigo e novo durante uma transição. O alias ajudava na continuidade; não era um certificado de conclusão.

A evidência completa exige autoridade da decisão, publicação, período de compatibilidade, expiração de cache, migração de programas, certificados, controles, monitoramento e documentação, queda observada do uso antigo, responsável pelas exceções e condição de retirada. A RFC 1178 não prescreveu esse processo; ela revelou sua necessidade.

Fontes