RFC 756

NIC name server - a datagram-based information utility

📅 published July 1979, from ietf

RFC 756 🎀 July 1979

The NIC Name Server--A Datagram Based Information Utility ✨

Written by John R. Pickens, Elizabeth J. Feinler, and James E. Mathis 💖, all from SRI International, Telecommunications Sciences Center, 333 Ravenswood, Menlo Park, California 94025 🌸. It's giving academic-conference energy: it was also published in the Proceedings of the Fourth Berkeley Conference on Distributed Data Management and Computer Networks 📚. This header doesn't list anything it obsoletes or updates, so there's no drama there 🙈.

Abstract 🦋

okay so this paper is about a brand new way to spread out and refresh host name/address info across big computer networks 🌐. The trick is that it uses datagrams to give you a simple transaction-based query/response service ✨. The NIC (Arpanet Network Information Center) is running a provisional version of it, and it's being used by mobile packet radio terminals AND several Arpanet DEC-10 hosts 💅. The paper also suggests upgrades so queries can use more flexible formats and can ask for service addresses too 🧚. A few architecture ideas are proposed for growing this into a distributed internet environment 🌈. And honestly? This technique could also support other distributed stuff, like user identification and group distribution for computer-based mail 💌. main character energy, bestie 👑.

1. Introduction 💜

In large computer networks, like the Arpanet [1], the network-wide standard host-addressing info has to be maintained and distributed 🌸. To cover that need, the Arpanet Network Information Center (NIC) at SRI International has been maintaining, administering, and distributing the host addressing database to Arpanet hosts since 1972 [2] 📖.

The most common way to keep every host's copy up to date is to bulk-transfer the entire database to each host individually 📦. This works for most host addressing needs on the Arpanet today ✅. BUT some hosts don't keep a complete or current copy, because they have limited memory and only process updates every so often 🥺. On top of that, as the Arpanet expands into the internet environment [3, 4], people really need new techniques to boost how name/address info gets distributed 🔥.

One method being looked into right now is dynamic distribution of host-address info through a transaction-based, inquiry-response process called the Name Server [5, 6] 🦋. To support that research, the NIC built a provisional Name Server that's compatible with a level of service specified in the Defense Advanced Research Projects Agency (DARPA) Internet experiment [5] 🎀. This paper describes the basic Name Server, then proposes a bunch of extra functions a service like this might be expected to support 💅.

The discussion is laid out like this: Section 1 describes the NIC Name Server and how it's derived from the NIC database service 📋. Section 2 covers extensions to the name server that allow a richer syntax and queries for service addresses 🧩. Section 3 talks about architectural issues and shares some early thoughts on how to move from the current centralized, hierarchic service to a distributed Name Server service 🌈.

2. THE NIC NAME SERVER 🖥️

A Name Server service has been installed on SRI-KA, an Arpanet DEC-10 ✨. You access it with inquiry-response via the Internet Name Server protocol [5], which in turn uses the DARPA Internet Protocol, IP4 [7] 💖.

To show it off, there's a simple interactive facility that formats user input into name server requests 💅. For example, a query like !ARPANET!FOO-TENEX returns an address such as "10 2 0 9" (NET=10, HOST=2, LOGICALHOST=0, IMP=9; for details on host address formats see [8]) 🍓.

User access to the name server has been built for several Arpanet DEC-10 TENEX hosts and Packet Radio Network LSI-11 Terminal Interface Unit (TIU) hosts [9, 10] 🌸. The TENEX program is mostly a demo vehicle, but the LSI-11 program is a huge upgrade for the TIU's host table 🙌. Here's the typical scenario: when the packet radio TIU starts up or initializes, it only has a minimal host table with the addresses of a few candidate name servers 🥹. The user runs a simple manual query process against the name server, then uses the address they get back to open a TELNET connection to the host they want 📞.

The info behind the name server comes from the NIC's Arpanet host address database 🗂️. An optimized version of that database gets handed to the name server as an input file when the program starts 🚀.

3. NAME SERVER ISSUES 🔍

The basic name server offers a simple address-binding service [5] 🔗. When a datagram query comes in [7, 11], the name server returns either an address, a list of similar names if it can't find a unique match, or an error indication 💌. There are a bunch of other useful functions we could imagine for the name server, like service queries and broader access to host-related info ✨.

3.1. Similar Names 🤔

One issue that still needs sorting is what the "similar names" response actually means 😭. A standard definition should be written down instead of being left to implementors' whims 📝.

If the "similar names" response is mainly there to give helpful info to a human-interface process, then it might make sense to model the name server's behavior on other processes that show host name info on demand 💅. One example is a common implementation of virtual terminal access on the Arpanet, User TELNET [12], which does three different things 🌈:

  1. When host name input ends (e.g. <CR>), the user only gets an audible alarm if the name used isn't unique. If the name is unique, it gets completed and the requested operation starts 🔔.
  2. In response to <ESC>, the name gets completed if it's unique, or the user gets an audible alarm if it isn't 😤.
  3. Only when ? is typed does a list of similar names get printed. "Similar names" here means all names that begin with the same character string, and the list is alphabetized 📋.

To support this style of user interface, it might be appropriate to return the "similar names" response only when someone asks for it 🙋‍♀️. Two ways to do that might be setting an option bit, or using ? to force the similar names response 💜.

3.2. Query Syntax 🧠

The second issue for providing name server service is query syntax 💅. The basic level of service described earlier only allows a few query functions 🥱. With smarter name servers, complex queries can be supported 🔥.

The current Internet name server needs two fields in the query string: a network name field and a host name field 📮. If the network field doesn't exist, a local network query is assumed 🏠.

Since network-independent queries are desirable, an expanded query functionality has to be specified 🌍. One way to do that is to add a special character, like *, which means "all", to the idea of a "missing field" (which means "local") 🎀.

The semantic range of queries you get from this convention is listed below. (Note: ~ is used to mean "null". If both network and host fields are null, the representation is ~ ~. "N" means "network" and "H" means "host".) 💖

~  ~    local net, local host (validity check?)

~  *    local net, all hosts

~  H    local net, named host

*  ~    all nets, local host (inverse search)

*  *    all nets, all hosts (probably prohibited)

*  H    all nets, named host

N  ~    named net, local host (inverse search)

N  *    named net, all hosts

N  H    named net, named host

By combining the on-demand similar-names function, "all" and "local", and by letting * be prefixed or appended to the query string as a wild card character, you can query like this 🃏:

~  SRI*?        All hosts named SRI* on local net

*  SRI*?        All hosts named SRI* on all nets

*  *UNIX*?      All hosts named *UNIX* on all nets

3.3. Service Queries 🛎️

Someone suggested generalizing the name server into a binding function [13, 14] 🙌. In that context, allowing service queries is a super useful extension ✨. One application that already exists within the Packet Radio Project at SRI is finding the addresses of hosts that support the LoaderServer service 📡. That's a service that lets packet radio TIUs receive executable programs via downline loading 💾.

Unlike host name queries, service querying needs a multiple response capability 🔁. The querying process would, upon receiving multiple service descriptors, try to establish access to each service, one at a time, until one works 🎯.

Service descriptors consist of an official name, a list of alias names, and a network-dependent address 🏷️. For Arpanet Internet services, the address field would consist of the host address (32 bits), port (32 bits), and protocol number (8 bits) 🔢. For Arpanet NCP services, the address would consist of a host address (24 bits) and a socket (32 bits) 🧮.

Syntactically, service queries can be derived from host queries by adding a service name field, like this 🧩:

                        NET HOST SERVICE

A network-independent service query, for example, can be written as 🌟:

                           * * SERVICE

3.4. Name Server Options 🎛️

The idea of options was introduced in the discussion of the "similar names" function 💅. Another group of options can be used to specify the format of the reply 📝. At one extreme is the compact, binary style that exists in the basic level of service 🤖. At the other extreme is an expanded, textual style, like a NIC host table record with official and alias names included 📚. Options can be imagined that specify:

  • Binary versus text format
  • Inclusion of each field in the reply
  • Inclusion of official name, per field, in the reply
  • Inclusion of alias names, per field, in the reply
  • Inclusion of other miscellaneous information, such as operating system, machine type, access restrictions, and so on.

Other options can be imagined that specify the scope of the search, like "find SERVER hosts only" 🔎. An alternate way to specify formats might be to settle on several standard ones and let an option select among them 🎀.

Certainly, not all name servers can support all of these options, and not all options are equally useful 💀. So the proposed list will be expanded or contracted to fit the actual needs of processes using the name server service 🫶.

3.5. MORE DATA Protocol 📦

Heads up: some of the proposed name server extensions could generate more than one datagram's worth of reply 😳. That's because the current DARPA Internet Protocol limits the size that all networks must support to 576 octets [15] 📏. Even so, replies of that size don't necessarily need a full-blown stream protocol 🌊. There are several alternatives 💅:

  1. Disallow options that imply large replies.
  2. Truncate the packet for large replies.
  3. Ignore the recommended maximum datagram size.
  4. Utilize an alternate base protocol for such requests.
  5. Develop a MORE DATA protocol.

If alternative 1 is chosen, overflow is possible even with the basic level of service 😬. Alternative 2 means unpredictable behavior for the user of the name server service 🫠. Alternative 3 reduces how available the service is 📉. Alternative 4 is definitely possible, but it might be overkill 🙃.

Alternative 5 looks like a reasonable solution and could be implemented very simply ✨. The name server could return, as part

of the reply, a code of the following form:

                       +------+---------+
                       | MORE | ID_NEXT |
                       +------+---------+

okay so ID_NEXT is a name-server-chosen quantity 💖 It's how the name server finds the next block of reply the next time someone asks. The name server can make it whatever it wants: an internal pointer, a block number, anything 🎀 Follow-on queries can work in one of two ways. Either the name server recomputes the entire original query and throws away output until it reaches the ID_NEXT block, or it stores the whole reply in a cache, split into blocks, with appropriate decay algorithms 🧚 Both are giving very different vibes, but they both get you there ✨

3.6. Dynamic Updates

So up to now, the host name database was basically assumed to be static or changing slowly, with updates done manually by an administrative authority 📋 That model fits most of what the Arpanet and Internet communities needed at the time. But dynamic, automated updating of the host table might be needed in the future 🦋 Mobile environments like the Packet Radio Network are the big example here 📡

In a closed user group community, like a local network of hosts that all trust each other, dynamic updating is basically just a technical question about packet formats 🫶 In wider communities, a mechanism to authenticate the change request has to be developed. Authentication is outside the scope of this paper though, so that's a whole other story for another day 🙈

4. ARCHITECTURE ✨

The Name Server concept is honestly invaluable 💅 It lets hosts with incomplete knowledge of the network address space still get full access to network services. Whether that's because of insufficient kernel space or because environments are changing dynamically, nobody really questions the need for the service. The big design issues are how to provide the service and how to administer and update the database 👑

In the current NIC Name Server, the service is centralized and supported by a database run by one single authority 🏢 Long term, other architectures are possible. They could offer more flexible ways to distribute host information within and between networks and administrative entities. These open the door to dynamic, automated approaches for maintaining and sharing data, especially host name data 🌈

From an evolutionary point of view, the initial Name Server services will likely be a centralized service, possibly with one large Name Server that knows about multiple networks 🌸 From there, expansion can go in two orthogonal directions:

  • In the direction of internal distribution, the name server can be split into multiple cooperating processes on separate hosts. The database can be replicated exactly or managed as a distributed database.
  • In the direction of administrative distribution, multiple autonomous name servers may exist and exchange data in an appropriate fashion, on a per network or other administrative basis.

For hosts with small host tables, caching might be used. Local, temporary copies of subsets of the addressing database would be kept around 🍓 Those copies could come from remembering previous queries made to name servers, or from receiving automatic distributions of data from name servers. For mobile hosts, where even the home network is unknown, it would be possible to keep a very sparse table with the addresses of only a few name servers 🧚

For hosts that don't even know any name server addresses, a very primitive name server function can be provided by all network hosts. It lets real name servers get located 🔍 For example, a query of the form * * RealNameServer addressed to an arbitrarily selected host could bring back the address of a real Name Server.

Finally, multiple name servers might be able to talk to each other dynamically while trying to resolve queries 🤝 If, for example, a name server on the Arpanet gets a query for a host on the Packet Radio Network, then the Arpanet name server can conceivably query the Packet Radio Network Name Server to resolve the reply 💜

5. FUTURE WORK 🔮

The techniques discussed in this paper for providing dynamic access to, and maintenance of, host address information are generally applicable to other information-providing services 💖 Two possibilities currently under investigation at SRI are user identification servers [16] and time servers. They offer people/address and time-stamp information, respectively, as datagram driven information utilities 🎀

Further work is needed to refine the implementation of the name server and the query processes that use it 🛠️ Two items in particular are direct system calls into the NIC database management system for general access to host information, and process-level query interfaces for using processes. The design issues for efficient implementation are complex and involve some trade-offs 🙈 The most obvious one is network traffic volume versus "freshness" of information. The local host table handler can either send a message to the name server for every address request, or use some type of local cache to remember frequently requested names. SRI is exploring both the process-level interface for the LSI-11 TIU and the problems of local host table management in small machines operating in a dynamic environment 🦋

Information services like the Name Server are integral components of distributed systems and applications. But how well such services actually get used is a relatively unstudied and unexplored area 🌙 One area where SRI plans to study their impact on distributed architectures is computer based mail applications. In that environment, information utilities can range from simple mailbox address queries to complex address list management needed for inter-organizational and group resolution 📬

6. CONCLUSION 👑

A provisional Name Server service, based on the NIC host address database, was described in this paper ✨ On top of that, a collection of design ideas for an internet Name Server service has been presented 🌈

Work is continuing on refining the NIC name server service. New requirements and opportunities for functional distribution are being investigated 💅 Lots of questions have been raised while exploring an expansion of the existing service. That expansion is expected to result in more useful support of internet (and intranet) capability 🫶

REFERENCES 📚

  1. L. G. Roberts and B. D. Wessler, "Computer Network Development to Achieve Resource Sharing," in Proceedings of SJCC, pp. 543-549 (AFIP, 1970).
  2. M. D. Kudlick and E. J. Feinler, Host Names On-line, RFC 608, Stanford Research Institute, Menlo Park, California (January 1974).
  3. V. G. Cerf and R. E. Kahn, "A Protocol for Packet Network Interconnection," IEEE Transactions on Communication Technology, Vol. COM-22, pp. 637-641 (1974)._
  4. V. G. Cerf and P. T. Kirstein, "Issues in Packet-Network Interconnection," Proc. IEEE, Vol. 66, No. 11, pp. 1386-1408 (November 1978).
  5. J. Postel, Internet Name Server, IEN 89, Information Sciences Institute, Univ. of Southern Calif., Marina Del Rey, California, May 1979.
  6. J. R. Pickens, E. J. Feinler and J. E. Mathis, An Experimental Network Information Center Name Server (NICNAME), IEN 103, SRI International, Menlo Park, California (May 1979).
  7. J. Postel, Internet Protocol, IEN 81, Information Sciences Institute, Univ. of Southern Calif., Marina Del Rey, California (February 1979).
  8. J. Postel, Address Mappings, IEN 91, Information Sciences Institute, Univ. of Southern Calif., Marina Del Rey, California (May 1979).
  9. R. E. Kahn, "The Organization of Computer Resources into a Packet Radio Network," IEEE Transactions on Communications, Vol. COM-25, No. 1, pp. 169-178 (January 1977).
  10. R. E. Kahn, S. A. Gronemeyer, J. Burchfiel, and R. C. Kunzelman, "Advances in Packet Radio Technology," Proc. IEEE, Vol. 66, No. 11, pp. 1468-1496 (November 1978).
  11. J. Postel, User Datagram Protocol, IEN 88, Information Sciences Institute, Univ. of Southern Calif., Marina Del Rey, California (May 1979).
  12. E. Leavitt, TENEX USER'S GUIDE, Bolt Beranek and Newman, Inc., Cambridge, Massachusetts.
  13. R. Bressler, A Proposed Experiment With a Message Switching Protocol (section on Information Operator), pp. 26-31, RFC 333, Bolt Beranek and Newman Inc, Cambridge, Mass. (May 15, 1972).
  14. Y. Dalal, Internet Meeting, January 24,25 1979, (Group Discussion).
  15. J. Postel, Internet Meeting Notes - 25,26 January 1979, pp. 12, IEN 76, Information Sciences Institute, Univ. of Southern Calif., Marina Del Rey, California (February 1979).
  16. E. J. Feinler, "The Identification Data Base in a Networking Environment," in NTC '77 Conference Record, pp. 21:3 (IEEE, 1977).
📦 where this page comes from