![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to adr-1 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / doc / csnet|
Return to adr-1 CVS log | Up to [Research Unix] / researchv10dc / doc / csnet |
1.1 root 1: From research!mtune!rutgers!SH.CS.NET!cic Wed Sep 30 00:55:41 1987
2: Received: by mtune.ATT.COM (smail2.5)
3: id AA19906; 30 Sep 87 00:55:41 EDT (Wed)
4: Received: by RUTGERS.EDU (5.54/1.14)
5: id AA19128; Tue, 29 Sep 87 18:14:44 EDT
6: Message-Id: <[email protected]>
7: Received: by SH.CS.NET id ac10308; 29 Sep 87 15:25 EDT
8: Date: Tue, 29 Sep 87 14:24:40 EDT
9: Subject: adr-1 CSNET ADDRESSES
10: Reply-To: rutgers!SH.CS.NET!cic
11: From: CSNET INFO SERVER <rutgers!SH.CS.NET!info>
12: To: [email protected]
13:
14: Request: info
15: Topic: adr-1
16: Document Updated: 1 Jun 87
17: Subject: CSNET Addresses and the Domain System
18: ==============================================================================
19: CSNET Coordination and Information Center (CIC) Hotline: 617/497-2777
20: 10 Moulton Street Email: [email protected]
21: Cambridge, MA 02238 Info-Server requests to: [email protected]
22: ==============================================================================
23:
24: CSNET ADDRESSES AND THE DOMAIN SYSTEM
25:
26: In July 1986, the CSNET CIC instituted a new policy of assigning a
27: domain-style name to each new CSNET PhoneNet site before the site begins
28: to send messages on PhoneNet. This starts the site off right, with a
29: name that conforms to the DDN Domain Naming System , and avoids the pain
30: of changing names in the future.
31:
32: Assigning a domain name involves registering a second-level domain name
33: with the Network Information Center (NIC) of the Defense Data Network
34: (DDN). The CSNET CIC has arranged with the DDN NIC to take care of the
35: registration process for organizations that are members of the CSNET
36: PhoneNet. In a companion document, "adr-2 Transition to Domains",
37: CSNET-FORUM v2 #6 (23 May 86), we explained how to choose a domain name
38: and register with the NIC. In this article, we talk about the
39: background of the domain naming system.
40:
41: The DDN is composed of the ARPANET, an experimental research and
42: development network, and the MILNET, an operational military network.
43: The Internet is composed of the DDN, plus other networks that share the
44: same protocols, including the CSNET X25Net. CSNET PhoneNet sites are
45: not part of the Internet, but they can exchange electronic messages with
46: the Internet through a "gateway" on RELAY.CS.NET (also known as
47: CSNET-RELAY.ARPA). This is the same host that also connects PhoneNet
48: sites to each other, and to other networks, public and private, that
49: have gateways on CSNET PhoneNet sites.
50:
51: The domain naming scheme represents an important step in making all
52: these networks easier to use and allowing them to expand in the future.
53:
54: In the past, the addressing scheme used by the DDN was based upon
55: individual host computers. As spelled out in RFC733 (the ARPANET
56: standard for text messages adopted in 1977), and in earlier standards,
57: the basic pattern for an ARPANET address was:
58:
59: user@host
60:
61: On the ARPANET, the hostnames must be translated into network numbers
62: before the mail delivery programs can make connections between hosts.
63: The original system stored the machine addresses with the host names in
64: a host table. The NIC Host Table was distributed by the DDN NIC to all
65: hosts on the network.
66:
67: The RFC733 system was firmly based on hardware. If a single
68: organization had multiple host computers on the ARPANET, all of the
69: hosts had to be registered with the Network Information Center of the
70: DDN (NIC) and entered in the NIC Host Table. But if there were hosts
71: that were not on the ARPANET themselves, but could be reached through an
72: ARPANET host, the NIC Host Table could not handle them. It was up to
73: the person sending the messages to spell out the route explicitly in the
74: mailing address.
75:
76: RFC733 did not, however, specify the rules for addressing messages to
77: hosts on other networks. The address form 'user%host1@host2', was
78: generally used on the CSNET PhoneNet and other networks associated with
79: the ARPANET, but was never adopted as a network standard, although the
80: current network standard allows it (as one of many possible options). Some
81: networks that gatewayed to the ARPANET used somewhat different rules,
82: which were also acceptable.
83:
84: The new domain system is quite different. It is based on RFC822, which
85: was adopted in 1983. RFC822 specifies a system of names, not physical
86: addresses. It sets up a domain, corresponding to an organizational
87: unit, not the physical hardware, as the basic unit of the name. All
88: users at the same organization have addresses in the same domain,
89: regardless of the hardware they use or the network or route that
90: delivers their messages.
91:
92: This means that only one name, the domain name for the organization,
93: must be registered with the NIC. Names below the level of the
94: organization as a whole are left up to the organizations to manage. The
95: responsibility for keeping track of the names and locations of host
96: computers is thus delegated, and information is no longer centralized at
97: the DDN NIC. Eventually, when the domain system is fully implemented,
98: the NIC will discontinue the NIC Host Table altogether.
99:
100: Distributed responsibility for names requires a distributed database.
101: Domain names must still be translated into network numbers and routes
102: between hosts, but this information is no longer kept in one place.
103: Instead, it is split up and stored on different Internet host computers
104: in dynamic database programs called "domain servers". When an Internet
105: host is about to send a message, it no longer checks its own copy of the
106: NIC Host Table for the recipient host. Instead, it queries other
107: Internet hosts, over real-time connections, to determine which Internet
108: host runs the domain server that stores the routing information for the
109: recipient's domain. The sending host then retrieves the routing
110: information, and routes the message to its destination (or at least to
111: the next Internet host along its route).
112:
113: CSNET PhoneNet sites cannot run their own domain servers, since they do
114: not have direct real-time access to the Internet; instead, they must
115: arrange with other hosts that are on the Internet to perform this
116: function. The CSNET CIC runs a domain server on RELAY.CS.NET, with a
117: backup on SH.CS.NET, and offers to be the domain server for any PhoneNet
118: site that needs this service.
119:
120: Domain names are organized in a hierarchical tree structure. At the top
121: is a set of top-level domain names chosen and administered by the DDN
122: NIC. The top-level domains for the United States represent classes of
123: organizations:
124:
125: COM Commercial organizations MIL Department of Defense
126: EDU Educational organizations NET Administrative organizations
127: GOV Civilian government for networks, e.g., CSNET.
128: ORG Nonprofit organizations ARPA Temporary top-level domain,
129:
130: Non-US countries have their own top-level domains, named for the
131: 2-letter country codes of the International Standards Organization
132: (ISO standard 3166). The DDN NIC has announces country domains, as they
133: are registered.
134:
135: Second-level domains represent individual organizations. Hypothetical
136: examples of domains for organizations might be:
137:
138: OXBRIDGE.EDU Oxbridge University
139: WIDGETS.COM Widgets Mfg. Co., Inc.
140: THINKTANK.ORG The Thinktank Institute
141:
142: Each new CSNET organization forms its domain name by selecting the
143: appropriate top-level domain, and choosing a second-level domain. The
144: CSNET CIC checks the combination to make sure that it is unique.
145:
146: Once an organization has been registered as a second-level domain, it
147: may freely create lower-level domains, according to its needs.
148:
149: The pattern for an electronic mail address is:
150:
151: local-part@domain
152:
153: The "local-part" is ideally a simple username, but RFC822 allows any
154: string in the local part (to the left of the @), so long as it can be
155: interpreted by the machine that takes the responsibility for
156: interpreting the complete "domain" (to the right of the @).
157:
158: The domain is a string of words separated by periods. Lower-level
159: domains are arranged left to right, in ascending order, ending with a
160: top-level domain. Any number of lower-level domains may be used.
161:
162: A domain may represent a subdivision of an organization (at any level),
163: or an individual host computer.
164:
165: Examples of addresses might be:
166:
167: [email protected] oxbridge.edu either has no subdomains,
168: or hides its subdomains from the
169: outside world.
170: [email protected] Engineering Dept within oxbridge.edu.
171: [email protected] AI project in the Computer Science
172: Department
173: [email protected] Workstation in the Campus Computer
174: Center.
175:
176: The transition to domains is not yet complete. Some Internet hosts are
177: not yet running domain servers, and some have not yet made the switch
178: from the temporary ".arpa" domain to the full domain naming scheme.
179:
180: The CSNET relay, originally CSNET-RELAY, then CSNET-RELAY.ARPA, and now
181: RELAY.CS.NET, rewrites all CSNET PhoneNet addresses to include the
182: relay's name when the message is destined for the Internet:
183:
184: From: @RELAY.CS.NET:[email protected]
185:
186: Later, when all Internet hosts have domain servers, and are able to
187: recognize all domain names, whether or not they are on the Internet,
188: the address will change to:
189:
190: From: [email protected]
191:
192:
193: THE RFC822 ROUTING ADDRESS
194:
195: For a long time, even after the RFC822 conventions were formally
196: adopted for use on the Internet, the most common method of writing the
197: routing address was the "%" notation:
198:
199: user%[email protected]
200:
201: However, this type of routing address is an informal convention,
202: and is not specified in any official RFC or other Internet document.
203: The routing address specified in RFC822 is of the form:
204:
205: @relay.cs.net:[email protected]
206:
207: This is the form that relay.cs.net uses for messages that are sent
208: from CSNET PhoneNet sites to Internet hosts.
209:
210: You will also see routing addresses for CSNET PhoneNet sites with
211: domain-style names. The reason is that there are still some Internet
212: hosts that cannot handle domain server entries for off-Internet hosts.
213:
214: @relay.cs.net:[email protected]
215:
216: Other examples of RFC822 routing addresses are:
217:
218: @wiscvm.wisc.edu:[email protected]
219: @seismo.css.gov:[email protected]
220:
221: It is possible for a routing address to route through multiple hosts:
222:
223: @elsewhere.com,@nowhere.edu,@relay.cs.net:[email protected]
224:
225: REFERENCES (Available from the CSNET Info Server):
226:
227: RFC733 "Standard for the Format of ARPA Network Text Messages", David H.
228: Crocker (The Rand Corporation), John J. Vittal (Bolt Beranek and
229: Newman Inc.), Kenneth T. Pogran (Massachusetts Institute of
230: Technology), D. Austin Henderson, Jr.(Bolt Beranek and Newman Inc.) 21
231: November 1977.
232:
233: RFC822 "Standard for the Format of ARPA Internet Text Messages", David H.
234: Crocker (University of Delaware), August 1982.
235:
236: RFC882 "Domain Names - Concepts and Facilities", P. Mockapetris
237: (Information Sciences Institute, University of Southern California),
238: November 1983.
239:
240: RFC883 "Domain Names - Implementation and Specification", P. Mockapetris
241: (Information Sciences Institute, University of Southern California),
242: November 1983.
243:
244: RFC920 "Domain Requirements", J. Postel and J. Reynolds (Information
245: Sciences Institute, University of Southern California), October 1984.
246:
247: RFC921 "Domain Names System Implementation Schedule - Revised", Jon Postel
248: (Information Sciences Institute, University of Southern California),
249: October 1984.
250:
251: RFC973 "Domain System Changes and Observations", Paul Mockapetris
252: (Information Sciences Institute, University of Southern California),
253: January 1983. Supplements RFC 883.
254:
255: RFC974 "Mail Routing and the Domain System", Craig Partridge (CSNET CIC,
256: BBN Laboratories, Inc.), January 1986.
257:
258: -----------
259:
260: This article appeared in CSNET-FORUM v2 #8 (8 Aug 86) with the title
261: "Background on the Domain Naming System".
262:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.