Category : UNIX Files
Archive   : UUPC11ND.ZIP

Output of file : UUNETDOM.INF contained in archive : UUPC11ND.ZIP

From: UUNET Postmaster
Message-Id: <[email protected]>
Subject: Re: Registering a domain (fwd)
To: [email protected]
Date: Tue, 2 Jan 90 11:16:03 EDT
In-Reply-To: <[email protected]>; from "Jeannie Hill" at Jan 2, 90 8:27 am
X-Mailer: ELM [version 2.2 PL14]

> I have been told that for a fee of $35, UUNET will provide MX name
> server service for an interested party. I would like the details of
> this in order that I can register the doamin as, with my mail
> continuing to use as my actual mail link. I realize I will
> require the permission of garp's postmaster for this as well.


A "zone" is a registry of domains kept by a particular organization. A
zone registry is "authoritative", that is, the master copy of the
registry is kept by the zone organization, and this copy is, by
definition, always up-to-date. Copies of this registry may be
distributed to other places and kept in caches, but these caches are
not authoritative because they may be out of date. An authoritative
answer is required for certain decisions, such as "this mail cannot be
delivered because there is no such domain", or "the name you have
chosen is available and is now assigned uniquely to you."

You need a registered domain name to use software (including smail)
which supports domain addresses. This name must be unique in the
world, and must be registered with the appropriate registry. You also
need to be in a domain that has a forwarder from the ARPANET.

Currently, the domain tree in the USA has three major top level
domains: COM for companies, EDU for educational institutions, and GOV
for government entities. Three other top level names exist: MIL, NET,
ORG, but are somewhat specialized. For the most part, countries other
than the USA are using the ISO 3166 2 letter abbreviation for their
country as a top level.

The second level is generally the name of the organization, using the
shortest possible abbreviation that is clear and unique, thus ATT, DEC,
IBM, HP, etc. The choice of exact name is up to the organization, and
longer names, such as Berkeley.EDU or Tektronix.COM are perfectly
acceptable. Just remember that people must type the name, as well as
see it displayed.

Not all countries use the second level for the organization. In
particular, Australia and Britain have set up second level domains
OZ.AU and AC.UK for their academic communities, and put the
organization at the third level.

The third and subsequent levels, if used, should be organizational
units within the organization. Try to keep the number of levels to a
minimum, since people have to type the names. More than four total
levels (country, org, org-unit1, and org-unit2) should rarely be
needed. The actual organizational units to be used are up to you, for
example, they might be departments, or they might be machine names.


Names are case independent. uucpnames MUST be all lower case.

"vax", "u3b20", and the like are terrible host names, because sooner or
later you'll have more than one vax, or more than one 3b20, and the
names will be confusing. We recommend organizational names, based on
the department or project the machine is used for. Of course, in order
to keep the names reasonably short and to avoid duplicating names in
the heirarchy, some compromise will be needed. For example,
csvax.CS.UND.EDU is redundant, but RISC.CS.UND.EDU might be a good name
for the computer used by the RISC project in the CS department.

Please note that you should support both RFC 976 and the documents it
refers to, in particular RFC 822 and RFC 920. This means, for

(a) The name "postmaster" on all machines visible to the outside
should be forwarded to the technical contact. This can be
easily done with an alias in /usr/lib/aliases, if your site
runs sendmail or smail release 2.0 or beyond.

(b) Your machine should not alter valid RFC 822 headers, such as
From:, of mail it generates or forwards. Many machines running
sendmail have a bug which adds uucpname! to the front of such
addresses. Installing smail will fix the bug, because mail
passed through the machine is not passed through sendmail.
We hope to make a fix to sendmail available, also, at a
later date.


UUNET charges a one time fee of $35 for processing the forms and
setting up the servers. This fee does NOT include a connection to the
uunet computer. (There is no charge for UUNET customers.)

Payment may be sent to:

UUNET Communications Services
3110 Fairview Park Drive, Suite 570
Falls Church, VA 22042
+1 703 876 5050

or we will invoice you. Please indicate the name of your domain and the
uucp name of your gateway machine on your payment so that we may properly
credit you.

Information about UUNET's other services can be obtained by sending
your postal address to uunet!info


We will notify you (via mail to "postmaster" in your domain) when your
domain is registered. You cannot use your domain name in outgoing mail
until registration is completed, although it is OK to install smail
(using the host.UUCP domain) ahead of time. We do recommend that you
set up to accept incoming mail for your domain name ahead of time, if
this is convenient.

Several steps are needed before your registration is complete. Some of
these steps are approval by the NIC, setting up the nameservers,
setting up the forwarder. Seeing your domain published in the UUCP map
is not, by itself, sufficient (or necessary) for the use of your domain


A forwarder is a kind of mail bridge host between DDN (formerly called
the ARPANET) and UUCP. The DDN nameserver structure directs all DDN
mail for your domain to the forwarder, and the forwarder passes the
mail from DDN into UUCP. Forwarders can also forward your mail from
UUCP to DDN, but it is not strictly necessary to use your forwarder for
this, since mail to any of the published UUCP->DDN gateways can do

To register your domain, you need to have a forwarder. If you know of
an Internet site that is willing to be a forwarder for your domain, let
us know. As a last resort, uunet can be a forwarder for you. HOWEVER,
we require that you obtain the permission of the site that is directly
connected to uunet before we start forwarding mail through them.


To register your domain with the NIC, we need to send in the following
form. Questions 4,7,8,9 and 10 are already answered for you. Do not
change them.

Answer questions 0,1,2,3,5,6 and 11 and return THE ENTIRE FORM to
uunet!postmaster. PLEASE do not just return the questions you answer.
It creates extra work for us, as we have to copy your answers back onto
the form we originally sent you.


(0) Specify what machine you want to be your forwarder. If you are directly
connected to uunet, uunet can be your forwarder. If you are not
directly connected, then you need to find some other site to be your
forwarder OR get the permission of a site that IS directly connected to
uunet to allow your arpanet mail to be forwarded through them. We must
receive the permission of the uunet site or the other forwarded
directly from that forwarder.

Who will be your forwarder?:
For Example:



To establish a domain, the following information must be sent to
the NIC Domain Registrar ([email protected]). Questions
may be addressed to the NIC Hostmaster by electronic mail at the
above address, or by phone at (415) 859-3695 or (800) 235-3155.

NOTE: The key people must have electronic mailboxes and NIC
"handles," unique NIC database identifiers. If you have access to
"WHOIS", please check to see if you are registered and if so, make
sure the information is current. Include only your handle and any
changes (if any) that need to be made in your entry. If you do not
have access to "WHOIS", please provide all the information indicated
and a NIC handle will be assigned.

(1) The name of the top-level domain to join (EDU, COM, MIL, etc...)

1. Top-level name:

(2) The name of the domain (up to 12 characters). This is the name
that will be used in tables and lists associating the domain with the
domain server addresses. [While, from a technical standpoint, domain
names can be quite long we recommend the use of shorter, more user-
friendly names.]

2. Complete Domain Name:

(3) The name and geographical address of the organization
establishing the domain.

3a. Geographical address:

3b. Organization name:

(4) The date you expect the fully qualified domain name to become
the official host name in HOSTS.TXT, if applicable.

4. Date operational: Will not appear in hosts.txt

(5) The NIC handle of the administrative head of the organization.
Alternately, the person's name, title, mailing address, phone number,
organization, and network mailbox. This is the contact point for
administrative and policy questions about the domain. In the case of
a research project, this should be the principal investigator.

Administrative Contact

5a. NIC Handle (if known) :
5b. Name (Last, First) :
5c. Title :
5d. Organization:
5e. Mail Address:

5f. Phone Number:
5g. Net Mailbox :

(6) The NIC handle of the technical contact for the domain.
Alternately, the person's name, title, mailing address, phone number,
organization, and network mailbox. This is the contact point for
problems concerning the domain or zone, as well as for updating
information about the domain or zone.

Technical and Zone Contact

6a. NIC Handle (if known):
6b. Name (Last, First) :
6c. Title :
6d. Organization:
6e. Mail Address:

6f. Phone Number:
6g. Net Mailbox :

(7) Domains must provide at least two independent servers that provide the
domain service for translating names to addresses for hosts in this domain.
Establishing the servers in physically separate locations and on different
PSNs is strongly recommended. A description of the primary and secondary
server machines, including

- Host domain name and network addresses
- Any domain-style nicknames (please limit your domain-style
nickname request, if any, to one)
- Hardware and software, using keywords from the Assigned
Numbers RFC.


7a. Primary Server Name:
7b. Primary Server Netaddress:
7c. Primary Server Hardware: SEQUENT-S81
7d. Primary Server Software: UNIX

(8) The Secondary server information.

8a. Secondary Server Name: seismo.CSS.GOV
8b. Secondary Server Netaddress:
8c. Secondary Server Hardware: SUN-3/160
8d. Secondary Server Software: UNIX

(9) A description of the servers that provide the domain service
and the date they will be operational.

9. Description and date operational: BIND. now operational

(10) Planned mapping of names of any other network hosts (including
any ARPANET or MILNET hosts), other than the server machines, into
the new domain's naming space.


(11) Please describe your organization briefly.

For example: Our Corporation is a consulting
organization of people working with UNIX and the C language in an
electronic networking environment. It sponsors two technical
conferences annually and distributes a bimonthly newsletter.



RECOMMENDED READING (available from the NIC)

Postel, J.B.; Reynolds, J.K. Domain requirements. Marina del Rey, CA:
University of Southern California, Information Sciences Inst.; 1984
October; RFC 920. 14 p. (NIC.DDN.MIL RFC:RFC920.TXT).

Harrenstien, K.; Stahl, M.K.; Feinler, E.J. DoD Internet host table
specification. Menlo Park, CA: SRI International, DDN Network
Information Center; 1985 October; RFC 952. 6 p. (NIC.DDN.MIL
RFC:RFC952.TXT). Obsoletes: RFC 810

Harrenstien, K.; Stahl, M.K.; Feinler, E.J. Hostname Server. Menlo
Park, CA: SRI International, DDN Network Information Center; 1985
October; RFC 953. 5 p. (NIC.DDN.MIL RFC:RFC953.TXT).
Obsoletes: RFC 811

Partridge, C. Mail routing and the domain system. Cambridge, MA: BBN
Labs., Inc.; 1986 January; RFC 974. 7 p. (NIC.DDN.MIL

Lazear, W.D. MILNET name domain transition. McLean, VA: MITRE Corp.;
1987 November; RFC 1031. 10 p. (NIC.DDN.MIL RFC:RFC1031.TXT).

Stahl, M.K. Domain administrators guide. Menlo Park, CA: SRI
International, DDN Network Information Center; 1987 November; RFC
1032. 14 p. (NIC.DDN.MIL RFC:RFC1032.TXT).

Lottor, M. Domain administrators operations guide. Menlo Park, CA:
SRI International, DDN Network Information Center; 1987 November; RFC
1033. 22 p. (NIC.DDN.MIL RFC:RFC1033.TXT).

Mockapetris, P. Domain names - concepts and facilities. Marina del
Rey, CA: University of Southern California, Information Sciences
Inst.; 1987 November; RFC 1034. 55 p. (NIC.DDN.MIL
RFC:RFC1034.TXT). Updated-by: RFC 1101
Obsoletes: RFC 973; RFC 882; RFC 883

Mockapetris, P. Domain names - implementation and specification.
Marina del Rey, CA: University of Southern California, Information
Sciences Inst.; 1987 November; RFC 1035. 55 p. (NIC.DDN.MIL
RFC:RFC1035.TXT). Updated-by: RFC 1101
Obsoletes: RFC 973; RFC 882; RFC 883

Mockapetris, P. DNS encoding of network names and other types. Marina
del Rey, CA: University of Southern California, Information Sciences
Inst.; 1989 April; RFC 1101. 14 p. (NIC.DDN.MIL RFC:RFC1101.TXT).
Updates: RFC 1034; RFC 1035