Summary

  • RFC 1123 made a leading digit legal in an Internet hostname, while RFC 1178 still advised against the choice because deployed programs might confuse a numerical-looking name with an address.
  • RFC 1178 treated names as arbitrary tags: a person's name, project role, spelling or geographic suggestion could become false or ambiguous as machines and organisations changed.
  • A permitted label did not prove how an application parsed it, which local domain completed it, what record a resolver returned, which machine or service answered, or whether a rename reached every dependency.

A standard and a field guide answered different questions

RFC 1178 is unusually modest about its authority. Published in August 1990 as FYI 5, it republishes an earlier essay and says that it is informational rather than a standard. Its RFC Editor record and IETF Datatracker entry fix that publication identity. The text does not define how DNS resolves a name. It asks how to choose a name that humans can say, remember and operate.

The contrast with RFC 1123 is therefore useful. Section 2.1 changed the legal Internet host-name syntax inherited from RFC 952: the first character could be a letter or a digit, and host software had to support that wider rule. The RFC Editor record preserves the document as part of the Host Requirements standard.

RFC 1178 nevertheless advised administrators not to begin a computer name with a digit. Some programs accepted either a host name or a numerical Internet address and did not reliably distinguish the two. Strings composed only of hexadecimal characters created another ambiguity. The syntax rule described the implementation target. The naming advice accounted for software that had not reached it, user interfaces that classified input before lookup and humans who had to diagnose the result.

That is not a defect in the idea of standards. It is the normal boundary between a rule and an installed population. The rule can establish what conforming software must accept. It cannot, by publication alone, inventory every parser already deployed or choose the least ambiguous input for a mixed estate.

A hostname was an arbitrary tag, not a résumé

RFC 1178's central insight is easy to miss beneath its jokes: a name should not be expected to describe a computer. The essay calls names arbitrary tags. It warns against binding a machine to the project it first served. A shop-floor computer may be joined by a second machine, divided into more specific tasks and later moved to unrelated work. The label that once sounded descriptive then becomes false, or forces a sequence such as shop2 that is merely numbering in disguise.

The same coupling problem appears when a desktop inherits a person's name. Conversation can no longer distinguish person from machine without extra context. When the person or hardware changes, the name may follow the wrong referent. A program written to find a special peripheral or database on the old machine can silently retain that assumption and fail against the replacement.

The evidence consequence is strict. A hostname can be evidence that a label was configured or published. It is not evidence of the machine's current purpose, its custodian, the presence of a peripheral, the service version, the identity of a person or the continuity of any of those facts over time. Those claims need their own records.

Legal input could be classified before DNS saw it

RFC 1123 did more than permit a leading digit. It recommended that a user be able to enter either a host domain name or a dotted-decimal IP address, with the software checking the dotted-decimal form syntactically before looking in DNS. That sequence created an application boundary ahead of name resolution.

If the program classified the string as an address, DNS might never receive the intended name query. If another program classified it as a name, the same characters could follow a different path. RFC 1178's caution targeted that mixed interpretation, not the grammar in isolation.

The older RFC 952 had required an alphabetic first character in the DoD host table. Its information record now notes the RFC 1123 update. That history shows a compatibility transition: permission widened before every operational habit and program necessarily converged.

A correct investigation must therefore record at least the raw input, the application and version that received it, the branch that classified it, the resolver configuration if a query occurred, the record type requested, the answer and cache state, and the later connection. “The name is legal” answers none of those later questions.

A short name borrowed meaning from its surroundings

RFC 1034 explains why the same visible label can refer to different nodes. A complete domain name ends at the root. A relative name is completed by local software using an origin or a search list, and user-interface interpretation can vary by implementation. Its RFC Editor record identifies the DNS concepts document; it does not choose a site's local search path.

RFC 1178 turns that architecture into an operator's example. A single-token mail destination entered at one site could be completed inside the local domain or treated as a name in another domain, depending on the mailer. Both the text and the local environment contributed to the effective destination.

This also explains why ordinary host labels could be reused in different domains. RFC 1034 allows the same label beneath different parent nodes; only siblings must be unique. The bare label is not a global identity. It becomes specific only with its parent path and, for an actual query, a requested record type.

A domain node can also hold different resource records or none. Even an exact fully qualified name therefore does not collapse name, address, machine and service into one fact. DNS can answer a typed question about published data. It cannot certify who owns the machine, who operates it, whether the returned endpoint is reachable or what an application will do there.

Good naming reduced ambiguity rather than creating truth

Several RFC 1178 rules are deliberately human. Long names were annoying even though protocol limits were much larger. Unusual spellings impeded speech and recall. Case could not be trusted as a distinguishing feature. Embarrassing labels could distract people encountering a system outside the room where it was named. An open-ended theme scaled better than a finite set that would run out after the next equipment order.

These are not alternate syntax standards. They are interface design observations. A label passes through conversations, tickets, handwritten notes, commands, mail addresses, logs and alarms. A spelling that is technically accepted may still increase error at one of those transitions.

The distinction matters because “valid” is often used as if it were a complete quality judgment. Here it means only that a string satisfies an applicable grammar. Operational quality asks whether the string is unambiguous in speech, robust across parsers, qualified in the right namespace, resistant to role drift and recoverable during a fault. The tests are related, but they are not interchangeable.

Renaming exposed the hidden inventory

The most durable warning in RFC 1178 concerns a future rename. By then, obscure software may refer to the old name, remote correspondents may still use it and backup labels may preserve a different mapping between name and machine. Changing one authoritative record does not update those copies.

RFC 952 had already acknowledged transition cost. It generally discouraged host nicknames but allowed old and new names to coexist for a suitable period after a change. That temporary alias was a migration aid, not evidence that migration had completed.

The important event is not “new name published.” It is the sequence: authority approves the change; the new record appears; intended aliases work; caches age; programs, certificates, access lists, monitoring rules and human procedures move; old-name use declines; an owner accepts the residual exceptions; and only then is the old binding retired. RFC 1178 did not specify this modern checklist. It documented why such a checklist becomes necessary.

The evidence chain starts before the lookup

For a hostname entered into a real system, the first record should be the literal string and the applicable syntax. Next comes parser classification: name or numerical address. If it is a relative name, record the origin and search list that completed it. Then record the resolver, time, cache, query type and response.

Only after those steps can evidence move to the endpoint: address selection, connection, service negotiation, machine or service identity, authority, application admission and outcome. A memorable label is useful precisely because people can carry it through that chain. It does not replace the chain.

Sources