📄 rfc897.txt
字号:
Network Working Group Jon Postel
Request for Comments: 897 ISI
February 1984
Updates: RFC 881
Domain Name System Implementation Schedule
Status of this Memo
This memo is a policy statement on the implementation of the Domain
Style Naming System in the Internet. This memo is a partial update
of RFC 881. This is an official policy statement of the ICCB and the
DARPA.
The intent of this memo is to detail the schedule for the
implementation for the Domain Style Naming System. The explanation
of how this system works is to be found in the references.
The Current Situation
Simple Names
Hosts in the ARPA research and DDN operational communities are
currently assigned names in a flat or global name space of
character strings. There are some limits on these names. They
must start with a letter, end with a letter or digit and have only
letters or digits or hyphen as interior characters. Case is not
significant.
For example: USC-ISIF
Tables
Every host in the Internet is expected to have a way of
translating the name of any other host into its Internet address.
By and large, the name to address translation is done by looking
up the information in a table of all hosts.
The maintenance of this table is centralized at the Network
Information Center (NIC). Each host is expected to obtain a
current copy of the table on a timely basis.
Interface to the World
A great deal of mail moves between the Internet and other
"systems" that somehow transport mail among computers. This is
currently done by hiding some sort of "other-system" addressing
information in the local-part of the mail address and using a
mail-relay host in the host-part of the mailbox.
Postel [Page 1]
RFC 897 February 1984
Domain Implementation Schedule
For example,
OBERST%EDUCOM.MAILNET@MIT-MULTICS
EDMISTON.CIC@CSNET-RELAY
The Future Situation
Hierarchical Names
Because of the growth of the Internet, structured names (or domain
style names) will be used. Each element of the structured name
will be a character string (with the same constraints that
previously applied to the simple names).
For example: F.ISI.USC.ARPA
Servers
Every host in the Internet will be expected to have a way of
translating the name of any other host into its Internet address.
By and large, the name to address translation will be done by
interacting with a service. There will be a number of servers
that each hold a portion of the name to address information.
The maintenance of the translation data will be subdivided and
distributed.
There are several stages of implementation for the servers and
several levels of development for use of the domain style names.
First, there is the simple substitution of the domain style names
for the current host names, and the subdivision of these into
several domains. At this stage all domain style names directly
translate to host addresses and all domain style names have two
components.
For example: USC-ISIF.ARPA or USC-ISIA.DDN
and: Postel@USC-ISIF.ARPA or Kahn@USC-ISIA.DDN
Here we expect that "USC-ISIF.ARPA" is the name of an Internet
host and that we can send mail for "Postel" to the SMTP port on
that host. It may be that some backward host can still fake it
by ignoring the ".ARPA" and looking up an address for
"USC-ISIF".
Postel [Page 2]
RFC 897 February 1984
Domain Implementation Schedule
Using the domain name servers (but not the tables) mail
forwarding may be supported. A domain name server query can
say "I want to send mail to ABCDEF.ARPA". The response might
be "to send mail to ABCDEF.ARPA send it to the mail relay
GHIJKL.ARPA at address 123.123.123.123".
Second, there is an extension to more name components.
For example: F.ISI.USC.ARPA or A.USC-ISI.DDN
and: Postel@F.ISI.USC.ARPA or Kahn@A.USC-ISI.DDN
Here we expect that "F.ISI.USC.ARPA" is the name of an Internet
host and that we can send mail for "Postel" to the SMTP port on
that host. It is unlikely that a backward host can hack this
at all.
Third, there is an extension to domain style names that may
represent only organizations or administrative entities. Finding
a host that represents such entities may require a level of
indirection in the search.
For example: USC-ISI.ARPA or ARPA.DDN
and: Postel@USC-ISI.ARPA or Kahn@ARPA.DDN
Here we don't count on "USC-ISI.ARPA" being the name of an
Internet host. When we want to send mail to "Postel" we ask
the domain name server about sending mail to "USC-ISI.ARPA".
The server will tell us the name (and address) of a real
Internet host that handles mail on this organizations behalf,
for example, "F.USC-ISI.ARPA = 10.2.0.52". We then send mail
for "Postel" to the SMTP port on F.USC-ISI.ARPA.
Interface to the World
Mail will continue to move between the Internet and other
"systems". This may be done by designating some sort of
"other-system" representative organization in the domain server
data bases that can indirect mail to a mail-relay host.
For example,
OBERST@EDUCOM.MAILNET
EDMISTON@CIC.CSNET
Postel [Page 3]
RFC 897 February 1984
Domain Implementation Schedule
The Transition Situation
Actually, the situation is a bit more complicated, of course. A
number of hosts are already using domain style names under the
constraint that their domain style name is exactly their old style
name with the string ".ARPA" appended. The first transition step is
to have all hosts do this, and then to eliminate the user of old
style names altogether.
Please note carefully that two types of changes are being made:
One is a change in the support mechanism for translating a host
name to an internet address,
that is from using local copies of a full centrally maintained
table to dynamically accessing a distributed set of servers
each posesing a portion of a data base maintained in a
distributed fashion.
The other is a change in the host names themselves,
from a flat global space of unstructured strings to a
hierarchical structure of names.
There are four steps to the transition plan.
First, change from old names to domain style names.
host-name --> host-name.ARPA
Second, one domain to a few domains.
host-name.ARPA --> host-name.ARPA and host-name.DDN
Third, change from using central tables to using name servers.
Fourth, allow many domains.
There are two communities that are taking slightly different courses
in this transition. The ARPA research community is making the full
transition. The DDN operational community is making the change in
naming on the same schedule, but is not requiring hosts in the DDN
operational community make the change to using servers at the same
time (they can if they want to). The DDN PMO will establish a
schedule for that change at a later time. The NIC will maintain a
central table of all DDN operational hosts.
Postel [Page 4]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -