Summary

  • RFC 1480 described three registration situations under .US: a delegated branch, a direct A-record entry for an IP host, and a direct MX-based entry for a non-IP host. A visible name did not identify which authority or transport arrangement stood behind it.
  • Delegation moved responsibility for a branch to a designated manager and attached continuing duties: equal treatment, technical competence, accurate operation, redundant servers, community service and an agreed transfer process. A record placed in the parent database did none of that by itself.

The same suffix concealed different machinery

RFC 1480, published in June 1993, documented the United States country-code domain as it was being divided into geographic and functional branches. A school could appear under K12.<state>.US; a library under LIB.<state>.US; a business beneath a locality. From the right-hand end, the names shared one orderly grammar.

The grammar was useful because it made a growing namespace searchable and administratively divisible. It was also capable of hiding several different mechanisms behind the same dots. RFC 1480 therefore opened its registration section by naming two modes and then splitting one of them again.

A branch could be delegated to an organisation that operated name servers for it. Alternatively, information could be entered directly into the main .US database. A direct entry could belong to an IP host with an address, or to a non-IP host reached for electronic mail through a forwarder.

That produces three states, not one ladder of maturity. Direct registration was not an incomplete delegation. A mail-forwarded name was not a defective IP host. Each arrangement answered a different operational need and placed responsibility in a different location.

A direct entry left authority with the parent

For an IP host, the direct case was simple enough to describe: its address corresponded to an A record in the DNS database. The parent administrator accepted the application and placed the record in the main data it operated.

The name could resolve. That did not give the registrant control of a child zone. RFC 1034 described control as a separate administrative act: the appropriate parent had to agree to delegate a portion of the tree. Until that cut existed, the parent remained the source that published the record.

RFC 1035 kept the wire evidence equally narrow. An A record carries a 32-bit Internet address. An NS record names a host expected to be authoritative for a zone beginning at the owner name. The first can make a host address visible without proving the second. A positive A answer is not a certificate of zone administration.

The distinction mattered to operations. A correction to a direct entry went through the administrator maintaining the parent database. A delegated manager could make changes inside its own zone, subject to the duties of the delegation. Identical suffixes did not imply identical change authority.

A mail address could cross a boundary the host had not crossed

RFC 1480 also admitted non-IP hosts, particularly systems in the UUCP world. Some spoke directly to an Internet-connected forwarder; others reached it through one or more intermediate machines. Their users could still receive an Internet-style name.

The DNS record did not pretend the named machine had acquired an IP address. It pointed mail to an Internet host that was willing to act as the exchange. RFC 1035 defined an MX record in precisely that role, while RFC 974 explained how senders selected mail exchangers.

RFC 1480 said the uniform address avoided making correspondents aware of the underlying network boundaries. The boundary nevertheless remained active behind the interface. The non-IP host needed an administrative agreement with the forwarder and a technical procedure for relaying mail. The forwarder's routing table needed a rule for the host. If another UUCP system lay on the path, that system also needed to know how to relay the message.

A DNS lookup could therefore prove that a mail route was advertised. It could not prove that the forwarder had kept its consent, that each private relay rule was current, that a dial-up path succeeded or that the recipient received the message. The name unified the address syntax, not every event required for delivery.

Delegation came with a manager, not merely an NS label

RFC 1480's delegation examples included K12.TX.US, berkeley.ca.us and LIB.MN.US. The purpose was administrative scale: one registrar could not indefinitely assign every name ending in .US, so portions of the work and authority had to move outward.

But the document did not describe delegation as the insertion of two server names and nothing more. It required a designated manager capable of an equitable, honest and competent job. The authority was framed as trusteeship for the local domain and the global Internet community, with responsibility and service taking precedence over claims of ownership.

The manager had to apply the same rules to requests, avoid favoring customers of a related network provider and avoid tying entry to a particular mail system, protocol or product. Significantly interested parties should agree that the manager was appropriate. The higher-level administrator generally waited for contending parties to agree, while reserving intervention for substantial neglect.

The technical duties were observable. The manager had to respond in a timely way, keep accurate data and operate robustly. A primary and secondary server needed Internet connectivity and had to be checkable for status and database accuracy. Separate physical locations were recommended so a local disaster would not erase the whole service.

An NS response alone cannot show that this social and operational contract was satisfied. It names expected authority. Competence, equal treatment, server independence and community acceptance require other records.

A transfer changed the custodian of a duty

The document also separated delegation from its later transfer. Moving the designated-manager trusteeship required communications from both the old and new organisations, assuring the higher-level administrator that the change was mutually agreed and that the successor understood the responsibilities. Input from affected parties was useful as well.

This was not a property sale automatically perfected by a private transaction. Nor was it a server replacement that silently changed the responsible institution. The higher-level record, the old manager's assent, the new manager's acceptance, interested-party concerns and actual server operation belonged to different parts of the event.

RFC 1591 later stated the general principle more broadly: country-domain administrators performed a public service, and a designated manager was trustee for both the nation and the global Internet community. That later text helps identify the institutional logic. It does not prove that every branch imagined in RFC 1480 was delegated, or that every designated manager met the standard.

The hierarchy was a 1993 operating proposal

RFC 1480 replaced RFC 1386, which had described the same domain only six months earlier. The quick revision is evidence of a policy document being maintained during growth. It is not a deployment census.

The RFC prioritized manageable subdivision over guaranteeing everyone the shortest or most obvious name. Political geography, school classes, libraries and general entities became branches because grouping work reduced the burden on one database administrator. The design recorded a view of how naming could scale at that moment.

The RFC Editor information record still classifies the memo as Informational. Its security section said security issues were not discussed. Redundant servers and trustee duties improved operational discipline, but they were not authentication, authorization or a security proof.

A much later verified erratum adds a missing alternation mark in Appendix I's BNF. The correction repairs the written grammar. It does not retroactively certify any registration, delegation or mail path.

A useful audit starts by asking what kind of fact the name is

The durable lesson is not that hierarchical names were deceptive. Their abstraction was the achievement. One stable syntax could make very different networks and administrative arrangements usable together.

The cost of that usability appears when an observer treats a name as a complete statement about the system behind it. A name may be present because a parent administrator entered an A record. It may be present because a parent entered an MX record whose exchange leads across another network. It may be present inside a delegated zone operated by another manager. The dots do not state which case applies.

An evidence ledger should therefore record the owner name, resource-record type, zone that published it, delegation cut, designated manager, server set, observation time and intended service separately. For mail, it also needs forwarder consent, private relay state, attempts and receipt. For governance, it needs the manager-selection and transfer records. Only then can a visible name be connected to the narrower conclusion someone wants to draw.

Sources