RFC relevance of december

As per Relevance of the word december, we have this rfc below:

Network Working Group A.
Request for Comments: 1386 J.
December 1992
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 ............................................ 5
2.2 City Codes or Locality Names............................ 5
2.3 Examples of Names....................................... 5
3. Registration ................................................ 8
3.1 Requirements ........................................... 8
3.2 Direct Entries ......................................... 9
3.2.1 UUCP Hosts .......................................... 9
3.2.2 Non-IP Hosts ........................................ 10
3.3 Delegated Subdomains ................................... 12
3.3.1 Schools ............................................. 12
3.3.2 State Agencies ...................................... 14
3.3.3 Federal Agencies .................................... 14
3.3.4 Delegation Requirement............................... 14
3.3.5 Delegation Procedures ............................... 15
3.3.6 Subdomain Contacts................................... 18
4. Database Information......................................... 19
4.1 Name Servers ........................................... 19
4.2 Zone files ............................................. 20
4.3 Resource Records ....................................... 21
4.3.1 A Records ........................................... 22
4.3.2 CNAME Records ....................................... 22
4.3.3 MX Records .......................................... 22
4.3.4 HINFO Records ....................................... 23
4.3.5 PTR Records ......................................... 23
4.4 Wildcards .............................................. 23
5. References .................................................. 24
6. Security Considerations ..................................... 25
7. Author's Address ............................................ 25
Appendix-I: US Domain Names BNF................................. 26
Appendix-II: US Domain Questionnaire for Host Entry.............. 28

Cooper & Postel [Page 1]

RFC 1386 The US Domain December 1992

1.

1.1 The Internet Domain Name

The Domain Name System (DNS) provides for the translation
host names and addresses. Within the Internet, this
translating from a name such as "venera.isi.edu", to an IP
such as "128.9.0.32". The DNS is a set of protocols and databases
The protocols define the syntax and semantics for a query language
ask 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 assigned by the Network Information
(Hostmaster@NIC.DDN.MIL).

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 registration 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 host name to address mappings were maintained by
Network Information Center (NIC) in a single file, called HOSTS.TXT
which was FTPed by all the hosts on the Internet. The
population was changing in character. The timeshared hosts that
up the original ARPANET were being replaced with local networks
workstations. Local organizations were administering their own
and addresses, but had to wait for the NIC to make changes
HOSTS.TXT to make the changes visible to the Internet at large
Organizations also wanted some local structure on the name space
The applications on the Internet were getting more sophisticated
creating a need for general purpose name service. The idea of
hierarchical name space, with the hierarchy roughly corresponding
organizational structure, and names using "." as the character
mark the boundary between hierarcy levels. A design using
distributed database and generalized resources was implemented

The domain system provides standard formats for resource data

Cooper & Postel [Page 2]

RFC 1386 The US Domain December 1992

standard methods for querying the database, and standard methods
name servers to 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.

Even though the intention was that any educational institution
where in the world could be registered under the EDU domain,
practice it has turned out with few exceptions only those in
United States have registered under EDU, similiary with COM (
commercial). In other countries, everything is registered under
2-letter country code, often with some subdivision. For example,
Korea (KR) the second level names are AC for academic community,
for commercial, GO for government, and RE for research. However
country may go it's own way about organizing its domain, and
have

Their are no plans of putting all of the organizational domains .
.GOV .COM etc., under .US

However, there are some states registered in the .GOV domain (11 by 2
letter code), and 3 by full names

ca.gov la.gov ohio.gov va.
co.gov md.gov or.gov wa.
hawaii.gov nc.gov sc.
ia.gov ny.gov texas.

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 as ".NA" for North America (this conflicts with the
Internet 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

Cooper & Postel [Page 3]

RFC 1386 The US Domain December 1992

1.3 The US

The US Domain is an official top-level domain in the DNS of
Internet community. It is registered with the Network
Center. The domain administrators are Jon Postel and Ann
Cooper at the Information Sciences Institute of the University
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 NIC 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 were
owned by small companies or individuals with computers at home
However, the US Domain has grown and currently registers hosts
federal government agencies, state government agencies, K12 schools
community colleges, private schools, libraries, county agencies,
city utilities, to name a few

The administration of the US Domain was managed solely by the
Registrar in the past. However, due to the increase of hosts
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.
namespace under .US is the state namespace, then the city namespace
then organization or computer name and so on

For example

SPK.WA.
VANC.WA.

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

Cooper & Postel [Page 4]

RFC 1386 The US Domain December 1992

The use of un-registered names is not effective and causes
for other users. Inventing your own name and using it
registering is not a good idea

2.1 State

The state codes are the two letter US Postal abbreviations

2.2 City Codes or Locality

Cities may be named (designated) by their full name (spelled out
hyphens replacing spaces (e.g., Los-Angeles or New-York)), or by
city code. The first choice is the full city name, the second
is the city codes from Western Union's "City Mnemonics" list, and
third choice is a code for your city chosen by the applicant
However, it is very desirable that all users in the same city use
same designator for the city

Abbreviated city names are a good idea, particularly when the
name is long, as there is much to type already. One of the
is that the city codes in the Western Union City Mnemonics list
sometimes not very good abbreviations. Users sometimes tend
prefer abbreviations that are commonly used already from that region
Such as SF for San Francisco, MPK for Menlo Park

Exceptions have been made in the abbreviations, even though
causes extra work to keep track of these abbreviations.
abbreviation for one city. Applicants are told what codes
currently in use, however, if a city code is not used yet, and
would prefer to use a different code that is more common among
natives, then the new code is allowed. However, once it'
registered, then everyone else who registers in that city will
to use that code or spell out the full city name

Some applicants have tried to get a copy of the Western Union
Mnemonics code list but it is no longer available from Western Union
However, we do have a copy but it is not online. If you
requesting an abbreviated city code please let us know and we
gladly look it up for you

2.3 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.

Cooper & Postel [Page 5]

RFC 1386 The US Domain December 1992

For large entities like large corporations with multiple
in several cities or states this often seems like a
constraint (especially when compared with the alternative
registering directly in the .COM domain). However, a company
have a headquarters office in a particular locality and so
register with that name

For example: IBM.Armonk.NY.

EXAMPLES OF THE NAMING STRUCTURE IN THE US

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

=====

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

Cooper & Postel [Page 6]

RFC 1386 The US Domain December 1992

CITY |
==============

Police.CITY.Culver-City.CA.US <==== a city
Fire-Dept.CITY.Los-Angeles.CA.US <==== a city
Fire-Dept.COUNTY.Los-Angeles.CA.US <==== a county

REGIONAL | DISTRICT |
=============================

SCAQMD.DISTRICT.CA.US <==== a regional
Bunker-Hill-Improvement.DISTRICT.LA.CA.US <==== a local

Huntington.LIB.LA.US <==== a private
Venice.LA-City.LIB.CA.US <==== a city
MDR.LA-County.LIB.CA.US <==== a county

K12 | CC | STATE UNIV | PRIVATE
=======================================

Los-Angeles.UC.STATE.CA.US <====
Berkeley.UC.STATE.CA.US <==== "CAL
Irvine.UC.STATE.CA.US <==== University of Calif.
Santa-Cruz.UC.STATE.CA.US <==== University of Calif. Santa
Northridge.CSU.STATE.CA.US <==== Calif. State. Univ.
Fullerton.CSU.STATE.CA.US <==== Calif. State. Univ.
Sonoma.CSU.STATE.CA.US <==== Calif. State. Univ.

SMCC.Santa-Monica.CC.CA.US <==== a public community
Trade-Tech.Los-Angeles.CC.CA.US <==== a public community

Hamilton.High.LA-Unified.K12.CA.US <==== a public K12
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <==== a public K12
John-Muir.Middle.Santa-Monica.K12.CA.US <==== a public K12

St-Monica.High.Santa-Monica.CA.US <==== a private high
St-Monica.Elem.Santa-Monica.CA.US <==== a private elem.
Crossroads-School.Santa-Monica.CA.US <==== a private
Mary-Ellens.Montessori-School.LA.CA.US <==== a private
Leland-Stanford-Jr-Univ.Stanford.CA.US <==== a private
Loyola-Marymount-Univ.Los-Angeles.CA.US <==== a private

Cooper & Postel [Page 7]

RFC 1386 The US Domain December 1992

When appropriate, subdomains are delegated and partioned in
categories, such as

K12..US = kindegarten thru 12th
CC..US = community
LIB..US =
STATE..US = state government
.FED.US = federal government

The Appendix-I contains the current US Domain Names BNF, but
actuality, the names under these subdomains may vary according to
decision of the administrators of these subdomains

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 host name. Cities and in some cases counties are used

3.

3.1

Anyone requesting to register a host in the US Domain is sent a
of the US Domain policy and procedure, and must fill out a US
questionnaire

The US Domain template, is similar to the NIC Domain
however, it is not the same. To request a copy of the US
questionnaire, send a message to the US Domain registrar (us
domain@isi.edu).

Note: If you are registering a name in a delegated
(see Section 3.3.6). Please register with
contact for that zone

The key people must have electronic mailboxes (that work).
provide all the information indicated in the "Administrator"
"Technical Contact" slot. This person will be the point of
for any administrative and policy questions about the domain

The administrator is usually the person who manages the
being registered. The technical contact can also be administrator,
the systems person, or someone who is familiar with the
details of the Internet. The technical contact should have a
working e-mail address. This is necessary in case something
wrong

Cooper & Postel [Page 8]

RFC 1386 The US Domain December 1992

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

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, turn around time for registering a host
usually a day or two. The nameservers 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. Fill out the application and
it directly to the US Domain administrator. If you are in an
where the zone is delegated to someone else your request will
forwarded to the zone administrator for your registration

3.2.1 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
ok. 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 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 9]

RFC 1386 The US Domain December 1992

This 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

For example: bah.rochester.ny.
host1.bah.rochester.ny.
host2.bah.rochester.ny.

3.2.2 NON-IP

To use US Domain names for non-IP hosts, there must be a
host that is an IP host. There must be an adminstrative
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

Cooper & Postel [Page 10]

RFC 1386 The US Domain December 1992

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 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 11]

RFC 1386 The US Domain December 1992

3.3 Delegated

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

Delegation of cities, companies within cities, schools (K12),
community colleges (CC), libraries (LIB), state government (STATE),
and federal government agencies, departments, etc., is acceptable
practical

For a delegated portion of the namespace, 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 ok

Delegation of the whole State namespace is not yet implemented.
delegated part of the name space is in the form of

.STATE..US
.K12..US
.CC..US
.LIB..US
....US
.CITY...US
..FED.US

3.3.1

As schools begin to join the Internet, there ought to be a
scheme for naming them. A "K12" name branch has been established
each state in the US Domain for this purpose

Public schools are usually organized by districts which can be
or smaller than a city or county

Cooper & Postel [Page 12]

RFC 1386 The US Domain December 1992

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

In some districts, the same school name is used at different levels
for example, Washington Elementary School and Washington High School
We suggest that when necessary the keywords "Elementary", "Middle",
and "High" be used to distinguish these schools. These
would only be used when they are needed, if the school's name
unique without such keywords don't use them

Typical K12 school names currently used are like

IVY.PRS.K12.NJ.
DMHS.JCPS.K12.KY.
OHS.EUNION.K12.CA.
BOHS.BREA.K12.CA.

These names could be long. Given the large number of schools
organizing by school district and state seems appropriate.
there are many things to name some of the names must 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.

Some School Examples
---------------------

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
Northridge.CSU.STATE.CA.US <== a state

If a school has a bunch 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.
...

Cooper & Postel [Page 13]

RFC 1386 The US Domain December 1992

3.2.2 State

US Domain namespace has been delegated to the state
agencies. For example, in the State of Minnesota, the subdomain
STATE.MN.

This means that the person running the namservers for state.mn.us
responsible for naming agencies, of the state govermnent.
example

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

3.3.3 Federal

A federal namespace has been delegated to 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

3.3.4 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 Domain Name System.
requirement is easily satisified if the technical
already runs some other nameservers

2) Organizations requesting delegations must provide at least
independent (robust and reliable) DNS name servers
physically separate locations on the Internet

Cooper & Postel [Page 14]

RFC 1386 The US Domain December 1992

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).

3.3.5 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

2) Note: In the past there was the concept of a "coordinator"
a group or a club or "Domain Park". They would arrange
coordinate the registration of all the computers used
members of the club and forward all the information for
group to the US Domain Administrator. Most coordinators
moved into the position of administrator of that now
subdomain

3) Add the new technical contact to the "us-dom-adm" mailing
for distributing updates to the US Domain policies
procedures, or other pertinent information

4) Delete any hosts from our zone file that belongs in the
delegated subdomain and make sure they now have the hosts
their zone file

Cooper & Postel [Page 15]

RFC 1386 The US Domain December 1992

5) Send them a copy of the zone file so their initial zone
is identical to ours. For example

mil.wi.us. 86400 SOA spool.mu.edu. manager.spool.mu.edu. (
920904 ;
28800 ;
14400 ;
3600000 ;
86400 ) ;

mil.wi.us. 86400 NS spool.mu.edu
spool.mu.edu. 50400 A 134.48.1.31
mil.wi.us. 86400 NS sophie.mscs.mu.edu

sophie.mscs.mu.edu. 50400 A 134.48.4.6
solaria.mil.wi.us. 86400 HINFO Sun 3/60
solaria.mil.wi.us. 86400 MX 10 spool.mu.edu
nthomas.mil.wi.us. 86400 HINFO 386 Clone
nthomas.mil.wi.us. 86400 MX 10 spool.mu.edu
rwmke.mil.wi.us. 86400 HINFO UNIX PC
rwmke.mil.wi.us. 86400 MX 10 spool.mu.edu
milestn.mil.wi.us. 86400 HINFO PC AT
milestn.mil.wi.us. 86400 MX 10 spool.mu.edu
dawley.mil.wi.us. 86400 HINFO 386 Clone
dawley.mil.wi.us. 86400 MX 10 spool.mu.edu
...
-------------------------------------

Cooper & Postel [Page 16]

RFC 1386 The US Domain December 1992

6) The US Domain zone file must have the following records
showing the name, address, e-mail, and phone number of
technical contact for the delegated subdomain and the name
the delegated name space and the names of the nameservers

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;Delegated zone: .mil.wi.
;Contact: Steven
; manager@spool.mu.
; Marquette
; (414) 288-6734

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
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

7) 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

8) 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

Cooper & Postel [Page 17]

RFC 1386 The US Domain December 1992

3.3.6 Subdomain

Approximately 680 individual hosts are registered, but we
delegated the following portions of the namespace. We do not
how many hosts are registered under each of these subsdomains

DELEGATED ZONE
============== =======

TUCSON.AZ.US leonard@arizona.
SF.CA.US sf-hostmaster@apple.
PREMENOS.SF.CA.US jenkins@premenos.sf.ca.
SCVL.CA.US sinster@scintilla.capitola.ca.
SANTA-CRUZ.CA.US sinster@scintilla.capitola.ca.
APTOS.CA.US sinster@scintilla.capitola.ca.
CAMPBELL.CA.US sinster@scintilla.capitola.ca.
CAPITOLA.CA.US sinster@scintilla.capitola.ca.
FELTON.CA.US sinster@scintilla.capitola.ca.
ZAYANTE.CA.US sinster@scintilla.capitola.ca.
BOULDER-CREEK.CA.US sinster@scintilla.capitola.ca.
DARWIN.PTVY.CA.US brian@angband.stanford.
LOGAN-HS.UNIONCITY.CA.US cjw@marmot.nersc.
BOULDER.CO.US trent@XOR.
COLOSPGS.CO.US trent@XOR.
DENVER.CO.US trent@XOR.
DVR.CO.US trent@XOR.
CHI.IL.US matt@oddjob.uchicago.
EUGENE.OR.US meyer@oregon.uoregon.
SPRINGFIELD.OR.US meyer@oregon.uoregon.
MULTNOMAH.LIB.OR.US brianw@polaris.admin.ogi.
PGH.PA.US ecd@CERT.
SPK.WA.US root@dogear.spk.wa.
MIL.WI.US manager@spool.mu.
ATL.GA.US charvey@gatech.gatech.
Mt-PARK.GA.US charvey@gatech.gatech.
CLARKSTON.GA.US charvey@gatech.gatech.
STATE.MN.US dfazio@mr.
MNPL.FRB.FED.US dfazio@mr.

K12.CA.US mdm@NIC.CSU.
CC.CA.US mdm@NIC.CSU.
K12.MI.US sandra.s.waite@um.cc.umich.
K12.TX.US bmanning@is.rice.
K12.NJ.US becker@nisc.jvnc.
K12.MS.US fwp@msstate.
dmhs.jcps.K12.KY.US lentner@sura.
TIES.K12.MN.US dfazio@mr.

Cooper & Postel [Page 18]

RFC 1386 The US Domain December 1992

The following MD.US counties have been delegated
(butler@brl.mil).

AL.MD.US.
AA.MD.US. Anne
BA.MD.US.
CAL.MD.US.
CAR.MD.US.
CE.MD.US.
CH.MD.US.
DO.MD.US.
FR.MD.US.
GA.MD.US.
HA.MD.US.
HO.MD.US.
KE.MD.US.
MO.MD.US.
PG.MD.US. Prince George"
QA.MD.US. Queen Anne'
SM.MD.US. St. Mary'
SO.MD.US.
TA.MD.US.
WA.MD.US.
WI.MD.US.
WO.MD.US.

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

Cooper & Postel [Page 19]

RFC 1386 The US Domain December 1992

The US Domain is currently supported by six name servers

venera.isi.
ns.isi.
ns.hercules.csl.sri.
nnsc.nsf.
ns.uu.
adm.brl.

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).

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
namservers which are authoritative for the zone. When the
are 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

Cooper & Postel [Page 20]

RFC 1386 The US Domain December 1992

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

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

Cooper & Postel [Page 21]

RFC 1386 The US Domain December 1992

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

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

Cooper & Postel [Page 22]

RFC 1386 The US Domain December 1992

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 RFC 1340. The hardware type
called the Machine Name, and the software type is called the
Name

The information users supply about this is often inconsistent
incomplete. Please follow the terms in the current "
Numbers".

4.3.5 PTR

A Domain Name Pointer record, PTR, allows special names to point
some other location in the domain data base. These are
used in setting up reverse pointers for the special IN-ADDR.
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
record registered in the US Domain. These PTR records need to
added by the administrator of the network where the host
connected. The US Domain administration does not administer
network and cannot make these entries in the DNS database

4.4

The wildcard records are of the form "*.",
is any domain name. The wildcards potentially apply
descendents of , but not to itself

For example, suppose a large company located in California with
large, non-IP/TCP, network wanted to create a mail gateway. If
company was called DWP.LA.CA.US, and the IP/TCP capable
machine (Internet forwarder) was called ELROY.JPL.NASA.GOV,

Cooper & Postel [Page 23]

RFC 1386 The US Domain December 1992

following RRs might be entered into the .US zone

dwp.la.ca.us MX 10 ELROY.JPL.NASA.
*.dwp.la.ca.us MX 10 ELROY.JPL.NASA.

The wildcard record *.DWP.LA.CA.US would cause an MX query for
domain name ending in DWP.LA.CA.US to return an MX RR pointing
ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the
dwp can be found

In the US Domain, wildcard records are allowed in our zone
under the organizational subdomain (and where noted otherwise) but
wildcard records are allowed under the "City" or "State" domain

The authors strongly believe that it is in everyone'
interest and good for the Internet to have each
explicitly registered (that is, we believe that
should not be used), we also realize that not
agrees with this belief. Thus, we will allow
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
fact that if anyone wanted to find one of the hosts in
domain name system it would be there, and problems can
detected more easily. When using wildcards records all
hosts under a subdomain are hidden

5.

[1] Stahl, M., "Domain Administrators Guide", RFC 1032,
International, November 1987.

[2] Lottor, M., "Domain Administrators Operations Guide" RFC 1033,
SRI International, November 1987.

[3] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, ISI, November 1987.

[4] Mockapetris, P., "Domain Names - Implementation
Specification", STD 13, RFC 1035, 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, RFC 974, BBN, January 1986.

Cooper & Postel [Page 24]

RFC 1386 The US Domain December 1992

6. SECURITY

Security issues are not discussed in this memo

7. AUTHORS'

Ann
USC/Information Sciences
4676 Admiralty
Marina del Rey, CA 90292

Phone: 1-310-822-1511
Email: cooper@isi.

Jon
USC/Information Sciences
4676 Admiralty
Marina del Rey, CA 90292

Phone: 1-310-822-1511
Email: postel@isi.

Cooper & Postel [Page 25]

RFC 1386 The US Domain December 1992

APPENDIX-I: US DOMAIN NAMES
================================

::=
::= |

::= zip code directory

::= <locality> |
|
<regional-agency-name>
::= hierarchical name of a
federal government agency

<locality> ::= zip code directory> |
|
or parish> |
locality name

::= |
|
|

::= hierarchical name of a
government agency

<regional-agency-name> ::= hierarchical name of a
agency or district not an element of
state government and typically larger
a single city or county, for example,
Southern California Air Quality
District

::= hierarchical name of an
within a city, for example: a company
business, private school, club, organization
or individual

::= hierarchical name of a
government agency

Cooper & Postel [Page 26]

RFC 1386 The US Domain December 1992

::= hierarchical name of a county
township, or parish government agency

::= hierarchical name of a
agency or district not an element of
city or county government and
equal or smaller than a single city
county, for example, the Bunker
Improvement District

::= "CITY

::= "COUNTY" | "TOWNSHIP" | "PARISH

::= "."

::= "FED

::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB

::= "STATE" | "COMMONWEALTH

::= "US

Note: "K12" may be used for public school districts, only
and "CC" may be used only for public community colleges
and "LIB" can only be used by libraries

Cooper & Postel [Page 27]

RFC 1386 The US Domain December 1992

APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST

To register a host in the US domain, the following information must
sent to the US Domain Registrar (Us-Domain@ISI.EDU). Questions may
sent by electronic mail to the above address, or by phone
Ann Cooper (310-822-1511).

(1) The name of the top-level domain to join

For example:

(2) The name of the administrative head of the organization,
title, mailing address, phone number, organization, and
mailbox. This is the contact point for administrative and
questions about the domain. In the case of a research project
this should be the principal investigator

For example

Organization The NetWorthy
Name Penelope Q.
Title
Mail Address The NetWorthy
4676 Andrews Way, Suite 100
Santa Clara, CA 94302-1212
Phone Number (415) 123-4567
Net Mailbox Sassafrass@ECHO.TNC.

Cooper & Postel [Page 28]

RFC 1386 The US Domain December 1992

(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
zone, as well as for updating information about the domain or zone

For example

Technical

Organization The NetWorthy
Name Ansel A.
Title Executive
Mail Address The NetWorthy
4676 Andrews Way, Suite 100
Santa Clara, CA. 94302-1212
Phone Number (415) 123-6789
Net Mailbox Aardvark@ECHO.TNC.

(4) The name of the host. This is the name that will be used in
and lists associating the domain with the domain server addresses
[While, from a technical standpoint, domain names can be quite
(programmers beware), shorter names are easier for people to
with.]

For example: NetWorthy.Santa-Clara.CA.

Or: Alpha.NetWorthy.Santa-Clara.CA.
Beta.NetWorthy.Santa-Clara.CA.

(5) If this machine is not directly on the internet, how does
communicate with the Internet. Through UUCP, CREN, etc?
forwarding host

For example: The host "Networthy.Santa-Clara.CA.US" uses
to connect to "RELAY.ISI.EDU" which is an Internet host

The administrator of RELAY.ISI.EDU must agree to be
forwarding host for Networthy.Santa-Clara.CA.US, and
forwarding host must know a delivery method and route to it
No double MXing

Cooper & Postel [Page 29]

RFC 1386 The US Domain December 1992

If you are requesting an indirect connection, that is, a
Exchanger (MX) record, what is the name and mailbox of
administrator of the forwarding host

For example:John
js@RELAY.ISI.

(6) Please describe your organization briefly

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

(7) What Domain Name System (DNS) Resource Records (RR) and values
to be entered

a. A Internet Address (internet hosts only
b. HINFO Host Information, Machine
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
IN MX 10 ISI.
IN WKS 128.9.3.123. UDP (
tftp
IN WKS 128.9.3.133. TCP (

finger

An example of RRs for a non-internet host

Beta.NetWorthy.Santa-Clara.CA.US MX 10 RELAY.ISI.
HINFO SUN-3/11OC

Cooper & Postel [Page 30]

RFC 1386 The US Domain December 1992

(8) Where is the IN-ADDR pointer record to be entered. (For
hosts only.) It is your responsibility to see that this is done
Contact the administrator of the IP network your host is on.
US Domain administration does not administer the network and
make these entries in the DNS database

For example

123.3.9.128.IN-ADDR.ARPA. PTR NetWorthy.Santa-Clara.CA.

Who is the contact for the zone of the IN-ADDR.ARPA data,
this record will be entered

(9) What Time to Live (TTL)? TTL is the time (in seconds) that
resolver will use the data it got from the domain server before
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

Cooper & Postel [Page 31]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX