💾 Archived View for spam.works › mirrors › textfiles › internet › us_domai.txt captured on 2023-11-14 at 10:26:45.
⬅️ Previous capture (2023-06-16)
-=-=-=-=-=-=-
[netinfo/us-domain.txt]
The US Domain
=============
Introduction:
The US domain is an official top-level domain in the Domain Name
System (DNS) of the Internet community. It is registered with the
Network Information Center (DDN-NIC). The domain administrators are
Jon Postel and Ann Westine Cooper at the Information Sciences
Institute of the University of Southern California (USC-ISI).
The US domain hierarchy is based on political geography, that is, the US
domain is subdivided into states, then cities, and so on. Any computer
in the United States may be registered in the US domain.
Typical host names in the US domain are:
VIXIE.SF.CA.US
DOGWOOD.ATL.GA.US
KILLER.DALLAS.TX.US
HOLODEK.SANTA-CRUZ.CA.US
GRIAN.CPS.ALTADENA.CA.US
Membership:
Because many computers in the United States are already registered in
the COM, EDU, and other top level domains, relatively few computers are
currently registered in the US domain. However the US Domain is
beginning to grow.
In the past the computers registered the US Domain were primarily
owned by small companies or individuals (and often located in homes).
It is expected than many more computers of all types and belonging to
all sizes of organizations will be registered in the US Domain.
Large organizations or companies are also encouraged to register in
the US Domain. Typically these have many hosts and will operate their
own DNS name servers. The US Domain will delegate an appropriate part
of the name space to such large organizations on the same terms as the
NIC requires for delegations of portions of the COM or EDU domains.
Administration:
Currently, the US Domain and all of its subdivisions (i.e., states,
cities etc.) are managed by the US Domain Registrar. The US Domain is
just beginning to grow and we want to be careful about what names get
used and how control is allocated until some usage patterns are
established. We will run the servers for all the states in the US
domain.
Registration of a host in the US domain does not grant permission to use
the Internet or its component networks. Any restrictions on sending
mail through (or other use of) the Internet is independent of host
registration in the US domain. Registration in the US domain does not
allocate any IP address, or cause registration in HOSTS.TXT.
There is no change in the procedures for registration in, or operation
of, other top-level domains such as COM, EDU, GOV, MIL, NET, or ORG.
These domains are not being moved under the US domain.
Delegation:
At some future point we will hand off the administration of individual
states to appropriate responsible people, probably in the state they
administer. Early experience shows that delegation of cities and of
companies within cities is most practical. The delegated part of the
name space will most likely be in the form of
<org-name>.<city>.<state>.US.
For example: IBM.ARMONK.NY.US.
Generally, organizations requesting delegations must provide at least
two independent DNS name servers in physically separate locations on
the Internet that provide the the domain service for translating names
to addresses in this domain.
The state codes are those assigned by the US Postal Service. Cities
may be named (designated) by their full name (spelled out with hyphens
replacing spaces (e.g., Los-Angeles or New-York)), or by a city code.
The first choice is the full city name, the second choice is the city
codes from Western Union's "City Mnemonics" list, and a third choice
is a code for your city that you choose. However, it is very
desirable that all users in the same city use the same designator for
the city.
For example: Joes-Bar.Santa-Monica.CA.US
Groups:
The administrator of a company or the organizer of a group (or "domain
park") of users with individual hosts may coordinate the registration of
the group by forwarding all the information for the group to the US
Domain Administrator.
In this case, the explicit specific information for each host must be
provided. All fully qualified names must be unique. If a host is not
directly on the Internet an MX record is required pointing to an
Internet host for forwarding. The forwarding host must be directly on
the Internet (that is, have an IP address), no "double MX-ing" is
allowed.
A group coordinator of, for example, the Computer Club in Chicago (CLUB),
could arrange to coordinate the registration of all the computers used
by members of the club. The registered names might have the form:
ALPHA.CLUB.CHI.IL.US MX 10 CS.CHICAGO-U.EDU
Only hosts on the Internet can act as forwarding hosts. Hosts on
networks such as UUCP, and BITNET, must be registered with an
Internet forwarding host. When registering a destination host in the US
domain with an MX record, the requester is responsible for also
registering the destination host with the administrator of the
forwarding host.
For example, when a message is sent to "Susan@ALPHA.CLUB.CHI.IL.US"
it will be routed to the Internet host "CS.CHICAGO-U.EDU" as directed
by the MX record. The host "CS.CHICAGO-U.EDU" must know some way of
delivering the message to the host "ALPHA.CLUB.CHI.IL.US" (uucp, slip,
whatever). So the destination host (ALPHA.CLUB.CHI.IL.US) must be
known to (registered with) the forwarding host (CS.CHICAGO-U.EDU), as
well as being registered in the US domain DNS database.
The administrator of the destination host must make an agreement with
the administrator of the forwarding host for the forwarding service.
This agreement must be in place before the request for registration is
sent to the US Domain Administrator.
Other Networks:
A section of the DNS database is called a "zone". With careful
coordination, a domain (like EDU) can be divided into several zones.
This has been done for the EDU and COM domains to aid in the
registration of hosts from the UUCP, and BITNET communities. If
a host is registered in the UUCP, or BITNET, portion of a domain (as
something.EDU or something.COM), it need not be registered in the US
domain, unless a geographical name (something.city.state.US) is
desired.
If a host is in a UUCP, or BITNET, network, it doesn't need to
register in the US domain, unless it wants to be registered with a
geographical DNS domain name.
Only hosts on the Internet can act as forwarding hosts. Hosts on
networks such as UUCP,or BITNET, etc., must affiliate their hosts
with an Internet host. This is necessary because when messages for
your host arrive at the Internet host it will need to know where to
forward them. MX records are necessary.
Unique Name:
It is the policy that a computer must have a single primary name, so it
should not be registered in both US and COM (or both US and EDU). It is
possible to have "nicknames" for a brief period while a host name change
is in progress.
Wild Cards:
While we 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 wild cards should not be used), we also realize that not
everyone agrees with this belief. Thus, we will allow wild card
records in the US domain under groups or organizations. For example,
"*.BIRDSONG.SUVL.CA.US".
Servers:
The US domain is currently supported by four name servers:
VENERA.ISI.EDU, VAXA.ISI.EDU, HERCULES.CSL.SRI.COM, and NNSC.NSF.NET.
Cost:
Currently, there is no cost for registering a host in the US domain.
References:
RFC-974, Partridge, C., "Mail Routing and the Domain Name System".
RFC-1034, Mockapetris, P., "Domain Names - Concepts and Facilities".
RFC-1035, Mockapetris, P., "Domain Names - Implementation and Specification".
Registration:
To register in the US Domain send a message to the US Domain Registrar
(Cooper@ISI.EDU). The response will be a US Domain Questionnaire for
you to fill out.
In several cities a "coordinator" has volunteered to process requests
locally and communicate with the US Domain Registrar on behalf of all
interested users in that city, or organization within that city. If
in your request we see that you are in a city or organization with a
coordinator we will refer you to that coordinator.
More Information:
For more information about the US domain please contact:
Ann Westine Cooper at (COOPER@ISI.EDU).
August 1990
US DOMAIN QUESTIONNAIRE FOR HOST ENTRY
To register a host in the US domain, the following information must be
sent to the US Domain Registrar, Ann Westine Cooper (COOPER@ISI.EDU).
Questions may be sent by electronic mail to the above address, or by
phone at (213-822- 1511).
(1) The name of the top-level domain to join.
For example: US
(2) The name of the administrative head of the organization, including
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
Postel & Cooper [Page 1]
Domain Questionnaire August 1991
(3) The name of the technical contact for the entry, including 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 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
(4) The name of the host. 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: NetWorthy.Santa-Clara.CA.US
Or: Alpha.NetWorthy.Santa-Clara.CA.US
Beta.NetWorthy.Santa-Clara.CA.US
(5) If this machine is not directly on the internet, how does it
communicate with the Internet. Through UUCP, CREN, etc? Which
forwarding host?
For example: The host "Networthy.Santa-Clara.CA.US" uses UUCP
to connect to "RELAY.ISI.EDU" which is an Internet host.
The administrator of RELAY.ISI.EDU must agree to be the
forwarding host for Networthy.Santa-Clara.CA.US, and the
forwarding host must know a delivery method and route to it.
No double MXing.
Postel & Cooper [Page 2]
Domain Questionnaire August 1991
If you are requesting an indirect connection, that is, a Mail
Exchanger (MX) record, what is the name and mailbox of the
administrator of the forwarding host.
For example:John Smith
js@RELAY.ISI.EDU
(6) 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.
(7) What Domain Name System (DNS) Resource Records (RR) and values are
to be entered.
a. A Internet Address (internet hosts only)
b. HINFO Host Information, Machine System
c. WKS Well Known Services, Protocols, Ports (internet hosts only)
d. MX Mail Exchanger (required for UUCP, and CREN hosts)
An example of RRs for an internet host.
NetWorthy.Santa-Clara.CA.US IN A 128.9.3.123
IN HINFO SUN-3/11OC UNIX
IN MX 10 ISI.EDU
IN WKS 128.9.3.123. UDP (echo
tftp)
IN WKS 128.9.3.133. TCP (telnet
ftp
tftp
finger)
An example of RRs for a non-internet host.
Beta.NetWorthy.Santa-Clara.CA.US MX 10 RELAY.ISI.EDU
HINFO SUN-3/11OC UNIX
Postel & Cooper [Page 3]
Domain Questionnaire August 1991
(8) Where is the IN-ADDR pointer record to be entered. (For internet
hosts only.) It is your responsibility to see that this is done.
Contact the administrator of the IP network your host is on.
For example:
123.3.9.128.IN-ADDR.ARPA. PTR NetWorthy.Santa-Clara.CA.US
Who is the contact for the zone of the IN-ADDR.ARPA data, where
this record will be entered?
(9) What Time to Live (TTL)? TTL is the time (in seconds) that a
resolver will use the data it got from the domain server before it
asks it again for the data. A typical TTL is One Week 604800.
(NOTE: TTL is not applicable to non-Internet hosts.)
For example:
One Week 604800
Postel & Cooper [Page 4]