Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]
UNKNOWN
Network Working GroupRequest for Comments: 830 A Distributed System for Internet Name Service by Zaw-Sing Su +-------------------------------------------------------------+ | | | This RFC proposes a distributed name service for DARPA | | Internet. Its purpose is to focus discussion on the | | subject. It is hoped that a general consensus will | | emerge leading eventually to the adoption of standards. | | | +-------------------------------------------------------------+ October 1982 SRI International 333 Ravenswood Avenue Menlo Park, California 94025 (415) 859-4576
RFC 830 October 1982 A Distributed System for Internet Name Service 1 INTRODUCTION For many years, the ARPANET Naming Convention "<user>@<host>" hasserved 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 networkinterconnection, this naming convention needs to be generalized toaccommodate internetworking. The Internet Naming Convention [1]describes a hierarchical naming structure for serving Internet userapplications such as SMTP for electronic mail, FTP and Telnet for filetransfer and terminal access. It is an integral part of the networkfacility generalization to accommodate internetworking. Realization of Internet Naming Convention requires theestablishment of both naming authority and name service. In thisdocument, we propose an architecture for a distributed System forInternet Name Service (SINS). We assume the reader's familiarity with[1], which describes the Internet Naming Convention. Internet Name Service provides a network service for nameresolution and resource negotiation for the establishment of directcommunication between a pair of source and destination applicationprocesses. The source application process is assumed to be inpossession of the destination name. In order to establishcommunication, the source application process requests for name service.The SINS resolves the destination name for its network address, andprovides negotiation for network resources. Upon completion ofsuccessful name service, the source application process provides thedestination address to the transport service for establishing directcommunication with the destination application process. 2 OVERVIEW2.1 System Organization SINS is a distributed system for name service. It logicallyconsists of two parts: the domain name service and the applicationinterface (Figure 1). The domain name service is an applicationindependent network service for the resolution of domain names. Thisresolution is provided through the cooperation among a set of domain 1
RFC 830 October 1982name servers (DNSs). With each domain is associated a DNS.* The readeris referred to [2] for the specification of a domain name server. Asnoted in [1], a domain is an administrative but not necessarily atopological entity. It is represented in the networks by its associatedDNS. The resolution of a domain name results in the address of itsassociated DNS. Application Application Process Process | | SINS | | -------|---------------------------------------------|----- Application | AIP AIP | Interface | | | | . . . . . . . | DNS - - - DNS - - - DNS - - . . . - - DNS | Domain Name ----------------------------------------------------------- Service Figure 1 Separation of Application Interface The application interface provides mechanisms for resolution beyondthat of destination domain and negotiation to ensure resourceavailability and compatibility. Such negotiation is sometimes referredto as the "what-can-you-do-for-me" negotiation. The applicationinterface isolates domain name service from application dependence. Itthus allows sharing of domain name service among various userapplications. The application interface consists of a set of applicationinterface processes (AIPs) one for each endpoint domain. For operationefficiency, the AIP is assumed to be combined with its associated DNSforming an endpoint DNS (Figure 2). Application Application Process Process | | SINS | | -------|---------------------------------------------|------- | Endpoint Endpoint | | DNS - - - DNS - - - DNS - - . . . - - DNS | | | ------------------------------------------------------------- Figure 2 Distribution of Name Service Components Among Domains--------------------* For reasons such as reliability, more than one DNS per domain may berequired. They may be cooperating DNSs or identical for redundancy. Ineither case, without loss of generality we may logically view theassociation as one DNS per domain. 2
RFC 830 October 19822.2 Domain Resolution For name service, the source application process presents to itslocal AIP the destination name, and the application service it requests.For most applications, the application service the source applicationprocess requests would be the service it offers. The destination nameis assumed to be fully qualified of the form: <local name>@<domain>.<domain>. ... .<domain>The domains named in the concatenation are hierarchically related [1].The left-to-right string of simple names in the concatenation proceedsfrom the most specific domain to the most general. The concatenation oftwo domains, ... .<domain A>.<domain B>. ...implies the one on the left, domain A, to be an immediate member (i.e.,the first-generation descendent) of the one on the right, domain B. Theright-most simple name designates a top-level domain, a first-generationdescendent of the naming universe. For domain resolution, the AIP consults the domain name service. Itpresents the co-located DNS with the fully qualified domainspecification: <domain>.<domain>. ... .<domain>The DNSs participating in a resolution resolve the concatenation fromthe right. The source endpoint DNS resolves the right-most simple nameand acts as a hub polling the other DNSs. It resolves the right-mostsimple name into an address for the DNS of the specified top-leveldomain, then polls that DNS with a request for further resolution. Whenpolled, a DNS resolves the next right-most simple domain name. Uponsuccessful resolution, an intermediate DNS may have a choice of eitherreturning the resulting address or forwarding the request to the nextDNS for continuing resolution.When a intermediate DNS receives a reply from the next DNS, it mustrespond to the request it has received. To simplify the domain nameservice protocol, an intermediate DNS is not allowed to act as a hub forfurther polling.2.3 Application Interface Addressing for destination endpoint domain is in general notsufficient for the source application process to establish directcommunication with the destination application process. In order toestablish direct communication, further addressing may be necessary.Addressing beyond destination endpoin domain may be necessary when theaddressing of application process cannot be derived from the address ofthe endpoint domain. To provide such derivation capability permanentbinding and universal binding convention, such as TCP port numberassignment, may be necessary. 3
RFC 830 October 1982 Beyond addressing, negotiation for resource availability andcompatibility is often found necessary. The application interfaceprovides a "what-can-you-do-for-me" negotiation capability between thesource and destination endpoint domains. Such negotiation mechanismsprovided in this design include those for the availability andcompatibility of transport service, e.g., TCP or UDP, and applicationservice, e.g., SMTP for mail transport. The availability of suchnegotiation service may allow dynamic binding and variations in systemdesign. The application interface offers an integrated service for various"what-can-you-do-for-me" negotiation capabilities.2.4 Example Let us assume that a request is made at ISID for remote filetransfer using NIFTP to SRI-TSC. The domain name for ISID isD.ISI.USC.ARPA,* and TSC.SRI.ARPA for SRI-TSC. The hierarchicalrelationship between these two domains is as depicted in Figure 3 below.The NIFTP process (an application process) at ISID forwards the domainname TSC.SRI.ARPA" to the local AIP in domain D for name service. TheAIP forwards the fully qualified domain name, "TSC.SRI.ARPA", to its co-located DNS for domain resolution. ARPA, the right-most simple name, is assumed to designate a top-level domain. The DNS of D recognizes this simple name, resolves itinto the address of the ARPA domain DNS, and forwards the request tothat DNS with a pointer pointing to the next domain "SRI". The ARPA DNSrecognizes "SRI" as one of its subdomains, resolves the address of thesubdomain's DNS. It has a choice at this point whether to return thisaddress to the source endpoint DNS or to forward the request to the DNSof SRI. naming universe / \ --- ARPA (DNS) / | / SRI (DNS) / | \ USC (DNS) TSC (DNS/AIP) | | | [TCP/FTP/RFT] ISI (DNS) | D (DNS/AIP) / \ [TCP/NIFTP/RFT] [TCP/FTP/RFT] | user--------------------* Domain names used in the examples are for illustration purposes only.The assignment of domain names is beyond the scope of this writeup. 4
RFC 830 October 1982If it returns the address, the source endpoint DNS at D, would continuepolling by forwarding the request to the SRI DNS. When the DNS of SRIdetects TSC as the last domain in the concatenation, it resolves theaddress for the DNS at TSC, and returns it to the source DNS at domainD. Upon receiving a successful domain resolution, the source DNS returnsthe obtained address to its associated AIP. Since the destination AIP is co-located at this address, the sourceAIP is able to forward a request with the service designation"TCP/NIFTP/RFT" for "what-can-you-do-for-me" negotiation. Realizingthat within TSC there is no NIFTP but FTP provided for remote filetransfer, the destination AIP would respond accordingly. Since ISIDalso offers FTP service, the "what-can-you-do-for-me" negotiation mayconclude successfully. The user request for file transfer may thus besatisfied. 3 SYSTEM COMPONENTS3.1 Component Processes The two basic distributed components of SINS are the endpoint DNSand the intermediate DNS. An endpoint DNS is associated with eachendpoint domain. An intermediate DNS is associated with a domainwithout any associated application process. The intermediate DNS is rather simple. It has the resolutioncapability for translating simple names of first-generation subdomainsto addresses of their associated DNS. It also communicates with otherDNS for domain resolution. An endpoint DNS consists of an AIP and a source DNS. The sourceDNS implements the polling mechanism which communicates with other DNSsas a hub for polling. It also has capability for the resolution of top-level domains. It responds to requests from the local AIP for domainresolution (Section 4.2.3). The major function of an AIP implements the intellegence of "what-can-you-do-for-me" negotiations. A communication module realizesnegotiation exchanges between the source and destination AIPs (Section4.2.2). As an interface between the application processes and the localDNS, it must also implement communication capabilities for exchangeswith the DNS and the application processes.3.2 Databases for Name Resolution There is a database associated with each resolution module. Thedatabase associated with an endpoint domain contains name-to-address 5
RFC 830 October 1982correspondences for the top-level domains, first-generation descendentsof the naming universe. It facilitates the endpoint DNS resolving theright-most simple name of a fully-qualified domain specification. The database associated with an intermediate domain contains name-to-address correspondences for the first-generation subdomains of thisdomain. Thus, the required database contents among the intermediate DNSdatabases are disjoint, and updates are local. It is also noticed that with the implementation of the SINS, thereis no need for database format standardization.3.3 Caching The component processes and resolution databases constitute thebasic System for Internet Name Service. The distributed components arerelated according to the domain hierarchy. The databases associatedwith the endpoint domains are all identical. Containing only name-to-address correspondence for top-level domains, the endpoint databaseshould be rather small in size. The disjoint nature of intermediate DNSdatabases allows easy local updates. However, communications will be very inefficient if the Internetname service is called for the establishment of every transaction. Astandard solution to aleviate such inefficiency is the use of caching. Caching is a mechanism reusing previous resolution results. Toexpedite establishment of communication, the resolution results arestored for future reference. We do not incorporate caching as astandard feature of the SINS. However, we assume the use of caching forefficient operations at individual implementor's discretion.4 INTER-COMPONENT COMMUNICATIONS (THE INTERNET NAME SERVICE PROTOCOLS) In this section, we present a format specification forcorrespondences between various component pairs. For co-locatedcomponents, communication becomes interprocess, and the exact formatless important. For inter-host communication, the format specificationhere defines a name service protocol. The communicating component pairs of concern here are applicationprocess/AIP, AIP/DNS, and AIP/AIP. The communications employrequest/response commands. A single command structure is adopted forall three pairs; while communications between a particular pair mayemploy a subset of the commands. Such uniformity allows minimumprocessing and maximum code sharing for implementation. 6
RFC 830 October 19824.1 Command Structure The basic command structure begins with two octets indicatingcommand type and the number of items in the command. They are followedby the indicated number of items. The type of an item is indicated inits first octet, followed by a one-octet content length, and then theitem content. Required presence or absence and order of the items foreach component pair are specified in this section. Command Type Number of Items Item Indicator Content Length Item Content . .Command Type This type coded in binary number indicates whether this command isa request, an affirmative response, or some other type of response (seeAppendix A for the command types and their corresponding code). Thistype specification implies the presence or absence and order of thefollowing items.Number of Items This number is expressed in binary number. It specifies the numberof following items. Owing to the possibility of a multiple response,this number may vary for a particular command.Item Indicator This indicator defines the item type. The possible types include:service, name, address, and comment. The type of an item implies itscontent structure.Content Length This length specification, in binary, indicates the length of thefollowing content in octets. The maximum can be specified is 255, thusthe maximum length of the content. However, this maximum may also beconstrained by the total length of the command (Section 4.3).Item Content The contents for different items are: Service -- Transport protocol/service protocol/service type (ASCII). (SeeAppendix A for standard identifiers for service specifications.) Name -- Whole or partial name string according to Internet Naming Convention [1] (ASCII). Address -- The address is presented in binary form. In this writeup, double quotes, " ", are used around decimal values separated by a space to represent octets of the binary form. 7
RFC 830 October 1982 Parsing of the address is implied by the specified transport protocol. In the case of TCP, the first four octets gives the 32-bit IP address, the 5th octet the IP-specific protocol number, and the 6th the TCP or UDP port number for the application service. Comment -- The item is mostly optional. Its presence may allow an intermediate server passing comment to the end user. Error comments explaining resolution failure is an example of its use.4.2 Command Specification In this section, we define the name service commands for thevarious communication pairs.4.2.1 Application Process/AIP Communication From the name service point of view, there is no need forcommunication between the AIP and an application process at thedestination. Thus, here we discuss communications at the originatingdomain. An application process initiates a dialogue by making a request forname service to its local AIP. It provides the requested applicationservice and a destination name for resolution.REQUEST Command Type Number of Items Service Indicator Length Transport Protocol/Service/Service Type Name Indicator Name Length Name StringExamples: 1 2 3 13 TCP/SMTP/mail 1 21 Postel@F.ISI.USC.ARPA 1 2 3 13 TCP/NIFTP/RFT 1 12 TSC.SRI.ARPA The first example is a resolution request for the name"Postel@F.ISI.USC.ARPA". It is 21 octets in length. The requestedapplication service is TCP/SMTP/mail. The second example is aresolution request for application service NIFTP at TSC.SRI.ARPA. 8
RFC 830 October 1982AFFIRMATIVE RESPONSE Command Type Number of Items Service Indicator Length Transport Protocol/Service/Service Type Name Indicator Name Length Name String Address Indicator Address Length AddressExamples: 2 3 3 13 TCP/SMTP/mail 1 21 Postel@F.ISI.USC.ARPA 2 6 "10 2 0 52 6 25" 2 4 3 13 TCP/NIFTP/RFT 1 12 TSC.SRI.ARPA 2 6 "10 3 0 2 6 47" 2 6 "39 0 0 5 6 47" An affirmative response implies that the destination offers therequested service. The parsing of an address is implied by theindicated transport protocol. In the first example, the transportprotocol is TCP. Thus, the address is composed of three fields: theinternet address ("10 2 0 52"), the protocol number ("6" for TCP [3]),and the port number ("25" for SMTP [3]). A multiple-address response inthe second example indicates that TSC is multi-homed via both ARPANET(net 10), and SRINET (net 39). A multiple-resolution response ispreferred. It offers the source a choice.NEGATIVE RESPONSE Command Type Number of Items Service Indicator Length Transport Protocol/Service/Service Type Name Indicator Name Length Name String Name Indicator Name Length Partial Name String [Comment Indicator Comment Length Comment] This indicates difficulty in resolution. Returned with thiscommand is the left-most portion of the specified name including thedifficulty encountered. An optional comment item may be included. 9
RFC 830 October 1982Examples: 3 4 3 13 TCP/SMTP/mail 1 16 Postel@F.ISI.USC 1 16 Postel@F.ISI.USC 9 18 Resolution Failure 3 4 3 13 TCP/NIFTP/RFT 1 13 TSC..SRI.ARPA 1 5 TSC.. 9 17 Syntactic AnomalyIn the first example, the resolution failed because USC is not top-leveldomain. The syntactic error of adajacent dots in the second example isobvious.INCOMPATIBLE SERVICE This response indicates no compatible application and/or transportservice is available at the destination. For example, the requestedapplication service may be SMTP, while only FTP-mail is available at thedestination. Return with this command is the available correspondingavailable service, if any, and its address. If no service is availablefor that service type, an empty string for service specification isreturned. Command Type Number of Items Service Indicator Length Transport Protocol/Service/Service Type Name Indicator Name Length Name String Service Indicator Length Transport Protocol/Service/Service Type [Address Indicator Address Length Address]Examples: 9 3 3 14 TCP/NIFTP/mail 1 21 Postel@F.ISI.USC.ARPA 3 0 9 5 3 13 TCP/NIFTP/RFT 1 12 TSC.SRI.ARPA 3 11 TCP/FTP/RFT 2 6 "10 3 0 2 6 21" 2 6 "39 0 0 5 6 21" 10
RFC 830 October 19824.2.2 AIP/AIP Communication Communication between the AIPs accomplishes the "what-can-you-do-for-me" negotiation. Examples in this section correspond to those ofSection 4.2.1.REQUEST Command Type Number of Items Service Indicator Length Transport Protocol/Service/Service TypeExamples: 1 1 3 13 TCP/SMTP/mail 1 1 3 13 TCP/NIFTP/RFTAFFIRMATIVE RESPONSE Command Type Number of Items Service Indicator Length Transport Protocol/Service/Service Type Address Indicator Address Length AddressExamples: 2 2 3 13 TCP/SMTP/mail 2 6 "10 2 0 52 6 25" 2 3 3 14 TCP/NIFTP/RFT 2 6 "10 3 0 2 6 47" 2 6 "39 0 0 5 6 47" An affirmative response implies that the destination offers thesame service as that of the originator. A multi-resolution response ispossible. The parsing of an address is implied by the indicatedtransport protocol. In the second example, the transport protocol isTCP. Thus, the address is composed of three fields: the internetaddress (10 2 0 52), the protocol number (6 for TCP), and the portnumber (25 for SMTP). The returned address(es) is to be relayed to theoriginating application process. 11
RFC 830 October 1982INCOMPATIBLE SERVICE Command Type Number of Items Service Indicator Length Transport Protocol/Service/Service Type Service Indicator Length Transport Protocol/Service/Service Type Address Indicator Address Length Address This response indicates no compatible application and/or transportservice available serving the destination. For example, SMTP may be therequested application service, while only NIFTP-mail is availableserving the destination. Return with this command is the availableservice of that type. If no service available for that service type, aempty text string is returned.Examples: 9 2 3 14 TCP/NIFTP/mail 3 0 9 4 3 13 TCP/NIFTP/RFT 3 11 TCP/FTP/RFT 2 6 "10 3 0 2 6 21" 2 6 "39 0 0 5 6 21"In the first example, the destination does not offer any kind of mailservice. The second example indicates that there is no NIFTP, but FTPavailable for remote file transfer service at the destination.4.2.3 AIP/DNS Communication The source AIP presents its associated DNS with a fully qualifieddomain specification for resolution. The expected resolution result isthe network address for the destination endpoint DNS. We assume no needfor communication between the DNS and AIP at the destination.REQUEST Command Type Number of Items Name Indicator Name Length Name StringExamples: 1 1 1 14 F.ISI.USC.ARPA 1 1 1 12 TSC.SRI.ARPA 12
RFC 830 October 1982AFFIRMATIVE RESPONSE Command Type Number of Items Name Indicator Name Length Name String Service Indicator Service Length Transport Protocol Address Indicator Address Length AddressExamples: 2 3 1 14 F.ISI.USC.ARPA 3 3 UDP 2 6 "10 2 0 52 17 42" 2 4 1 7 TSC.SRI.ARPA 3 3 UDP 2 6 "10 3 0 2 17 42" 2 6 "39 0 0 5 17 42"An affirmative response returns an address of the destination endpointDNS. This returned address is that of the destination DNS. Thedestination transport service needs to be indicated for guiding theparsing of the destination address.NEGATIVE RESPONSE Command Type Number of Items Name Indicator Name Length Name String Name Indicator Name Length Partial Name String [Comment Indicator Comment Length Comment] This response indicates that the domain name service is unable toresolve the given destination domain name. It could be caused by anunknown simple name, which may result from, for example, misspelling.Returned with this command is the left-most portion of the specifiedname 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 19824.2.4 DNS/DNS Communication The domain name service is an application independent networkservice. It provides the resolution of domain names. For thespecification of this service the reader is referred to [2].4.3 Transport Protocol For generality, this specification is intentionally transportprotocol independent. Implications for the use of TCP and UDP arespecifically considered. Typically, for distributed name service a server A makes a requestto a server B, server B may need to in turn contact other servers tocomplete a resolution. TCP is a connection-oriented protocol. Itoffers reliable transport, but also imposes certain amount of overheadfor connection establishment and maintenance. For most cases, the useof TCP is not recommended. UDP is a datagram service offering a transport capacity perdatagram in excess of 500 octets. Such capacity should suffice mostconceivable commands within this specification. However, it does imposea limit on the total length of a command. In order to enhancereliability, the request is incorporated as part of every responsecommand. 5 NCP TO TCP TRANSITION The Internet Naming Convention, "<user>@<domain>. ... . <domain>"[1], is a generalization of "<user>@<host>", the ARPANET NamingConvention. It is a generalization in the sense that the ARPANET NamingConvention can be considered as a partially qualified form of the subset"<user>@<host>.ARPANET". (We assume here ARPANET is a top-level domainname.) For the transition from NCP to TCP, we may initially treat eachhost name entry in the current host table as a subdomain of the top-level domain ARPANET. Thus, initially there would be a very flat domainstructure. This structure can be gradually changed after the transitiontoward a hierarchical structure when more and more domains andsubdomains are defined and name servers installed. In the process ofthis change, the host table would be gradually converted intodistributed domain tables (databases). For the newly created domaintables, no standard format would be required. Each individual domaintable may have its own format suitable to the design of its associateddomain name server. 14
RFC 830 October 1982REFERENCES[1] Su, Z. and J. Postel, "The Domain Naming Convention for InternetUser Applications,"RFC 819, SRI International (August 1982).[2] Postel, J., "Domains Name Server," RFC XXX, USC/InformationSciences Institute (to appear).[3] Postel, J., "Assigned Numbers,"RFC 790, USC/Information SciencesInstitute (September 1981). 15
RFC 830 October 1982Appendix A CONVENTION ASSIGNMENTS Command Types Request 1 Affirmative Response 2 Negative Response 3 Imcompatible Service 9 INDICATORS Name Indicator 1 Address Indicator 2 Service Indicator 3 Comment Indicator 9 TRANSPORT PROTOCOLS: TCP, UDP, NCP SERVICES Service Protocols Service Type MTP mail SMTP mail FTP (FTP mail) mail NIFTP (NIFTP mail) mail MMDF mail FTP RFT (remote file transfer) Telnet RTA (remote terminal access) 16
[8]ページ先頭