RFCs in HTML Format

RFC 1480

Network Working Group                                          A. Cooper
Request for Comments: 1480                                     J. Postel
Obsoletes: 1386                                                June 1993

                             The US Domain

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

Cooper & Postel                                                 [Page 1]

RFC 1480 The US Domain June 1993 6. Security Considerations ..................................... 35 7. Authors' Addresses .......................................... 36 Appendix-I: US Domain Names BNF................................. 37 Appendix-II: US Domain Questionnaire ............................ 42 1. INTRODUCTION 1.1 The Internet Domain Name System The Domain Name System (DNS) provides for the translation between hostnames and addresses. Within the Internet, this means translating from a name such as "venera.isi.edu", to an IP address such as "". The DNS is a set of protocols and databases. The protocols define the syntax and semantics for a query language to ask questions about information located by DNS-style names. The databases are distributed and replicated. There is no dependence on a single central server, and each part of the database is provided in at least two servers. The assignment of the 32-bit IP addresses is a separate activity. IP addresses are delegated by the central Internet Registry to regional authorities (such as the RIPE NCC for Europe) and the network providers. To have a network number assigned please contact your network service provider or regional registration authority. To determine who this is (or as a last resort), you can contact the central Internet Registry at Hostmaster@INTERNIC.NET. In addition to translating names to addresses for hosts that are on the Internet, the DNS provides for registering DNS-style names for other hosts reachable (via electronic mail) through gateways or mail relays. The records for such name registrations point to an Internet host (one with an IP address) that acts as a mail forwarder for the registered host. For example, the host "bah.rochester.ny.us" is registered in the DNS with a pointer to the mail relay "relay1.uu.net". This type of pointer is called an MX record. This gives electronic mail users a uniform mail addressing syntax and avoids making users aware of the underlying network boundaries. The reason for the development of the domain system was growth in the Internet. The hostname to address mappings were maintained by the InterNIC in a single file, called HOSTS.TXT, which was FTP'd by all the hosts on the Internet. The network population was changing in character. The time-share hosts that made up the original ARPANET were being replaced with local networks of workstations. Local organizations were administering their own names and addresses, but Cooper & Postel [Page 2]
RFC 1480 The US Domain June 1993 had to wait for the NIC to make changes in HOSTS.TXT to make 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 and creating a need for general purpose name service. The idea of a hierarchical name space, with the hierarchy roughly corresponding to organizational structure, and names using "." as the character to mark the boundary between hierarchy levels was developed. A design using a distributed database and generalized resources was implemented. The DNS provides standard formats for resource data, standard methods for querying the database, and standard methods for name servers to refresh 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, and all the 2-letter country codes from the list of countries in ISO-3166. The establishment of new top-level domains is managed by the Internet Assigned Numbers Authority (IANA). The IANA may be contacted at IANA@ISI.EDU. Even though the original intention was that any educational institution anywhere in the world could be registered under the EDU domain, in practice, it has turned out with few exceptions, only those in the United States have registered under EDU, similarly with COM (for commercial). In other countries, everything is registered under the 2-letter country code, often with some subdivision. For example, in Korea (KR) the second level names are AC for academic community, CO for commercial, GO for government, and RE for research. However, each country may go its own way about organizing its domain, and many have. There are no current plans of putting all of the organizational domains EDU, GOV, COM, etc., under US. These name tokens are not used in the US Domain to avoid confusion. Currently, only four year colleges and universities are being registered in the EDU domain. All other schools are being registered in the US Domain. There are also concerns about the size of the other top-level domains (especially COM) and ideas are being considered for restructuring. Other names sometimes appear as top-level domain names. Some people have made up names in the DNS-style without coordinating or registering with the DNS management. Some names that typically appear are BITNET, UUCP, and two-letter codes for continents, such as Cooper & Postel [Page 3]
RFC 1480 The US Domain June 1993 "NA" for North America (this conflicts 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 do occasionally. The amateur radio network people created their own naming scheme, and it interferes sometimes with Internet addresses. 1.3 The US Domain The US Domain is an official top-level domain in the DNS of the Internet community. The 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 and thus the US Domain is established as a top-level domain and registered with the InterNIC the same way other country domains are. Because organizations in the United States have registered primarily in the EDU and COM domains, little use was initially made of the US domain. In the past, the computers registered in the US Domain were primarily owned by small companies or individuals with computers at home. However, the US Domain has grown and currently registers hosts in federal government agencies, state government agencies, K12 schools, community colleges, technical/vocational schools, private schools, libraries, city and county government agencies, to name a few. Initially, the administration of the US Domain was managed solely by the Domain Registrar. However, due to the increase in registrations, administration of subdomains is being delegated to others. Any computer in the United States may be registered in the US Domain. 2. NAMING STRUCTURE The US Domain hierarchy is based on political geography. The basic name space under US is the state name space, then the "locality" name space, (like a city, or county) then organization or computer name and so on. For example: BERKELEY.CA.US PORTLAND.WA.US Cooper & Postel [Page 4]
RFC 1480 The US Domain June 1993 There is of course no problem with running out of names. The things that are named are individual computers. If you register now in one city and then move, the database can be updated with a new name in your new city, and a pointer can be set up from your old name to your new name. This type of pointer is called a CNAME record. The use of unregistered names is not effective and causes problems for other users. Inventing your own name and using it without registering is not a good idea. In addition to strictly geographically names, some special names are used, such as FED, STATE, AGENCY, DISTRICT, K12, LIB, CC, CITY, and COUNTY. Several new name spaces have been created, DNI, GEN, and TEC, and a minor change under the "locality" name space was made to the existing CITY and COUNTY subdomains by abbreviating them to CI and CO. A detailed description follows. Below US, Parallel to States: ----------------------------- "FED" - This branch may be used for agencies of the federal government. For example: <org-name>.<city>.FED.US "DNI" - DISTRIBUTED NATIONAL INSTITUTES - The "DNI" branch was created directly under the top-level US. This branch is to be used for distributed national institutes; organizations that span state, regional, and other organizational boundaries; that are national in scope, and have distributed facilities. For example: <org-name>.DNI.US. Name Space Within States: ------------------------ "locality" - cities, counties, parishes, and townships. Subdomains under the "locality" would be like CI.<city>.<state>.US, CO.<county>.<state>.US, or businesses. For example: Petville.Marvista.CA.US. "CI" - This branch is used for city government agencies and is a subdomain under the "locality" name (like Los Angeles). For example: Fire-Dept.CI.Los-Angeles.CA.US. "CO" - This branch is used for county government agencies and is a subdomain under the "locality" name (like Los Angeles). For example: Fire-Dept.CO.San-Diego.CA.US. Cooper & Postel [Page 5]
RFC 1480 The US Domain June 1993 "K12" - This branch may be used for public school districts. A special name "PVT" can be used in the place of a school district name for private schools. For example: <school-name>.K12.<state>.US and <school-name>.PVT.K12.<state>.US. "CC" - COMMUNITY COLLEGES - This branch was established for all state wide community colleges. For example: <school-name>.CC.<state>.US. "TEC" - TECHNICAL AND VOCATIONAL SCHOOLS - The branch "TEC" was established for technical and vocational schools and colleges. For example: <school-name>.TEC.<state>.US. "LIB" - LIBRARIES (STATE, REGIONAL, CITY, COUNTY) - This branch may be used for libraries only. For example: <lib-name>.LIB.<state>.US. "STATE" - This branch may be used for state government agencies. For example: <org-name>.STATE.<state>.US. "GEN" - GENERAL INDEPENDENT ENTITY - This branch is for the things that don't fit easily into any other structure listed -- things that might fit in to something like ORG at the top-level. It is best not to use the same keywords (ORG, EDU, COM, etc.) that are used at the top-level to avoid confusion. GEN would be used for such things as, state-wide 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 | +-----+ +-----+ +-----+ +-----+ +-----+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Cooper & Postel [Page 6]
RFC 1480 The US Domain June 1993 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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| +--------+ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Cooper & Postel [Page 7]
RFC 1480 The US Domain June 1993 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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" California. 2.2 Locality Names Within the state name space there are "locality" names, some may be cities, some may be counties, some may be local names, but not incorporated entities. Registered names under "locality" could be like: <hostname>.CI.<locality>.<state>.US ==> city gov't agency <hostname>.CO.<locality>.<state>.US, ==> county gov't agency <hostname>.<locality>.<state>.US ==> businesses In the cases where the locality name is a county, there is a branch under the locality name, called "county" or "CO", that is used by the county government. Businesses are registered directly under the locality name. Cooper & Postel [Page 8]
RFC 1480 The US Domain June 1993 Under the city locality name space there is a "city" or "CI" branch for city government agencies. As usual, businesses and private schools may register directly under the city name. In the case where there is both a county and a city with the same locality name there is no problem, since the names will be unique with the "CO" or "CI" keyword. In our area the county has a fire department and the city has its own fire department. They could have names like: Fire-Dept.CI.Los-Angeles.CA.US Fire-Dept.CO.Los-Angeles.CA.US Cities may be named (designated) 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 be appropriate to use the well-known city abbreviation known throughout a locality. However, it is very desirable that all users in the same city use the same designator for the city. That is, any particular locality should have just one DNS name. Some users would like names associated with a greater metropolitan area or region like the "Bay Area" or "Tri-Cities". One problem with 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 metropolitan city in your hostname. Cities and counties are used. Should all the names be obvious? Trying to do this is desirable and also impossible. There will come a point when the obviously right name for an organization is already taken. As the system grows this will happen with increasing frequency. While ease of use to the end user is desirable, a higher priority must be placed on having a system that operates. This means that the manageability of the system must have high consideration. The reason the DNS was created was to subdivide the problem of maintaining a list of hosts in the Internet into manageable portions. The happy result is that this subdivision makes name uniqueness easier and promotes logical grouping. What is a "logical grouping" though, always depends on the viewer. Many levels of delegation are needed to keep the zone files manageable. Many sections of the name space are needed to allow unique names to be easily added. Cooper & Postel [Page 9]
RFC 1480 The US Domain June 1993 Way back in the olden days, when the Internet was invented, some thought that an 8-bit network number would be more than enough to number all the networks that would ever exist. Today, there are over 10,000 networks operating in the Internet, and arguments are made about the doubling time being 2 years versus 4 years. One concern is that things will continue to grow dramatically, and this will require more subdivision of the domain name management. Maybe the plan for the US Domain is overkill on growth planning, but there has never been overplanning for growth yet. When things are bigger, names have to be longer. There is an argument that with only 8-character names, and in each position allow a-z, 0-9, and -, you get 37**8 = 3,512,479,453,921 or 3.5 trillion possible names. It is a great argument, but how many of us want names like "xs4gp-7q". It is like license plate numbers, sure some people get the name they want on a vanity plate, but a lot more people who want something specific on a vanity plate can't get it because someone else got it 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. A decision has been made by the IANA (after consultation with the new InterNIC Internet Registry and the Federal Networking Council (FNC)) to direct these school registrations to the US domain using the naming structure described here. There is a need for competent, experienced, volunteers to come forward to act as third and perhaps fourth level registries and to operate delegated portions of the DNS. There are two reasons for registering schools in the US Domain. (1) uniqueness of names, and (2) management of the database. 1. Name Uniqueness: There are many "Washington" high schools, only one can be "Washington.EDU" (actually none can be, since that name is used by a University. There will be many name conflicts if all schools attempt to register directly under EDU. In addition, 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 keywords would only be used Cooper & Postel [Page 10]
RFC 1480 The US Domain June 1993 when they are needed, if the school's name is unique without such keywords, don't use them. 2. Database Management: One goal of the DNS is to divide up the management of the name database in to small pieces. Each piece (or "zone" in DNS terminology) could be managed by a distinct administrator. Adding all the high schools to the EDU domain will make the already large zone file for EDU even larger, possibly to the point of being unmanageable. For both these reasons it is necessary to introduce structure into names. Structure provides a basis for making common names unique in context, and for dividing the management responsibility. The US Domain has a framework established and has registered many schools already in this structured scheme. The general form is: <school>.<district>.K12.<state>.US. For example: Hamilton.LA-Unified.K12.CA.US Public schools are usually organized by districts which can be larger or smaller than a city or county. For example, the Portland school district in Oregon, is in three or four counties. Each of those counties also has non-Portland districts. It makes sense to name schools within districts. However districts often have the same name as a city or county so there has to be a way to distinguish a public school district name from some other type of locality name. The keyword "K12" is used for this. For example, typical K12 school names currently used are: IVY.PRS.K12.NJ.US DMHS.JCPS.K12.KY.US OHS.EUNION.K12.CA.US BOHS.BREA.K12.CA.US These names are generally longer than the old alternative of shorter names in the EDU domain, but that would not have lasted long without a significant number of schools finding that their "obviously correct" name has already been used by some other school. Cooper & Postel [Page 11]
RFC 1480 The US Domain June 1993 When there are many things to name some of the names will be long. In some cases there may be appropriate abbreviations that can be used. For example Hamilton High School in Los Angeles could be: Hami.Hi.LA.K12.CA.US If a school has a number of PCs, then each PC should have a name. Suppose they are named "alpha", "beta", ... then if they belong to a 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.US ... The K12 subdomain provides two points at which to delegate a branch of the database to distinct 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. In some cases, this may be a particular school, a school district, or ever all of K12 for a state. The responsibility for managing a K12 branch or sub-branch may be delegated to an appropriate volunteer. We envision that such delegations of the schools' DNS service may eventually migrate to someone else "more appropriate" from an administrative organizational point of view. The "obvious" state agency to manage the schools' DNS branch may take some time to get up to speed on Internetting. In the meantime, we can have the more advanced schools up and running. Special Schools and Service Units In many states, there are special schools that are not in districts that 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 do not have a one-to-one relationship with districts. There is some concern about naming these schools and service units within the naming structure for schools established 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 a possibility. 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 be directly under K12. For example, Cooper & Postel [Page 12]
RFC 1480 The US Domain June 1993 TIES.K12.MN.US. The special public funded schools can be handled in a similar fashion. 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 is a "pseudo district" in Massachusetts called SPCL, and there is a special school called the Progressive Computer Institute, then that school could have the name 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 may be thought of as businesses. Public schools are in districts, and districts provide a natural organizational structure for naming and delegation. For private schools there are no districts and they really do operate like businesses. But, many people are upset to think about their children in a private school being in a business category and not in K12 with the rest of the children. To accommodate both public and private schools, in each state's K12 branch, we've added an artificial district called private or "PVT". 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 have the <locality> based name "Old-Trail.Pasadena.CA.US" or the private school base name "Old-Trail.PVT.K12.CA.US". Some suggest that for private schools instead of a special pseudo district PVT to use a locality name. One reason to use district names is that, in time, it seems likely that school district administrators will take over the operation of 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 one can't have two different people registering new things below identically named branches. Cooper & Postel [Page 13]
RFC 1480 The US Domain June 1993 For example, if there is a school district named Pasadena and a 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 is 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 or the delegation of these will get very tricky later. If it is all 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 distinguish Community Colleges and Technical/Vocational schools, 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 Cooper & Postel [Page 14]
RFC 1480 The US Domain June 1993 2.4 State Agencies Several states are setting up networks to interconnect the offices of state government agencies. The hosts in such networks should be registered under the STATE.<state-code>.US branch. A US Domain name space has been established for the 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 established for the 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. This is to be used for organizations that span state, regional, and other organizational boundaries; are national in scope, and have distributed facilities. An example would be: Distributed National Institutes: -------------------------------- MetaCenter.DNI.US <==== The MetaCenter Supercomputer Centers Cooper & Postel [Page 15]
RFC 1480 The US Domain June 1993 The MetaCenter domain encompasses 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 enable applications and services like file systems and archival storage to be operated in a distributed fashion; thus, allowing the resources at the four centers to appear integrated and "seamless" to users of the centers. 2.7 General Independent Entities This name space was created for organizations that don't really fit anywhere else, such as state-wide associations, clubs, and "domain parks". Think of this 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". Such a club has membership from all over the state and is not associated with any one city (or locality). Another example is "domain parks" that have been established up-to-now as entities in ORG. For example, there is "LONESTAR.ORG", which is a kind of computer club in Texas that has lots of dial-in computers registered. In the US Domain such an entity might have a name like "LONESTAR.GEN.TX.US". The organizations registered in GEN may typically be non-profit entities. These organizations don't fit in a <locality> and are not a school, library, or state agency. Ordinary businesses are not registered in GEN. Some suggest that these kinds of organizations are just like all the other things and ought to be registered under some <locality>. This may be true, but sometimes one just can't find any way to convince the applicant that it is the right thing to do. One can argue that any organization has to have a headquarters, or an office, or something about it that is in a fixed place, and thus the organization could be registered in that place. Some suggest that no token is needed, these entities could be directly under the <state-code>. The problem with not having a token, is that you can't delegate the responsibility for registering these entities to someone separate from whoever is responsible for the <state-code>. You want to be able to delegate for both name- uniqueness reasons, and operational management reasons. Having a token there makes both easy. Cooper & Postel [Page 16]
RFC 1480 The US Domain June 1993 General Independent Entities: ----------------------------- CAL-Comp-Club.GEN.CA.US <==== The Computer Club of California 2.8 Examples of Names For small entities like individuals or small businesses, there is usually no problem with selecting locality based names. For example: Zuckys.Santa-Monica.CA.US For large entities like large corporations with multiple facilities in several cities or states this often seems like an unreasonable constraint (especially when compared with the alternative of registering directly in the COM domain). However, a company does have a headquarters office in a particular locality and so 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 Cooper & Postel [Page 17]
RFC 1480 The US Domain June 1993 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 Cooper & Postel [Page 18]
RFC 1480 The US Domain June 1993 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 appropriate, subdomains are delegated and partioned in various categories, such as: <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. Cooper & Postel [Page 19]
RFC 1480 The US Domain June 1993 3. REGISTRATION There are two types of registrations (1) Delegation, where a branch of the US Domain is delegated to an organization running name servers to support that branch; or (2) Direct Registration, in which the information is put directly into the main database. In Direct Registration there are two cases: (a) an IP-host (with an IP address), and (b) non-IP host (for example, a UUCP host). Any particular registration will involve any one of these three situations. 3.1 Requirements Anyone requesting to register a host in the US Domain is 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. To request a copy of the US Domain template, send a message to the US Domain registrar (us-domain@isi.edu). If you are registering a name in a delegated zone, please 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 information is also available via email from RFC-INFO@ISI.EDU (include 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 will be the point of contact for any administrative and policy questions about the domain. The administrator is usually the person who manages the organization being registered. The technical contact can also be 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. This is necessary in case something goes wrong. It is important that your "Return-Path" and "From" field indicate an Internet-style address. UUCP-style addresses such as "host1!user" will not work. This is 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. Cooper & Postel [Page 20]
RFC 1480 The US Domain June 1993
RFC 1480 The US Domain June 1993 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Cooper & Postel [Page 41]
RFC 1480 The US Domain June 1993 APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY To register a host in the US domain, the US Domain Template must be sent to the US Domain Registrar (US-Domain@ISI.EDU). The first few pages explain each question on the attached template. FILL OUT THE TWO PAGE TEMPLATE AT THE END. Questions may be sent by electronic mail to the above address, or by phone to Ann Cooper, USC/Information Sciences Institute, (310) 822-1511. (1) Please specify whether this is a new application, modification to an existing registration, or deletion. (2) The name of the domain. This is the name that will be used in tables and lists associating the domain with the domain server addresses. See RFC 1480 - The US Domain for more details. <host>.<city/locality>.<state>.US. = city/locality based names <school>.<district>.K12.<state>.US. = kindergarten thru 12th grade <school>.PVT.K12.<state>.US. = private K thru 12th grade <school>.<locality>.<state>.US. = PVT sch opt: locality names <school>.CC.<state>.US. = community colleges <school>.TEC.<state>.US. = technical or vocational schools <lib-name>.LIB.<state>.US. = libraries <org-name>.STATE.<state>.US. = state government agencies <org-name>.FED.US. = federal government agencies <org-name>.DNI.US. = distributed national institutes <org>.GEN.<state>.US. = statewide assoc,clubs,domain parks For example: networthy.santa-clara.ca.us. (3) The name of the entity represented, that is, the organization being named. For example: The Networthy Corporation. Not the name of the organization submitting the request. (4) Please describe the domain briefly. For example: The Networthy Corporation is a consulting organization of people working with UNIX and the C language in an electronic networking environment. It sponsors two technical conferences annually and distributes a bimonthly newsletter. (5) The date you expect the domain to be fully operational. Cooper & Postel [Page 42]
RFC 1480 The US Domain June 1993 For every registration, we need both the Administrative and the Technical contacts of a domain (questions 6 & 7) and we MUST have a network mailbox for each. If you have a NIC handle (a unique NIC database identifier) please enter it. (If you don't know what a NIC handle is leave it blank). Also the title, mailing address, phone number, organization, and network mailbox. (6) The name of the administrative head of the "organization". The administrator is the contact point for administrative and policy questions about the domain. The Domain administrator should work closely with the personnel he has designated as the "technical contact" for his domain. In this example the Domain Administrator would be the Administrator of the Networthy Corporation, not the Administrator of the organization running the name server (unless it is the same person). (7) The name of the technical and zone contact. The technical and zone contact handles the technical aspects of maintaining the domain's name server and resolver software, and database files. He keeps the name server running. More than likely, this person would be the technical contact running the primary name server. *********************************************************************** PLEASE READ: There are several types of registrations. (a) Delegation (i.e., a portion of the US Domain name space is given to an organization running name servers to support that branch; For example, K12.TX.US, for all K12 schools in Texas). For (a) answer questions 8 and 9. (b) Direct Registration of an IP Host. For (b) answer question 10. (c) Direct Registration of a non-IP Host. For (c) answer question 11 and 12. *********************************************************************** QUESTIONS FOR DELEGATIONS (8) PRIMARY SERVER Information. It is required to supply both the Contact information as well as hardware/software information of the primary name server. (9)* SECONDARY SERVER Information. It is required to supply the hardware and software information of all secondary name servers. Cooper & Postel [Page 43]
RFC 1480 The US Domain June 1993 Domains must provide at least two independent servers that provide the domain service for translating names to addresses for hosts in this domain. If you are applying for a domain and a network number assignment simultaneously and a host on your proposed network will be used as a server for the domain, you must wait until you receive your network number assignment and have given the server(s) a net- address before sending in the domain application. Establishing the servers in physically separate locations and on different PSNs and/or networks is strongly recommended. NOTE: For those applicants not able to run name servers, or for non-IP hosts the Name Server information is not applicable. (See #10 and #11). ======================================================================= QUESTION FOR DIRECT IP HOSTS (If you answered 8 & 9 do not answer 10, 11, or 12). (10) What Domain Name System (DNS) Resource Records (RR) and values are to be entered for your IP host (must have an "A" record). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Example: RRs for an INTERNET hosts. (a) DOMAIN NAME (required)...: Networthy.Santa-Clara.CA.US. (b) IP ADDRESS (required)....: A (required) (c) HARDWARE (opt)...........: SUN-3/11O (d) OPERATING SYS (opt)......: UNIX (e) WKS (opt)........: UDP (echo tftp) TCP (ftp) (f) MX (opt).................: 10 RELAY.ISI.EDU. It is your responsibility to see that an IN-ADDR pointer record is entered in the DNS database. (For Internet hosts only). Contact the administrator of the IP network your host is on to have this done. The US Domain administration does not administer the network and cannot make these entries in the DNS database. ======================================================================= QUESTIONS FOR NON-IP HOSTS (such as UUCP). Many applicants have hosts in the UUCP world. Some are one hop away, some two and three hops away from their "Internet Forwarder", this is ok. What is important is getting an Internet host to be your forwarder. If you do not already have an Internet forwarder, there are several businesses that provide this service for a fee, (see 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 may be willing to act as an Internet Forwarder. You would need to work this out with the systems administrator. We cannot make these arrangements for you. Cooper & Postel [Page 44]
RFC 1480 The US Domain June 1993 (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 Cooper & Postel [Page 45]
RFC 1480 The US Domain June 1993 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....: Cooper & Postel [Page 46]
RFC 1480 The US Domain June 1993 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).........: Cooper & Postel [Page 47]

Back to RFC index




Register domain name and transfer | Cheap webhosting service | Domain name registration