Significantly interested parties in the domain should agree that the
designated manager is the appropriate party.
The US Domain Administrator tries to have any contending parties
reach agreement among themselves, and generally takes no action to
change things unless all the contending parties agree; only in cases
where the designated manager has substantially neglected their
responsibilities would the US Domain Administrator step in.
The designated manager must do a satisfactory job of operating the
DNS service for the domain.
That is, the actual management of the assigning of domain names,
delegating subdomains and operating name servers must be done with
technical competence. This includes keeping the US Domain
Administrator or other higher-level domain managers advised of the
status of the domain, responding to requests in a timely manner, and
operating the database with accuracy, robustness, and resilience.
There must be a primary and a secondary name server that have IP
connectivity to the Internet and can be easily checked for
operational status and database accuracy by the US Domain
Administrator.
One of the aspects of having two name servers for each domain (or
zone), is for robustness. One concern under this heading is that the
name service not go out entirely if there is a local power failure
(earthquake, tornado, or other disaster).
Name Servers should be in distinctly separate physical locations. It
is appropriate to have more than two name servers, but there must be
at least two.
For any transfer of the designated manager trusteeship from one
organization to another, the higher-level domain manager must receive
communications from both the old organization and the new
organization that assures the US Domain Administrator that the
transfer in mutually agreed, and that the new organization
understands its responsibilities.
It is also very helpful for the US Domain Administrator to receive
communications from other parties that may be concerned or affected
by the transfer.
Delegation of cities, companies within cities, schools (K12),
community colleges (CC), libraries (LIB), state government (STATE),
and federal government agencies (FED), etc., is acceptable and
practical.
For a delegated portion of the name space, for example a city, no
alterations can be made to that name, no abbreviations added, etc.
unless applied for.
Sometimes there may be two people running name servers in the same
city because different portions of the name space has been delegated
to them. For example, someone may be delegated the <city>.<state>.US
name space, and someone else from a state government agency may have
the .STATE.<state>.US, portion. For example, Fred may run the name
servers for Sacramento.CA.US and Joe may run the name servers for
STATE.CA.US in Sacramento.
If a company would like to have wildcard records added, or run their
own name servers in a city that we have delegated name space to, this
is acceptable.
Delegation of the whole State name space is not yet implemented. The
delegated part of the name space is in the form of:
.<locality>.<state>.US.
.CI.<locality>.<state>.US.
.CO.<locality>.<state>.US.
.STATE.<state>.US.
.K12.<state>.US.
PVT.K12.<state>.US.
.CC.<state>.US.
.TEC.<state>.US.
.LIB.<state>.US.
.GEN.<state>.US.
.DNI.US.
.FED.US.
3.3.1. Delegation Requirements
When a subdomain is delegated, the following requirements must be
met:
1) There must be a knowledgeable and competent technical contact,
familiar with the Internet DNS. This requirement is easily
satisified if the technical contact already runs some other
name servers.
2) Organizations requesting delegations must provide at least two
independent (robust and reliable) DNS name servers in
physically separate locations on the Internet.
3) The subdomain must accept all applicants on an equal basis.
4) The subdomain must provide timely processing of requests. To
do this, it is helpful to have several individuals
knowledgeable about the procedures so that the operations are
not delayed due to one persons unavailability (for example, by
being on vacation).
5) The subdomain manager must tell the US Domain Administrator
when there are changes in the name servers that should be
reflected in the US Domain zone files, or changes in the
contact information.
K12 Administrators
In the long term, registering schools will be a big job. So you
need to have in mind delegating parts of the work to various
school districts. If you can delegate every school district in
the state then you are finished, except for checking that they are
all operating correctly. However, initially you will have quite a
bit to do with educating people, helping them choose names and
getting name servers arranged. You are responsible for seeing
that the naming of schools follow the guidelines suggested in this
memo.
All K12 Administrators will initially be responsible for managing
the "pseudo district" PVT for private schools. Private schools
have the option of registering as <school-name>.PVT.K12.<state>.US
or as a business under the city based names.
Locality Administrators
If you have been delegated a locality subdomain, you will be
responsible for registering not only businesses directly under the
locality, but city and county agencies under the "CI" and "CO"
branches. When appropriate these branches should be delegated.
If you want, you may spell out "CITY" instead of "CI" or "COUNTY"
instead of "CO", but you must be consistent and use only one or
the other in a given locality. The whole city government should
be under one branch.
WHOIS Database
Only the second and third level delegated name spaces will be
entered in the WHOIS database. For example, K12.CA.US would have
an entry in WHOIS. Anything under K12.CA.US will not be listed.
The US Domain Administrator will send the information that you
supplied on your US Domain template to the InterNIC. It is the
hope that in the future, each delegated subdomain will provide
their own WHOIS directory database for their branch.
3.3.2 Delegation Procedures
The procedure that is followed when a subdomain is delegated includes
the following steps:
1) Evaluate the technical contact's experience with DNS. Make
sure there is a need for the proposed delegation. Make sure
the technical contact has the information about the US Domain
and the suggested naming structure. Two contacts with email
addresses are necessary in case something goes wrong.
2) Add the new technical contact to the "us-dom-adm" mailing list
for distributing updates concerning the US Domain policies and
procedures.
3) Delete any hosts from our zone file that belongs in the newly
delegated subdomain and make sure they now have the hosts in
their zone file.
4) Send them a copy of the zone file so their initial zone file
is identical to ours. For example:
mil.wi.us. 69582 SOA spool.mu.edu.
manager.spool.mu.edu. (
930119 ;serial
28800 ;refresh
14400 ;retry
3600000 ;expire
86400 ) ;minim
mil.wi.us. 69582 NS spool.mu.edu.
spool.mu.edu. 85483 A 134.48.1.31
mil.wi.us. 69582 NS sophie.mscs.mu.edu.
sophie.mscs.mu.edu. 85483 A 134.48.4.6
solaria.mil.wi.us. 69582 HINFO Sun 3/60 SunOs
solaria.mil.wi.us. 69582 MX 10 spool.mu.edu.
nthomas.mil.wi.us. 69582 HINFO 386 Clone DOS
nthomas.mil.wi.us. 69582 MX 10 spool.mu.edu.
rwmke.mil.wi.us. 69582 HINFO UNIX PC UNIX
rwmke.mil.wi.us. 69582 MX 10 spool.mu.edu.
milestn.mil.wi.us. 69582 MX 10 spool.mu.edu.
nrunner.mil.wi.us. 69582 HINFO MacIntosh System 7
nrunner.mil.wi.us. 69582 MX 10 spool.mu.edu.
dawley.mil.wi.us. 69582 HINFO 386 Clone DOS
dawley.mil.wi.us. 69582 MX 10 spool.mu.edu.
...
5) The US Domain zone file must have the following records,
showing the name, address, email, and phone number of the
technical contact for the delegated subdomain and the name of
the delegated name space and the names of the name servers.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;Contact: Joseph Klein (tjk@spool.mu.edu)
; Marquette University
; (414) 288-6734
;
;Delegate mil.wi.us zone
mil.wi.us. 604800 NS SPOOL.MU.EDU.
604800 NS SOPHIE.MSCS.MU.EDU.
; A glue record is not needed this time. Glue records are
; needed when the name of the server is a subdomain of the
; delegated domain.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
6) Check to see that delegated subdomain name servers are up and
running, and make sure the delegated hosts are installed in
their zone file. Now delete any hosts from the US Domain zone
file that belongs in the newly delegated subdomain.
7) Inform the technical contact of the newly delegated subdomain
that wildcard records are allowed in the zone file under the
organizational subdomain but no wildcard records are allowed
under the "city" or "state" domain.
8) Make sure each administrator has a copy of this RFCand
follows the guidelines set forth.
3.3.3 Subdomain Contacts
The number of hosts registered under each subdomain is unknown. See
Section 3.1 for information on the delegated domains and the
contacts.
4. DATABASE INFORMATION
4.1. Name Servers
Name servers are the repositories of information that make up the
domain database. The database is divided up into sections called
zones, which are distributed among the name servers. While name
servers can have several optional functions and sources of data, the
essential task of a name server is to answer queries using data in
its zones. The response to a query can always be generated using
only local data, and either contains the answer to the question or a
referral to other name servers "closer" to the desired information.
A given zone will be available from several name servers to insure
its availability in spite of host or communication link failure.
Every zone is required to be available on at least two servers, and
many zones have more redundancy than that.
The US Domain is currently supported by seven name servers:
venera.isi.edu
ns.isi.edu
rs.internic.net
ns.csl.sri.com
ns.uu.net
adm.brl.mil
excalibur.usc.edu
4.2 Zone Files
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, and may be out-of-date.
Every zone has at least one node, and hence domain name, for which it
is authoritative, and all of the nodes in a particular zone are
connected. Given the tree structure, every zone has a highest node
which is closer to the root than any other node in the zone. The
name of this node is often used to identify the zone. The data that
describes a zone has four major parts:
1) Authoritative data for all nodes within the zone.
2) Data that defines the top node of the zone
(can be thought of as part of the authoritative data).
3) Data that describes delegated subzones, i.e., cuts
around the bottom of the zone,
4) Data that allows access to name servers for subzones
(sometimes called "glue" data).
The zone administrator has to maintain the zones at all the name
servers which are authoritative for the zone. When the changes are
made, they must be distributed to all of the name servers.
Copies of the zone files are not available unless you are on the
Internet. To look at the zone files use the "dig" program of the DNS
domain name system.
dig @nshost host-your-checking axfr
4.3 Resource Records
Records in the zone data files are called resource records (RRs).
The standard Resource records (RR) are specified in STD 13, RFC1034
and STD 13, RFC1035 (3,4). An RR has a standard format as shown.
<name> [<ttl>] [<class>] <type> <data>
The first field is always the name of the domain record. The second
field is an optional time to live field. This specifies how long
this data will be stored in the data base. The third field is the
address class; the class field specifies the protocol group most
often this is the Internet class "IN". The fourth field states the
type of the resource record. The fields after that are dependent on
the Type of RR. The fifth field is the data field which is defined
differently for each type and class of data. Here is a list of the
current commonly used types:
SOA Start of Authority
NS Name Server
A Internet Address
CNAME Canonical Name (nickname pointer)
HINFO Host Information
WKS Well Known Services
MX Mail Exchanger
PTR Pointer
What do the fields mean?
foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU.
(1) (2) (3) (4) (5)
1) domain name
2) time to live information
3) mail exchanger record
4) preference value to determine (if more than one
forwarder) which mailer to use first, lower number
higher preference
5) the Internet forwarding host.
4.3.1 "A" Records
Internet (IP) Address. The data for an "A" record is an Internet
address in a dotted decimal form. A sample "A" record might look
like:
venera.isi.edu. A 128.9.0.32
(name) (A) (address)
The name field is the machine name, and the address is the network
address. There should be only one "A" record for each address of a
host.
4.3.2 CNAME Records
Canonical Name resource record, CNAME, specifies an alias for a
canonical name. This is essentially a pointer to the official name
for the requested name. All other RRs appear under this official
name. A machine named FERNWOOD.MPK.CA.US may want to have the
nickname ANTERIOR.MPK.CA.US. In that case, the following RR would be
used:
anterior.mpk.ca.us. CNAME fernwood.mpk.ca.us.
(alias nickname) (canonical name)
Nicknames (the name associated with the RR is the nickname) may be
added for awhile when a host changes its name, usually because it
moves to another state. It helps to have this CNAME pointer so if
any mail comes to the old address it will get forwarded to the new
one. There cannot be any other RRs associated with a nickname of the
same class.
4.3.3 MX Records
Mail Exchanger records, MX, are used to specify a machine that knows
how to deliver mail to a machine that is not directly connected to
the Internet. For example, venera.isi.edu is the mail gateway that
knows how to deliver mail to foo.la.ca.us, but other machines on the
network cannot deliver mail directly to foo.la.ca.us. These two
machines may have a private connection or use a different transport
medium (such as uucp). The preference value (10) is the order that a
mailer should follow when there is more than one way to deliver mail
to a single machine. The lower the number the higher the preference.
foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU.
foo.LA.CA.US. 604800 MX 20 relay1.uu.net.
4.3.4 HINFO Records
Host information resource records, HINFO is for host specific data.
This lists the hardware and operating system that are running at the
listed host. It should be noted that a space separates the hardware
information and the operating system information. If you want to
include a space in the machine name you must quote the name. Host
information is not specific to any class, so ANY may be used for the
address class. There should be one HINFO record for each host.
acb.la.ca.us. HINFO VAX-11/780 UNIX
(Hardware) (Operating System)
The official HINFO types can be found in the latest Assigned Numbers
RFC, the most recent edition being STD 2, RFC1340 [9]. The hardware
type is called the Machine Name, and the software type is called the
System Name.
The information users supply about this is often inconsistent or
incomplete. Please follow the terms in the current "Assigned
Numbers".
4.3.5 PTR Records
A Domain Name Pointer record, PTR, allows special names to point to
some other location in the domain data base. These are typically
used in setting up reverse pointers for the special IN-ADDR.ARPA
domain. PTR names should be unique to the zone.
0.0.9.128.in-addr.arpa PTR isi-net.isi.edu.
(special name) (real name)
A PTR record is to be added to the IN-ADDR.ARPA domain for every "A"
record registered in the US Domain. These PTR records need to be
added by the administrator of the network where the host is
connected. The US Domain Administration does not administer the
network and cannot make these entries in the DNS database.
4.4 Wildcards
The wildcard records are of the form "*.<anydomain>", where
<anydomain> is any domain name. The wildcards potentially apply to
descendents of <anydomain>, but not to <anydomain> itself.
For example, suppose a large company located in California with a
large, non-IP/TCP, network wanted to create a mail gateway. If the
company was called DWP.LA.CA.US, and the IP/TCP capable gateway
machine (Internet forwarder) was called ELROY.JPL.NASA.GOV, the
following RRs might be entered into the .US zone.
dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV
*.dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV
The wildcard record *.DWP.LA.CA.US would cause an MX query for any
domain name ending in DWP.LA.CA.US to return an MX RR pointing at
ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host
dwp can be found.
In the US Domain, wildcard records are allowed in our zone files
under the organizational subdomain (and where noted otherwise) but no
wildcard records are allowed under the "City" or "State" domain.
The authors strongly believe that it is in everyone's
interest and good for the Internet to have each host
explicitly registered (that is, we believe that wildcards
should not be used), we also realize that not everyone
agrees with this belief. Thus, we will allow wildcard
records in the US Domain under groups or organizations.
For example, *.DWP.LA.CA.US.
The reason we feel single entries are the best is by the mere
fact that if anyone wanted to find one of the hosts in the
domain name system it would be there, and problems can be
detected more easily. When using wildcards records all the
hosts under a subdomain are hidden.
5. REFERENCES
[1] Stahl, M., "Domain Administrators Guide", RFC1032, SRI
International, November 1987.
[2] Lottor, M., "Domain Administrators Operations Guide" RFC1033,
SRI International, November 1987.
[3] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC1034, ISI, November 1987.
[4] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC1035, ISI, November 1987.
[5] Dunlap, K., "Name Server Operations Guide for Bind,
Release 4.3", UC Berkeley, SMM:11-3.
[6] Partridge, C., "Mail Routing and the Domain Name System",
STD 14, RFC974, BBN, January 1986.
[7] Albitz, P., C. Liu, "DNS and Bind" Help for UNIX System
Administrators, O'Reilly and Associates, Inc., October 1992.
[8] ACM SIGUCCS Networking Taskforce, "Connecting to the Internet -
What Connecting Institutions Should Anticipate", FYI 16,
RFC1359, August 1992.
[9] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC1340, ISI, July 1992.
6. Security Considerations
Security issues are not discussed in this memo.
7. Authors' Addresses
Ann Cooper
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 1-310-822-1511
Email: cooper@isi.edu
Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 1-310-822-1511
Email: postel@isi.edu
APPENDIX-I: US DOMAIN NAMES BNF
================================
<us-domain-name> ::= <us-name><dot><us>
<us-name> ::= <state-name><dot><state-code> |
<fed-name><dot><fed>
<dni-name><dot><dni>
<state-code> ::= <the two-letter code of a state from the
zip code directory>
<state-name> ::= <local-name><dot><locality> |
<state-agency-name><dot><state> |
<regional-agency-name><dot><agency>
<fed-name> ::= <the dotted hierarchical name of a US
federal government agency>
<dni-name> ::= <the dotted hierarchical name of a
distributed national institution>
<locality> ::= <the full name of a city from the
zip code directory> |
<a short code name for a city> |
<the full name of a county, township,
or parish> |
<other well known and commonly used
locality name>
<local-name> ::= <entity-name> |
<city-name><dot><city> |
<county-name><dot><county> |
<local-agency-name><dot><local-agency>
<state-agency-name> ::= <the dotted hierarchical name of a state
government agency>
<regional-agency-name> ::= <the dotted hierarchical name of a
special agency or district not an
element of the state government and
typically larger than a single city or
county, for example, the Southern
California Air Quality Management District>
<entity-name> ::= <the dotted hierarchical name of an
entity within a city, for example: a
company, business, private school, club,
organization, or individual>
<city-name> ::= <the dotted hierarchical name of a city
government agency>
<county-name> ::= <the dotted hierarchical name of a county,
township, or parish government agency>
<local-agency-name> ::= <the dotted hierarchical name of a special
agency or district not an element of a
city or county government and typically
equal or smaller than a single city or
county, for example, the Bunker Hill
Improvement District>
<city> ::= "CI" | "CITY"
<county> ::= "CO" | "COUNTY" | "TOWNSHIP" | "PARISH"
<dot> ::= "."
<fed> ::= "FED"
<dni> ::= "DNI"
<state> ::= "STATE" | "COMMONWEALTH"
<agency> ::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB" |
"GEN" | "TEC"
<local-agency> ::= "AGENCY" | "DISTRICT"
<us> ::= "US"
Notes:
Within States:
"K12" may be used for public school districts. A special name
"PVT" can be used in the place of a school district name for
private schools.
"CC" may be used only for public community colleges.
"LIB" may be only used by libraries.
"TEC" is used only for technical and vocational schools and colleges.
"GEN" is for general independent entities, that is, organizations
that don't really fit anywhere else (such as statewide associations,
clubs, and "domain parks").
"STATE" may be used only for state government entities.
Below US, parallel to States:
"FED" is for agencies of the federal government.
"DNI" is for distributed national institutes; organizations that
span state, regional, and other organizational boundaries; that
are national in scope, and have distributed facilities.
Examples:
=========
Geo-Petrellis.Culver-City.CA.US <== resturant
Joe-Josts.Long-Beach.CA.US <== bar
IBM.Armonk.NY.US <== business
Camp-Curry.Yosemite.CA.US <== business
Yosemite.NPS.Interior.FED.US <== federal agency
Senate.FED.US <== US Senate
DOD.FED.US <== US Defense Dept.
DOT.FED.US <== US Transportation Dept.
MNPL.FRB.FED.US <== the Minneapolis branch of
the Federal Reserve Bank
MetaCenter.DNI.US <== distributed Nat'l Inst
Senate.STATE.MN.US <== state Senate
House.STATE.MN.US <== state House of Reps
Assembly.STATE.CA.US <== state Assembly
MDH.STATE.MN.US <== state Health Dept.
DOT.STATE.MN.US <== state Transportation Dept
CALTRANS.STATE.CA.US <== state Transportation Dept
DMV.STATE.CA.US <== state Motor Vehicles Dept
Culver-City.DMV.STATE.CA.US <== local office of DMV
Police.CI.Culver-City.CA.US <== city department
Fire-Dept.CI.Los-Angeles.CA.US <== city department
Fire-Dept.CO.Los-Angeles.CA.US <== county department
Main.Library.CI.Los-Angeles.CA.US <== city department
MDR.Library.CO.Los-Angeles.CA.US <== county department
Huntington.LIB.CA.US <== private library
SMCC.Santa-Monica.CC.CA.US <== public community college
Trade-Tech.Los-Angeles.CC.CA.US <== public community college
Valley.Los-Angeles.CC.CA.US <== public community college
Hamilton.High.LA-Unified.K12.CA.US <== public school
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <== public school
John-Muir.Middle.Santa-Monica.K12.CA.US <== public school
St-Monicas.High.Santa-Monica.CA.US <== private school
Crossroads-School.Santa-Monica.CA.US <== private school
Mary-Ellens-Montessori-School.LA.CA.US <== private school
Progress-Learning-Center.PVT.K12.CA.US <== private school
Brick-and-Basket-Institute.TEC.CA.US <== technical college
Bunker-Hill.DISTRICT.Los-Angeles.CA.US <== local district
SCAQMD.DISTRICT.CA.US <== regional district
Berkeley.UC.STATE.CA.US <== "CAL"
Los-Angeles.UC.STATE.CA.US <== UCLA
Irvine.UC.STATE.CA.US <== UC Irvine
Northridge.CSU.STATE.CA.US <== CSUN
Los-Angeles.CSU.STATE.CA.US <== Cal State LA
Leland-Stanford-Jr-University.Stanford.CA.US <== private school
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY
To register a host in the US domain, the US Domain Template must be
sent to the US Domain Registrar (US-Domain@ISI.EDU). The first few
pages explain each question on the attached template. FILL OUT THE
TWO PAGE TEMPLATE AT THE END. Questions may be sent by electronic
mail to the above address, or by phone to Ann Cooper, USC/Information
Sciences Institute, (310) 822-1511.
(1) Please specify whether this is a new application, modification to
an existing registration, or deletion.
(2) The name of the domain. This is the name that will be used in
tables and lists associating the domain with the domain server
addresses. See RFC1480 - The US Domain for more details.
<host>.<city/locality>.<state>.US. = city/locality based names
<school>.<district>.K12.<state>.US. = kindergarten thru 12th grade
<school>.PVT.K12.<state>.US. = private K thru 12th grade
<school>.<locality>.<state>.US. = PVT sch opt: locality names
<school>.CC.<state>.US. = community colleges
<school>.TEC.<state>.US. = technical or vocational schools
<lib-name>.LIB.<state>.US. = libraries
<org-name>.STATE.<state>.US. = state government agencies
<org-name>.FED.US. = federal government agencies
<org-name>.DNI.US. = distributed national institutes
<org>.GEN.<state>.US. = statewide assoc,clubs,domain parks
For example: networthy.santa-clara.ca.us.
(3) The name of the entity represented, that is, the organization
being named. For example: The Networthy Corporation. Not the
name of the organization submitting the request.
(4) Please describe the domain 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.
(5) The date you expect the domain to be fully operational.
For every registration, we need both the Administrative and the
Technical contacts of a domain (questions 6 & 7) and we MUST have a
network mailbox for each. If you have a NIC handle (a unique NIC
database identifier) please enter it. (If you don't know what a NIC
handle is leave it blank). Also the title, mailing address, phone
number, organization, and network mailbox.
(6) The name of the administrative head of the "organization". The
administrator is the contact point for administrative and policy
questions about the domain. The Domain administrator should work
closely with the personnel he has designated as the "technical
contact" for his domain. In this example the Domain Administrator
would be the Administrator of the Networthy Corporation, not the
Administrator of the organization running the name server
(unless it is the same person).
(7) The name of the technical and zone contact. The technical and
zone contact handles the technical aspects of maintaining the
domain's name server and resolver software, and database files.
He keeps the name server running. More than likely, this person
would be the technical contact running the primary name server.
***********************************************************************
PLEASE READ: There are several types of registrations.
(a) Delegation (i.e., a portion of the US Domain name space is
given to an organization running name servers to support that
branch; For example, K12.TX.US, for all K12 schools in Texas).
For (a) answer questions 8 and 9.
(b) Direct Registration of an IP Host.
For (b) answer question 10.
(c) Direct Registration of a non-IP Host.
For (c) answer question 11 and 12.
***********************************************************************
QUESTIONS FOR DELEGATIONS
(8) PRIMARY SERVER Information. It is required to supply both the
Contact information as well as hardware/software information of
the primary name server.
(9)* SECONDARY SERVER Information. It is required to supply the
hardware and software information of all secondary name servers.
Domains must provide at least two independent servers that provide the
domain service for translating names to addresses for hosts in this
domain. If you are applying for a domain and a network number
assignment simultaneously and a host on your proposed network will be
used as a server for the domain, you must wait until you receive your
network number assignment and have given the server(s) a net- address
before sending in the domain application. Establishing the servers in
physically separate locations and on different PSNs and/or networks is
strongly recommended.
NOTE: For those applicants not able to run name servers, or for non-IP
hosts the Name Server information is not applicable. (See #10 and #11).
=======================================================================
QUESTION FOR DIRECT IP HOSTS (If you answered 8 & 9 do not answer
10, 11, or 12).
(10) What Domain Name System (DNS) Resource Records (RR) and values are
to be entered for your IP host (must have an "A" record).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Example: RRs for an INTERNET hosts.
(a) DOMAIN NAME (required)...: Networthy.Santa-Clara.CA.US.
(b) IP ADDRESS (required)....: A 128.9.3.123 (required)
(c) HARDWARE (opt)...........: SUN-3/11O
(d) OPERATING SYS (opt)......: UNIX
(e) WKS (opt)........: 128.9.3.123. UDP (echo tftp) TCP (ftp)
(f) MX (opt).................: 10 RELAY.ISI.EDU.
It is your responsibility to see that an IN-ADDR pointer record is
entered in the DNS database. (For Internet hosts only). Contact the
administrator of the IP network your host is on to have this done.
The US Domain administration does not administer the network and
cannot make these entries in the DNS database.
=======================================================================
QUESTIONS FOR NON-IP HOSTS (such as UUCP).
Many applicants have hosts in the UUCP world. Some are one hop away,
some two and three hops away from their "Internet Forwarder", this is
ok. What is important is getting an Internet host to be your
forwarder. If you do not already have an Internet forwarder, there
are several businesses that provide this service for a fee, (see
RFC1359 - Connecting to the Internet What Connecting Institutions
Should Anticipate, ACM SIGUCCS, August 1992). Sometimes local colleges
in your area are already on the Internet and may be willing to act
as an Internet Forwarder. You would need to work this out with the
systems administrator. We cannot make these arrangements for you.
(11) Internet Forwarding Host Information
(11a) What is the name of your Internet forwarding host?
For example: The host Yacht-Club.MDR.CA.US uses
UUCP to connect to RELAY.ISI.EDU which is an Internet
host. (i.e., RELAY.ISI.EDU is the forwarding host).
(11b) What is the name of your contact person at forwarding host?
The Administrator of RELAY.ISI.EDU must agree to be the
forwarding host for Yacht-Club.MDR.CA.US, and the
forwarding host must know a delivery method and route to
Networthy. No double MXing.
(11c) What is the mailbox of your contact?
What is the mailbox of the administrator of the forwarding
host.
Example: Contact Name......: John Smith
Contact Email.....: js@RELAY.ISI.EDU
(12) What Domain Name System (DNS) Resource Records (RR) and values
are to be entered for your NON-IP host.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Example: RRs for a NON-IP host (uucp).
(a) DOMAIN NAME (required).....: Yacht-Club.MDR.CA.US.
(b) HARDWARE (opt).............: SUN-3/11O
(c) OPERATING SYS (opt)........: UNIX
(d) MX (required)..............: 10 RELAY.ISI.EDU.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
PLEASE ALLOW AT LEAST 8 WORKING DAYS FOR PROCESSING THIS APPLICATION
US DOMAIN TEMPLATE [6/93]
PLEASE SUBMIT THE FOLLOWING TWO PAGE TEMPLATE TO (Us-Domain@isi.edu).
Sections or fields of this form marked with an asterisk (*) may be
copied as many times as necessary. (For example: If you had two phone
numbers for the Administrative Contact, you would use the same number
"6h" twice. PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY.
=====================================================================
1. REGISTRATION TYPE
(N)ew (M)odify (D)elete..:
2.* FULLY-QUALIFIED DOMAIN NAME:
3. ORGANIZATION INFORMATION
3a. Organization Name.....:
3b. Address Line 1........:
3b. Address Line 2........:
3c. City..................:
3d. State.................:
3e. Zip/Code..............:
4. DESCRIPTION OF ORG/DOMAIN:
5. Date Operational......:
6. ADMINISTRATIVE CONTACT OF ORG/DOMAIN
6a. NIChandle (if known)..:
6b. Whole Name............:
6c. Organization Name.....:
6d. Address Line 1........:
6d. Address Line 2........:
6e. City..................:
6f. State.................:
6g. Zip/Code..............:
6h.* Voice Phone...........:
6i.* Electronic Mailbox....:
7. TECHNICAL AND ZONE CONTACT
7a. NIChandle (if known)..:
7b. Whole Name............:
7c. Organization Name.....:
7d. Address Line 1........:
7d. Address Line 2........:
7e. City..................:
7f. State.................:
7g. Zip/Code..............:
7h.* Voice Phone...........:
7i.* Electronic Mailbox....:
FILL OUT QUESTIONS 8 AND 9 FOR DELEGATIONS ONLY (i.e., those
organizations running name servers for a branch of the US Domain
name space, for example: k12.<state>.us).
8. PRIMARY SERVER: CONTACT INFO, HOSTNAME, NETADDRESS
8a. NIChandle (if known)..:
8b. Whole Name............:
8c. Organization Name.....:
8d. Address Line 1........:
8d. Address Line 2........:
8e. City..................:
8f. State.................:
8g. Zip/Code..............:
8h.* Voice Phone...........:
8i.* Electronic Mailbox....:
8j. Hostname..............:
8k.* IP Address............:
8l.* HARDWARE..............:
8m.* OPERATING SYS.........:
9. * SECONDARY SERVER: HOSTNAME, NETADDRESS
9a.* Hostname..............:
9b.* IP Address............:
9c.* HARDWARE..............:
9d.* OPERATING SYS.........:
FILL OUT QUESTION 10 FOR DIRECT REGISTRATIONS IP HOSTS
10. RESOURCE RECORDS (RRs) FOR IP INTERNET HOSTS
10a. DOMAIN NAME...........:
10b.* IP ADDRESS (required).:
10c. HARDWARE..............:
10d. OPERATING SYS.........:
10e. WKS ..................:
10f.* MX....................:
FILL OUT QUESTIONS 11 AND 12 FOR NON-IP HOSTS (such as UUCP)
11. FORWARDING HOST INFORMATION
11a. Forwarding Host......:
11b. Contact Name.........:
11c. Contact Email........:
12. RESOURCE RECORDS (RRs) FOR NON-IP HOSTS (UUCP)
12a. DOMAIN NAME...........:
12b. HARDWARE..............:
12c. OPERATING SYS.........:
12d.* MX (required).........: