Académique Documents
Professionnel Documents
Culture Documents
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
1 INTRODUCTION
2 OVERVIEW
1
RFC 830 October 1982
name servers (DNSs). With each domain is associated a DNS.* The reader
is referred to [2] for the specification of a domain name server. As
noted in [1], 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.
Application Application
Process Process
| |
SINS | |
-------|---------------------------------------------|----- Application
| AIP AIP | Interface
| | | | . . . . . . .
| DNS - - - DNS - - - DNS - - . . . - - DNS | Domain Name
----------------------------------------------------------- Service
Application Application
Process Process
| |
SINS | |
-------|---------------------------------------------|-------
| Endpoint Endpoint |
| DNS - - - DNS - - - DNS - - . . . - - DNS |
| |
-------------------------------------------------------------
--------------------
* For reasons such as reliability, more than one DNS per domain may be
required. They may be cooperating DNSs or identical for redundancy. In
either case, without loss of generality we may logically view the
association as one DNS per domain.
2
RFC 830 October 1982
For domain resolution, the AIP consults the domain name service. It
presents the co-located DNS with the fully qualified domain
specification:
2.4 Example
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 1982
3 SYSTEM COMPONENTS
The two basic distributed components of SINS are the endpoint DNS
and the intermediate DNS. An endpoint DNS is associated with each
endpoint domain. An intermediate DNS is associated with a domain
without any associated application process.
5
RFC 830 October 1982
3.3 Caching
Command Type
Number of Items
Item Indicator
This indicator defines the item type. The possible types include:
service, name, address, and comment. The type of an item implies its
content structure.
Content Length
Item Content
REQUEST
Examples:
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
AFFIRMATIVE RESPONSE
Examples:
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"
NEGATIVE RESPONSE
9
RFC 830 October 1982
Examples:
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 Anomaly
In the first example, the resolution failed because USC is not top-level
domain. The syntactic error of adajacent dots in the second example is
obvious.
INCOMPATIBLE SERVICE
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 1982
REQUEST
Examples:
1 1
3 13 TCP/SMTP/mail
1 1
3 13 TCP/NIFTP/RFT
AFFIRMATIVE RESPONSE
Examples:
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"
INCOMPATIBLE SERVICE
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 mail
service. The second example indicates that there is no NIFTP, but FTP
available for remote file transfer service at the destination.
The source AIP presents its associated DNS with a fully qualified
domain specification for resolution. The expected resolution result is
the network address for the destination endpoint DNS. We assume no need
for communication between the DNS and AIP at the destination.
REQUEST
Examples:
1 1
1 14 F.ISI.USC.ARPA
1 1
1 12 TSC.SRI.ARPA
12
RFC 830 October 1982
AFFIRMATIVE RESPONSE
Examples:
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"
NEGATIVE RESPONSE
Example:
1 3
1 9 F.ISI.USC
1 9 F.ISI.USC
9 18 Resolution Failure
13
RFC 830 October 1982
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).
15
RFC 830 October 1982
Appendix 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
SERVICES
MTP mail
SMTP mail
FTP (FTP mail) mail
NIFTP (NIFTP mail) mail
MMDF mail
16