name containing the cause of resolution failure.
Example:
1 3
1 9 F.ISI.USC
1 9 F.ISI.USC
9 18 Resolution Failure
13
RFC 830 October 1982
4.2.4 DNS/DNS Communication
The domain name service is an application independent network
service. It provides the resolution of domain names. For the
specification of this service the reader is referred to [2].
4.3 Transport Protocol
For generality, this specification is intentionally transport
protocol independent. Implications for the use of TCP and UDP are
specifically considered.
Typically, for distributed name service a server A makes a request
to a server B, server B may need to in turn contact other servers to
complete a resolution. TCP is a connection-oriented protocol. It
offers reliable transport, but also imposes certain amount of overhead
for connection establishment and maintenance. For most cases, the use
of TCP is not recommended.
UDP is a datagram service offering a transport capacity per
datagram in excess of 500 octets. Such capacity should suffice most
conceivable commands within this specification. However, it does impose
a limit on the total length of a command. In order to enhance
reliability, the request is incorporated as part of every response
command.
5 NCP TO TCP TRANSITION
The Internet Naming Convention, "@. ... . "
[1], is a generalization of "@", the ARPANET Naming
Convention. It is a generalization in the sense that the ARPANET Naming
Convention can be considered as a partially qualified form of the subset
"@.ARPANET". (We assume here ARPANET is a top-level domain
name.)
For the transition from NCP to TCP, we may initially treat each
host name entry in the current host table as a subdomain of the top-
level domain ARPANET. Thus, initially there would be a very flat domain
structure. This structure can be gradually changed after the transition
toward a hierarchical structure when more and more domains and
subdomains are defined and name servers installed. In the process of
this change, the host table would be gradually converted into
distributed domain tables (databases). For the newly created domain
tables, no standard format would be required. Each individual domain
table may have its own format suitable to the design of its associated
domain name server.
14
RFC 830 October 1982
REFERENCES
[1] Su, Z. and J. Postel, "The Domain Naming Convention for Internet
User Applications," RFC 819, SRI International (August 1982).
[2] Postel, J., "Domains Name Server," RFC XXX, USC/Information
Sciences Institute (to appear).
[3] Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences
Institute (September 1981).
=9= |