As per Relevance of the word community, we have this rfc below:
Network Working Group J.
Request for Comments: 881
November 1983
The Domain Names Plan and
This RFC outlines a plan and schedule for the implementation of
style names throughout the DDN/ARPA Internet community.
introduction of domain style names will impact all hosts on the DDN/
Internet
The
Domain style names are being introduced in the Internet to allow
controlled delegation of the authority and responsibility
adding hosts to the system. This also allows a subdivision of
task of maintaining information about hosts
The subdivision will be based on administrative authority
organization boundaries (not necessarily network boundaries).
Certain requirements will be placed on organizations wishing to
"top level" domains. Initially, all the hosts in the
will be in the domain "ARPA". As soon as is practical a
domain, "DDN", will be introduced. Other domains may be
after that, provided the requirements listed below are met
Domain names will be supported in the long run by a system
special servers called "domain servers" which will be used
translate names to addresses. While this system of domain
is being created and programs are being converted to use them,
existing host tables will evolve to include domain style names
The domain server design also provides for mapping
addresses to the host name of the mail server for that mailbox
This feature allows mailboxes to be related to an
rather than to a specific host
This plan will be implemented in the ARPA community. After
domain system is demonstrated in the ARPA community, the
Program Management Office (DDN-PMO) will determine the
for implementation of the domain system in the DDN community
This approach will cause some extra steps in the ARPA
implementation, and may limit communication between the ARPA
DDN communities in some ways. The details and implications
this two phase approach are discussed more fully below
Postel [Page 1]
RFC 881 November 1983
The Domain Names Plan and Schedule
A Catch 22
There is a problem in introducing domain style names: a great
of software has to be changed. Some groups would like to
using domain style names right away, and other groups don't
to see them or use them for a very long time.
patterns are very complex and as soon as domain style names
allowed and used by a few groups they will start showing up
everywhere. This argues that everyone should be prepared for
before they are used at all. However, we know that with
being people and with so many of people involved, the
of everyone being ready in any reasonable time period is
zero. The way out of this situation is to set up a
schedule for experimenting with domain style names and
their use. People that get ready on schedule should have
problems with these names
Evolution of the
Nearly all the hosts in the Internet now use some form of
table based on the master file "HOSTS.TXT" maintained by
Network Information Center (NIC).
One way to introduce domain style names is to add to the
in this table names in the domain style. In particular, make
first name in each entry the official host name in the
domain
For example, the current entry for USC-ISIF is
HOST : 10.2.0.52 : USC-ISIF,ISIF : DEC-1090T : TOPS20 :
TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :
This could become
HOST : 10.2.0.52 : USC-ISIF.ARPA,USC-ISIF,ISIF : DEC-1090T :
TOPS20 : TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,UDP/TFTP :
For some hosts and programs this could be done today with
disruptions, but for others substantial problems could occur.
example, with over five hundred entries in the table the
of 500 names could exceed the space allocated to store the
in some programs. (One could argue that these programs are
to blow up soon anyway as new host entries are added to
table.) Another problem is that period (or dot, ".") is not now
legal character in host names and some programs may not be able
parse these new names
Postel [Page 2]
RFC 881 November 1983
The Domain Names Plan and Schedule
The plan is to make such a domain style name table available
parallel with the regular table for a few months, then to
the regular table with this domain style table. The dates
these changes is given in the schedule below
So far, no new domains have been introduced. Only a table
all the entries having official names in the ARPA domain has
provided. This should allow programs to be constructed to
with domain style names in a general way without any special
to add or delete the string ".ARPA" to or from host names
The introduction of new domains is tied to the provision of
servers by those domains. As new domains meet the
and are authorized they will also be added to the host table.
new domains will be added before master table is converted to
domain style entries
In the long run the Internet will become too complex and
too fast to keep a master table of all the hosts. At some
the master table will be reduced to simply the entries for
domain servers for the top level domains. By this time all
translation of host names into addresses should take place
consulting domain servers
Conversion to
As soon as domain servers become available programs should
converted to use them to translate names into addresses.
details of these procedures are given in RFCs 882 and 883.
The general idea is that a host no longer keeps a complete
table but rather makes a request on the domain server each time
name must be translated to an address. The code module in
host that implements the protocol to do this is called
"resolver". The resolver may keep a cache of recently
names and addresses for improved performance
Many hosts have a library function or system call that is used
access the host table to translate names to addresses. It
to be possible to replace this function or call with the
module such that most programs would not know which method
used to accomplish the name to address translation
Postel [Page 3]
RFC 881 November 1983
The Domain Names Plan and Schedule
Requirements on a
There are several requirements that must be met to establish
domain. In general it must be responsibly managed. There must
a responsible person to serve as a coordinator for domain
questions, there must be a robust name service, it must be of
least a minimum size, and the domain must be registered with
central domain administrator
Responsible Person
An individual must be identified who has authority for
administration of the names within the domain, and who
responsibility for the behavior of the hosts in the domain
their interactions with hosts outside the domain
The operation of a name server should not be taken on lightly
There are some difficult problems in providing an
service, primarily the problems in keeping the data base up
date, and keeping the service operating
If some host in a domain somehow misbehaves in
with hosts outside the domain (e.g., consistently
protocols), the responsible person for the domain must be
to take action to eliminate the problem
Domain Servers
A robust and reliable domain service must be provided. One
of meeting this requirement is to provide at least
independent domain servers for the domain. The data base can
of course, be the same. The database can be prepared
copied to each domain server. But, the servers should be
separate machines on independent power supplies, et cetera
basically as physically independent as can be and yet in
same domain. They should have no common point of failure
One of the difficult problems in operating a domain server
the acquisition and maintenance of the data. In this case
data is the host names and addresses. In some
this information changes fairly rapidly and keeping up-to-
data may be difficult. This is one motivation for sub-domains
One may wish to create sub-domains until the rate of change
the data in a sub-domain domain server data base is
managed
The concepts and implementation details of the domain
are given in RFCs 882 and 883.
Postel [Page 4]
RFC 881 November 1983
The Domain Names Plan and Schedule
Minimum Size
The domain must be of at least a minimum size.
measures of size may be used in combination in making
test. Measures may include: (a) the number of host
in the domain, (b) the number of people with primary
in the domain, (c) the amount of traffic that crosses
boundary of the domain [packets/day or mail items/week].
Specific threshold values for these measures will
established before new domains are authorized
There is no requirement to form a domain because some set
hosts is above the minimum size
Registration
The administrator must register the domain with the
authority. The central authority must be satisfied that
requirements are met before authorization for the domain
granted
The administrator of a domain is required to make sure
host and sub-domain names within that jurisdiction conform
the standard name conventions and are unique with in
domain
If sub-domains are set up the administrator may wish to
along some of his authority and responsibility to a sub-
administrator
Mailbox
The design of the domain servers provides two levels of
for mail
The first, called "agent binding", is that the right hand part
the typical mail box (Y in X@Y) can be mapped a host that
either accept the mail as the destination or accept the mail
forwarding
The second, called "mailbox binding", is to map the entire
(X@Y) to a destination (this mechanism can also support
mailing list functions).
Agent binding can be used to establish mailboxes that are based
an organization name rather than a host name
For example, an organization, "BLAT", with hosts "BLAT-20"
Postel [Page 5]
RFC 881 November 1983
The Domain Names Plan and Schedule
"BLAT-VAX" in the ARPA domain could set up mailboxes of
form "user@BLAT.ARPA" and use the domain server mechanisms
mapping these to the host that accepts the mail for
organization
Mailbox binding will allow different mappings for
mailboxes of an organization or host to the destination host.
will also provide for aliases and mailing groups
Mailbox binding requires adding information on
mailboxes to the domain server database. This could be
substantial increase in the database size and
responsibility
The ARPA Community and the DDN
This plan will be put into effect in the ARPA community
The DDN community will adopt the domain style names, but
continue with the present scheme of a centrally maintained
copied periodically by each host. Once the use of domain
has been demonstrated by use in the ARPA community, the DDN-
will establish a schedule for implementing the domain system
the DDN community
This means that there may be a period of a year or more with
two communities using different schemes for
information about host names and addresses
Specifically
The NIC will maintain a table a "HOSTS.TXT" style table for
by DDN hosts. This table will contain domain style names
all DDN hosts (e.g., USC-ISIA.DDN). Since this is the
information DDN hosts will use to translate host names
Internet Addresses, this table must also contain names
addresses of ARPA community hosts of interest to DDN
(e.g., USC-ISIF.ARPA).
There will be a domain server with data for the DDN domain
That is, hosts in the ARPA community that use the domain
of resolvers and servers will be able to access servers
have the data base covering the DDN community
It is quite likely that the table for the use of the DDN
will be incomplete with respect to coverage of the ARPA
and any new domains that are established. One motivation for
domain system is the subdivision of name management to avoid
Postel [Page 6]
RFC 881 November 1983
The Domain Names Plan and Schedule
difficulty of keeping a global table of all hosts. As the
community moves to significant use of the domains system
maintenance of a global table for use by the DDN community
become very difficult
This means that DDN hosts might not be able to look up the
of some ARPA community hosts in their local tables. In some
this might result in an inability establish communication from
DDN hosts to such "unknown" ARPA community hosts
The most likely case is for a computer mail message sent
an ARPA community user on a host know to name servers but
in the central table to a user on a DDN community host
relies on a local copy of the central table. When the DDN
attempts to answer this message his mail program will
to look up the host name. This will fail, and the most
result is that the mail program will tell the user that
is no such host
Please note that DDN community hosts are permitted (
encouraged) to implement the domain system in parallel with
ARPA community. However, there is no requirement that they do
until called for in the schedule to be established by the DDN-PMO
Postel [Page 7]
RFC 881 November 1983
The Domain Names Plan and Schedule
The
04-Oct-83 The ARPANET/MILNET Logical
02-Nov-83 Publish Domain Name
This Plan and Schedule (RFC-881), Domain Names - Concepts
Facilities (RFC-882), and Domain Names -
Specification (RFC-883).
16-Nov-83 Make Available Domain Style Host
Create a copy a modified version of the HOSTS.TXT table
DHOSTS.TXT with an additional name (as the first name) in
entry of the form "official-host-name.ARPA".
15-Dec-83 Final Specification of simple Query & Reply
This specification covers the protocol procedures and
formats for the simple queries and replies to support
host names to internet addresses only
15-Dec-83 Make Limited Domain Server & Resolvers
An example limited domain server running on TOPS-20 and
limited resolvers running on each of TOPS-20 and VAX-Berkeley-
should be made available for testing and copying. This
version would be able to do queries and responses for host name
internet address translation only, and the servers would still
the global table. This simple server would not refer the
to another server. This simple server and these resolvers
in datagram mode only. However, this would allow user programs
begin to use the servers
01-Feb-84 Specification of Domain Requirements
Detailed requirements for qualifying a set of hosts as a domain
and procedure for registering new domains is published
15-Feb-84 The ARPANET/MILNET Access
MILNET access controls installed in the MILNET/ARPANET
and TAC user access controls put into effect (see DDN MGT
16). [Date approximate.]
Postel [Page 8]
RFC 881 November 1983
The Domain Names Plan and Schedule
07-Mar-84 Replace Main Host Table with Domain Style Host
The DHOSTS.TXT becomes HOSTS.TXT
14-Mar-84 Final Specification of Query & Reply Protocol
This specification covers the protocol procedures and
formats for the all queries and replies between resolvers
servers
14-Mar-84 Make Improved Domain Servers & Resolvers
An example improved domain server running on TOPS-20 and
improved resolvers running on each of TOPS-20
VAX-Berkeley-Unix should be made available for testing
copying. This version should be able to do any of the
query and response operations, and should support segmented
base by refering resolvers to other servers if necessary.
server loads zone data from local master files only, and only
program start up. This server and these resolvers operate
either datagram or reliable connection style communication.
version does not support the data base update portion of
server protocol
04-Apr-84 Domain Servers for ARPA Domain
Authoritative domain servers for the ARPA domain will be
for regular use
02-May-84 Introduce New Domains in the Main Host
Add the DDN domain. Most MILNET hosts will change to the
domain. Authoritative domain servers for the DDN domain will
available for regular use. HOSTS.TXT is updated
02-May-84 Establish a New Top Level Domains Only
Start a new table, DOMAINS.TXT, that lists only the top
domains and the entries for their domain servers
16-May-84 Final Specification of Maintenance Protocol
This specification covers the protocol procedures and
formats for the data base update exchanges between servers
16-May-84 Make Improved Domain Servers & Resolvers
An example improved domain server running on TOPS-20 and
Postel [Page 9]
RFC 881 November 1983
The Domain Names Plan and Schedule
improved resolvers running on each of TOPS-20
VAX-Berkeley-Unix should be made available for testing
copying. This version should be able to do any of the
query and response operations, and should support segmented
base by refering resolvers to other servers if necessary.
server loads zone data from local master files and remote servers
and only at program start up. This server and these
operate with either datagram or reliable connection
communication
06-Jun-84 Permit the Introduction of New
Organizations meeting the requirements for establishing
domains will be allowed to begin use of new domain names.
domains must be registered, meet the requirements (
running domain servers), and will be added to the HOSTS.TXT table
18-Jul-84 Final Specification of Complete Protocol
This specification covers the protocol procedures and
formats for the complete domain names system
18-Jul-84 Make Full Domain Servers & Resolvers
At this point an example domain server and an example
running on each of TOPS-20 and VAX-Berkeley-Unix should be
available for testing and copying. This version should be able
do any of the defined query and response operations, and
support segmented data base by refering resolvers to other
if necessary. This version should support the data base
portion of the server protocol, including data aging and
zone updating from remote servers. This is a full
of the protocol
05-Sep-84 Discontinue the Full Host Table for the ARPA
Stop maintaining the HOSTS.TXT table for the ARPA community.
HOSTS.TXT table continues to be used in the DDN community
complete data for the DDN domain, however the data for the
and other domains may no longer be complete or fully up to date
03-Oct-84 DDN-PMO Schedules DDN
The DDN-PMO establishes the schedule for the implementation of
domain system in the DDN community
Postel [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
