Summary

  • RFC 1101 proposed DNS mappings for network names, numbers and nested subnets. It placed PTR records at host-zero IN-ADDR.ARPA names and used an A record as a mask carrier when a further subnet level followed.
  • The proposal separated locally selected names from centrally assigned-number records. A DNS response could describe an association in its scope; it did not allocate the number, automatically track a later renaming, prove present control, or establish a network outcome.

The capability DNS had not inherited

P. Mockapetris’s April 1989 memo, DNS Encoding of Network Names and Other Types, begins with a narrow gap. DNS was extensible and had already taken over many functions of HOSTS.TXT, but mapping between network names and numbers remained outside it. RFC 1101 proposed a specific method for that mapping and, separately, experimental ideas for more general identifier-to-number indexes.

The status distinction is revealing. The network-name method was a proposed standard; the broad “Yellow Pages” ideas were experimental. The RFC did not say that every number could acquire one universal human meaning. It supplied a way for an administrator to publish a selected label beside a number in a defined part of DNS. A diagnostic display could become more intelligible without claiming that the display had settled ownership, control, routing or service.

The right to choose a name stayed near the name

Network names made an administrative question visible. The older syntax was a flat space, compatible with a central allocator regulating names as it regulated numbers. RFC 1101 reports that the majority opinion instead favoured local control. It assumed expanded host-name syntax and allowed an administrator to create network names in domains under that administrator’s control.

The price was complexity: network names would become as complicated as host names. The gain was that a label could be maintained where its context was known. Historical examples such as ARPANET.ARPA. are therefore examples of a naming choice in the RFC, not permanent definitions of a resource and not grants of the number to which a record happened to point.

The reverse direction required another place. A locally chosen label could not, by itself, tell a reader where to start from an IP address. RFC 1101 reused the existing IN-ADDR.ARPA tree so that the already delegated address-oriented space could hold the inverse description. It did not need to invent a second global namespace merely to publish this bounded association.

Host zero was a filing location, not a host

The proposal placed information at the name corresponding to a host-zero address. Its generic PTR form was:

<reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>

The network name held a reciprocal PTR. If the network had a further level of subnetting, an A record at the host-zero entry held the subnet mask. The RFC uses 0.0.0.10.IN-ADDR.ARPA. and 0.0.2.128.IN-ADDR.ARPA. as illustrations of this shape. Those strings are historical examples, not current observations.

Host zero did not become a usable endpoint. The convention made a recognisable place in the DNS tree where an organisation could attach descriptive data and a reader could test whether the data existed. A PTR joined a number-shaped entry to a locally maintained name. It did not program a router, grant a right, or turn that name into the legal or operational identity of the number.

The A record is just as bounded. Here it was a mask carrier, not ordinary proof that a hostname had an address. Under the class-A/B/C procedure described in the RFC, a reader masked an IP address, reversed the octets, queried for the PTR, and used the A-record mask to repeat the process for the next subnet level. When no A record appeared, the nesting stopped. That is a historical lookup algorithm, not a certificate of current topology or reachability.

Three useful directions were still three different statements

RFC 1101 also allowed an organisation name to hold PTR records to one or more host-zero network entries. A name could lead to a number-shaped entry; that entry could lead to a chosen name; an organisation label could lead to several network records. The triangle is helpful precisely because its arrows are separate.

A published organisation-to-record association is evidence about that publication. A network label is evidence about a naming choice. A response is evidence about an algorithm and a moment. None, alone or piled together without new evidence, proves current ownership, a corporate relationship, physical custody, authorization, a BGP route, packet receipt or application success. RFC 1101 makes the record more useful by keeping those larger assertions out of it.

The memo also recognised a practical tension. Centrally maintained tables could be more consistent; distributed data could be more timely and maintainable. A record format does not abolish the work of keeping facts correct. It gives the work a scope and lets readers see where an assertion originated.

An allocated number did not compel a later local name

The experimental YP section states the limit most directly. RFC 1101 imagined DNS-domain indexes for pairs such as port mnemonic and port number, autonomous system identifier and number, or assigned network name and IP address. A key had to say both its “from” and “to” data types: a number without that context was not enough.

For assigned networks, the NIC could maintain paired YP domains documenting its allocation decisions. But the RFC says those records would map assigned names and numbers, not the names organisations later selected themselves. They would not automatically track renaming by new owners. Allocation history and local naming were deliberately distinct facts.

A central list can be strong evidence of its allocator’s decision. A local zone can be strong evidence of a locally maintained label. Neither one becomes a shortcut to a present operator, a service, a route or a transaction result. The record describes reality at its own boundary; it does not create all the reality a reader may be tempted to attach to it.

Read the RFC at its historical scale

RFC 1101 is evidence about a 1989 proposal. Its classful procedure, YP domains and illustrative organisations are not a description of current DNS deployment. Its discipline remains sound: make a mapping inspectable, state its direction and scope, and do not ask it to carry decisions the record never contained.

The Internet became easier to investigate when it learned to preserve partial facts. It remains investigable when readers preserve their limits: a record may describe a label and a number; allocation, present control, live routing and outcome still require their own evidence.

Sources and evidence boundary

This historical analysis uses RFC 1101, RFC 1034 and RFC 1035. They support the 1989 proposal, its record forms and its allocation/local-name distinction. They do not establish current DNS data, present control, ownership, identity, routing, reachability, authority or service performance.