RFC 1480

The US Domain

๐Ÿ“… published June 1993, from ietf

1. Introduction โœจ

RFC number: 1480 Title: The US Domain Authors: A. Cooper and J. Postel Category: Informational (it's giving "for your info," not a standard) ๐ŸŽ€ Date: June 1993 Obsoletes: 1386 Updates: none listed in the title block

Status of This Memo

This memo gives info to the Internet community. It is not a specification of an Internet standard. Distribution of this memo is unlimited. ๐Ÿ’…

Table of Contents

   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
   6.  Security Considerations ..................................... 35
   7.  Authors' Addresses .......................................... 36
   Appendix-I:  US Domain Names BNF................................. 37
   Appendix-II: US Domain Questionnaire ............................ 42

1.1. The Internet Domain Name System

Okay so the Domain Name System (DNS) is the thing that translates hostnames into addresses. On the Internet, that means turning a name like "venera.isi.edu" into an IP address like "128.9.0.32". ๐Ÿฆ‹ It's a set of protocols plus databases. The protocols define the syntax and semantics of a query language for asking questions about information stored under DNS-style names. The databases are distributed and replicated, so there's no dependence on one central server, and every part of the database is served by at least two servers. Iconic redundancy ๐Ÿ’–

Assigning those 32-bit IP addresses is a separate activity. The central Internet Registry delegates them to regional authorities (like the RIPE NCC for Europe) and to network providers. ๐ŸŒธ

To get a network number assigned, contact your network service provider or your regional registration authority. If you can't figure out who that is (or as a last resort), you can reach the central Internet Registry at Hostmaster@INTERNIC.NET. ๐Ÿ“ฌ

Beyond names for hosts on the Internet, DNS also lets you register DNS-style names for hosts you can reach through electronic mail via gateways or mail relays. Those records point to an Internet host (one with an IP address) that acts as a mail forwarder for the registered host. For example, "bah.rochester.ny.us" is registered in the DNS with a pointer to the mail relay "relay1.uu.net". That type of pointer is called an MX record. This gives email users one uniform mail addressing syntax and hides the underlying network boundaries from them. โœจ

So why was the domain system even invented? Internet growth, babe ๐Ÿ“ˆ The hostname-to-address mappings were kept in one file called HOSTS.TXT, maintained by the InterNIC, and every host on the Internet FTP'd it. The network was changing too. The time-share hosts of the original ARPANET were being replaced by local networks of workstations. Local organizations were running their own names and addresses but had to wait for the NIC to edit HOSTS.TXT before anyone outside could see the changes. Orgs also wanted some local structure in the name space. Applications were getting more sophisticated and needed a general-purpose name service. So a hierarchical name space was developed, roughly matching organizational structure, where "." marks the boundary between hierarchy levels. It was built as a distributed database with generalized resources. ๐Ÿงš

DNS provides standard formats for resource data, standard methods for querying the database, and standard methods for name servers to refresh their local data from other name servers. ๐Ÿ’œ

1.2. Top-Level Domains

The top-level domains in the DNS are EDU, COM, GOV, MIL, ORG, INT, and NET, plus all the 2-letter country codes from the ISO-3166 list of countries. The IANA (Internet Assigned Numbers Authority) manages the creation of new top-level domains, and you can reach it at IANA@ISI.EDU. ๐Ÿ‘‘

Even though the original plan was that any educational institution anywhere in the world could register under EDU, in practice only institutions in the United States have registered there, and the same goes for COM (commercial). Other countries put everything under their 2-letter country code, often with some subdivision. For example, in Korea (KR) the second-level names are AC (academic community), CO (commercial), GO (government), and RE (research). Each country can go its own way about organizing its domain, and many have. ๐ŸŒˆ

There are no current plans to put all the organizational domains (EDU, GOV, COM, and so on) under US. Those name tokens aren't used in the US Domain, to avoid confusion. ๐Ÿ™ˆ

Right now, only four-year colleges and universities are registering in the EDU domain. All other schools register in the US Domain. ๐ŸŽ“

There are also concerns about how big the other top-level domains are (especially COM), and ideas for restructuring are being considered. ๐Ÿ˜ญ

Other names sometimes show up as top-level domain names. Some people have made up DNS-style names without coordinating with or registering through DNS management. Names that typically pop up are BITNET, UUCP, and two-letter continent codes like "NA" for North America (which clashes with the official Internet code for Namibia). ๐Ÿ’€

For example, the DNS-style name "KA7EEJ.CO.USA.NA" is used in the amateur radio network. These addresses are never supposed to show up on the Internet, but they occasionally do. The amateur radio network people created their own naming scheme, and it sometimes interferes with Internet addresses. ๐Ÿ“ป

1.3. The US Domain

The US Domain is an official top-level domain in the DNS of the Internet community. Its domain administrators are Jon Postel and Ann Westine Cooper at the Information Sciences Institute of the University of Southern California (USC-ISI). ๐Ÿซถ

US is the ISO-3166 2-letter country code for the United States, so the US Domain is established as a top-level domain and registered with the InterNIC the same way other country domains are. ๐Ÿ‡บ๐Ÿ‡ธ

Because US organizations mostly registered in the EDU and COM domains, the US Domain got little use at first. Back then, the computers registered in the US Domain were mainly owned by small companies or individuals with computers at home. But the US Domain has grown, and it now registers hosts in federal government agencies, state government agencies, K12 schools, community colleges, technical and vocational schools, private schools, libraries, and city and county government agencies, just to name a few. ๐Ÿ”ฅ

At first, the Domain Registrar managed the US Domain alone. Because registrations increased, administration of subdomains is now being delegated to others. ๐ŸŒธ

Any computer in the United States may be registered in the US Domain. โœจ

"CO" is the branch for county government agencies ๐Ÿ›๏ธ, and it sits as a subdomain under the "locality" name (like Los Angeles). For example: Fire-Dept.CO.San-Diego.CA.US. ๐Ÿ’…

"K12" is for public school districts ๐ŸŽ. Private schools can use the special name "PVT" in place of a district name, so you'd get <school-name>.K12.<state>.US and <school-name>.PVT.K12.<state>.US ๐ŸŽ€

"CC" is for community colleges ๐ŸŽ“. This branch was set up for all the statewide community colleges, like <school-name>.CC.<state>.US. โœจ

"TEC" is for technical and vocational schools and colleges ๐Ÿ› ๏ธ. Something like <school-name>.TEC.<state>.US ๐Ÿงš

"LIB" is for libraries only ๐Ÿ“š, including state, regional, city, and county ones. For example: <lib-name>.LIB.<state>.US ๐ŸŒธ

"STATE" is for state government agencies ๐Ÿข. For example: <org-name>.STATE.<state>.US ๐Ÿ’œ

"GEN" is the catch-all for general independent entities ๐ŸŒˆ. It's for things that don't fit neatly into any other branch, the kinds of things that might otherwise sit under ORG at the top level. It's best not to reuse the top-level keywords (ORG, EDU, COM, etc.) here so nobody gets confused. GEN is for things like statewide organizations, clubs, or domain parks. For example: <org-name>.GEN.<state-code>.US ๐Ÿฆ‹


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

VIEW OF SECOND LEVEL DOMAINS UNDER US

                         +-------+
                         |  US   |
                         +-------+
                             |
           +----------------------------------+
           |        |        |       |        |
        +-----+  +-----+  +-----+  +-----+  +-----+
        | FED |  | DNI |  | TX  |  | SD  |  | CA  |
        +-----+  +-----+  +-----+  +-----+  +-----+

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SCHOOL AND LIBRARY VIEW
                             +-----+
                             |  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 AGENCIES

                             +-----+
                             |  CA |
                             +-----+
                                |
                   +-------------------------+
                   |            |            |
                +-------+   +--------+    +-----+
                | STATE |   |DISTRICT|    | GEN |
                +-------+   +--------+    +-----+
                  /|\          /|\          /|\
                +--------+   +------+   +---------+
                |CALTRANS|   |SCAQMD|   |domain pk|
                ---------+   +------+   +---------+
                   |
                +--------+
                |TCEW100E|
                +--------+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

VIEW OF LOCALITY
                             +-----+
                             |  CA |
                             +-----+
                                |
                +-----------------------------------+
                |                                   |
      +-------------------------+           +----------------+
      |       LOS ANGELES       |           |  SANTA MONICA  |
      +-------------------------+           +----------------+
       /  |          |       /|\                |       /|\
      /   |          |        |                 |        |
  +---+ +--+        +--+  +-----------+       +--+     +---+
  |bus| |CI|        |CO|  | pvt school|       |CI|     |bus|
  +---+ +--+        +--+  +-----------+       +--+     +---+
         /\          |                          |
        /  \         |                  +------------+
       /    \        |                  |HARBOR GUARD|
      /      \       |                  +------------+
 +-----+ +-----+   +-----+ +----+
 |FIRE | |ADMIN|   |PARKS| |FIRE|
 +-----+ +-----+   +-----+ +----+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2.1. State Codes ๐Ÿ—บ๏ธ

The state codes are the two-letter US Postal abbreviations. For example: "CA" is California. ๐ŸŒด

2.2. Locality Names ๐Ÿ™๏ธ

Inside the state namespace there are "locality" names. Some of them may be cities, some may be counties, and some may be local names that aren't incorporated entities.

Registered names under "locality" could look like this:

<hostname>.CI.<locality>.<state>.US   ==>  city gov't agency
<hostname>.CO.<locality>.<state>.US,  ==>  county gov't agency
<hostname>.<locality>.<state>.US      ==>  businesses

When the locality is a county, there's a branch under the locality name called "county" or "CO", and the county government uses it. Businesses register directly under the locality name. ๐Ÿ’ผ

Under a city locality name there's a "city" or "CI" branch for city government agencies. As usual, businesses and private schools may register directly under the city name. ๐Ÿซ

If a county and a city share the same locality name, that's totally fine, because the "CO" or "CI" keyword keeps the names unique. Where I live, the county has a fire department and the city has its own, so they could have names like these:

   Fire-Dept.CI.Los-Angeles.CA.US
   Fire-Dept.CO.Los-Angeles.CA.US

Cities can be named by their full name, spelled out with hyphens replacing spaces (e.g., Los-Angeles or Fort-Collins), or by a city code. The first choice is the full city name. In some cases it may make sense to use a well-known city abbreviation that everyone in the locality recognizes. Still, it's really important that all users in the same city use the same designator for it. In other words, any particular locality should have just one DNS name. ๐Ÿ™Œ

Some people want names tied to a bigger metro area or region, like the "Bay Area" or "Tri-Cities". The catch is that these names aren't necessarily unique within a state. The best move here is to use the larger metropolitan city in your hostname. Cities and counties are used.

Should all the names be obvious? Trying to make them obvious is desirable, and also impossible. At some point, the obviously right name for an organization will already be taken. As the system grows, that happens more and more often. Ease of use for the end user matters, but a higher priority is a system that actually works. That means manageability needs a lot of consideration. ๐Ÿ› ๏ธ

DNS was created to split the job of keeping track of hosts on the Internet into manageable chunks. ๐Ÿงฉ

The happy result is that splitting things up makes names easier to keep unique and encourages logical grouping. What counts as a "logical grouping," though, always depends on who's looking. ๐Ÿ‘€

Lots of levels of delegation are needed to keep zone files manageable. Lots of sections of the namespace are needed so unique names can be added easily. ๐Ÿฐ

Way back in the olden days, when the Internet was invented, some people thought an 8-bit network number would be more than enough to number every network that would ever exist. Today there are over 10,000 networks operating on the Internet, and people argue about whether the doubling time is 2 years or 4 years. ๐Ÿ˜ญ

One concern is that things will keep growing dramatically, which will require more subdivision of domain name management. Maybe the plan for the US Domain is overkill on growth planning, but there has never been too much planning for growth. ๐ŸŒฑ

When things get bigger, names have to get longer. One argument goes like this: with only 8-character names, where each position can be a-z, 0-9, or -, you get 37**8 = 3,512,479,453,921, or 3.5 trillion possible names. It's a great argument, but how many of us actually want names like xs4gp-7q? It's like license plates. Sure, some people get the vanity plate they want, but a lot more people who want something specific can't have it because someone else got there first. Structure and longer names also let more people get their "obviously right" name. ๐Ÿ’…

2.3. Schools ๐Ÿซ

K12 schools are connecting to the Internet and registering in the Internet DNS. The IANA made a decision (after consulting the new InterNIC Internet Registry and the Federal Networking Council (FNC)) to send these school registrations to the US domain, using the naming structure described here. ๐Ÿงพ

We need competent, experienced volunteers to step up and act as third and perhaps fourth level registries, and to run 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, but only one can be Washington.EDU. (Actually, none can be, since that name is already used by a university.) If every school tried to register directly under EDU, there would be tons of name conflicts. ๐Ÿ’ฅ

Also, in some districts the same school name is used at different levels, like Washington Elementary School and Washington High School. We suggest that when necessary, the keywords "Elementary", "Middle", and "High" be used to tell these schools apart. Those keywords should only be used when they're needed. If the school's name is unique without them, skip them. โœจ

  1. Database Management:

One goal of DNS is to split up the management of the name database into small pieces. Each piece (or "zone" in DNS terminology) could be managed by a separate administrator. If every high school went into the EDU domain, the EDU zone file, which is already huge, would grow even bigger and might become unmanageable. ๐Ÿ“‚

For both of these reasons, structure has to be introduced into names. Structure gives common names a context where they can be unique, and it divides up the management responsibility. ๐ŸŒˆ

The US Domain already has a framework in place and has registered many schools in this structured scheme. The general form is:

<school>.<district>.K12.<state>.US.

For example: Hamilton.LA-Unified.K12.CA.US ๐Ÿฆ‹

Okay so public schools are usually organized into districts, and districts can be bigger or smaller than a city or county ๐Ÿซโœจ. The Portland school district in Oregon is in three or four counties, and each of those counties also has non-Portland districts ๐Ÿคฏ.

It makes sense to name schools inside their districts ๐ŸŽ€. BUT districts often share a name with a city or county, so there has to be a way to tell a school district name apart from some other kind of locality name. That's where the keyword "K12" comes in ๐Ÿ”‘.

Here are some typical K12 school names being used right now:

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

Ngl these names are way longer than the old shorter names in the EDU domain ๐Ÿ˜ญ, but those short ones would not have lasted long. Tons of schools would find that their "obviously correct" name had already been taken by some other school ๐Ÿ’€.

When there are a lot of things to name, some names are going to be long ๐Ÿงš. Sometimes there are good abbreviations to use. For example, Hamilton High School in Los Angeles could be:

          Hami.Hi.LA.K12.CA.US

If a school has a bunch of PCs, each PC should have a name ๐Ÿ’ป. Say they're named "alpha", "beta", ... and they belong to a school named "Lincoln.High.Lakewood.K12.CA.US". Then their names would be:

            alpha.Lincoln.High.Lakewood.K12.CA.US.
            beta.Lincoln.High.Lakewood.K12.CA.US
            ...

The K12 subdomain gives two points where a branch of the database can be handed off to different administrators: the K12 Administrator for each state, and the district administrator for each district within a state ๐Ÿ‘‘.

The US Domain Administrator will delegate a branch of the US domain to an appropriate party ๐Ÿฆ‹. Sometimes that's a particular school, a school district, or even all of K12 for a state.

Managing a K12 branch or sub-branch can be delegated to an appropriate volunteer ๐Ÿซถ. We expect these delegations of the schools' DNS service might eventually move to someone else who is "more appropriate" from an administrative organizational point of view. The "obvious" state agency to run the schools' DNS branch may take some time to get up to speed on Internetting ๐Ÿ“š. In the meantime, the more advanced schools can get up and running ๐Ÿš€.

Special Schools and Service Units

In many states, there are special schools that are not in districts. These are run directly by the state or by consortiums ๐ŸŒˆ. There are also service units that provide "educational services", ranging from books and computers to janitorial supplies and building maintenance ๐Ÿงน. Often these service units don't have a one-to-one relationship with districts.

There's some concern about naming these schools and service units inside the naming structure for schools set out in this memo ๐Ÿ™ˆ. There are several possibilities. For a state with many service units, creating a "pseudo district" ESU (or whatever the common terminology is in that state) is an option. For example, the Johnson service unit could be JOHNSON.ESU.K12.CA.US. For a state with a few such service units (and avoiding conflicts with district names), the service units could sit directly under K12. For example:

          TIES.K12.MN.US

The special public funded schools can be handled in a similar way ๐Ÿ’…. If there are many special schools in a state, a "pseudo district" should be established and all the special schools listed under it. For example, suppose there's a "pseudo district" in Massachusetts called SPCL, and a special school called the Progressive Computer Institute. Then that school could be named PCI.SPCL.K12.MA.US. If there are only a few special schools, they can be listed directly under K12 (avoiding name conflicts with district names). For example, the California Academy of Math and Science is CAMS.K12.CA.US. CAMS is sponsored by seven schools, the California Department of Education, and a University ๐ŸŽ“.

"PVT" Private Schools

Private schools can be thought of as businesses ๐Ÿ’ผ. Public schools live in districts, and districts give a natural organizational structure for naming and delegation. For private schools there are no districts, and they really do operate like businesses. But lots of people get upset at the thought of their kids in a private school being in a business category and not in K12 with the rest of the children ๐Ÿ˜ค. So to accommodate both public and private schools, we've added an artificial district called private or "PVT" to each state's K12 branch ๐ŸŽ€. This gives a private school the option of registering like a business under "locality", or in the PVT.K12.<state-code>.US branch.

For example:

      Crossroads.PVT.K12.CA.US
      Crossroads-Santa-Monica.CA.US

A public school "Oak High" in the "Woodward" school district in California would have a name like Oak-High.Woodward.K12.CA.US.

A private school "Old Trail" in Pasadena, California could use the <locality> based name Old-Trail.Pasadena.CA.US or the private school base name Old-Trail.PVT.K12.CA.US.

Some people suggest that, instead of a special pseudo district PVT, private schools should use a locality name. One reason to use district names is that, over time, it seems likely that school district administrators will take over running the DNS for their district ๐Ÿง. One needs to be able to delegate at that branch point. One implication of delegation is that the delegatee is now in charge of a chunk of the name space and will be registering new names. To keep names unique, you can't have two different people registering new things below identically named branches ๐Ÿ”’.

For example, if there's a school district named Pasadena and a city named Pasadena, the branch of the name space PASADENA.K12.CA.US might be delegated to the administrator of that public school district. If a private school in Pasadena wanted to be registered in the DNS, it would have to get the public school district administrator to do it (perhaps unlikely), or not be in the K12 branch at all (unless there's the PVT pseudo district) ๐Ÿ˜ฌ.

So, if private schools are registered by <school>.<locality>.K12.<state-code>.US and public schools are registered by <school>.<district>.K12.<state-code>.US, there can't be any locality names that are the same as district names. Otherwise the delegation of these will get very tricky later ๐ŸŒ€.

If everything is done by locality names rather than district names, and public and private schools are mixed together, then finding an appropriate party to delegate the locality to may be difficult ๐Ÿซ .

Another suggestion was that private schools be registered directly under K12, while public schools must be under a district under K12. This would require the operator of the K12 branch to register all districts and private schools himself (checking for name uniqueness). He couldn't easily delegate the registration of the private schools to anyone else ๐Ÿ˜ตโ€๐Ÿ’ซ.

Community Colleges and Technical Schools

To tell Community Colleges and Technical/Vocational schools apart, the keywords "CC" and "TEC" have been created ๐Ÿ“.

Some School Examples

      Hamilton.High.LA-Unified.K12.CA.US        <== a public school
      Sherman-Oaks.Elem.LA-Unified.K12.CA.US    <== a public school
      John-Muir.Middle.Santa-Monica.K12.CA.US   <== a public school
      Crossroads-School.Santa-Monica.CA.US      <== a private school
      SMCC.CC.CA.US                             <== a community college
      TECMCC.CC.CA.US                           <== a community college
      Brick-and-Basket-Institute.TEC.CA.US      <== a technical college
      Northridge.CSU.STATE.CA.US                <== a state university

2.4. State Agencies ๐Ÿ›๏ธ

Several states are setting up networks to connect the offices of state government agencies ๐Ÿ”Œ. The hosts in these networks should be registered under the STATE.<state-code>.US branch.

A US Domain name space has been set up for state government agencies. For example, in the State of Minnesota, the subdomain is STATE.MN.US.

      State Agencies:
      ---------------

      Senate.STATE.MN.US      <== State Senate
      MDH.STATE.MN.US         <== Dept. of Health
      CALTRANS.STATE.CA.US    <== Dept. of Transportation
      DMV.STATE.CA.US         <== Dept. of Motor Vehicles

2.5. Federal Agencies ๐Ÿ‡บ๐Ÿ‡ธ

A federal name space has been set up for federal government agencies. For example, the subdomain for the Federal Reserve Bank of Minneapolis is MNPL.FRB.FED.US. Other examples are listed below ๐Ÿ‘€.

      Federal Government Agencies:
      ---------------------------

      Senate.FED.US   <====  US Senate
      DOD.FED.US      <====  US Defense Dept.
      USPS.FED.US     <====  US Postal Service
      VA.FED.US       <====  US Veterans Administration
      IRS.FED.US      <====  US Internal Revenue Service
      Yosemite.NPS.Interior.FED.US    <====  A Federal agency

2.6. Distributed National Institutes ๐ŸŒ

The "DNI" branch was created directly under the top-level US. It's for organizations that span state, regional, and other organizational boundaries, are national in scope, and have distributed facilities ๐Ÿ—บ๏ธ. An example:

      Distributed National Institutes:
      --------------------------------

      MetaCenter.DNI.US   <====  The MetaCenter Supercomputer Centers

The MetaCenter domain covers the four NSF sponsored 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 let applications and services like file systems and archival storage run in a distributed way ๐Ÿ’–. That way, the resources at the four centers appear integrated and "seamless" to the people using them โœจ.

2.7. General Independent Entities ๐Ÿงบ

This name space was created for organizations that don't really fit anywhere else, like state-wide associations, clubs, and "domain parks". Think of it as the miscellaneous category ๐Ÿฆ„.

The examples are state-wide clubs. For example, the Garden Club of Arizona might want to be GARDEN.GEN.AZ.US. A club like this has members from all over the state and isn't associated with any one city (or locality) ๐ŸŒธ. Another example is "domain parks" that have been set up until now as entities in ORG. For example, there's LONESTAR.ORG, a kind of computer club in Texas with lots of dial-in computers registered ๐Ÿ’ป. In the US Domain, an entity like that might have a name like LONESTAR.GEN.TX.US.

Organizations registered in GEN may typically be non-profit entities ๐Ÿค. These organizations don't fit in a <locality>, and they aren't a school, library, or state agency. Ordinary businesses are not registered in GEN ๐Ÿ™…โ€โ™€๏ธ.

Some people suggest these kinds of organizations are just like all the other things and ought to be registered under some <locality>. That may be true, but sometimes one just can't convince the applicant that it's the right thing to do ๐Ÿฅบ. One can argue that any organization has a headquarters, an office, or something else that's in a fixed place, so the organization could be registered at that place ๐Ÿ“.

Okay so some people be like "why even bother with a token?" ๐Ÿค” Like, why not just park these entities right under the <state-code>? Here's the tea: without a token, you can't hand off registering these entities to someone who isn't the person running the <state-code>. ๐Ÿ’… And you really want that delegation for two reasons, name uniqueness ๐Ÿ”‘ and operational management ๐Ÿ› ๏ธ. A token makes both way easier. Iconic. ๐ŸŽ€

General Independent Entities:
-----------------------------

CAL-Comp-Club.GEN.CA.US   <====  The Computer Club of California

2.8 Examples of Names ๐Ÿฆ‹

For small entities like individuals or small businesses, picking a locality-based name is usually no problem at all. โœจ For example: Zuckys.Santa-Monica.CA.US ๐Ÿ“

Big corporations with multiple facilities in several cities or states? Okay, this one can feel like an unreasonable constraint ๐Ÿ˜ค, especially compared to just registering directly in the COM domain. BUT a company does have a headquarters office in one particular locality, so it could register with that name. Example: IBM.Armonk.NY.US ๐Ÿ‘‘

PRIVATE (business or individual)
================================

Camp-Curry.Yosemite.CA.US       <====  a business
IBM.Armonk.NY.US                <====  a business
Dogwood.atl.GA.US               <====  a business
Geo-Petrellis.Culver-City.CA.US <====  a restaurant
Zuckys.Santa-Monica.CA.US       <====  a restaurant
Joe-Josts.Long-Beach.CA.US      <====  a bar
Holodek.Santa-Cruz.CA.US        <====  a personal computer

FEDERAL
=======

Senate.FED.US           <====  US Senate
DOD.FED.US              <====  US Defense Dept.
DOT.FED.US              <====  US Transportation Dept.
USPS.FED.US             <====  US Postal Service
VA.FED.US               <====  US Veterans Administration
IRS.FED.US              <====  US Internal Revenue Service
Yosemite.NPS.Interior.FED.US    <====  a federal agency
MNPL.FRB.FED.US.     <====  US Fed. Reserve Bank of Minneapolis
STATE
=====

Senate.STATE.MN.US      <====  state Senate
House.STATE.MN.US       <====  state House of Reps
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 DMV
DNI  (distributed national Institutes)
======================================

METACENTER.DNI.US       <==== a distributed nat'l Inst.


GEN (General Independent Entities)
==================================

GARDEN.GEN.AZ.US        <==== a garden club of Arizona


CITY | CI | COUNTY | CO (locality)
==================================

Parks.CI.Culver-City.CA.US          <====  a city department
Fire-Dept.CI.Los-Angeles.CA.US      <====  a city department
Fire-Dept.CO.Los-Angeles.CA.US      <====  a county department
Planning.CO.Fulton.GA.US.           <====  a county department
Main.Library.CI.Los-Angeles.CA.US   <====  a city department
MDR.Library.CO.Los-Angeles.CA.US    <====  a county department


TOWNSHIP | PARISH (locality)
============================

Police.TOWNSHIP.Green.OH.US           <====  a township department
Administration.PARISH.Lafayette.LA.US <====  a parish department
DISTRICT | LIBRARY  (agency)
============================

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

Huntington.LIB.CA.US                  <====  a private library
Venice.LA-City.LIB.CA.US              <====  a city library
MDR.LA-County.LIB.CA.US               <====  a county library
K12 | PRIVATE SCHOOLS (PVT) | CC | TEC
======================================

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

St-Monica.High.Santa-Monica.CA.US       <====  a private school
Crossroads-School.Santa-Monica.CA.US    <====  a private school
Mary-Ellens.Montessori-School.LA.CA.US  <====  a private school
Progress-Learning-Center.PVT.K12.CA.US  <====  a private school

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

Brick-and-Basket-Institute.TEC.CA.US    <== a technical college

When it makes sense, subdomains get delegated and partitioned into categories like these: ๐Ÿงฉ

       <locality>.<state>.US   =   city/locality based names
              K12.<state>.US   =   kindergarten thru 12th grade
           PVT.K12.<state.US   =   private kindergarten thru 12th grade
               CC.<state>.US   =   community colleges
              TEC.<state>.US   =   technical or vocational schools
              LIB.<state>.US   =   libraries
            STATE.<state>.US   =   state government agencies
           <org-name>.FED.US   =   federal government agencies
           <org-name>.DNI.US   =   distributed national institutes
      <org-name>.GEN.<state>.US. = statewide assoc,clubs,domain parks

The Appendix-I contains the current US Domain Names BNF. ๐Ÿ“–


3. REGISTRATION ๐Ÿ“ฌ

Okay, so there are two types of registrations. ๐Ÿ’Œ Option one is Delegation, where a branch of the US Domain is handed off to an organization running name servers to support that branch. Option two is Direct Registration, where the info goes straight into the main database. ๐Ÿฆ‹

In Direct Registration there are two cases: (a) an IP-host (one with an IP address), and (b) a non-IP host (for example, a UUCP host). Any particular registration will involve any one of these three situations. โœจ

3.1 Requirements

Anyone who wants to register a host in the US Domain gets sent a copy of the "Instructions for the US Domain Template", and must fill out a US Domain template. ๐Ÿ“

The US Domain template is similar to the InterNIC Domain template, but it is not the same, so don't mix them up ๐Ÿ™ˆ. To request a copy of the US Domain template, send a message to the US Domain registrar at us-domain@isi.edu.

If you are registering a name in a delegated zone, please register with the contact for that zone. ๐ŸŒˆ You can FTP the file in-notes/us-domain-delegated.txt from venera.isi.edu, via anonymous FTP. This info is also available by email from RFC-INFO@ISI.EDU. Put this as the only text in the message: Help: us_domain_delegated_domains

The key people must have electronic mailboxes (that work). ๐Ÿ“ซ Please provide all the information indicated in the "Administrator" and "Technical Contact" slots.

The administrator is the point of contact for any administrative and policy questions about the domain. Usually this is the person who manages the organization being registered. ๐Ÿ‘‘

The technical contact can also be the administrator, or the systems person, or someone who is familiar with the technical details of the Internet. The technical contact should have a valid working email address, because this is necessary in case something goes wrong. ๐Ÿซถ

It is important that your "Return-Path" and "From" fields indicate an Internet-style address. UUCP-style addresses such as host1!user will not work. That's fine within the UUCP world, but not the Internet. ๐Ÿ™ƒ If you want people on the Internet to be able to send mail to you, your return path needs to be an Internet-style address such as host1!user@Internet.gateway.host or user@Internet.gateway.host.

It is also possible to register through one of the Internet service providers that have established working relationships with the US Domain Administrator. ๐Ÿค

If everything checks out, the turnaround time for registering a host 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 by delegation. ๐Ÿ’–

3.2 Direct Entries

Direct entry in the database of the US Domain appeals most to individuals and small companies. ๐ŸŒธ You may fill out the application and send it directly to the US Domain Administrator. If you are in an area where the zone is delegated to someone else, your request will be forwarded to the zone administrator for your registration. Or, you may send the form directly to the manager of a delegated zone (see Section 3.1). ๐Ÿงš

3.2.1 IP-Hosts

These are hosts with IP addresses which correspond to "A" records in the DNS database. ๐ŸŒ

3.2.2 Non-IP Hosts

Many applicants have hosts in the UUCP world. Some are one hop away, and some are two and three hops away from their "Internet Forwarder". This is acceptable! ๐Ÿฅฐ What is important is getting an Internet host to be your forwarder.

If you do not already have an Internet forwarder, there are several businesses that provide this service for a fee, such as:

  • UUNET.UU.NET (postmaster@uunet.uu.net)
  • PSI (postmaster@UU2.PSI.COM)
  • CERFNET (help@cerf.net)

Sometimes local colleges in your area are already on the Internet and may be willing to act as an Internet Forwarder. You would need to work this out with the systems administrator, as we cannot make these arrangements for you. ๐Ÿ™

Although we work with UUCP service providers, the Internet US Domain registration is not affiliated with the registration of UUCP Map entries. The UUCP map entry does not provide us with sufficient information. ๐Ÿ—บ๏ธ If you do not have a copy of the US Domain questionnaire template, please send a message to us-domain@isi.edu and request one. See Appendix-II.

The example below is not an appropriate registration for the US Domain. ๐Ÿšซ

  #N starl
  #S Amiga 2500; AmigaDOS 2.04; Dillon's AmigaUUCP 1.15D
  #O Starlight BBS
  #C Stephen Baker
  #E starl!sbaker
  #T +1 305 378 1161
  #P 1107 SW 200th St #303B Miami, Fl. 33157
  #L 25 47 N / 88 10 W [city]
  #R
  #U mthvax
  #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 group where other UUCP sites will feed from you, that's fine. ๐Ÿ“ฐ These UUCP sites do not need to register. However, if the other sites become a subdomain of your hostname, then we will need to register them individually or add a wildcard record. (See Section 4.4. Wildcards.) ๐Ÿƒ

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

To use US Domain names for non-IP hosts, there must be a forwarder host that is an IP host. There must also be an administrative agreement and a technical procedure for relaying mail between the non-IP host and the forwarder host. ๐Ÿ“ฎ

Case 1:
-------

Okay so, picture this: your host isn't on the Internet proper, but it chats directly with a buddy who is ๐Ÿซถ

   +----------+            +---------+            |                 |
   |your-host |---UUCP-----|forwarder|----IP/TCP--|    INTERNET     |
   +----------+            +---------+            |                 |
                                                  +-----------------+

The forwarder MUST be an IP host on the Internet ๐ŸŒ and you MUST ask "forwarder" if they're willing to be the Internet forwarder for "your-host" ๐Ÿ’Œ

In the US Domain of the DNS database there MUST be an entry like this (only the US Domain Administrator can add it ๐Ÿ‘‘):

       "your-host"  MX  10  "forwarder"

In the "forwarder" routing tables there MUST be information about "your-host", with a rule like: if I see mail for "your-host", I will send it via UUCP by calling phone number "123-4567" ๐Ÿ“žโœจ

Case 2

This one is giving multi-hop energy ๐Ÿฆ‹ Your host talks to another host, that talks to another host, that finally talks to an IP host. So there are multiple hops between you and the Internet ๐ŸŒธ

                                                  +-----------------+
   +----------+            +---------+            |                 |
   |path-host |---UUCP-----|forwarder|----IP/TCP--|    INTERNET     |
   +----------+            +---------+            |                 |
       |                                          +-----------------+
      UUCP
       |
   +----------+
   |your-host |
   +----------+

Again, the forwarder MUST be an IP host on the Internet ๐Ÿ’… You MUST ask "forwarder" if they're willing to be the Internet Forwarder for "Your-Host", and you MUST ask "path-host" to relay your 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 about "your-host", with a rule like: if I see mail for "your-host", I will 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" (this is sometimes called double MXing) ๐Ÿ™ˆ The host on the right hand side of an MX entry MUST be a host on the Internet with an IP address (e.g., 128.9.2.32). No double MXing, bestie, it's a vibe-killer ๐Ÿ’€

3.3. Delegated Subdomains

Many branches of the US Domain are delegated ๐ŸŽ€ There MUST be a knowledgeable and competent technical contact, familiar with the Internet DNS. This requirement is easily satisified if the technical contact already runs some other name servers ๐Ÿ’–

Examples of delegations are K12.TX.US for the Kindergarten through 12th Grade public schools in Texas, the locality berkeley.ca.us, or the LIB.MN.US branch for the libraries in Minnesota ๐Ÿ“š๐ŸŒˆ

The administrator of the US Domain is responsible for the assignment of all the DNS names that end with .US. Of course, one person or even one group can't handle all this in the long run, so portions of the name space are delegated to others ๐Ÿซถ

The major concern in selecting a designated manager for a domain is that it be able to carry out the necessary responsibilities, and have the ability to do an equitable, just, honest, and competent job โœจ

The key requirement is that for each domain there MUST be a designated 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 domain itself and the global Internet community ๐ŸŒ

Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community ๐Ÿ’…

The designated manager MUST be equitable to all groups in the domain that request domain names ๐Ÿซถ

This means that the same rules are applied to all requests. All requests MUST be processed in a nondiscriminatory fashion, and academic and commercial (and other) users are treated on an equal basis. No bias SHALL be shown regarding requests that may come from customers of some other business related to the manager, e.g., no preferential service for customers of a particular data network provider ๐Ÿ™…โ€โ™€๏ธ There can be no requirement that a particular mail system (or other application), protocol, or product be used ๐ŸŽ€

There are no requirements on subdomains beyond the requirements on higher-level domains themselves. That is, the requirements are applied recursively. In particular, all subdomains SHALL be allowed to operate their own domain name servers, providing in them whatever information the subdomain manager sees fit (as long as it is true and correct) ๐Ÿงš

Significantly interested parties in the domain SHOULD agree that the designated manager is the appropriate party ๐Ÿฆ‹

The US Domain Administrator tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree. Only in cases where the designated manager has substantially neglected their responsibilities would the US Domain Administrator step in ๐Ÿ‘€

The designated manager MUST do a satisfactory job of operating the DNS service for the domain ๐Ÿ’–

That is, the actual management of the assigning of domain names, delegating subdomains and operating name servers MUST be done with technical competence. This includes keeping the US Domain Administrator or other higher-level domain managers advised of the status of the domain, responding to requests in a timely manner, and operating the database with accuracy, robustness, and resilience ๐Ÿ”ฅ

There MUST be a primary and a secondary name server that have IP connectivity to the Internet and can be easily checked for operational status and database accuracy by the US Domain Administrator ๐Ÿ›ก๏ธ

One of the aspects of having two name servers for each domain (or zone) is robustness ๐ŸŒˆ One concern under this heading is that the name service not go out entirely if there is a local power failure (earthquake, tornado, or other disaster) ๐ŸŒช๏ธ

Name Servers SHOULD be in distinctly separate physical locations. It is appropriate to have more than two name servers, but there MUST be at least two ๐Ÿ’œ

For any transfer of the designated manager trusteeship from one organization to another, the higher-level domain manager MUST receive communications from both the old organization and the new organization that assure the US Domain Administrator that the transfer is mutually agreed, and that the new organization understands its responsibilities ๐Ÿค

It is also very helpful for the US Domain Administrator to receive communications from other parties that may be concerned or affected by the transfer ๐Ÿซถ

Delegation of cities, companies within cities, schools (K12), community colleges (CC), libraries (LIB), state government (STATE), and federal government agencies (FED), etc., is acceptable and practical ๐Ÿ›๏ธ

For a delegated portion of the name space, for example a city, no alterations can be made to that name, no abbreviations added, etc. unless applied for โœ‹

Sometimes there may be two people running name servers in the same city because different portions of the name space have been delegated to them. For example, someone may be delegated the <city>.<state>.US name space, and someone else from a state government agency may have the .STATE.<state>.US portion. For example, Fred may run the name servers for Sacramento.CA.US and Joe may run the name servers for STATE.CA.US in Sacramento ๐Ÿ‘ฏ

If a company would like to have wildcard records added, or run their own name servers in a city that we have delegated name space to, this is acceptable ๐Ÿ“

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

            .<locality>.<state>.US.
         .CI.<locality>.<state>.US.
         .CO.<locality>.<state>.US.
                 .STATE.<state>.US.
                   .K12.<state>.US.
                PVT.K12.<state>.US.
                    .CC.<state>.US.
                   .TEC.<state>.US.
                   .LIB.<state>.US.
                   .GEN.<state>.US.
                           .DNI.US.
                           .FED.US.

3.3.1. Delegation Requirements

When a subdomain is delegated, the following requirements MUST be met ๐Ÿ“‹

  1. There MUST be a knowledgeable and competent technical contact, familiar with the Internet DNS. This requirement is easily satisified if the technical contact already runs some other name servers ๐ŸŽ€
  2. Organizations requesting delegations MUST provide at least two independent (robust and reliable) DNS name servers in physically separate locations on the Internet ๐ŸŒ
  3. The subdomain MUST accept all applicants on an equal basis ๐Ÿซถ
  4. The subdomain MUST provide timely processing of requests. To do this, it is helpful to have several individuals knowledgeable about the procedures, so that operations are not delayed due to one person's unavailability (for example, by being on vacation) ๐Ÿ–๏ธ
  5. The subdomain manager MUST tell the US Domain Administrator when there are changes in the name servers that SHOULD be reflected in the US Domain zone files, or changes in the contact information ๐Ÿ’Œ

K12 Administrators

In the long term, registering schools will be a big job ๐Ÿซ So you need to have in mind delegating parts of the work to various school districts. If you can delegate every school district in the state, then you are finished, except for checking that they are all operating correctly โœจ Initially, though, you'll have quite a bit to do with educating people, helping them choose names, and getting name servers arranged ๐Ÿงš You are responsible for seeing that the naming of schools follows the guidelines suggested in this memo ๐Ÿ“

All K12 Administrators will initially be responsible for managing the "pseudo district" PVT for private schools. Private schools have the option of registering as <school-name>.PVT.K12.<state>.US or as a business under the city based names ๐ŸŽ“

Locality Administrators

If you have been delegated a locality subdomain, you will be responsible for registering not only businesses directly under the locality, but also city and county agencies under the "CI" and "CO" branches ๐Ÿ™๏ธ When appropriate, these branches SHOULD be delegated.

If you want, you may spell out "CITY" instead of "CI" or "COUNTY" instead of "CO", but you MUST be consistent and use only one or the other in a given locality. The whole city government SHOULD be under one branch ๐ŸŒ†

WHOIS Database

Only the second and third level delegated name spaces will be entered in the WHOIS database. For example, K12.CA.US would have an entry in WHOIS. Anything under K12.CA.US will not be listed ๐Ÿ” The US Domain Administrator will send the information that you supplied on your US Domain template to the InterNIC. It is the hope that in the future, each delegated subdomain will provide its own WHOIS directory database for its branch ๐Ÿ’œ

3.3.2. Delegation Procedures

The procedure that is followed when a subdomain is delegated includes the following steps:

Okay bestie, here's the rest of the delegation checklist ๐Ÿ’… Every step matters, so don't skip any ๐Ÿซถ

  1. Check the technical contact's DNS experience ๐Ÿง  Make sure the delegation is actually needed โœจ and that the contact has the info about the US Domain and the suggested naming structure ๐ŸŽ€ You need two contacts with email addresses because something can go wrong, and you want a backup, periodt ๐Ÿ’–
  2. Add the new technical contact to the us-dom-adm mailing list ๐Ÿ“ฌ That's where updates about US Domain policies and procedures get shared ๐Ÿฆ‹
  3. Delete any hosts from our zone file that belong in the newly delegated subdomain ๐Ÿ—‘๏ธ and make sure those hosts show up in their zone file instead ๐ŸŒธ
  4. Send them a copy of the zone file so their starting zone file is identical to ours ๐Ÿ‘ฏโ€โ™€๏ธ For example:
mil.wi.us.      69582   SOA     spool.mu.edu.
                                manager.spool.mu.edu. (
                                930119  ;serial
                                28800   ;refresh
                                14400   ;retry
                                3600000 ;expire
                                86400 ) ;minim

mil.wi.us.      69582   NS      spool.mu.edu.
spool.mu.edu.   85483   A       134.48.1.31
mil.wi.us.      69582   NS      sophie.mscs.mu.edu.
sophie.mscs.mu.edu.     85483   A       134.48.4.6
solaria.mil.wi.us.      69582   HINFO   Sun 3/60 SunOs
solaria.mil.wi.us.      69582   MX      10 spool.mu.edu.
nthomas.mil.wi.us.      69582   HINFO   386 Clone DOS
nthomas.mil.wi.us.      69582   MX      10 spool.mu.edu.

rwmke.mil.wi.us.        69582   HINFO   UNIX PC UNIX
rwmke.mil.wi.us.        69582   MX      10 spool.mu.edu.
milestn.mil.wi.us.      69582   MX      10 spool.mu.edu.
nrunner.mil.wi.us.      69582   HINFO   MacIntosh System 7
nrunner.mil.wi.us.      69582   MX      10 spool.mu.edu.
dawley.mil.wi.us.       69582   HINFO   386 Clone DOS
dawley.mil.wi.us.       69582   MX      10 spool.mu.edu.
  ...
  1. The US Domain zone file must have the following records ๐Ÿ“ They show the name, address, email, and phone number of the technical contact for the delegated subdomain, plus the name of the delegated name space and the names of the name servers ๐Ÿซง
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;Contact:  Joseph Klein (tjk@spool.mu.edu)
;          Marquette University
;          (414) 288-6734
;
;Delegate mil.wi.us zone

mil.wi.us.      604800  NS      SPOOL.MU.EDU.
                604800  NS      SOPHIE.MSCS.MU.EDU.

; A glue record is not needed this time. Glue records are
; needed when the name of the server is a subdomain of the
; delegated domain.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  1. Check that the delegated subdomain's name servers are up and running โšก and make sure the delegated hosts are installed in their zone file ๐Ÿ’ป Then, and only then, delete any hosts from the US Domain zone file that belong in the newly delegated subdomain ๐Ÿ™ˆ
  2. Tell the technical contact of the newly delegated subdomain that wildcard records are allowed in the zone file under the organizational subdomain ๐ŸŒˆ but no wildcard records are allowed under the "city" or "state" domain ๐Ÿšซ
  3. Make sure every administrator has a copy of this RFC and follows the guidelines set forth in it ๐Ÿ“–โœจ

3.3.3 Subdomain Contacts ๐Ÿ’œ

The number of hosts registered under each subdomain is unknown ๐Ÿคทโ€โ™€๏ธ For info on the delegated domains and the contacts, check out Section 3.1 ๐Ÿงš

4. DATABASE INFORMATION โœจ

4.1. Name Servers

Okay so name servers are the storage units for the whole domain database ๐Ÿ—„๏ธ๐Ÿ’–. The database gets chopped into chunks called zones, and those zones get spread across the name servers. Name servers can have a bunch of optional functions and pull data from different sources, but their essential job (the thing they absolutely slay at) is answering queries using the data in their zones. A response can always be generated from local data alone, and it either contains the answer or a referral to other name servers that are "closer" to the info you want ๐Ÿฆ‹.

A given zone is available from several name servers so it stays up even when a host or communication link fails ๐Ÿ›Ÿ. Every zone is required to be available on at least two servers, and many zones have way more redundancy than that ๐Ÿซถ.

The US Domain is currently supported by seven name servers:

        venera.isi.edu
        ns.isi.edu
        rs.internic.net
        ns.csl.sri.com
        ns.uu.net
        adm.brl.mil
        excalibur.usc.edu

4.2 Zone Files

A "zone" is a registry of domains kept by a particular organization ๐Ÿ“’. A zone registry is "authoritative", which means the master copy is kept by the zone organization, and that copy is, by definition, always up-to-date โœจ. Copies of this registry may be distributed elsewhere and kept in caches, but those caches are not authoritative and may be out-of-date ๐Ÿ™ˆ.

Every zone has at least one node, and therefore at least one domain name, for which it is authoritative, and all of the nodes in a particular zone are connected ๐Ÿ”—. Given the tree structure, every zone has a highest node that is closer to the root than any other node in the zone. The name of this node is often used to identify the zone. The data that describes a zone has four major parts:

  1. Authoritative data for all nodes within the zone.
  2. Data that defines the top node of the zone (can be thought of as part of the authoritative data).
  3. Data that describes delegated subzones, i.e., cuts around the bottom of the zone,
  4. Data that allows access to name servers for subzones (sometimes called "glue" data).

The zone administrator has to maintain the zones at all the name servers that are authoritative for the zone. When changes are made, they must be distributed to all of the name servers ๐Ÿ“ฌ.

Copies of the zone files are not available unless you are on the Internet ๐ŸŒ. To look at the zone files, use the "dig" program of the DNS domain name system ๐Ÿ”.

     dig   @nshost  host-your-checking  axfr

4.3 Resource Records

Records in the zone data files are called resource records (RRs) ๐Ÿ’…. The standard resource records (RR) are specified in STD 13, RFC 1034 and STD 13, RFC 1035 (3,4). An RR has a standard format, shown here:

               <name> [<ttl>] [<class>] <type> <data>

The first field is always the name of the domain record. The second field is an optional time to live field, which specifies how long this data will be stored in the database โณ. The third field is the address class. The class field specifies the protocol group, and most often this is the Internet class "IN" ๐ŸŒˆ. The fourth field states the type of the resource record, and the fields after that depend on the type of RR. The fifth field is the data field, which is defined differently for each type and class of data. Here's a list of the current commonly used types:

        SOA     Start of Authority
        NS      Name Server
        A       Internet Address
        CNAME   Canonical Name (nickname pointer)
        HINFO   Host Information
        WKS     Well Known Services
        MX      Mail Exchanger
        PTR     Pointer

So what do the fields mean? Let's break it down with this example ๐Ÿ‘€:

        foo.LA.CA.US.    604800    MX   10     Venera.ISI.EDU.
        (1)              (2)       (3)  (4)    (5)
  1. domain name
  2. time to live information
  3. mail exchanger record
  4. preference value to determine (if more than one forwarder) which mailer to use first, lower number higher preference
  5. the Internet forwarding host.

4.3.1 "A" Records

An "A" record holds an Internet (IP) address ๐ŸŒธ. The data for an "A" record is an Internet address in dotted decimal form. A sample "A" record looks like this:

        venera.isi.edu.          A      128.9.0.32
           (name)               (A)     (address)

The name field is the machine name, and the address is the network address. There should be only one "A" record for each address of a host.

4.3.2 CNAME Records

A Canonical Name resource record, CNAME, specifies an alias for a canonical name. It's essentially a pointer to the official name for the requested name, and all other RRs appear under this official name ๐ŸŽ€. Say a machine named FERNWOOD.MPK.CA.US wants the nickname ANTERIOR.MPK.CA.US. In that case, this RR would be used:

        anterior.mpk.ca.us.     CNAME      fernwood.mpk.ca.us.
         (alias nickname)                   (canonical name)

Nicknames (where the name attached to the RR is the nickname) may be kept around for a while when a host changes its name, usually because it moves to another state ๐Ÿšš. It helps to have this CNAME pointer, so if any mail comes to the old address, it gets forwarded to the new one ๐Ÿ’Œ. There cannot be any other RRs associated with a nickname of the same class.

4.3.3 MX Records

Mail Exchanger records, MX, are used to specify a machine that knows how to deliver mail to a machine that isn't directly connected to the Internet ๐Ÿ“ฎ. For example, venera.isi.edu is the mail gateway that knows how to deliver mail to foo.la.ca.us, but other machines on the network can't deliver mail directly to foo.la.ca.us ๐Ÿ˜ค. These two machines might have a private connection or use a different transport medium (such as uucp). The preference value (10) is the order a mailer should follow when there's more than one way to deliver mail to a single machine. The lower the number, the higher the preference ๐Ÿ‘‘.

        foo.LA.CA.US.  604800  MX  10  Venera.ISI.EDU.
        foo.LA.CA.US.  604800  MX  20  relay1.uu.net.

4.3.4 HINFO Records

Host information resource records, HINFO, hold host-specific data ๐Ÿงš. They list the hardware and operating system running on the listed host. It should be noted that a space separates the hardware information from the operating system information. If you want to include a space in the machine name, you must quote the name. Host information isn't specific to any class, so ANY may be used for the address class. There should be one HINFO record for each host.

        acb.la.ca.us.       HINFO       VAX-11/780      UNIX
                                        (Hardware)      (Operating System)

The official HINFO types can be found in the latest Assigned Numbers RFC, the most recent edition being STD 2, RFC 1340 [9]. The hardware type is called the Machine Name, and the software type is called the System Name ๐Ÿง .

The information users supply about this is often inconsistent or incomplete ๐Ÿ™ƒ. Please follow the terms in the current "Assigned Numbers".

4.3.5 PTR Records

A Domain Name Pointer record, PTR, lets special names point to some other location in the domain database ๐Ÿ”„. These are typically used for setting up reverse pointers in the special IN-ADDR.ARPA domain. PTR names should be unique to the zone.

              0.0.9.128.in-addr.arpa     PTR    isi-net.isi.edu.
                  (special name)                  (real name)

A PTR record is to be added to the IN-ADDR.ARPA domain for every "A" record registered in the US Domain ๐Ÿ“. These PTR records need to be added by the administrator of the network where the host is connected. The US Domain Administration does not administer the network and cannot make these entries in the DNS database, so it's not on them ๐Ÿ™….

4.4 Wildcards

Wildcard records take the form "*.<anydomain>", where <anydomain> is any domain name ๐Ÿƒ. The wildcards potentially apply to descendants of <anydomain>, but not to <anydomain> itself.

Let's say a big company in California with a large, non-IP/TCP network wants to create a mail gateway ๐Ÿข. If the company is called DWP.LA.CA.US, and the IP/TCP capable gateway machine (Internet forwarder) is called ELROY.JPL.NASA.GOV, these RRs might be entered into the .US zone:

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

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

In the US Domain, wildcard records are allowed in zone files under the organizational subdomain (and where noted otherwise), but no wildcard records are allowed under the "City" or "State" domain ๐Ÿšซ.

The authors strongly believe that it is in everyone's interest and good for the Internet to have each host explicitly registered (that is, we believe that wildcards should not be used). We also realize that not everyone agrees with this belief. Thus, we will allow wildcard records in the US Domain under groups or organizations, for example *.DWP.LA.CA.US. ๐Ÿซถ
The reason we feel single entries are the best is simply that if anyone wanted to find one of the hosts in the domain name system, it would be there, and problems can be detected more easily. When wildcard records are used, all the hosts under a subdomain are hidden ๐Ÿ™ˆ.

5. REFERENCES

  • [1] Stahl, M., "Domain Administrators Guide", RFC 1032, SRI 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 and 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.
  • [7] Albitz, P., C. Liu, "DNS and Bind" Help for UNIX System Administrators, O'Reilly and Associates, Inc., October 1992.
  • [8] ACM SIGUCCS Networking Taskforce, "Connecting to the Internet - What Connecting Institutions Should Anticipate", FYI 16, RFC 1359, August 1992.
  • [9] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, ISI, July 1992.

6. Security Considerations ๐Ÿšจ

Okay, bestie, this is the big one ๐Ÿ˜ญ. Security issues are not discussed in this memo. Not a single word, so please don't go looking for them here ๐Ÿ’€.

7. Authors' Addresses ๐ŸŽ€

Here's who to DM about this one, bestie ๐Ÿ’Œ

Ann Cooper
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA  90292
Phone:  1-310-822-1511
Email:  cooper@isi.edu

Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA  90292
Phone:  1-310-822-1511
Email:  postel@isi.edu

APPENDIX-I: US DOMAIN NAMES BNF ๐Ÿ—บ๏ธ

Okay, this is the grammar that builds every US domain name, and it's honestly kind of iconic. Here it is, verbatim:

<us-domain-name>    ::= <us-name><dot><us>

<us-name>           ::= <state-name><dot><state-code> |
                        <fed-name><dot><fed>
                        <dni-name><dot><dni>

<state-code>        ::= <the two-letter code of a state from the
                         zip code directory>

<state-name>        ::= <local-name><dot><locality> |
                        <state-agency-name><dot><state> |
                        <regional-agency-name><dot><agency>

<fed-name>          ::= <the dotted hierarchical name of a US
                         federal government agency>

<dni-name>          ::= <the dotted hierarchical name of a
                         distributed national institution>

<locality>          ::= <the full name of a city from the
                          zip code directory> |
                        <a short code name for a city> |
                        <the full name of a county, township,
                         or parish> |
                        <other well known and commonly used
                         locality name>

<local-name>        ::= <entity-name> |
                        <city-name><dot><city> |
                        <county-name><dot><county> |
                        <local-agency-name><dot><local-agency>

<state-agency-name> ::= <the dotted hierarchical name of a state
                         government agency>

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

<entity-name>       ::= <the dotted hierarchical name of an
                         entity within a city, for example: a
                         company, business, private school, club,
                         organization, or individual>

<city-name>         ::= <the dotted hierarchical name of a city
                         government agency>

<county-name>       ::= <the dotted hierarchical name of a county,
                          township, or parish government agency>

<local-agency-name> ::= <the dotted hierarchical name of a special
                         agency or district not an element of a
                         city or county government and typically
                         equal or smaller than a single city or
                         county, for example, the Bunker Hill
                         Improvement District>

<city> ::= "CI" | "CITY"

<county> ::= "CO" | "COUNTY" | "TOWNSHIP" | "PARISH"

<dot> ::= "."

<fed> ::= "FED"

<dni> ::= "DNI"

<state> ::= "STATE" | "COMMONWEALTH"

<agency> ::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB" |
             "GEN"    | "TEC"

<local-agency> ::= "AGENCY" | "DISTRICT"

<us> ::= "US"

Now the notes, which are where all the good tea is ๐Ÿซ–

Within States:

  • K12 may be used for public school districts. A special name PVT can be used in the place of a school district name for private schools.
  • CC may be used only for public community colleges.
  • LIB may be only used by libraries.
  • TEC is used only for technical and vocational schools and colleges.
  • GEN is for general independent entities, that is, organizations that don't really fit anywhere else (such as statewide associations, clubs, and "domain parks").
  • STATE may be used only for state government entities.

Below US, parallel to States:

  • FED is for agencies of the federal government.
  • DNI is for distributed national institutes: organizations that span state, regional, and other organizational boundaries, that are national in scope, and that have distributed facilities.

Examples: ๐Ÿงš

Geo-Petrellis.Culver-City.CA.US         <== resturant

Joe-Josts.Long-Beach.CA.US              <== bar

IBM.Armonk.NY.US                        <== business

Camp-Curry.Yosemite.CA.US               <== business

Yosemite.NPS.Interior.FED.US            <== federal agency

Senate.FED.US                           <== US Senate

DOD.FED.US                              <== US Defense Dept.

DOT.FED.US                              <== US Transportation Dept.

MNPL.FRB.FED.US                         <== the Minneapolis branch of
                                            the Federal Reserve Bank

MetaCenter.DNI.US                       <== distributed Nat'l Inst

Senate.STATE.MN.US                      <== state Senate

House.STATE.MN.US                       <== state House of Reps

Assembly.STATE.CA.US                    <== state Assembly
MDH.STATE.MN.US                         <== state Health Dept.

DOT.STATE.MN.US                         <== state Transportation Dept

CALTRANS.STATE.CA.US                    <== state Transportation Dept

DMV.STATE.CA.US                         <== state Motor Vehicles Dept

Culver-City.DMV.STATE.CA.US             <== local office of DMV

Police.CI.Culver-City.CA.US             <== city department

Fire-Dept.CI.Los-Angeles.CA.US          <== city department

Fire-Dept.CO.Los-Angeles.CA.US          <== county department

Main.Library.CI.Los-Angeles.CA.US       <== city department

MDR.Library.CO.Los-Angeles.CA.US        <== county department

Huntington.LIB.CA.US                    <== private library

SMCC.Santa-Monica.CC.CA.US              <== public community college

Trade-Tech.Los-Angeles.CC.CA.US         <== public community college

Valley.Los-Angeles.CC.CA.US             <== public community college

Hamilton.High.LA-Unified.K12.CA.US      <== public school

Sherman-Oaks.Elem.LA-Unified.K12.CA.US  <== public school

John-Muir.Middle.Santa-Monica.K12.CA.US <== public school

St-Monicas.High.Santa-Monica.CA.US      <== private school

Crossroads-School.Santa-Monica.CA.US    <== private school

Mary-Ellens-Montessori-School.LA.CA.US  <== private school

Progress-Learning-Center.PVT.K12.CA.US  <== private school

Brick-and-Basket-Institute.TEC.CA.US    <== technical college

Bunker-Hill.DISTRICT.Los-Angeles.CA.US <== local district

SCAQMD.DISTRICT.CA.US                   <== regional district
Berkeley.UC.STATE.CA.US                 <== "CAL"

Los-Angeles.UC.STATE.CA.US              <== UCLA

Irvine.UC.STATE.CA.US                   <== UC Irvine

Northridge.CSU.STATE.CA.US              <== CSUN

Los-Angeles.CSU.STATE.CA.US             <== Cal State LA

Leland-Stanford-Jr-University.Stanford.CA.US    <== private school

# APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY ๐Ÿ“

Okay, so to register a host in the US domain, you have to send the US Domain Template to the US Domain Registrar at US-Domain@ISI.EDU ๐Ÿ’Œ The first few pages explain each question on the attached template. **Fill out the two page template at the end.** You can send questions by email to that same address, or call Ann Cooper at USC/Information Sciences Institute, (310) 822-1511.

**(1)** Tell them whether this is a new application, a modification to an existing registration, or a deletion.

**(2)** This is the name of the domain. It's the name that shows up in tables and lists linking the domain to the domain server addresses. See RFC 1480 - The US Domain for more details. Here are the formats:

```
<host>.<city/locality>.<state>.US. =  city/locality based names
<school>.<district>.K12.<state>.US. =  kindergarten thru 12th grade
       <school>.PVT.K12.<state>.US. =  private K thru 12th grade
    <school>.<locality>.<state>.US. =  PVT sch opt: locality names
            <school>.CC.<state>.US. =  community colleges
           <school>.TEC.<state>.US. =  technical or vocational schools
         <lib-name>.LIB.<state>.US. =  libraries
       <org-name>.STATE.<state>.US. =  state government agencies
                 <org-name>.FED.US. =  federal government agencies
                 <org-name>.DNI.US. =  distributed national institutes
            <org>.GEN.<state>.US. =  statewide assoc,clubs,domain parks

     For example:  networthy.santa-clara.ca.us.
```

**(3)** This is the name of the entity being represented, meaning the organization being named. For example: The Networthy Corporation. Not the name of the organization submitting the request.

**(4)** Describe the domain briefly. For example: The Networthy Corporation is a consulting organization of people working with UNIX and the C language in an electronic networking environment. It sponsors two technical conferences annually and distributes a bimonthly newsletter.

**(5)** The date you expect the domain to be fully operational.

For every registration, we need both the Administrative and the Technical contacts of a domain (questions 6 & 7), and we MUST have a network mailbox for each. If you have a NIC handle (a unique NIC database identifier), please enter it. (If you don't know what a NIC handle is, leave it blank.) Also include the title, mailing address, phone number, organization, and network mailbox.

**(6)** The name of the administrative head of the "organization". The administrator is the contact point for administrative and policy questions about the domain. The Domain administrator should work closely with the personnel he has designated as the "technical contact" for his domain. In this example, the Domain Administrator would be the Administrator of the Networthy Corporation, not the Administrator of the organization running the name server (unless it is the same person).

**(7)** The name of the technical and zone contact. The technical and zone contact handles the technical aspects of maintaining the domain's name server and resolver software, and database files. He keeps the name server running. More than likely, this person would be the technical contact running the primary name server.

> ***********************************************************************
>
> PLEASE READ: There are several types of registrations.
>
> (a) Delegation (i.e., a portion of the US Domain name space is given to an organization running name servers to support that branch; For example, K12.TX.US, for all K12 schools in Texas). For (a) answer questions 8 and 9.
>
> (b) Direct Registration of an IP Host. For (b) answer question 10.
>
> (c) Direct Registration of a non-IP Host. For (c) answer question 11 and 12.
>
> ***********************************************************************

---

**QUESTIONS FOR DELEGATIONS** ๐Ÿซถ

**(8)** PRIMARY SERVER Information. It is required to supply both the Contact information as well as hardware/software information of the primary name server.

**(9)\*** SECONDARY SERVER Information. It is required to supply the hardware and software information of all secondary name servers.

Domains must provide at least two independent servers that provide the domain service for translating names to addresses for hosts in this domain. If you are applying for a domain and a network number assignment simultaneously, and a host on your proposed network will be used as a server for the domain, you must wait until you receive your

Okay so, a host on your brand-new network can't be your server until that network number is actually assigned, and you've given that server its address. Otherwise you have to wait before sending in the domain application ๐Ÿซถ Also, putting your servers in physically separate places and on different PSNs and/or networks is strongly recommended ๐ŸŒธ

> NOTE: For those applicants not able to run name servers, or for non-IP hosts the Name Server information is not applicable. (See #10 and #11).

---

# (10) Questions for direct IP hosts ๐ŸŽ€

> (If you answered 8 & 9 do not answer 10, 11, or 12).

What Domain Name System (DNS) Resource Records (RR) and values are to be entered for your IP host (must have an "A" record) ๐Ÿ’–

```
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Example: RRs for an INTERNET hosts.

(a)  DOMAIN NAME (required)...:  Networthy.Santa-Clara.CA.US.
(b)  IP ADDRESS (required)....:  A  128.9.3.123  (required)
(c)  HARDWARE (opt)...........:  SUN-3/11O
(d)  OPERATING SYS (opt)......:  UNIX
(e)  WKS (opt)........:  128.9.3.123. UDP (echo tftp) TCP (ftp)
(f)  MX (opt).................:  10  RELAY.ISI.EDU.
```

Okay, this one is your job, bestie ๐Ÿ’… You have to make sure an IN-ADDR pointer record is entered in the DNS database. (For Internet hosts only.) Ask the administrator of the IP network your host is on to do it. The US Domain administration doesn't run the network and can't make these entries in the DNS database, so don't go asking them ๐Ÿ™ˆ

---

# (11) Questions for non-IP hosts (such as UUCP) ๐ŸŒˆ

Lots of applicants have hosts in the UUCP world. Some are one hop away from their "Internet Forwarder," some are two or three hops away, and that's totally fine โœจ What really matters is getting an Internet host to be your forwarder. If you don't already have one, there are several businesses that provide this service for a fee (see RFC 1359 - Connecting to the Internet What Connecting Institutions Should Anticipate, ACM SIGUCCS, August 1992). Sometimes local colleges in your area are already on the Internet and might be willing to act as an Internet Forwarder. You'd need to work that out with the systems administrator, since we can't make these arrangements for you ๐Ÿซ 

## (11) Internet Forwarding Host Information ๐Ÿฆ‹

**(11a) What is the name of your Internet forwarding host?**

For example: The host Yacht-Club.MDR.CA.US uses UUCP to connect to RELAY.ISI.EDU which is an Internet host. (i.e., RELAY.ISI.EDU is the forwarding host).

**(11b) What is the name of your contact person at forwarding host?**

The Administrator of RELAY.ISI.EDU must agree to be the forwarding host for Yacht-Club.MDR.CA.US, and the forwarding host must know a delivery method and route to Networthy. No double MXing. ๐Ÿ™…โ€โ™€๏ธ

**(11c) What is the mailbox of your contact?**

What is the mailbox of the administrator of the forwarding host.

```
Example:  Contact Name......:  John Smith
          Contact Email.....:  js@RELAY.ISI.EDU
```

(12) What Domain Name System (DNS) Resource Records (RR) and values are to be entered for your NON-IP host. ๐Ÿ“

```
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Example: RRs for a NON-IP host (uucp).

(a)  DOMAIN NAME (required).....:   Yacht-Club.MDR.CA.US.
(b)  HARDWARE (opt).............:   SUN-3/11O
(c)  OPERATING SYS (opt)........:   UNIX
(d)  MX (required)..............:   10  RELAY.ISI.EDU.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```

> **PLEASE ALLOW AT LEAST 8 WORKING DAYS FOR PROCESSING THIS APPLICATION** โณ

---

## US Domain template ๐Ÿ“

Please send the following two-page template to **Us-Domain@isi.edu**. Fields marked with an asterisk (*) can be copied as many times as you need. (For example: if you had two phone numbers for the Administrative Contact, you'd use the same number "6h" twice.) **PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY.** ๐Ÿฅน

```
                          US DOMAIN TEMPLATE                    [6/93]

PLEASE SUBMIT THE FOLLOWING TWO PAGE TEMPLATE TO (Us-Domain@isi.edu).
Sections or fields of this form marked with an asterisk (*) may be
copied as many times as necessary. (For example: If you had two phone
numbers for the Administrative Contact, you would use the same number
"6h" twice.  PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY.
=====================================================================
      1.   REGISTRATION TYPE
           (N)ew (M)odify (D)elete..:

      2.*  FULLY-QUALIFIED DOMAIN NAME:

      3.   ORGANIZATION INFORMATION
      3a.  Organization Name.....:
      3b.  Address Line 1........:
      3b.  Address Line 2........:
      3c.  City..................:
      3d.  State.................:
      3e.  Zip/Code..............:

      4.   DESCRIPTION OF ORG/DOMAIN:

      5.   Date Operational......:

      6.   ADMINISTRATIVE CONTACT OF ORG/DOMAIN
      6a.  NIChandle (if known)..:
      6b.  Whole Name............:
      6c.  Organization Name.....:
      6d.  Address Line 1........:
      6d.  Address Line 2........:
      6e.  City..................:
      6f.  State.................:
      6g.  Zip/Code..............:
      6h.* Voice Phone...........:
      6i.* Electronic Mailbox....:

      7.   TECHNICAL AND ZONE CONTACT
      7a.  NIChandle (if known)..:
      7b.  Whole Name............:
      7c.  Organization Name.....:
      7d.  Address Line 1........:
      7d.  Address Line 2........:
      7e.  City..................:
      7f.  State.................:
      7g.  Zip/Code..............:
      7h.* Voice Phone...........:
      7i.* Electronic Mailbox....:

FILL OUT QUESTIONS 8 AND 9 FOR DELEGATIONS ONLY (i.e., those
organizations running name servers for a branch of the US Domain
name space, for example:  k12.<state>.us).

      8.   PRIMARY SERVER: CONTACT INFO, HOSTNAME, NETADDRESS
      8a.  NIChandle (if known)..:
      8b.  Whole Name............:
      8c.  Organization Name.....:
      8d.  Address Line 1........:
      8d.  Address Line 2........:
      8e.  City..................:
      8f.  State.................:
      8g.  Zip/Code..............:
      8h.* Voice Phone...........:
      8i.* Electronic Mailbox....:
      8j.  Hostname..............:
      8k.* IP Address............:
      8l.* HARDWARE..............:
      8m.* OPERATING SYS.........:

      9. * SECONDARY SERVER: HOSTNAME, NETADDRESS
      9a.* Hostname..............:
      9b.* IP Address............:
      9c.* HARDWARE..............:
      9d.* OPERATING SYS.........:

FILL OUT QUESTION 10 FOR DIRECT REGISTRATIONS IP HOSTS

     10.   RESOURCE RECORDS (RRs) FOR IP INTERNET HOSTS
     10a.  DOMAIN NAME...........:
     10b.* IP ADDRESS (required).:
     10c.  HARDWARE..............:
     10d.  OPERATING SYS.........:
     10e.  WKS ..................:
     10f.* MX....................:

FILL OUT QUESTIONS 11 AND 12 FOR NON-IP HOSTS (such as UUCP)

     11.   FORWARDING HOST INFORMATION
     11a.  Forwarding Host......:
     11b.  Contact Name.........:
     11c.  Contact Email........:

     12.   RESOURCE RECORDS (RRs) FOR NON-IP HOSTS (UUCP)
     12a.  DOMAIN NAME...........:
     12b.  HARDWARE..............:
     12c.  OPERATING SYS.........:
     12d.* MX (required).........:
```
๐Ÿ“ฆ where this page comes from