Summary

  • RFC 830 proposed two stages: resolve a hierarchical domain to its endpoint name-service address, then let Application Interface Processes negotiate transport and application compatibility.
  • Its live negotiation could return an alternative service and several addresses, while its domain databases stayed small, disjoint and locally formatted; caching was useful but optional.
  • The DNS design in RFCs 882 and 883 chose a different common boundary: typed resource data, zones, authority, referrals, caches and refresh rules became part of a standard distributed database. A record still did not prove a running service.

The request that changed protocol without changing its purpose

RFC 830's most revealing example was not a successful lookup. A source wanted remote file transfer by NIFTP at TSC. The destination did not offer NIFTP, but it did offer FTP for the same service type. If the source also supported FTP, its local process could accept the alternative and continue.

That result required two different answers. The first answer located the destination domain's name-service endpoint. The second asked what transport and application service that endpoint could provide. Treating them as one lookup would have hidden the design's central claim: knowing where an administrative domain could be contacted was not the same as knowing which application inside it could serve the request.

The distinction survives in more modern systems even when the components have different names. A directory can publish an address. A cache can repeat it. Neither event shows that the process is listening, that the client and server share a protocol, that the caller is authorised or that the transaction will finish. RFC 830 made that evidentiary gap visible by placing a live exchange inside name service itself.

A domain was represented by a service endpoint, not by every application

RFC 819 had described the domain hierarchy as a distribution of naming jurisdiction. A domain could reflect administration without matching network topology. Each parent needed unique names for its children; a complete name gained meaning from its path to the common root. Internal naming environments could remain different and still join the hierarchy.

RFC 830 built on that model. Its System for Internet Name Service, or SINS, had an application-independent domain name service and a separate application interface. Each domain was logically associated with a domain name server. Endpoint domains also had an Application Interface Process, normally co-located with that server.

The domain layer did less than a reader accustomed to later DNS might expect. Its successful result was the address of the DNS/AIP associated with the destination endpoint domain. That was a rendezvous with the domain's service boundary. It was not necessarily the address, protocol or port of the requested application.

More addressing could be needed when an application address could not be derived from the domain endpoint. A permanent convention such as a well-known TCP port might supply that binding. RFC 830 nevertheless wanted to support dynamic variation. The AIPs could negotiate availability and compatibility rather than make every application detail permanent in the naming database.

Resolution began at the right edge

The proposed full name had a local part followed by increasingly general domains. Domain resolution removed the local part and processed the domain labels from the right. The right-most label identified a top-level domain.

The source endpoint DNS knew how to locate top-level DNSs. It acted as the polling hub, contacted the server for the right-most label and then pursued the next label. An intermediate DNS knew the addresses of its immediate subdomains. It could return the next server's address or forward the request once. To keep the protocol simpler, an intermediate server was not allowed to become another continuing hub.

This arrangement distributed authority without copying the whole name space. A top-level map could stay small at endpoint servers. Each intermediate server needed only its immediate children. Those database contents were disjoint, so changes could remain local to the domain that owned them.

RFC 830 went further: it saw no need to standardise the internal database format. Interoperation depended on the request and response commands at the boundary, not on forcing every administrator to store records in the same local representation. The public contract was the exchange; the implementation behind it could vary.

The second phase asked what the domain could do

After domain resolution, the source AIP could contact the destination AIP. The request described a transport, an application protocol and a service type. An affirmative response returned the service and an address. In the TCP examples, that address included an IP address, protocol number and port.

The destination could return several addresses. RFC 830 preferred such a result because it gave the source a choice, including for a multihomed endpoint. It did not say that every address would have equal reachability or fate. The list exposed alternatives; selection and later evidence remained with the source.

The destination could also answer that the requested service was incompatible and supply an available alternative. That is how the NIFTP request could become FTP without changing the user's purpose of remote file transfer. If no corresponding service existed, the returned service could be empty.

The negotiation proved only what the participating endpoint process reported at that moment. It did not authenticate the human, allocate capacity, authorise the caller or guarantee the following connection. A later transport failure would not make the domain resolution false. An application refusal would not prove that the server address was wrong. The chain had separate failure and authority boundaries.

The common protocol was larger than the common database

SINS used one command structure across application/AIP, AIP/DNS and AIP/AIP pairs. Typed items could carry a name, address, service or comment. A negative answer could return the unresolved portion of a name and an explanation. The proposal was transport independent, although it usually preferred UDP to avoid TCP connection overhead for short exchanges.

This is an unusual allocation of complexity. Local domain databases could use different formats, and caching was left to implementers. Yet the live conversations among components had a detailed standard grammar. The design kept persistent shared state thin while standardising the moment when independent processes had to understand each other.

Caching exposed the tension. RFC 830 recognised that resolving every transaction from scratch would be inefficient. It expected implementers to cache prior results, but did not make caching a standard SINS feature. That freedom reduced the common specification. It also left freshness, expiry and cache behaviour outside the interoperable evidence contract.

The transition chose a database boundary

RFC 881 described the operational path away from HOSTS.TXT. Domain-style names could first appear in a parallel table. Later, a resolver could replace the host-table library call so applications did not have to know whether an address came from a file or a server. Eventually the central table would shrink to the entries needed to find top-level domain servers.

RFCs 882 and 883 supplied a different design centre from RFC 830. A domain name identified a set of information. The query carried both the name and the type of resource wanted. Data could also be separated by protocol class. Name servers held authoritative zones and referrals. Resolvers pursued queries and cached the answers. Cached data was distinguished from authoritative data and discarded through timeouts.

The local application interface no longer needed a universal network negotiation protocol. A program called a resolver through a procedure or operating-system interface. The interoperable network contract was between resolvers and name servers and among name servers. The database itself gained standard resource formats, query methods, zone maintenance and refresh rules.

RFC 1034 later placed RFC 830 among several earlier naming proposals. It separately identified the distributed database and generalised resources of RFCs 882 and 883 as the design that evolved into the DNS it specified with RFC 1035. The historical record therefore supports a fork, not a renaming: the hierarchy survived, while the boundary around shared intelligence changed.

A typed record was not a live promise

The database design won powerful advantages. Typed records could serve many applications without teaching a universal AIP every application protocol. Declarative data could be copied, cached, audited and refreshed. Delegated zones kept administration distributed while a stable wire format allowed independent implementations to interoperate.

Its cost was not that DNS became untrustworthy. The cost was that a record and an operating capability were different evidence. An authoritative record proves what the relevant zone published. A cached record proves what a resolver retained within its freshness rules. Neither alone proves that a process is listening, that a client can use it, or that policy permits the transaction.

RFC 830 put the live question inside name service and accepted extra dependency, latency and shared service vocabulary. DNS put more declarative facts inside a standard database and left live capability to applications. Neither boundary can carry every decision. The durable lesson is to say which layer answered which question.

Sources