karl@cheops.cis.ohio-state.edu (Karl Kleinpaste) (05/25/89)
My fingers can only take so much...
I've gotten about 4 requests of this general flavor:
We're about to be connected to [pick a regional IP network], and I'd like
to offer nameservice/MX for a couple of our UUCP neighbors also. Could
you please be so kind as to explain how to do that?
I figured that there must be a pretty severe need for a description of
how one goes about setting up to do such things. This file describes
how I do it. It's certainly not the only way, but some parts (e.g.,
registration with the NIC) are definitely unavoidable.
Note that this is for a new domain in one of the non-geographical
top-level domains, e.g., com, edu, org, that sort of thing - not for
hosts in the .us domain. Supporting such a lone host only requires a
one-line change to sendmail.cf, and not all the related cruft with new
nameserver zone files that new entities in the organizational
top-level domains require, which is what I describe here. A concrete
example is provided.
There's several steps to this: [1] Fill out a domain registration
form; [2] Add the new domain to your nameserver configuration; [3]
Reconfigure your sendmail slightly so that mail addressed to the new
domain is sent via UUCP rather than TCP; and [4] make sure that your
UUCP transport (smail, for me) understands how to translate that into
a suitable UUCP path. Details follow.
Have the intended registree fill out a copy of the NIC's
NETINFO:DOMAIN-TEMPLATE.TXT; a copy is included at the end. Have them
fill out questions 1, 2, 4, 8 and 10. The rest is filled in by
yourself, since you're the one who'll be running their nameserver and
know about the configuration. For a backup nameserver to be running
as secondary, I have a couple of friends with whom I routinely
exchange services of performing secondary - find yourself a friendly
person and develop a reasonable relationship for such stuff, it'll
work out well for both of you in the long run.
Anyhow, have them fill out the form and return it to you. You fill in
the rest of the items which they can't answer (notably, listing
yourself as the technical/zone contact), and send it off to
hostmaster@sri-nic.arpa. So far, this is just another domain
registration. Then you need to reconfigure your nameserver slightly
to include the new domain. Here's my zone file for one of my recent
new domains, resource.com:
resource.com. in soa tut.cis.ohio-state.edu. karl.tut.cis.ohio-state.edu. (
890516 ; serial
86400 ; refresh
300 ; retry
3600000 ; expire
86400 ) ; minimum
resource.com. in ns tut.cis.ohio-state.edu.
resource.com. in ns cheops.cis.ohio-state.edu.
resource.com. in ns giza.cis.ohio-state.edu.
resource.com. in ns saqqara.cis.ohio-state.edu.
resource.com. in ns accuvax.nwu.edu.
resource.com. in mx 0 saqqara.cis.ohio-state.edu.
* in mx 0 saqqara.cis.ohio-state.edu.
Install that in some appropriate place with suitable name changes
appropriate to your systems which are performing NS service and the
domain which you're registering. I find it's wise to have the
nameserver already providing service for the new domain before you
actually send the registration to hostmaster; then you can note in the
registration application that things are already up and running. Of
course, when you install the new zone file above with appropriate
changes, you'll need to add a line to the boot file for your
nameserver, thus:
primary resource.com /etc/named.d/resource.com
I put all zone files into /etc/named.d - a pseudo-SysV sort of
directory into which to put such things. If it doesn't happen any
other time, make sure that you restart your nameserver at some point
so that the reconfiguration takes effect. (Well, of course, you knew
that, if you run a nameserver already - but I'm trying to forestall
confusion and mistakes and so forth.)
Then you need to reconfigure your sendmail.cf to understand the new
domain and send it off via UUCP rather than letting your sendmail get
confused by the domain syntax and try to send it via TCP. I do it
thusly:
## The class C is the set of commercial domains to which we speak UUCP
## directly. These are not hosts within your domain, but whole domains
## external to yourself.
CCatt pyramid stargate netsys copi morningstar resource
...
S0
...
R$+<@$*$=C.com> $#smail$@$2$3.com$:$1 Commercial
R$+<@$*dallas.tx.us> $#smail$@$2dallas.tx.us$:$1 Killer-spcl
R$+<@$*ysu.edu> $#smail$@$2ysu.edu$:$1 Youngstown State
Note that I support direct domain-addressable things for a number of
.com entities, so I define a whole class just for that purpose. (I'm
not formally listed as the MX for all of them, e.g., Pyramid and AT&T;
but I have direct links to them and see no reason to use the Internet
for mail going to the far side of town to AT&T, for example.) Other
than those, it's a bunch of special cases.
Note that I use smail as my UUCP mailer. This, then, must in turn
require that I have a /usr/lib/uucp/paths file which understands the
domain translations for suitable UUCP destinations. For the
Resource example, I must make sure that my paths file contains a
line such as
resource.com resource!%s
Thus, S0 of sendmail.cf will detect "anything@resource.com" and invoke
smail on such a destination with exactly that syntax; when smail gets
a grip on it, it'll translate it to "resource!anything," which is
exactly what is needed.
That's it (he said wryly) - once those things are done, you're both
the nameserver as well as the MX forwarder for the new domain.
Below are a copy of the NIC's domain template, as well as the domain
registration which I sent in for resource.com.
Enjoy,
--Karl
----------------
[ NETINFO:DOMAIN-TEMPLATE.TXT ] [ 9/88 ]
To establish a domain, the following information must be sent to
the NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA). 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.
For example: COM
(2) 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.
For example:
Administrator
Organization The NetWorthy Corporation
Name Penelope Q. Sassafrass
Title President
Mail Address The NetWorthy Corporation
4676 Andrews Way, Suite 100
Santa Clara, CA 94302-1212
Phone Number (415) 123-4567
Net Mailbox Sassafrass@ECHO.TNC.COM
NIC Handle PQS
(3) 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.
For example:
Technical and Zone Contact
Organization The NetWorthy Corporation
Name Ansel A. Aardvark
Title Executive Director
Mail Address The NetWorthy Corporation
4676 Andrews Way, Suite 100
Santa Clara, CA. 94302-1212
Phone Number (415) 123-6789
Net Mailbox Aardvark@ECHO.TNC.COM
NIC Handle AAA2
(4) 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 (programmers beware), shorter names are
easier for people to cope with.]
For example: TNC
(5) A description of the servers that provide the domain service for
translating names to addresses for hosts in this domain, and the date
they will be operational.
A good way to answer this question is to say "Our server is
supplied by person or company X and does whatever their standard
issue server does."
For example: Our server is a copy of the one operated by
the NIC; it will be installed and made operational on
1 November 1987.
(6) Domains must provide at least two independent servers for the
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.
The preferred format for this information is:
Primary Server: HOST-DOMAIN-NAME, NETADDRRESS, HARDWARE, SOFTWARE
Secondary Server: HOST-DOMAIN-NAME, NETADDRRESS, HARDWARE, SOFTWARE
Example:
Primary Server: BAR.FOO.COM, 10.9.0.13, VAX-11/750, UNIX
Secondary Server: XYZ.ABC.COM, 128.4.2.1, IBM-PC, MS-DOS
(7) 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.
For example:
BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
(8) An estimate of the number of hosts that will be in the domain.
(a) Initially
(b) Within one year
(c) Two years
(d) Five years.
For example:
(a) Initially = 50
(b) One year = 100
(c) Two years = 200
(d) Five years = 500
(9) The date you expect the fully qualified domain name to become
the official host name in HOSTS.TXT, if applicable.
Please note: Registration of a domain does not imply an
automatic name change to previously registered ARPANET or MILNET
hosts that will be included in the domain. Please list below
the official host names and network addresses of any ARPANET or
MILNET hosts that now appear in HOSTS.TXT whose names will
change as a result of this domain registration. (Also be sure
to answer question # 7, above.)
(10) Please describe your organization briefly.
For example: The NetWorthy 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.
PLEASE ALLOW AT LEAST 10 WORKING DAYS FOR PROCESSING THIS APPLICATION
----------------
To: hostmaster@sri-nic.arpa
Subject: Domain registration: RESOURCE.COM
(1) The name of the top-level domain to join.
COM
(2) 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.
Administrator
Organization Resource Systems
Name Bryan M. Beck
Title Programmer/Technical Specialist
Mail Address Resource Systems
2545 Farmers Drive, Suite 390
Columbus, Ohio 43235
Phone Number (614) 764-7800
Net Mailbox bryan@resource.com
NIC Handle -not yet registered-
(3) 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
Organization The Ohio State University, Computer Science Dept
Name Karl Kleinpaste
Title Senior Researcher
Mail Address 2036 Neil Ave Mall
Columbus, OH 43210
Phone Number 614/292-7347
Net Mailbox karl@tut.cis.ohio-state.edu
NIC Handle KK53
(4) 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 (programmers beware), shorter names are
easier for people to cope with.]
RESOURCE
(5) A description of the servers that provide the domain service for
translating names to addresses for hosts in this domain, and the date
they will be operational.
TUT.CIS.OHIO-STATE.EDU, BIND 4.8
ACCUVAX.NWU.EDU, BIND 4.8
Already operational
(6) Domains must provide at least two independent servers for the
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
TUT.CIS.OHIO-STATE.EDU, 128.146.8.60, Pyramid 98x, OSx 4.0
ACCUVAX.NWU.EDU, 129.105.49.1, MicroVAX-II, 4.3BSD
(7) 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.
None.
(8) An estimate of the number of hosts that will be in the domain.
(a) Initially = 2
(b) One year = 6
(c) Two years = 10
(d) Five years = 20
(9) The date you expect the fully qualified domain name to become
the official host name in HOSTS.TXT, if applicable.
N/A.
(10) Please describe your organization briefly.
Resource Systems is a health care information system consulting
firm specializing in decision suport systems developed in 4GL
languages in a UNIX, XENIX, VMS enviornments.
PLEASE ALLOW AT LEAST 10 WORKING DAYS FOR PROCESSING THIS APPLICATION