As per Relevance of the word register, we have this rfc below:
Network Working Group A.
Request for Comments: 1480 J.
Obsoletes: 1386 June 1993
The US
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
Table of
1. Introduction ................................................ 2
1.1 The Internet Domain Name System......................... 2
1.2 Top-Level Domains....................................... 3
1.3 The US Domain .......................................... 4
2. Naming Structure ............................................ 4
2.1 State Codes ............................................ 8
2.2 Locality Names.......................................... 8
2.3 Schools ................................................ 10
2.4 State Agencies.......................................... 15
2.5 Federal Agencies ....................................... 15
2.6 Distributed National Institutes......................... 15
2.7 General Independent Entities............................ 16
2.8 Examples of Names....................................... 17
3. Registration ................................................ 20
3.1 Requirements ........................................... 20
3.2 Direct Entries ......................................... 21
3.2.1 IP-Hosts............................................. 21
3.2.2 Non-IP Hosts ........................................ 21
3.3 Delegated Subdomains ................................... 24
3.3.1 Delegation Requirement............................... 26
3.3.2 Delegation Procedures ............................... 28
3.3.3 Subdomain Contacts................................... 29
4. Database Information......................................... 30
4.1 Name Servers ........................................... 30
4.2 Zone files ............................................. 30
4.3 Resource Records ....................................... 31
4.3.1 "A" Records ......................................... 32
4.3.2 CNAME Records ....................................... 32
4.3.3 MX Records .......................................... 33
4.3.4 HINFO Records ....................................... 33
4.3.5 PTR Records ......................................... 33
4.4 Wildcards .............................................. 34
5. References .................................................. 35
Cooper & Postel [Page 1]
RFC 1480 The US Domain June 1993
6. Security Considerations ..................................... 35
7. Authors' Addresses .......................................... 36
Appendix-I: US Domain Names BNF................................. 37
Appendix-II: US Domain Questionnaire ............................ 42
1.
1.1 The Internet Domain Name
The Domain Name System (DNS) provides for the translation
hostnames and addresses. Within the Internet, this means
from a name such as "venera.isi.edu", to an IP address such
"128.9.0.32". The DNS is a set of protocols and databases.
protocols define the syntax and semantics for a query language to
questions about information located by DNS-style names.
databases are distributed and replicated. There is no dependence
a single central server, and each part of the database is provided
at least two servers
The assignment of the 32-bit IP addresses is a separate activity.
addresses are delegated by the central Internet Registry to
authorities (such as the RIPE NCC for Europe) and the
providers
To have a network number assigned please contact your network
provider or regional registration authority. To determine who
is (or as a last resort), you can contact the central
Registry at Hostmaster@INTERNIC.NET
In addition to translating names to addresses for hosts that are
the Internet, the DNS provides for registering DNS-style names
other hosts reachable (via electronic mail) through gateways or
relays. The records for such name registrations point to an
host (one with an IP address) that acts as a mail forwarder for
registered host. For example, the host "bah.rochester.ny.us"
registered in the DNS with a pointer to the mail
"relay1.uu.net". This type of pointer is called an MX record
This gives electronic mail users a uniform mail addressing syntax
avoids making users aware of the underlying network boundaries
The reason for the development of the domain system was growth in
Internet. The hostname to address mappings were maintained by
InterNIC in a single file, called HOSTS.TXT, which was FTP'd by
the hosts on the Internet. The network population was changing
character. The time-share hosts that made up the original
were being replaced with local networks of workstations.
organizations were administering their own names and addresses,
Cooper & Postel [Page 2]
RFC 1480 The US Domain June 1993
had to wait for the NIC to make changes in HOSTS.TXT to make
changes visible to the Internet at large. Organizations also
some local structure on the name space. The applications on
Internet were getting more sophisticated and creating a need
general purpose name service. The idea of a hierarchical name space
with the hierarchy roughly corresponding to organizational structure
and names using "." as the character to mark the boundary
hierarchy levels was developed. A design using a
database and generalized resources was implemented
The DNS provides standard formats for resource data, standard
for querying the database, and standard methods for name servers
refresh local data from other name servers
1.2 Top-Level
The top-level domains in the DNS are EDU, COM, GOV, MIL, ORG, INT
and NET, and all the 2-letter country codes from the list
countries in ISO-3166. The establishment of new top-level domains
managed by the Internet Assigned Numbers Authority (IANA). The
may be contacted at IANA@ISI.EDU
Even though the original intention was that any
institution anywhere in the world could be registered under the
domain, in practice, it has turned out with few exceptions,
those in the United States have registered under EDU, similarly
COM (for commercial). In other countries, everything is
under the 2-letter country code, often with some subdivision.
example, in Korea (KR) the second level names are AC for
community, CO for commercial, GO for government, and RE for research
However, each country may go its own way about organizing its domain
and many have
There are no current plans of putting all of the
domains EDU, GOV, COM, etc., under US. These name tokens are
used in the US Domain to avoid confusion
Currently, only four year colleges and universities are
registered in the EDU domain. All other schools are being
in the US Domain
There are also concerns about the size of the other top-level
(especially COM) and ideas are being considered for restructuring
Other names sometimes appear as top-level domain names. Some
have made up names in the DNS-style without coordinating
registering with the DNS management. Some names that
appear are BITNET, UUCP, and two-letter codes for continents, such
Cooper & Postel [Page 3]
RFC 1480 The US Domain June 1993
"NA" for North America (this conflicts with the official
code for Namibia).
For example, the DNS-style name "KA7EEJ.CO.USA.NA" is used in
amateur radio network. These addresses are never supposed to show
on the Internet but they do occasionally. The amateur radio
people created their own naming scheme, and it interferes
with Internet addresses
1.3 The US
The US Domain is an official top-level domain in the DNS of
Internet community. The domain administrators are Jon Postel and
Westine Cooper at the Information Sciences Institute of
University of Southern California (USC-ISI).
US is the ISO-3166 2-letter country code for the United States
thus the US Domain is established as a top-level domain
registered with the InterNIC the same way other country domains are
Because organizations in the United States have registered
in the EDU and COM domains, little use was initially made of the
domain. In the past, the computers registered in the US Domain
primarily owned by small companies or individuals with computers
home. However, the US Domain has grown and currently registers
in federal government agencies, state government agencies, K12
schools, community colleges, technical/vocational schools,
schools, libraries, city and county government agencies, to name
few
Initially, the administration of the US Domain was managed solely
the Domain Registrar. However, due to the increase in registrations
administration of subdomains is being delegated to others
Any computer in the United States may be registered in the US Domain
2. NAMING
The US Domain hierarchy is based on political geography. The
name space under US is the state name space, then the "locality"
space, (like a city, or county) then organization or computer
and so on
For example
BERKELEY.CA.
PORTLAND.WA.
Cooper & Postel [Page 4]
RFC 1480 The US Domain June 1993
There is of course no problem with running out of names
The things that are named are individual computers
If you register now in one city and then move, the database can
updated with a new name in your new city, and a pointer can be set
from your old name to your new name. This type of pointer is
a CNAME record
The use of unregistered names is not effective and causes
for other users. Inventing your own name and using it
registering is not a good idea
In addition to strictly geographically names, some special names
used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC, CITY,
COUNTY. Several new name spaces have been created, DNI, GEN,
TEC, and a minor change under the "locality" name space was made
the existing CITY and COUNTY subdomains by abbreviating them to
and CO. A detailed description follows
Below US, Parallel to States
-----------------------------
"FED" - This branch may be used for agencies of the
government. For example: ..FED.
"DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch
created directly under the top-level US. This branch is to be
for distributed national institutes; organizations that span state
regional, and other organizational boundaries; that are national
scope, and have distributed facilities. For example
.DNI.US
Name Space Within States
------------------------
"locality" - cities, counties, parishes, and townships.
under the "locality" would be like CI...US
CO...US, or businesses. For example
Petville.Marvista.CA.US
"CI" - This branch is used for city government agencies and is
subdomain under the "locality" name (like Los Angeles). For example
Fire-Dept.CI.Los-Angeles.CA.US
"CO" - This branch is used for county government agencies and is
subdomain under the "locality" name (like Los Angeles). For example
Fire-Dept.CO.San-Diego.CA.US
Cooper & Postel [Page 5]
RFC 1480 The US Domain June 1993
"K12" - This branch may be used for public school districts.
special name "PVT" can be used in the place of a school district
for private schools. For example: .K12..US
.PVT.K12..US
"CC" - COMMUNITY COLLEGES - This branch was established for all
wide community colleges. For example: .CC..US
"TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC"
established for technical and vocational schools and colleges.
example: .TEC..US
"LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch
be used for libraries only. For example: .LIB..US
"STATE" - This branch may be used for state government agencies.
example: .STATE..US
"GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the
that don't fit easily into any other structure listed -- things
might fit in to something like ORG at the top-level. It is best
to use the same keywords (ORG, EDU, COM, etc.) that are used at
top-level to avoid confusion. GEN would be used for such things as
state-wide organizations, clubs, or domain parks. For example
.GEN..US
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VIEW OF SECOND LEVEL DOMAINS UNDER
+-------+
| US |
+-------+
|
+----------------------------------+
| | | | |
+-----+ +-----+ +-----+ +-----+ +-----+
| FED | | DNI | | TX | | SD | | CA |
+-----+ +-----+ +-----+ +-----+ +-----+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Cooper & Postel [Page 6]
RFC 1480 The US Domain June 1993
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SCHOOL AND LIBRARY
+-----+
| CA |
+-----+
|
+------------------------------------------------+
| | | | |
+-----+ +-----+ +-----+ +-------------+ +-----+
| K12 | | CC | | TEC | | LOS ANGELES | | LIB |
+-----+ +-----+ +-----+ +-------------+ +-----+
/ \ /|\ /|\ /|\ /|\
+--------+ +---+ +---+ +--------+ +----------+ +------+
|sch dist| |PVT| |SJC| |WM TRADE| |pvt school| |MALIBU
+--------+ +---+ +---+ +--------+ +----------+ +------+
/|\ /|\
+--------+ +--------+
|sch name| |sch name
+--------+ +--------+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VIEW OF STATE, REGIONAL, and GENERAL
+-----+
| CA |
+-----+
|
+-------------------------+
| | |
+-------+ +--------+ +-----+
| STATE | |DISTRICT| | GEN |
+-------+ +--------+ +-----+
/|\ /|\ /|\
+--------+ +------+ +---------+
|CALTRANS| |SCAQMD| |domain pk
---------+ +------+ +---------+
|
+--------+
|TCEW100E
+--------+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Cooper & Postel [Page 7]
RFC 1480 The US Domain June 1993
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VIEW OF
+-----+
| CA |
+-----+
|
+-----------------------------------+
| |
+-------------------------+ +----------------+
| LOS ANGELES | | SANTA MONICA |
+-------------------------+ +----------------+
/ | | /|\ | /|\
/ | | | | |
+---+ +--+ +--+ +-----------+ +--+ +---+
|bus| |CI| |CO| | pvt school| |CI| |bus
+---+ +--+ +--+ +-----------+ +--+ +---+
/\ | |
/ \ | +------------+
/ \ | |HARBOR GUARD
/ \ | +------------+
+-----+ +-----+ +-----+ +----+
|FIRE | |ADMIN| |PARKS| |FIRE
+-----+ +-----+ +-----+ +----+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2.1 State
The state codes are the two letter US Postal abbreviations.
example: "CA" California
2.2 Locality
Within the state name space there are "locality" names, some may
cities, some may be counties, some may be local names, but
incorporated entities
Registered names under "locality" could be like
<hostname>.CI.<locality>..US ==> city gov't
<hostname>.CO.<locality>..US, ==> county gov't
<hostname>.<locality>..US ==>
In the cases where the locality name is a county, there is a
under the locality name, called "county" or "CO", that is used by
county government. Businesses are registered directly under
locality name
Cooper & Postel [Page 8]
RFC 1480 The US Domain June 1993
Under the city locality name space there is a "city" or "CI"
for city government agencies. As usual, businesses and
schools may register directly under the city name
In the case where there is both a county and a city with the
locality name there is no problem, since the names will be
with the "CO" or "CI" keyword. In our area the county has a
department and the city has its own fire department. They could
names like
Fire-Dept.CI.Los-Angeles.CA.
Fire-Dept.CO.Los-Angeles.CA.
Cities may be named (designated) by their full name (spelled out
hyphens replacing spaces (e.g., Los-Angeles or Fort-Collins), or by
city code. The first choice is the full city name. In some cases
may be appropriate to use the well-known city abbreviation
throughout a locality. However, it is very desirable that all
in the same city use the same designator for the city. That is,
particular locality should have just one DNS name
Some users would like names associated with a greater
area or region like the "Bay Area" or "Tri-Cities". One problem
this is that these names are not necessarily unique within a state
The best thing to do in this case is to use the larger
city in your hostname. Cities and counties are used
Should all the names be obvious? Trying to do this is desirable
also impossible. There will come a point when the obviously
name for an organization is already taken. As the system grows
will happen with increasing frequency. While ease of use to the
user is desirable, a higher priority must be placed on having
system that operates. This means that the manageability of
system must have high consideration
The reason the DNS was created was to subdivide the problem
maintaining a list of hosts in the Internet into manageable portions
The happy result is that this subdivision makes name
easier and promotes logical grouping. What is a "logical grouping
though, always depends on the viewer
Many levels of delegation are needed to keep the zone
manageable. Many sections of the name space are needed to
unique names to be easily added
Cooper & Postel [Page 9]
RFC 1480 The US Domain June 1993
Way back in the olden days, when the Internet was invented,
thought that an 8-bit network number would be more than enough
number all the networks that would ever exist. Today, there are
10,000 networks operating in the Internet, and arguments are
about the doubling time being 2 years versus 4 years
One concern is that things will continue to grow dramatically,
this will require more subdivision of the domain name management
Maybe the plan for the US Domain is overkill on growth planning,
there has never been overplanning for growth yet
When things are bigger, names have to be longer. There is
argument that with only 8-character names, and in each position
a-z, 0-9, and -, you get 37**8 = 3,512,479,453,921 or 3.5
possible names. It is a great argument, but how many of us
names like "xs4gp-7q". It is like license plate numbers, sure
people get the name they want on a vanity plate, but a lot
people who want something specific on a vanity plate can't get
because someone else got it first. Structure and longer names
let more people get their "obviously right" name
2.3
K12 schools are connecting to the Internet and registering in
Internet DNS. A decision has been made by the IANA (
consultation with the new InterNIC Internet Registry and the
Networking Council (FNC)) to direct these school registrations to
US domain using the naming structure described here
There is a need for competent, experienced, volunteers to
forward to act as third and perhaps fourth level registries and
operate delegated portions of the DNS
There are two reasons for registering schools in the US Domain. (1)
uniqueness of names, and (2) management of the database
1. Name Uniqueness
There are many "Washington" high schools, only one can
"Washington.EDU" (actually none can be, since that name is
by a University. There will be many name conflicts if
schools attempt to register directly under EDU
In addition, in some districts, the same school name is used
different levels, for example, Washington Elementary School
Washington High School. We suggest that when necessary,
keywords "Elementary", "Middle", and "High" be used
distinguish these schools. These keywords would only be
Cooper & Postel [Page 10]
RFC 1480 The US Domain June 1993
when they are needed, if the school's name is unique
such keywords, don't use them
2. Database Management
One goal of the DNS is to divide up the management of the
database in to small pieces. Each piece (or "zone" in
terminology) could be managed by a distinct administrator
Adding all the high schools to the EDU domain will make
already large zone file for EDU even larger, possibly to
point of being unmanageable
For both these reasons it is necessary to introduce structure
names. Structure provides a basis for making common names unique
context, and for dividing the management responsibility
The US Domain has a framework established and has registered
schools already in this structured scheme. The general form is
.<district>.K12..US
For example: Hamilton.LA-Unified.K12.CA.
Public schools are usually organized by districts which can be
or smaller than a city or county. For example, the Portland
district in Oregon, is in three or four counties. Each of
counties also has non-Portland districts
It makes sense to name schools within districts. However
often have the same name as a city or county so there has to be a
to distinguish a public school district name from some other type
locality name. The keyword "K12" is used for this
For example, typical K12 school names currently used are
IVY.PRS.K12.NJ.
DMHS.JCPS.K12.KY.
OHS.EUNION.K12.CA.
BOHS.BREA.K12.CA.
These names are generally longer than the old alternative of
names in the EDU domain, but that would not have lasted long
a significant number of schools finding that their "
correct" name has already been used by some other school
Cooper & Postel [Page 11]
RFC 1480 The US Domain June 1993
When there are many things to name some of the names will be long
In some cases there may be appropriate abbreviations that can
used. For example Hamilton High School in Los Angeles could be
Hami.Hi.LA.K12.CA.
If a school has a number of PCs, then each PC should have a name
Suppose they are named "alpha", "beta", ... then if they belong to
school named "Lincoln.High.Lakewood.K12.CA.US" their names would be
alpha.Lincoln.High.Lakewood.K12.CA.US
beta.Lincoln.High.Lakewood.K12.CA.
...
The K12 subdomain provides two points at which to delegate a
of the database to distinct administrators -- the K12
for each state, and the district administrator for each
within a state
The US Domain Administrator will delegate a branch of the US
to an appropriate party. In some cases, this may be a
school, a school district, or ever all of K12 for a state
The responsibility for managing a K12 branch or sub-branch may
delegated to an appropriate volunteer. We envision that
delegations of the schools' DNS service may eventually migrate
someone else "more appropriate" from an administrative
point of view. The "obvious" state agency to manage the schools'
branch may take some time to get up to speed on Internetting. In
meantime, we can have the more advanced schools up and running
Special Schools and Service
In many states, there are special schools that are not in
that are run directly by the state or by consortiums. There are
service units that provide "educational services" ranging from
and computers to janitorial supplies and building maintenance.
these service units do not have a one-to-one relationship
districts
There is some concern about naming these schools and service
within the naming structure for schools established in this memo
There are several possibilities. For a state with many service
creating a "pseudo district" ESU (or whatever, the common
is in that state) is a possibility. For example, the Johnson
unit could be JOHNSON.ESU.K12.CA.US. For a state with a few
service units (and avoiding conflicts with district names)
service units could be directly under K12. For example
Cooper & Postel [Page 12]
RFC 1480 The US Domain June 1993
TIES.K12.MN.US
The special public funded schools can be handled in a
fashion. If there are many special schools in a state, a "
district" should be established and all the special schools
under it. For example, suppose there is a "pseudo district"
Massachusetts called SPCL, and there is a special school called
Progressive Computer Institute, then that school could have the
PCI.SPCL.K12.MA.US. If there are only a few special schools,
can be listed directly under K12 (avoiding name conflicts
district names). For example, the California Academy of Math
Science is CAMS.K12.CA.US. CAMS is sponsored by seven schools,
California Department of Education, and a University
"PVT" Private
Private schools may be thought of as businesses. Public schools
in districts, and districts provide a natural
structure for naming and delegation. For private schools there
no districts and they really do operate like businesses. But,
people are upset to think about their children in a private
being in a business category and not in K12 with the rest of
children. To accommodate both public and private schools, in
state's K12 branch, we've added an artificial district called
or "PVT". This gives a private school the option of registering
a business under "locality" or in the PVT.K12..US branch
For example
Crossroads.PVT.K12.CA.
Crossroads-Santa-Monica.CA.
A public school "Oak High" in the "Woodward" school district
California would have a name like "Oak-High.Woodward.K12.CA.US".
A private school "Old Trail" in Pasadena, California could have
<locality> based name "Old-Trail.Pasadena.CA.US" or the
school base name "Old-Trail.PVT.K12.CA.US".
Some suggest that for private schools instead of a special
district PVT to use a locality name. One reason to use
names is that, in time, it seems likely that school
administrators will take over the operation of the DNS for
district. One needs to be able to delegate at that branch point
One implication of delegation is that the delegatee is now in
of a chunk of the name space and will be registering new names.
keep names unique one can't have two different people registering
things below identically named branches
Cooper & Postel [Page 13]
RFC 1480 The US Domain June 1993
For example, if there is a school district named Pasadena and a
named Pasadena, the branch of the name space PASADENA.K12.CA.US
be delegated to the administrator of that public school district.
a private school in Pasadena wanted to be registered in the DNS,
would have to get the public school district administrator to do
(perhaps unlikely) or not be in the K12 branch at all (unless
is the PVT pseudo district).
So, if private schools are registered
.<locality>.K12..US and public schools
registered by .<district>.K12..US, there can't
any locality names that are the same as district names or
delegation of these will get very tricky later
If it is all done by locality names rather than district names,
public and private schools are mixed together, then finding
appropriate party to delegate the locality to may be difficult
Another suggestion was that private schools be registered
under K12, while public schools must be under a district under K12.
This would require the operator of the K12 branch to register
districts and private schools himself (checking for name uniqueness),
he couldn't easily delegate the registration of the private
to anyone else
Community Colleges and Technical
To distinguish Community Colleges and Technical/Vocational schools
the keywords "CC" and "TEC" have been created
Some School
Hamilton.High.LA-Unified.K12.CA.US <== a public
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <== a public
John-Muir.Middle.Santa-Monica.K12.CA.US <== a public
Crossroads-School.Santa-Monica.CA.US <== a private
SMCC.CC.CA.US <== a community
TECMCC.CC.CA.US <== a community
Brick-and-Basket-Institute.TEC.CA.US <== a technical
Northridge.CSU.STATE.CA.US <== a state
Cooper & Postel [Page 14]
RFC 1480 The US Domain June 1993
2.4 State
Several states are setting up networks to interconnect the offices
state government agencies. The hosts in such networks should
registered under the STATE..US branch
A US Domain name space has been established for the state
agencies. For example, in the State of Minnesota, the subdomain
STATE.MN.US
State Agencies
---------------
Senate.STATE.MN.US <== State
MDH.STATE.MN.US <== Dept. of
CALTRANS.STATE.CA.US <== Dept. of
DMV.STATE.CA.US <== Dept. of Motor
2.5 Federal
A federal name space has been established for the federal
agencies. For example, the subdomain for the Federal Reserve Bank
Minneapolis is MNPL.FRB.FED.US. Other examples are listed below
Federal Government Agencies
---------------------------
Senate.FED.US <==== US
DOD.FED.US <==== US Defense Dept
USPS.FED.US <==== US Postal
VA.FED.US <==== US Veterans
IRS.FED.US <==== US Internal Revenue
Yosemite.NPS.Interior.FED.US <==== A Federal
2.6 Distributed National
The "DNI" branch was created directly under the top-level US.
is to be used for organizations that span state, regional, and
organizational boundaries; are national in scope, and
distributed facilities. An example would be
Distributed National Institutes
--------------------------------
MetaCenter.DNI.US <==== The MetaCenter Supercomputer
Cooper & Postel [Page 15]
RFC 1480 The US Domain June 1993
The MetaCenter domain encompasses the four NSF
supercomputer centers. These are
San Diego Supercomputer Center (SDSC
National Center for Supercomputing Applications (NCSA
Pittsburgh Supercomputing Center (PSC
Cornell Theory Center (CTC
The MetaCenter Network will enable applications and services
file systems and archival storage to be operated in a
fashion; thus, allowing the resources at the four centers to
integrated and "seamless" to users of the centers
2.7 General Independent
This name space was created for organizations that don't really
anywhere else, such as state-wide associations, clubs, and "
parks". Think of this as the miscellaneous category
The examples are state-wide clubs. For example, the Garden Club
Arizona, might want to be "GARDEN.GEN.AZ.US". Such a club
membership from all over the state and is not associated with any
city (or locality). Another example is "domain parks" that have
established up-to-now as entities in ORG. For example, there
"LONESTAR.ORG", which is a kind of computer club in Texas that
lots of dial-in computers registered. In the US Domain such
entity might have a name like "LONESTAR.GEN.TX.US".
The organizations registered in GEN may typically be non-
entities. These organizations don't fit in a <locality> and are
a school, library, or state agency. Ordinary businesses are
registered in GEN
Some suggest that these kinds of organizations are just like all
other things and ought to be registered under some <locality>.
may be true, but sometimes one just can't find any way to
the applicant that it is the right thing to do. One can argue
any organization has to have a headquarters, or an office,
something about it that is in a fixed place, and thus
organization could be registered in that place
Some suggest that no token is needed, these entities could
directly under the . The problem with not having
token, is that you can't delegate the responsibility for
these entities to someone separate from whoever is responsible
the . You want to be able to delegate for both name
uniqueness reasons, and operational management reasons. Having
token there makes both easy
Cooper & Postel [Page 16]
RFC 1480 The US Domain June 1993
General Independent Entities
-----------------------------
CAL-Comp-Club.GEN.CA.US <==== The Computer Club of
2.8 Examples of
For small entities like individuals or small businesses, there
usually no problem with selecting locality based names
For example: Zuckys.Santa-Monica.CA.
For large entities like large corporations with
facilities in several cities or states this often seems like
unreasonable constraint (especially when compared with
alternative of registering directly in the COM domain). However
a company does have a headquarters office in a particular
and so could register with that name. Example: IBM.Armonk.NY.
PRIVATE (business or individual
================================
Camp-Curry.Yosemite.CA.US <==== a
IBM.Armonk.NY.US <==== a
Dogwood.atl.GA.US <==== a
Geo-Petrellis.Culver-City.CA.US <==== a
Zuckys.Santa-Monica.CA.US <==== a
Joe-Josts.Long-Beach.CA.US <==== a
Holodek.Santa-Cruz.CA.US <==== a personal
=======
Senate.FED.US <==== US
DOD.FED.US <==== US Defense Dept
DOT.FED.US <==== US Transportation Dept
USPS.FED.US <==== US Postal
VA.FED.US <==== US Veterans
IRS.FED.US <==== US Internal Revenue
Yosemite.NPS.Interior.FED.US <==== a federal
MNPL.FRB.FED.US. <==== US Fed. Reserve Bank of
Cooper & Postel [Page 17]
RFC 1480 The US Domain June 1993
=====
Senate.STATE.MN.US <==== state
House.STATE.MN.US <==== state House of
MDH.STATE.MN.US <==== state Health Dept
HUD.STATE.CA.US <==== state House and Urban Dev. 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 <==== a local office of
DNI (distributed national Institutes
======================================
METACENTER.DNI.US <==== a distributed nat'l Inst
GEN (General Independent Entities
==================================
GARDEN.GEN.AZ.US <==== a garden club of
CITY | CI | COUNTY | CO (locality
==================================
Parks.CI.Culver-City.CA.US <==== a city
Fire-Dept.CI.Los-Angeles.CA.US <==== a city
Fire-Dept.CO.Los-Angeles.CA.US <==== a county
Planning.CO.Fulton.GA.US. <==== a county
Main.Library.CI.Los-Angeles.CA.US <==== a city
MDR.Library.CO.Los-Angeles.CA.US <==== a county
TOWNSHIP | PARISH (locality
============================
Police.TOWNSHIP.Green.OH.US <==== a township
Administration.PARISH.Lafayette.LA.US <==== a parish
Cooper & Postel [Page 18]
RFC 1480 The US Domain June 1993
DISTRICT | LIBRARY (agency
============================
SCAQMD.DISTRICT.CA.US <==== a regional
Bunker-Hill-Improvement.DISTRICT.LA.CA.US <==== a local
Huntington.LIB.CA.US <==== a private
Venice.LA-City.LIB.CA.US <==== a city
MDR.LA-County.LIB.CA.US <==== a county
K12 | PRIVATE SCHOOLS (PVT) | CC |
======================================
Hamilton.High.LA-Unified.K12.CA.US <==== a public
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <==== a public K12
John-Muir.Middle.Santa-Monica.K12.CA.US <==== a public K12
Culver-High.CCSD.K12.CA.US <==== a public K12
St-Monica.High.Santa-Monica.CA.US <==== a private
Crossroads-School.Santa-Monica.CA.US <==== a private
Mary-Ellens.Montessori-School.LA.CA.US <==== a private
Progress-Learning-Center.PVT.K12.CA.US <==== a private
SMCC.Santa-Monica.CC.CA.US <==== a public community
Trade-Tech.Los-Angeles.CC.CA.US <==== a public community
Valley.Los-Angeles.CC.CA.US <==== a public community
Brick-and-Basket-Institute.TEC.CA.US <== a technical
When appropriate, subdomains are delegated and partioned
various categories, such as
<locality>..US = city/locality based
K12..US = kindergarten thru 12th
PVT.K12.
CC..US = community
TEC..US = technical or vocational
LIB..US =
STATE..US = state government
.FED.US = federal government
.DNI.US = distributed national
.GEN..US. = statewide assoc,clubs,domain
The Appendix-I contains the current US Domain Names BNF
Cooper & Postel [Page 19]
RFC 1480 The US Domain June 1993
3.
There are two types of registrations (1) Delegation, where a
of the US Domain is delegated to an organization running name
to support that branch; or (2) Direct Registration, in which
information is put directly into the main database
In Direct Registration there are two cases: (a) an IP-host (with
IP address), and (b) non-IP host (for example, a UUCP host).
particular registration will involve any one of these
situations
3.1
Anyone requesting to register a host in the US Domain is sent a
of the "Instructions for the US Domain Template", and must fill out
US Domain template
The US Domain template, is similar to the InterNIC Domain template
but it is not the same. To request a copy of the US Domain template
send a message to the US Domain registrar (us-domain@isi.edu).
If you are registering a name in a delegated zone, please
with the contact for that zone. You can FTP the file "in-notes/us
domain-delegated.txt" from venera.isi.edu, via anonymous FTP.
information is also available via email from RFC-INFO@ISI.
(include as the only text in the
"Help: us_domain_delegated_domains").
The key people must have electronic mailboxes (that work).
provide all the information indicated in the "Administrator"
"Technical Contact" slots
The administrator will be the point of contact for any
and policy questions about the domain. The administrator is
the person who manages the organization being registered
The technical contact can also be administrator, or the
person, or someone who is familiar with the technical details of
Internet. The technical contact should have a valid working
address. This is necessary in case something goes wrong
It is important that your "Return-Path" and "From" field indicate
Internet-style address. UUCP-style addresses such as "host1!user
will not work. This is fine within the UUCP world, but not
Internet. If you want people on the Internet to be able to send
to you, your return path needs to be an Internet-style address
as: host1!user@Internet.gateway.host or user@Internet.gateway.host
Cooper & Postel [Page 20]
RFC 1480 The US Domain June 1993
It is also possible to register through one of the Internet
providers that have established working relationships with the
Domain Administrator
If everything checks out, the turn around time for registering a
is usually a few days. The name servers are updated anywhere from 12
to 24 hours later
There are two ways to be registered in the US Domain, directly, or
delegation
3.2 Direct
Direct entry in the database of the US Domain appeals most
individuals and small companies. You may fill out the
and send it directly to the US Domain Administrator. If you are
an area where the zone is delegated to someone else your request
be forwarded to the zone administrator for your registration. Or
you may send the form directly to the manager of a delegated
(see Section 3.1).
3.2.1 IP-
These are hosts with IP addresses which correspond to "A" records
the DNS database
3.2.2 Non-IP
Many applicants have hosts in the UUCP world. Some are one hop away
some two and three hops away from their "Internet Forwarder", this
acceptable. What is important is getting an Internet host to be
forwarder. If you do not already have an Internet forwarder,
are several businesses that provide this service for a fee, such
UUNET.UU.NET (postmaster@uunet.uu.net), PSI (postmaster@UU2.PSI.COM
and CERFNET (help@cerf.net). Sometimes local colleges in your
are already on the Internet and may be willing to act as an
Forwarder. You would need to work this out with the
administrator as we cannot make these arrangements for you
Although we work with UUCP service providers, the Internet US
registration is not affiliated with the registration of UUCP
entries. The UUCP map entry does not provide us with
information. If you do not have a copy of the US
questionnaire template, please send a message to: us-domain@isi.
and request one. See Appendix-II
Cooper & Postel [Page 21]
RFC 1480 The US Domain June 1993
The example below is not an appropriate registration for the US Domain
#N
#S Amiga 2500; AmigaDOS 2.04; Dillon's AmigaUUCP 1.15
#O Starlight
#C Stephen
#E starl!
#T +1 305 378 1161
#P 1107 SW 200th St #303B Miami, Fl. 33157
#L 25 47 N / 88 10 W [city
#
#U
#W starl!sbaker (Stephen Baker); Mon Feb 24 19:58:24 EST 1992
starl mthvax(DAILY
If you are registering your host as a central site for a USENET
where other UUCP sites will feed from you, that's fine. These
sites do not need to register. If however, the other sites become
subdomain of your hostname, then we will need to register
individually or add a wildcard record. (See Section 4.4. Wildcards).
For example: bah.rochester.ny.
host1.bah.rochester.ny.
host2.bah.rochester.ny.
To use US Domain names for non-IP hosts, there must be a
host that is an IP host. There must be an administrative
and a technical procedure for relaying mail between the non-IP
and the forwarder host
Case 1:
-------
Your host is not an IP host but does talk directly with a host
is an IP host
+-----------------+
+----------+ +---------+ | |
|your-host |---UUCP-----|forwarder|----IP/TCP--| INTERNET |
+----------+ +---------+ | |
+-----------------+
"Forwarder" must be an IP host on the Internet
You must ask "forwarder" if they are willing to be the
forwarder for "your-host".
In the US Domain of the DNS data base there must be an entry
this
"your-host" MX 10 "forwarder
Cooper & Postel [Page 22]
RFC 1480 The US Domain June 1993
This must be entered by the US Domain Administrator
In the "forwarder" routing tables there must be information
"your-host" with a rule like: If I see mail for "your-host" I
send it via uucp by calling phone number "123-4567".
Case 2:
-------
In this case your hosts talks to another host that ... that talks
an IP host. In other words, there are multiple hops between your
and the Internet
+-----------------+
+----------+ +---------+ | |
|path-host |---UUCP-----|forwarder|----IP/TCP--| INTERNET |
+----------+ +---------+ | |
| +-----------------+
|
+----------+
|your-host |
+----------+
"Forwarder" must be an IP host on the Internet
You must ask "forwarder" if they are willing to be the
Forwarder for "Your-Host". You must ask "path-host" to relay
mail
In the US Domain of the DNS Database there must be an entry like this
"your-host" MX 10 "forwarder
This must be entered by the US Domain Administrator
In the "forwarder" routing tables there must be information
"your-host" with a rule like: If I see mail for "your-host" I
send it via UUCP to "path-host" by calling phone number "123-4567".
and "path-host" must also know how to relay the mail to "your-host".
Note: It is assumed that "path-host" is already MXed to "forwarder".
It is not appropriate to ask to MX "your-host" to "path-host" (
is sometimes called double MXing). The host on the right hand
of an MX entry must be a host on the Internet with an IP
(e.g., 128.9.2.32).
Cooper & Postel [Page 23]
RFC 1480 The US Domain June 1993
3.3 Delegated
Many branches of the US Domain are delegated. There must be
knowledgeable and competent technical contact, familiar with
Internet DNS. This requirement is easily satisified if the
contact already runs some other name servers
Examples of delegations are K12.TX.US for the Kindergarten
12th Grade public schools in Texas, the locality "berkeley.ca.us",
the LIB.MN.US branch for the libraries in Minnesota
The administrator of the US Domain is responsible for the
of all the DNS names that end with ".US". Of course, one person
even one group can't handle all this in the long run so portions
the name space are delegated to others
The major concern in selecting a designated manager for a domain
that it be able to carry out the necessary responsibilities, and
the ability to do an equitable, just, honest, and competent job
The key requirement is that for each domain there be a
manager for supervising that domain's name space
These designated authorities are trustees for the delegated domain
and have a duty to serve the community
The designated manager is the trustee of the domain for the
itself and the global Internet community
Concerns about "rights" and "ownership" of domains are inappropriate
It is appropriate to be concerned about "responsibilities"
"service" to the community
The designated manager must be equitable to all groups in the
that request domain names
This means that the same rules are applied to all requests.
requests must be processed in a nondiscriminatory fashion,
academic and commercial (and other) users are treated on an
basis. No bias shall be shown regarding requests that may come
customers of some other business related to the manager -- e.g.,
preferential service for customers of a particular data
provider. There can be no requirement that a particular mail
(or other application), protocol, or product be used
There are no requirements on subdomains beyond the requirements
higher-level domains themselves. That is, the requirements
applied recursively. In particular, all subdomains shall be
Cooper & Postel [Page 24]
RFC 1480 The US Domain June 1993
to operate their own domain name servers, providing in them
information the subdomain manager sees fit (as long as it is true
correct).
Significantly interested parties in the domain should agree that
designated manager is the appropriate party
The US Domain Administrator tries to have any contending
reach agreement among themselves, and generally takes no action
change things unless all the contending parties agree; only in
where the designated manager has substantially neglected
responsibilities would the US Domain Administrator step in
The designated manager must do a satisfactory job of operating
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
technical competence. This includes keeping the US
Administrator or other higher-level domain managers advised of
status of the domain, responding to requests in a timely manner,
operating the database with accuracy, robustness, and resilience
There must be a primary and a secondary name server that have
connectivity to the Internet and can be easily checked
operational status and database accuracy by the US
Administrator
One of the aspects of having two name servers for each domain (
zone), is for robustness. One concern under this heading is that
name service not go out entirely if there is a local power
(earthquake, tornado, or other disaster).
Name Servers should be in distinctly separate physical locations.
is appropriate to have more than two name servers, but there must
at least two
For any transfer of the designated manager trusteeship from
organization to another, the higher-level domain manager must
communications from both the old organization and the
organization that assures the US Domain Administrator that
transfer in mutually agreed, and that the new
understands its responsibilities
It is also very helpful for the US Domain Administrator to
communications from other parties that may be concerned or
by the transfer
Cooper & Postel [Page 25]
RFC 1480 The US Domain June 1993
Delegation of cities, companies within cities, schools (K12),
community colleges (CC), libraries (LIB), state government (STATE),
and federal government agencies (FED), etc., is acceptable
practical
For a delegated portion of the name space, for example a city,
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
city because different portions of the name space has been
to them. For example, someone may be delegated the ..
name space, and someone else from a state government agency may
the .STATE..US, portion. For example, Fred may run the
servers for Sacramento.CA.US and Joe may run the name servers
STATE.CA.US in Sacramento
If a company would like to have wildcard records added, or run
own name servers in a city that we have delegated name space to,
is acceptable
Delegation of the whole State name space is not yet implemented.
delegated part of the name space is in the form of
.<locality>..US
.CI.<locality>..US
.CO.<locality>..US
.STATE..US
.K12..US
PVT.K12..US
.CC..US
.TEC..US
.LIB..US
.GEN..US
.DNI.US
.FED.US
3.3.1. Delegation
When a subdomain is delegated, the following requirements must
met
1) There must be a knowledgeable and competent technical contact
familiar with the Internet DNS. This requirement is
satisified if the technical contact already runs some
name servers
Cooper & Postel [Page 26]
RFC 1480 The US Domain June 1993
2) Organizations requesting delegations must provide at least
independent (robust and reliable) DNS name servers
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.
do this, it is helpful to have several
knowledgeable about the procedures so that the operations
not delayed due to one persons unavailability (for example,
being on vacation).
5) The subdomain manager must tell the US Domain
when there are changes in the name servers that should
reflected in the US Domain zone files, or changes in
contact information
K12
In the long term, registering schools will be a big job. So
need to have in mind delegating parts of the work to
school districts. If you can delegate every school district
the state then you are finished, except for checking that they
all operating correctly. However, initially you will have quite
bit to do with educating people, helping them choose names
getting name servers arranged. You are responsible for
that the naming of schools follow the guidelines suggested in
memo
All K12 Administrators will initially be responsible for
the "pseudo district" PVT for private schools. Private
have the option of registering as .PVT.K12..
or as a business under the city based names
Locality
If you have been delegated a locality subdomain, you will
responsible for registering not only businesses directly under
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
the other in a given locality. The whole city government
be under one branch
Cooper & Postel [Page 27]
RFC 1480 The US Domain June 1993
WHOIS
Only the second and third level delegated name spaces will
entered in the WHOIS database. For example, K12.CA.US would
an entry in WHOIS. Anything under K12.CA.US will not be listed
The US Domain Administrator will send the information that
supplied on your US Domain template to the InterNIC. It is
hope that in the future, each delegated subdomain will
their own WHOIS directory database for their branch
3.3.2 Delegation
The procedure that is followed when a subdomain is delegated
the following steps
1) Evaluate the technical contact's experience with DNS.
sure there is a need for the proposed delegation. Make
the technical contact has the information about the US
and the suggested naming structure. Two contacts with
addresses are necessary in case something goes wrong
2) Add the new technical contact to the "us-dom-adm" mailing
for distributing updates concerning the US Domain policies
procedures
3) Delete any hosts from our zone file that belongs in the
delegated subdomain and make sure they now have the hosts
their zone file
4) Send them a copy of the zone file so their initial zone
is identical to ours. For example
mil.wi.us. 69582 SOA spool.mu.edu
manager.spool.mu.edu. (
930119 ;
28800 ;
14400 ;
3600000 ;
86400 ) ;
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
solaria.mil.wi.us. 69582 MX 10 spool.mu.edu
nthomas.mil.wi.us. 69582 HINFO 386 Clone
nthomas.mil.wi.us. 69582 MX 10 spool.mu.edu
Cooper & Postel [Page 28]
RFC 1480 The US Domain June 1993
rwmke.mil.wi.us. 69582 HINFO UNIX PC
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
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
technical contact for the delegated subdomain and the name
the delegated name space and the names of the name servers
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;Contact: Joseph Klein (tjk@spool.mu.edu
; Marquette
; (414) 288-6734
;
;Delegate mil.wi.us
mil.wi.us. 604800 NS SPOOL.MU.EDU
604800 NS SOPHIE.MSCS.MU.EDU
; A glue record is not needed this time. Glue records
; needed when the name of the server is a subdomain of
; delegated domain
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
6) Check to see that delegated subdomain name servers are up
running, and make sure the delegated hosts are installed
their zone file. Now delete any hosts from the US Domain
file that belongs in the newly delegated subdomain
7) Inform the technical contact of the newly delegated
that wildcard records are allowed in the zone file under
organizational subdomain but no wildcard records are
under the "city" or "state" domain
8) Make sure each administrator has a copy of this RFC
follows the guidelines set forth
3.3.3 Subdomain
The number of hosts registered under each subdomain is unknown.
Section 3.1 for information on the delegated domains and
contacts
Cooper & Postel [Page 29]
RFC 1480 The US Domain June 1993
4. DATABASE
4.1. Name
Name servers are the repositories of information that make up
domain database. The database is divided up into sections
zones, which are distributed among the name servers. While
servers can have several optional functions and sources of data,
essential task of a name server is to answer queries using data
its zones. The response to a query can always be generated
only local data, and either contains the answer to the question or
referral to other name servers "closer" to the desired information
A given zone will be available from several name servers to
its availability in spite of host or communication link failure
Every zone is required to be available on at least two servers,
many zones have more redundancy than that
The US Domain is currently supported by seven name servers
venera.isi.
ns.isi.
rs.internic.
ns.csl.sri.
ns.uu.
adm.brl.
excalibur.usc.
4.2 Zone
A "zone" is a registry of domains kept by a particular organization
A zone registry is "authoritative", that is, the master copy of
registry is kept by the zone organization, and this copy is,
definition, always up-to-date. Copies of this registry may
distributed to other places and kept in caches, but these caches
not authoritative, and may be out-of-date
Every zone has at least one node, and hence domain name, for which
is authoritative, and all of the nodes in a particular zone
connected. Given the tree structure, every zone has a highest
which is closer to the root than any other node in the zone.
name of this node is often used to identify the zone. The data
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
(can be thought of as part of the authoritative data).
Cooper & Postel [Page 30]
RFC 1480 The US Domain June 1993
3) Data that describes delegated subzones, i.e.,
around the bottom of the zone
4) Data that allows access to name servers for
(sometimes called "glue" data).
The zone administrator has to maintain the zones at all the
servers which are authoritative for the zone. When the changes
made, they must be distributed to all of the name servers
Copies of the zone files are not available unless you are on
Internet. To look at the zone files use the "dig" program of the
domain name system
dig @nshost host-your-checking
4.3 Resource
Records in the zone data files are called resource records (RRs).
The standard Resource records (RR) are specified in STD 13, RFC 1034
and STD 13, RFC 1035 (3,4). An RR has a standard format as shown
[] []
The first field is always the name of the domain record. The
field is an optional time to live field. This specifies how
this data will be stored in the data base. The third field is
address class; the class field specifies the protocol group
often this is the Internet class "IN". The fourth field states
type of the resource record. The fields after that are dependent
the Type of RR. The fifth field is the data field which is
differently for each type and class of data. Here is a list of
current commonly used types
SOA Start of
NS Name
A Internet
CNAME Canonical Name (nickname pointer
HINFO Host
WKS Well Known
MX Mail
PTR
Cooper & Postel [Page 31]
RFC 1480 The US Domain June 1993
What do the fields mean
foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU
(1) (2) (3) (4) (5)
1) domain
2) time to live
3) mail exchanger
4) preference value to determine (if more than
forwarder) which mailer to use first, lower
higher
5) the Internet forwarding host
4.3.1 "A"
Internet (IP) Address. The data for an "A" record is an
address in a dotted decimal form. A sample "A" record might
like
venera.isi.edu. A 128.9.0.32
(name) (A) (address
The name field is the machine name, and the address is the
address. There should be only one "A" record for each address of
host
4.3.2 CNAME
Canonical Name resource record, CNAME, specifies an alias for
canonical name. This is essentially a pointer to the official
for the requested name. All other RRs appear under this
name. A machine named FERNWOOD.MPK.CA.US may want to have
nickname ANTERIOR.MPK.CA.US. In that case, the following RR would
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
added for awhile when a host changes its name, usually because
moves to another state. It helps to have this CNAME pointer so
any mail comes to the old address it will get forwarded to the
one. There cannot be any other RRs associated with a nickname of
same class
Cooper & Postel [Page 32]
RFC 1480 The US Domain June 1993
4.3.3 MX
Mail Exchanger records, MX, are used to specify a machine that
how to deliver mail to a machine that is not directly connected
the Internet. For example, venera.isi.edu is the mail gateway
knows how to deliver mail to foo.la.ca.us, but other machines on
network cannot deliver mail directly to foo.la.ca.us. These
machines may have a private connection or use a different
medium (such as uucp). The preference value (10) is the order that
mailer should follow when there is more than one way to deliver
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
Host information resource records, HINFO is for host specific data
This lists the hardware and operating system that are running at
listed host. It should be noted that a space separates the
information and the operating system information. If you want
include a space in the machine name you must quote the name.
information is not specific to any class, so ANY may be used for
address class. There should be one HINFO record for each host
acb.la.ca.us. HINFO VAX-11/780
(Hardware) (Operating System
The official HINFO types can be found in the latest Assigned
RFC, the most recent edition being STD 2, RFC 1340 [9]. The
type is called the Machine Name, and th