The ARPANET Official Network Host Table, as outlined in RFC 608, no longer suits the needs of the DoD community, nor does it follow a format suitable for internetting.  This paper specifies a new host table format applicable to both ARPANET and Internet needs. In addition to host name to host address translation and selected protocol information, we have also included network and gateway name to address correspondence, and host operating system information. This Host Table is utilized by the DoD Host Name Server maintained by the ARPANET Network Information Center (NIC) on behalf of the Defense Communications Agency (DCA) (RFC 811).  It obsoletes the host table described in RFC 608.

HOSTNAME SERVER

The NIC Internet Hostname Server is a TCP-based host information   program and protocol running on the SRI-NIC machine.  It is one of a series of internet name services maintained by the DDN Network Information Center (NIC) at SRI International on behalf of the Defense Communications Agency (DCA).  The function of this particular server is to deliver machine-readable name/address information describing networks, gateways, hosts, and eventually domains, within the internet environment.  As currently implemented, the server provides the information outlined in the DoD Internet Host Table Specification.

Protocol

To access this server from a program, establish a TCP connection to port 101 (decimal) at the service host, SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51).  Send the information request (a single line), and read the resulting response.  The connection is closed by the server upon completion of the response, so only one request can be made for each connection.

The Domain Naming Convention for Internet User Applications

Introduction

For many years, the naming convention “<user>@<host>” has served the ARPANET user community for its mail system, and the substring”<host>” has been used for other applications such as file transfer (FTP) and terminal access (Telnet).  With the advent of network interconnection, this naming convention needs to be generalized to accommodate internetworking.  A decision has recently been reached to replace the simple name field, “<host>”, by a composite name field, “<domain>”.  This note is an attempt to clarify this generalized naming convention, the Internet Naming Convention, and to explore the implications of its adoption for Internet name service and user applications.

The following example illustrates the changes in naming convention:

ARPANET Convention:   Fred@ISIF

Internet Convention:  Fred@F.ISI.ARPA

The intent is that the Internet names be used to form a tree-structured administrative dependent, rather than a strictly topology dependent, hierarchy.  The left-to-right string of name components proceeds from the most specific to the most general, that is, the root of the tree, the administrative universe, is on the right. The name service for realizing the Internet naming convention is assumed to be application independent.  It is not a part of any particular application, but rather an independent name service serves different user applications.

A Distributed System for Internet Name Service

INTRODUCTION

For many years, the ARPANET Naming Convention “<user>@<host>” has served its user community for its mail system.  The substring “<host>” has been used for other user applications such as file transfer (FTP) and terminal access (Telnet).  With the advent of network interconnection, this naming convention needs to be generalized to accommodate internetworking.  The Internet Naming Convention  describes a hierarchical naming structure for serving Internet user applications such as SMTP for electronic mail, FTP and Telnet for file transfer and terminal access.  It is an integral part of the network facility generalization to accommodate internetworking. Realization of Internet Naming Convention requires the establishment of both naming authority and name service.  In this document, we propose an architecture for a distributed System for Internet Name Service (SINS).  We assume the reader’s familiarity with, which describes the Internet Naming Convention.

Internet Name Service provides a network service for name resolution and resource negotiation for the establishment of direct communication between a pair of source and destination application processes.  The source application process is assumed to be in possession of the destination name.  In order to establish communication, the source application process requests for name service. The SINS resolves the destination name for its network address, and provides negotiation for network resources.  Upon completion of successful name service, the source application process provides the destination address to the transport service for establishing direct communication with the destination application process.

Overview

SINS is a distributed system for name service.  It logically consists of two parts: the domain name service and the application interface. The domain name service is an application independent network service for the resolution of domain names.  This resolution is provided through the cooperation among a set of domain name servers (DNSs).  With each domain is associated a DNS.* The reader is referred to for the specification of a domain name server.  As noted in , a domain is an administrative but not necessarily a topological entity.  It is represented in the networks by its associated DNS.  The resolution of a domain name results in the address of its associated DNS.