home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 800s / rfc830.txt < prev    next >
Text File  |  1992-09-22  |  32KB  |  989 lines
  1. Network Working Group
  2. Request for Comments: 830
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.              A Distributed System for Internet Name Service
  11.  
  12.  
  13.                                   by
  14.                               Zaw-Sing Su
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.       +-------------------------------------------------------------+     
  26.       |                                                             |
  27.       |   This RFC proposes a distributed name service for DARPA    |
  28.       |   Internet.  Its purpose is to focus discussion on the      |
  29.       |   subject.  It is hoped that a general consensus will       |
  30.       |   emerge leading eventually to the adoption of standards.   |
  31.       |                                                             | 
  32.       +-------------------------------------------------------------+
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.                              October 1982
  40.  
  41.  
  42.  
  43.                            SRI International
  44.                          333 Ravenswood Avenue
  45.                      Menlo Park, California  94025
  46.  
  47.                 (415)  859-4576
  48.  
  49.  
  50. RFC 830                                                       October 1982
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.              A Distributed System for Internet Name Service
  59.  
  60.  
  61.  
  62.                             1   INTRODUCTION
  63.  
  64.      For many years, the ARPANET Naming Convention "<user>@<host>" has
  65. served its user community for its mail system.  The substring "<host>"
  66. has been used for other user applications such as file transfer (FTP)
  67. and terminal access (Telnet).  With the advent of network
  68. interconnection, this naming convention needs to be generalized to
  69. accommodate internetworking.  The Internet Naming Convention [1]
  70. describes a hierarchical naming structure for serving Internet user
  71. applications such as SMTP for electronic mail, FTP and Telnet for file
  72. transfer and terminal access.  It is an integral part of the network
  73. facility generalization to accommodate internetworking.
  74.  
  75.      Realization of Internet Naming Convention requires the
  76. establishment of both naming authority and name service.  In this
  77. document, we propose an architecture for a distributed System for
  78. Internet Name Service (SINS).  We assume the reader's familiarity with
  79. [1], which describes the Internet Naming Convention.
  80.  
  81.      Internet Name Service provides a network service for name
  82. resolution and resource negotiation for the establishment of direct
  83. communication between a pair of source and destination application
  84. processes.  The source application process is assumed to be in
  85. possession of the destination name.  In order to establish
  86. communication, the source application process requests for name service.
  87. The SINS resolves the destination name for its network address, and
  88. provides negotiation for network resources.  Upon completion of
  89. successful name service, the source application process provides the
  90. destination address to the transport service for establishing direct
  91. communication with the destination application process.
  92.  
  93.  
  94.  
  95.                               2   OVERVIEW
  96.  
  97. 2.1  System Organization
  98.  
  99.      SINS is a distributed system for name service.  It logically
  100. consists of two parts: the domain name service and the application
  101. interface (Figure 1).  The domain name service is an application
  102. independent network service for the resolution of domain names.  This
  103. resolution is provided through the cooperation among a set of domain
  104.  
  105.  
  106.                                    1
  107.  
  108. RFC 830                                                       October 1982
  109.  
  110.  
  111.  
  112. name servers (DNSs).  With each domain is associated a DNS.*  The reader
  113. is referred to [2] for the specification of a domain name server.  As
  114. noted in [1], a domain is an administrative but not necessarily a
  115. topological entity.  It is represented in the networks by its associated
  116. DNS.  The resolution of a domain name results in the address of its
  117. associated DNS.
  118.  
  119.  
  120.      Application                                   Application
  121.        Process                                       Process
  122.           |                                             |
  123.    SINS   |                                             |
  124.    -------|---------------------------------------------|-----  Application
  125.    |     AIP                                           AIP   |   Interface
  126.    |      |                                             |    |  . . . . . . .
  127.    |     DNS  - - -  DNS  - - -  DNS  - -  . . .  - -  DNS   |  Domain Name
  128.    -----------------------------------------------------------    Service
  129.  
  130.            Figure 1   Separation of Application Interface
  131.  
  132.      The application interface provides mechanisms for resolution beyond
  133. that of destination domain and negotiation to ensure resource
  134. availability and compatibility.  Such negotiation is sometimes referred
  135. to as the "what-can-you-do-for-me" negotiation.  The application
  136. interface isolates domain name service from application dependence.  It
  137. thus allows sharing of domain name service among various user
  138. applications.
  139.  
  140.      The application interface consists of a set of application
  141. interface processes (AIPs) one for each endpoint domain.  For operation
  142. efficiency, the AIP is assumed to be combined with its associated DNS
  143. forming an endpoint DNS (Figure 2).
  144.  
  145.  
  146.        Application                                   Application
  147.          Process                                       Process
  148.             |                                             |
  149.      SINS   |                                             |
  150.      -------|---------------------------------------------|-------
  151.      |   Endpoint                                      Endpoint  |
  152.      |     DNS  - - -  DNS  - - -  DNS  - -  . . .  - -  DNS     |
  153.      |                                                           |
  154.      -------------------------------------------------------------
  155.  
  156.     Figure 2  Distribution of Name Service Components Among Domains
  157.  
  158. --------------------
  159. * For reasons such as reliability, more than one DNS per domain may be
  160. required.  They may be cooperating DNSs or identical for redundancy.  In
  161. either case, without loss of generality we may logically view the
  162. association as one DNS per domain.
  163.  
  164.  
  165.                    2
  166.  
  167. RFC 830                                                       October 1982
  168.  
  169. 2.2  Domain Resolution
  170.  
  171.      For name service, the source application process presents to its
  172. local AIP the destination name, and the application service it requests.
  173. For most applications, the application service the source application
  174. process requests would be the service it offers.  The destination name
  175. is assumed to be fully qualified of the form:
  176.  
  177.        <local name>@<domain>.<domain>. ... .<domain>
  178.  
  179. The domains named in the concatenation are hierarchically related [1].
  180. The left-to-right string of simple names in the concatenation proceeds
  181. from the most specific domain to the most general.  The concatenation of
  182. two domains,
  183.  
  184.         ... .<domain A>.<domain B>. ...
  185.  
  186. implies the one on the left, domain A, to be an immediate member (i.e.,
  187. the first-generation descendent) of the one on the right, domain B.  The
  188. right-most simple name designates a top-level domain, a first-generation
  189. descendent of the naming universe.
  190.  
  191.      For domain resolution, the AIP consults the domain name service.  It
  192. presents the co-located DNS with the fully qualified domain
  193. specification:
  194.  
  195.         <domain>.<domain>. ... .<domain>
  196.  
  197. The DNSs participating in a resolution resolve the concatenation from
  198. the right.  The source endpoint DNS resolves the right-most simple name
  199. and acts as a hub polling the other DNSs.  It resolves the right-most
  200. simple name into an address for the DNS of the specified top-level
  201. domain, then polls that DNS with a request for further resolution.  When
  202. polled, a DNS resolves the next right-most simple domain name.  Upon
  203. successful resolution, an intermediate DNS may have a choice of either
  204. returning the resulting address or forwarding the request to the next
  205. DNS for continuing resolution.
  206. When a intermediate DNS receives a reply from the next DNS, it must
  207. respond to the request it has received.  To simplify the domain name
  208. service protocol, an intermediate DNS is not allowed to act as a hub for
  209. further polling.
  210.  
  211.  
  212. 2.3  Application Interface
  213.  
  214.      Addressing for destination endpoint domain is in general not
  215. sufficient for the source application process to establish direct
  216. communication with the destination application process.  In order to
  217. establish direct communication, further addressing may be necessary.
  218. Addressing beyond destination endpoin domain may be necessary when the
  219. addressing of application process cannot be derived from the address of
  220. the endpoint domain.  To provide such derivation capability permanent
  221. binding and universal binding convention, such as TCP port number
  222. assignment, may be necessary.
  223.  
  224.                                    3
  225.  
  226. RFC 830                                                       October 1982
  227.  
  228.      Beyond addressing, negotiation for resource availability and
  229. compatibility is often found necessary.  The application interface
  230. provides a "what-can-you-do-for-me" negotiation capability between the
  231. source and destination endpoint domains.  Such negotiation mechanisms
  232. provided in this design include those for the availability and
  233. compatibility of transport service, e.g., TCP or UDP, and application
  234. service, e.g., SMTP for mail transport.  The availability of such
  235. negotiation service may allow dynamic binding and variations in system
  236. design.
  237.  
  238.      The application interface offers an integrated service for various
  239. "what-can-you-do-for-me" negotiation capabilities.
  240.  
  241. 2.4  Example
  242.  
  243.      Let us assume that a request is made at ISID for remote file
  244. transfer using NIFTP to SRI-TSC.  The domain name for ISID is
  245. D.ISI.USC.ARPA,* and TSC.SRI.ARPA for SRI-TSC.  The hierarchical
  246. relationship between these two domains is as depicted in Figure 3 below.
  247. The NIFTP process (an application process) at ISID forwards the domain
  248. name TSC.SRI.ARPA" to the local AIP in domain D for name service.  The
  249. AIP forwards the fully qualified domain name, "TSC.SRI.ARPA", to its co-
  250. located DNS for domain resolution.
  251.  
  252.      ARPA, the right-most simple name, is assumed to designate a top-
  253. level domain.  The DNS of D recognizes this simple name, resolves it
  254. into the address of the ARPA domain DNS, and forwards the request to
  255. that DNS with a pointer pointing to the next domain "SRI".  The ARPA DNS
  256. recognizes "SRI" as one of its subdomains, resolves the address of the
  257. subdomain's DNS.  It has a choice at this point whether to return this
  258. address to the source endpoint DNS or to forward the request to the DNS
  259. of SRI.
  260.  
  261.                                          naming
  262.                                         universe
  263.                                       /          \
  264.                                --- ARPA (DNS)
  265.                              /       |
  266.                            /        SRI (DNS)
  267.                          /           |  \
  268.                        USC (DNS)        TSC (DNS/AIP)
  269.                         |                |
  270.                         |          [TCP/FTP/RFT]
  271.                        ISI (DNS)
  272.                         |
  273.                         D (DNS/AIP)
  274.                       /   \
  275.         [TCP/NIFTP/RFT]   [TCP/FTP/RFT]
  276.                     |
  277.                   user
  278.  
  279. --------------------
  280. * Domain names used in the examples are for illustration purposes only.
  281. The assignment of domain names is beyond the scope of this writeup.
  282.  
  283.                                    4
  284.  
  285. RFC 830                                                       October 1982
  286.  
  287.  
  288. If it returns the address, the source endpoint DNS at D, would continue
  289. polling by forwarding the request to the SRI DNS.  When the DNS of SRI
  290. detects TSC as the last domain in the concatenation, it resolves the
  291. address for the DNS at TSC, and returns it to the source DNS at domain
  292. D.  Upon receiving a successful domain resolution, the source DNS returns
  293. the obtained address to its associated AIP.
  294.  
  295.      Since the destination AIP is co-located at this address, the source
  296. AIP is able to forward a request with the service designation
  297. "TCP/NIFTP/RFT" for "what-can-you-do-for-me" negotiation.  Realizing
  298. that within TSC there is no NIFTP but FTP provided for remote file
  299. transfer, the destination AIP would respond accordingly.  Since ISID
  300. also offers FTP service, the "what-can-you-do-for-me" negotiation may
  301. conclude successfully.  The user request for file transfer may thus be
  302. satisfied.
  303.  
  304.  
  305.  
  306.                          3   SYSTEM COMPONENTS
  307.  
  308. 3.1  Component Processes
  309.  
  310.      The two basic distributed components of SINS are the endpoint DNS
  311. and the intermediate DNS.  An endpoint DNS is associated with each
  312. endpoint domain.  An intermediate DNS is associated with a domain
  313. without any associated application process.
  314.  
  315.      The intermediate DNS is rather simple.  It has the resolution
  316. capability for translating simple names of first-generation subdomains
  317. to addresses of their associated DNS.  It also communicates with other
  318. DNS for domain resolution.
  319.  
  320.      An endpoint DNS consists of an AIP and a source DNS.  The source
  321. DNS implements the polling mechanism which communicates with other DNSs
  322. as a hub for polling.  It also has capability for the resolution of top-
  323. level domains.  It responds to requests from the local AIP for domain
  324. resolution (Section 4.2.3).
  325.  
  326.      The major function of an AIP implements the intellegence of "what-
  327. can-you-do-for-me" negotiations.  A communication module realizes
  328. negotiation exchanges between the source and destination AIPs (Section
  329. 4.2.2).  As an interface between the application processes and the local
  330. DNS, it must also implement communication capabilities for exchanges
  331. with the DNS and the application processes.
  332.  
  333.  
  334. 3.2  Databases for Name Resolution
  335.  
  336.      There is a database associated with each resolution module.  The
  337. database associated with an endpoint domain contains name-to-address
  338.  
  339.  
  340.  
  341.                                    5
  342.  
  343. RFC 830                                                       October 1982
  344.  
  345.  
  346.  
  347. correspondences for the top-level domains, first-generation descendents
  348. of the naming universe.  It facilitates the endpoint DNS resolving the
  349. right-most simple name of a fully-qualified domain specification.
  350.  
  351.      The database associated with an intermediate domain contains name-
  352. to-address correspondences for the first-generation subdomains of this
  353. domain.  Thus, the required database contents among the intermediate DNS
  354. databases are disjoint, and updates are local.
  355.  
  356.      It is also noticed that with the implementation of the SINS, there
  357. is no need for database format standardization.
  358.  
  359.  
  360. 3.3  Caching
  361.  
  362.      The component processes and resolution databases constitute the
  363. basic System for Internet Name Service.  The distributed components are
  364. related according to the domain hierarchy.  The databases associated
  365. with the endpoint domains are all identical.  Containing only name-to-
  366. address correspondence for top-level domains, the endpoint database
  367. should be rather small in size.  The disjoint nature of intermediate DNS
  368. databases allows easy local updates.
  369.  
  370.      However, communications will be very inefficient if the Internet
  371. name service is called for the establishment of every transaction.  A
  372. standard solution to aleviate such inefficiency is the use of caching.
  373.  
  374.      Caching is a mechanism reusing previous resolution results.  To
  375. expedite establishment of communication, the resolution results are
  376. stored for future reference.  We do not incorporate caching as a
  377. standard feature of the SINS.  However, we assume the use of caching for
  378. efficient operations at individual implementor's discretion.
  379.  
  380.  
  381.  
  382. 4   INTER-COMPONENT COMMUNICATIONS (THE INTERNET NAME SERVICE PROTOCOLS)
  383.  
  384.      In this section, we present a format specification for
  385. correspondences between various component pairs.  For co-located
  386. components, communication becomes interprocess, and the exact format
  387. less important.  For inter-host communication, the format specification
  388. here defines a name service protocol.
  389.  
  390.      The communicating component pairs of concern here are application
  391. process/AIP, AIP/DNS, and AIP/AIP.  The communications employ
  392. request/response commands.  A single command structure is adopted for
  393. all three pairs; while communications between a particular pair may
  394. employ a subset of the commands.  Such uniformity allows minimum
  395. processing and maximum code sharing for implementation.
  396.  
  397.  
  398.  
  399.  
  400.                                    6
  401.  
  402. RFC 830                                                       October 1982
  403.  
  404. 4.1  Command Structure
  405.  
  406.      The basic command structure begins with two octets indicating
  407. command type and the number of items in the command.  They are followed
  408. by the indicated number of items.  The type of an item is indicated in
  409. its first octet, followed by a one-octet content length, and then the
  410. item content.  Required presence or absence and order of the items for
  411. each component pair are specified in this section.
  412.  
  413.     Command Type   Number of Items
  414.  
  415.     Item Indicator   Content Length   Item Content
  416.           .
  417.           .
  418.  
  419. Command Type
  420.  
  421.      This type coded in binary number indicates whether this command is
  422. a request, an affirmative response, or some other type of response (see
  423. Appendix A for the command types and their corresponding code).  This
  424. type specification implies the presence or absence and order of the
  425. following items.
  426.  
  427. Number of Items
  428.  
  429.      This number is expressed in binary number.  It specifies the number
  430. of following items.  Owing to the possibility of a multiple response,
  431. this number may vary for a particular command.
  432.  
  433. Item Indicator
  434.  
  435.      This indicator defines the item type.  The possible types include:
  436. service, name, address, and comment.  The type of an item implies its
  437. content structure.
  438.  
  439. Content Length
  440.  
  441.      This length specification, in binary, indicates the length of the
  442. following content in octets.  The maximum can be specified is 255, thus
  443. the maximum length of the content.  However, this maximum may also be
  444. constrained by the total length of the command (Section 4.3).
  445.  
  446. Item Content
  447.  
  448.      The contents for different items are:
  449.      Service -- Transport protocol/service protocol/service type
  450.                 (ASCII). (See Appendix A for standard identifiers for
  451.                 service specifications.)
  452.      Name -- Whole or partial name string according to Internet Naming
  453.              Convention [1] (ASCII).
  454.      Address -- The address is presented in binary form.  In this
  455.                 writeup, double quotes, " ", are used around decimal
  456.                 values separated by a space to represent octets of the
  457.                 binary form.
  458.  
  459.                                    7
  460.  
  461. RFC 830                                                       October 1982
  462.  
  463.  
  464.  
  465.                 Parsing of the address is implied by the specified
  466.                 transport protocol.  In the case of TCP, the first
  467.                 four octets gives the 32-bit IP address, the 5th octet
  468.                 the IP-specific protocol number, and the 6th the TCP or
  469.                 UDP port number for the application service.
  470.  
  471.      Comment -- The item is mostly optional.  Its presence may allow
  472.                 an intermediate server passing comment to the end user.
  473.                 Error comments explaining resolution failure is an
  474.                 example of its use.
  475.  
  476.  
  477. 4.2  Command Specification
  478.  
  479.      In this section, we define the name service commands for the
  480. various communication pairs.
  481.  
  482.  
  483. 4.2.1 Application Process/AIP Communication
  484.  
  485.      From the name service point of view, there is no need for
  486. communication between the AIP and an application process at the
  487. destination.  Thus, here we discuss communications at the originating
  488. domain.
  489.  
  490.      An application process initiates a dialogue by making a request for
  491. name service to its local AIP.  It provides the requested application
  492. service and a destination name for resolution.
  493.  
  494. REQUEST
  495.  
  496.    Command Type   Number of Items
  497.  
  498.    Service Indicator   Length   Transport Protocol/Service/Service Type
  499.  
  500.    Name Indicator   Name Length   Name String
  501.  
  502. Examples:
  503.  
  504.    1  2
  505.    3 13 TCP/SMTP/mail
  506.    1 21 Postel@F.ISI.USC.ARPA
  507.  
  508.    1  2
  509.    3 13 TCP/NIFTP/RFT
  510.    1 12 TSC.SRI.ARPA
  511.  
  512.      The first example is a resolution request for the name
  513. "Postel@F.ISI.USC.ARPA".  It is 21 octets in length.  The requested
  514. application service is TCP/SMTP/mail.  The second example is a
  515. resolution request for application service NIFTP at TSC.SRI.ARPA.
  516.  
  517.  
  518.                                    8
  519.  
  520. RFC 830                                                       October 1982
  521.  
  522.  
  523.  
  524. AFFIRMATIVE RESPONSE
  525.  
  526.    Command Type   Number of Items
  527.  
  528.    Service Indicator   Length   Transport Protocol/Service/Service Type
  529.  
  530.    Name Indicator   Name Length    Name String
  531.  
  532.    Address Indicator   Address Length   Address
  533.  
  534. Examples:
  535.  
  536.    2  3
  537.    3 13 TCP/SMTP/mail
  538.    1 21 Postel@F.ISI.USC.ARPA
  539.    2  6 "10  2  0 52  6 25"
  540.  
  541.    2  4
  542.    3 13 TCP/NIFTP/RFT
  543.    1 12 TSC.SRI.ARPA
  544.    2  6 "10  3  0  2  6 47"
  545.    2  6 "39  0  0  5  6 47"
  546.  
  547.      An affirmative response implies that the destination offers the
  548. requested service.  The parsing of an address is implied by the
  549. indicated transport protocol.  In the first example, the transport
  550. protocol is TCP.  Thus, the address is composed of three fields: the
  551. internet address ("10 2 0 52"), the protocol number ("6" for TCP [3]),
  552. and the port number ("25" for SMTP [3]).  A multiple-address response in
  553. the second example indicates that TSC is multi-homed via both ARPANET
  554. (net  10), and SRINET (net  39).  A multiple-resolution response is
  555. preferred.  It offers the source a choice.
  556.  
  557. NEGATIVE RESPONSE
  558.  
  559.    Command Type   Number of Items
  560.  
  561.    Service Indicator   Length   Transport Protocol/Service/Service Type
  562.  
  563.    Name Indicator   Name Length   Name String
  564.  
  565.    Name Indicator   Name Length   Partial Name String
  566.  
  567.    [Comment Indicator   Comment Length   Comment]
  568.  
  569.      This indicates difficulty in resolution.  Returned with this
  570. command is the left-most portion of the specified name including the
  571. difficulty encountered.  An optional comment item may be included.
  572.  
  573.  
  574.  
  575.  
  576.                                    9
  577.  
  578. RFC 830                                                       October 1982
  579.  
  580.  
  581. Examples:
  582.  
  583.    3  4
  584.    3 13 TCP/SMTP/mail
  585.    1 16 Postel@F.ISI.USC
  586.    1 16 Postel@F.ISI.USC
  587.    9 18 Resolution Failure
  588.  
  589.    3  4
  590.    3 13 TCP/NIFTP/RFT
  591.    1 13 TSC..SRI.ARPA
  592.    1  5 TSC..
  593.    9 17 Syntactic Anomaly
  594.  
  595. In the first example, the resolution failed because USC is not top-level
  596. domain.  The syntactic error of adajacent dots in the second example is
  597. obvious.
  598.  
  599. INCOMPATIBLE SERVICE
  600.  
  601.      This response indicates no compatible application and/or transport
  602. service is available at the destination.  For example, the requested
  603. application service may be SMTP, while only FTP-mail is available at the
  604. destination.  Return with this command is the available corresponding
  605. available service, if any, and its address.  If no service is available
  606. for that service type, an empty string for service specification is
  607. returned.
  608.  
  609.    Command Type   Number of Items
  610.  
  611.    Service Indicator   Length   Transport Protocol/Service/Service Type
  612.  
  613.    Name Indicator   Name Length   Name String
  614.  
  615.    Service Indicator   Length   Transport Protocol/Service/Service Type
  616.  
  617.    [Address Indicator   Address Length   Address]
  618.  
  619. Examples:
  620.  
  621.    9  3
  622.    3 14 TCP/NIFTP/mail
  623.    1 21 Postel@F.ISI.USC.ARPA
  624.    3  0
  625.  
  626.    9  5
  627.    3 13 TCP/NIFTP/RFT
  628.    1 12 TSC.SRI.ARPA
  629.    3 11 TCP/FTP/RFT
  630.    2  6 "10  3  0  2  6 21"
  631.    2  6 "39  0  0  5  6 21"
  632.  
  633.  
  634.  
  635.                                    10
  636.  
  637. RFC 830                                                       October 1982
  638.  
  639.  
  640.  
  641. 4.2.2 AIP/AIP Communication
  642.  
  643.      Communication between the AIPs accomplishes the "what-can-you-do-
  644. for-me" negotiation.  Examples in this section correspond to those of
  645. Section 4.2.1.
  646.  
  647. REQUEST
  648.  
  649.    Command Type   Number of Items
  650.  
  651.    Service Indicator   Length   Transport Protocol/Service/Service Type
  652.  
  653. Examples:
  654.  
  655.    1  1
  656.    3 13 TCP/SMTP/mail
  657.  
  658.    1  1
  659.    3 13 TCP/NIFTP/RFT
  660.  
  661. AFFIRMATIVE RESPONSE
  662.  
  663.    Command Type   Number of Items
  664.  
  665.    Service Indicator   Length   Transport Protocol/Service/Service Type
  666.  
  667.    Address Indicator   Address Length   Address
  668.  
  669. Examples:
  670.  
  671.    2  2
  672.    3 13 TCP/SMTP/mail
  673.    2  6 "10  2  0 52  6 25"
  674.  
  675.    2  3
  676.    3 14 TCP/NIFTP/RFT
  677.    2  6 "10  3  0  2  6 47"
  678.    2  6 "39  0  0  5  6 47"
  679.  
  680.      An affirmative response implies that the destination offers the
  681. same service as that of the originator.  A multi-resolution response is
  682. possible.  The parsing of an address is implied by the indicated
  683. transport protocol.  In the second example, the transport protocol is
  684. TCP.  Thus, the address is composed of three fields: the internet
  685. address (10 2 0 52), the protocol number (6 for TCP), and the port
  686. number (25 for SMTP).  The returned address(es) is to be relayed to the
  687. originating application process.
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.                                    11
  695.  
  696. RFC 830                                                       October 1982
  697.  
  698. INCOMPATIBLE SERVICE
  699.  
  700.    Command Type   Number of Items
  701.  
  702.    Service Indicator   Length   Transport Protocol/Service/Service Type
  703.  
  704.    Service Indicator   Length   Transport Protocol/Service/Service Type
  705.  
  706.    Address Indicator   Address Length   Address
  707.  
  708.      This response indicates no compatible application and/or transport
  709. service available serving the destination.  For example, SMTP may be the
  710. requested application service, while only NIFTP-mail is available
  711. serving the destination.  Return with this command is the available
  712. service of that type.  If no service available for that service type, a
  713. empty text string is returned.
  714.  
  715. Examples:
  716.  
  717.    9  2
  718.    3 14 TCP/NIFTP/mail
  719.    3  0
  720.  
  721.    9  4
  722.    3 13 TCP/NIFTP/RFT
  723.    3 11 TCP/FTP/RFT
  724.    2  6 "10  3  0  2  6 21"
  725.    2  6 "39  0  0  5  6 21"
  726.  
  727. In the first example, the destination does not offer any kind of mail
  728. service.  The second example indicates that there is no NIFTP, but FTP
  729. available for remote file transfer service at the destination.
  730.  
  731.  
  732. 4.2.3 AIP/DNS Communication
  733.  
  734.      The source AIP presents its associated DNS with a fully qualified
  735. domain specification for resolution.  The expected resolution result is
  736. the network address for the destination endpoint DNS.  We assume no need
  737. for communication between the DNS and AIP at the destination.
  738.  
  739. REQUEST
  740.  
  741.    Command Type   Number of Items
  742.  
  743.    Name Indicator   Name Length   Name String
  744.  
  745. Examples:
  746.  
  747.    1  1
  748.    1 14 F.ISI.USC.ARPA
  749.  
  750.    1  1
  751.    1 12 TSC.SRI.ARPA
  752.  
  753.                                    12
  754.  
  755. RFC 830                                                       October 1982
  756.  
  757.  
  758.  
  759. AFFIRMATIVE RESPONSE
  760.  
  761.    Command Type   Number of Items
  762.  
  763.    Name Indicator   Name Length    Name String
  764.  
  765.    Service Indicator   Service Length   Transport Protocol
  766.  
  767.    Address Indicator   Address Length   Address
  768.  
  769. Examples:
  770.  
  771.    2  3
  772.    1 14 F.ISI.USC.ARPA
  773.    3  3 UDP
  774.    2  6 "10  2  0 52 17 42"
  775.  
  776.    2  4
  777.    1  7 TSC.SRI.ARPA
  778.    3  3 UDP
  779.    2  6 "10  3  0  2 17 42"
  780.    2  6 "39  0  0  5 17 42"
  781.  
  782. An affirmative response returns an address of the destination endpoint
  783. DNS.  This returned address is that of the destination DNS.  The
  784. destination transport service needs to be indicated for guiding the
  785. parsing of the destination address.
  786.  
  787. NEGATIVE RESPONSE
  788.  
  789.    Command Type   Number of Items
  790.  
  791.    Name Indicator   Name Length   Name String
  792.  
  793.    Name Indicator   Name Length   Partial Name String
  794.  
  795.    [Comment Indicator  Comment Length   Comment]
  796.  
  797.      This response indicates that the domain name service is unable to
  798. resolve the given destination domain name.  It could be caused by an
  799. unknown simple name, which may result from, for example, misspelling.
  800. Returned with this command is the left-most portion of the specified
  801. name containing the cause of resolution failure.
  802.  
  803. Example:
  804.  
  805.      1  3
  806.      1  9 F.ISI.USC
  807.      1  9 F.ISI.USC
  808.      9 18 Resolution Failure
  809.  
  810.  
  811.  
  812.                                    13
  813.  
  814. RFC 830                                                       October 1982
  815.  
  816.  
  817. 4.2.4 DNS/DNS Communication
  818.  
  819.      The domain name service is an application independent network
  820. service.  It provides the resolution of domain names.  For the
  821. specification of this service the reader is referred to [2].
  822.  
  823.  
  824. 4.3  Transport Protocol
  825.  
  826.      For generality, this specification is intentionally transport
  827. protocol independent.  Implications for the use of TCP and UDP are
  828. specifically considered.
  829.  
  830.      Typically, for distributed name service a server A makes a request
  831. to a server B, server B may need to in turn contact other servers to
  832. complete a resolution.  TCP is a connection-oriented protocol.  It
  833. offers reliable transport, but also imposes certain amount of overhead
  834. for connection establishment and maintenance.  For most cases, the use
  835. of TCP is not recommended.
  836.  
  837.      UDP is a datagram service offering a transport capacity per
  838. datagram in excess of 500 octets.  Such capacity should suffice most
  839. conceivable commands within this specification.  However, it does impose
  840. a limit on the total length of a command.  In order to enhance
  841. reliability, the request is incorporated as part of every response
  842. command.
  843.  
  844.  
  845.  
  846.                        5   NCP TO TCP TRANSITION
  847.  
  848.      The Internet Naming Convention, "<user>@<domain>.  ...  . <domain>"
  849. [1], is a generalization of "<user>@<host>", the ARPANET Naming
  850. Convention.  It is a generalization in the sense that the ARPANET Naming
  851. Convention can be considered as a partially qualified form of the subset
  852. "<user>@<host>.ARPANET".  (We assume here ARPANET is a top-level domain
  853. name.)
  854.  
  855.      For the transition from NCP to TCP, we may initially treat each
  856. host name entry in the current host table as a subdomain of the top-
  857. level domain ARPANET.  Thus, initially there would be a very flat domain
  858. structure.  This structure can be gradually changed after the transition
  859. toward a hierarchical structure when more and more domains and
  860. subdomains are defined and name servers installed.  In the process of
  861. this change, the host table would be gradually converted into
  862. distributed domain tables (databases).  For the newly created domain
  863. tables, no standard format would be required.  Each individual domain
  864. table may have its own format suitable to the design of its associated
  865. domain name server.
  866.  
  867.  
  868.  
  869.  
  870.                                    14
  871.  
  872. RFC 830                                                       October 1982
  873.  
  874.  
  875.  
  876. REFERENCES
  877.  
  878. [1]  Su, Z. and J. Postel, "The Domain Naming Convention for Internet
  879. User Applications,"  RFC 819, SRI International (August 1982).
  880.  
  881. [2]  Postel, J., "Domains Name Server," RFC XXX, USC/Information
  882. Sciences Institute (to appear).
  883.  
  884. [3]  Postel, J., "Assigned Numbers," RFC 790, USC/Information Sciences
  885. Institute (September 1981).
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.                                    15
  929.  
  930. RFC 830                                                       October 1982
  931.  
  932.  
  933.  
  934.                                Appendix A
  935.  
  936.  
  937.              CONVENTION ASSIGNMENTS
  938.  
  939.      Command Types
  940.  
  941.      Request              1
  942.      Affirmative Response 2
  943.      Negative Response    3
  944.      Imcompatible Service 9
  945.  
  946.  
  947.      INDICATORS
  948.  
  949.      Name Indicator       1
  950.      Address Indicator    2
  951.      Service Indicator    3
  952.      Comment Indicator    9
  953.  
  954.  
  955.      TRANSPORT PROTOCOLS:  TCP, UDP, NCP
  956.  
  957.  
  958.      SERVICES
  959.  
  960.      Service Protocols                  Service Type
  961.  
  962.      MTP                                mail
  963.      SMTP                               mail
  964.      FTP    (FTP mail)                  mail
  965.      NIFTP  (NIFTP mail)                mail
  966.      MMDF                               mail
  967.  
  968.      FTP                                RFT (remote file transfer)
  969.  
  970.      Telnet                             RTA (remote terminal access)
  971.  
  972.  
  973.  
  974.  
  975.  
  976.  
  977.  
  978.  
  979.  
  980.  
  981.  
  982.  
  983.  
  984.  
  985.  
  986.                                    16
  987.  
  988.  
  989.