diff options
Diffstat (limited to 'doc/rfc/rfc1480.txt')
| -rw-r--r-- | doc/rfc/rfc1480.txt | 2635 |
1 files changed, 2635 insertions, 0 deletions
diff --git a/doc/rfc/rfc1480.txt b/doc/rfc/rfc1480.txt new file mode 100644 index 0000000..f8dd440 --- /dev/null +++ b/doc/rfc/rfc1480.txt @@ -0,0 +1,2635 @@ + + + + + + +Network Working Group A. Cooper +Request for Comments: 1480 J. Postel +Obsoletes: 1386 June 1993 + + The US Domain + + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify 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 + + + +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 + "128.9.0.32". 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 + + + 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 turn around 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, + some 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) + and 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. + + + + + + +Cooper & Postel [Page 21] + +RFC 1480 The US Domain June 1993 + + + 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. If however, 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 be an administrative agreement + and a technical procedure for relaying mail between the non-IP host + and the forwarder host. + + Case 1: + ------- + + Your host is not an IP host but does talk directly with a host that + is an IP host. + +-----------------+ + +----------+ +---------+ | | + |your-host |---UUCP-----|forwarder|----IP/TCP--| INTERNET | + +----------+ +---------+ | | + +-----------------+ + "Forwarder" must be an IP host on the Internet. + + You must ask "forwarder" if they are willing to be the Internet + forwarder for "your-host". + + In the US Domain of the DNS data base there must be an entry like + this: + "your-host" MX 10 "forwarder" + + + +Cooper & Postel [Page 22] + +RFC 1480 The US Domain June 1993 + + + This must be entered by the US Domain Administrator. + + In the "forwarder" routing tables there must be information 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: + ------- + + In this case your hosts talks to another host that ... that talks to + an IP host. In other words, there are multiple hops between your host + and the Internet. + +-----------------+ + +----------+ +---------+ | | + |path-host |---UUCP-----|forwarder|----IP/TCP--| INTERNET | + +----------+ +---------+ | | + | +-----------------+ + UUCP + | + +----------+ + |your-host | + +----------+ + + "Forwarder" must be an IP host on the Internet. + + You must ask "forwarder" if they are willing to be the Internet + Forwarder for "Your-Host". 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). + + + + + + +Cooper & Postel [Page 23] + +RFC 1480 The US Domain June 1993 + + + 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 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 + + + +Cooper & Postel [Page 24] + +RFC 1480 The US Domain June 1993 + + + 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 for 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 assures the US Domain Administrator that the + transfer in 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. + + + + +Cooper & Postel [Page 25] + +RFC 1480 The US Domain June 1993 + + + Delegation of cities, companies within cities, schools (K12), + community colleges (CC), libraries (LIB), state government (STATE), + and federal government agencies (FED), etc., is acceptable 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 has 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. + + + + + +Cooper & Postel [Page 26] + +RFC 1480 The US Domain June 1993 + + + 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 the operations are + not delayed due to one persons 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. However, initially you will 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 follow 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 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. + + + + + + +Cooper & Postel [Page 27] + +RFC 1480 The US Domain June 1993 + + + 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 + their own WHOIS directory database for their branch. + + 3.3.2 Delegation Procedures + + The procedure that is followed when a subdomain is delegated includes + the following steps: + + 1) Evaluate the technical contact's experience with DNS. Make + sure there is a need for the proposed delegation. Make sure + the technical contact has the information about the US Domain + and the suggested naming structure. Two contacts with email + addresses are necessary in case something goes wrong. + + 2) Add the new technical contact to the "us-dom-adm" mailing list + for distributing updates concerning the US Domain policies and + procedures. + + 3) Delete any hosts from our zone file that belongs in the newly + delegated subdomain and make sure they now have the hosts in + their zone file. + + 4) Send them a copy of the zone file so their initial 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. + + + +Cooper & Postel [Page 28] + +RFC 1480 The US Domain June 1993 + + + 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. + ... + + 5) The US Domain zone file must have the following records, + showing the name, address, email, and phone number of the + technical contact for the delegated subdomain and 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. + ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; + + 6) Check to see that delegated subdomain name servers are up and + running, and make sure the delegated hosts are installed in + their zone file. Now delete any hosts from the US Domain zone + file that belongs in the newly delegated subdomain. + + 7) Inform 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. + + 8) Make sure each administrator has a copy of this RFC and + follows the guidelines set forth. + + 3.3.3 Subdomain Contacts + + The number of hosts registered under each subdomain is unknown. See + Section 3.1 for information on the delegated domains and the + contacts. + + + +Cooper & Postel [Page 29] + +RFC 1480 The US Domain June 1993 + + +4. DATABASE INFORMATION + + 4.1. Name Servers + + Name servers are the repositories of information that make up the + domain database. The database is divided up into sections called + zones, which are distributed among the name servers. While name + servers can have several optional functions and sources of data, the + essential task of a name server is to answer queries using data in + its zones. The response to a query can always be generated using + only local data, and either contains the answer to the question or a + referral to other name servers "closer" to the desired information. + + A given zone will be available from several name servers to insure + its availability in spite of host or communication link failure. + Every zone is required to be available on at least two servers, and + many zones have 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", that is, the master copy of the + registry is kept by the zone organization, and this copy is, by + definition, always up-to-date. Copies of this registry may be + distributed to other places and kept in caches, but these caches are + not authoritative, and may be out-of-date. + + Every zone has at least one node, and hence 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 + which 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). + + + +Cooper & Postel [Page 30] + +RFC 1480 The US Domain June 1993 + + + 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 which are authoritative for the zone. When the 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 as shown. + + <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. This specifies how long + this data will be stored in the data base. The third field is the + address class; the class field specifies the protocol group most + often this is the Internet class "IN". The fourth field states the + type of the resource record. The fields after that are dependent on + the Type of RR. The fifth field is the data field which is defined + differently for each type and class of data. Here is 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 + + + + + + + + + +Cooper & Postel [Page 31] + +RFC 1480 The US Domain June 1993 + + + What do the fields mean? + + foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU. + (1) (2) (3) (4) (5) + + 1) domain 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 + + Internet (IP) Address. The data for an "A" record is an Internet + address in a dotted decimal form. A sample "A" record might look + like: + + 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 + + Canonical Name resource record, CNAME, specifies an alias for a + canonical name. This is essentially a pointer to the official name + for the requested name. All other RRs appear under this official + name. A machine named FERNWOOD.MPK.CA.US may want to have the + nickname ANTERIOR.MPK.CA.US. In that case, the following RR would be + used: + + anterior.mpk.ca.us. CNAME fernwood.mpk.ca.us. + (alias nickname) (canonical name) + + Nicknames (the name associated with the RR is the nickname) may be + added for awhile 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 will get forwarded to the new + one. There cannot be any other RRs associated with a nickname of the + same class. + + + + + + + +Cooper & Postel [Page 32] + +RFC 1480 The US Domain June 1993 + + + 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 is not 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 cannot deliver mail directly to foo.la.ca.us. These two + machines may have a private connection or use a different transport + medium (such as uucp). The preference value (10) is the order that a + mailer should follow when there is 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 is for host specific data. + This lists the hardware and operating system that are running at the + listed host. It should be noted that a space separates the hardware + information and the operating system information. If you want to + include a space in the machine name you must quote the name. Host + information is not 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, allows special names to point to + some other location in the domain data base. These are typically + used in setting up reverse pointers for 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) + + + + + +Cooper & Postel [Page 33] + +RFC 1480 The US Domain June 1993 + + + 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. + + 4.4 Wildcards + + The wildcard records are of the form "*.<anydomain>", where + <anydomain> is any domain name. The wildcards potentially apply to + descendents of <anydomain>, but not to <anydomain> itself. + + For example, suppose a large company located in California with a + large, non-IP/TCP, network wanted to create a mail gateway. If the + company was called DWP.LA.CA.US, and the IP/TCP capable gateway + machine (Internet forwarder) was called ELROY.JPL.NASA.GOV, the + following 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 our 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 by the mere + fact 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 using wildcards records all the + hosts under a subdomain are hidden. + + + + + + + + +Cooper & Postel [Page 34] + +RFC 1480 The US Domain June 1993 + + +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 + + Security issues are not discussed in this memo. + + + + + + + + + + + + + + + + + + +Cooper & Postel [Page 35] + +RFC 1480 The US Domain June 1993 + + +7. Authors' Addresses + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cooper & Postel [Page 36] + +RFC 1480 The US Domain June 1993 + + + APPENDIX-I: US DOMAIN NAMES BNF + ================================ + + <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> + + + + + + + +Cooper & Postel [Page 37] + +RFC 1480 The US Domain June 1993 + + + <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" + + + Notes: + + 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. + + + + +Cooper & Postel [Page 38] + +RFC 1480 The US Domain June 1993 + + + "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 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 + + + + +Cooper & Postel [Page 39] + +RFC 1480 The US Domain June 1993 + + + 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 + + + + +Cooper & Postel [Page 40] + +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 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. + +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] +
\ No newline at end of file |