From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1386.txt | 1739 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1739 insertions(+) create mode 100644 doc/rfc/rfc1386.txt (limited to 'doc/rfc/rfc1386.txt') diff --git a/doc/rfc/rfc1386.txt b/doc/rfc/rfc1386.txt new file mode 100644 index 0000000..fa3d18f --- /dev/null +++ b/doc/rfc/rfc1386.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group A. Cooper +Request for Comments: 1386 J. Postel + December 1992 + 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 ............................................ 5 + 2.2 City Codes or Locality Names............................ 5 + 2.3 Examples of Names....................................... 5 + 3. Registration ................................................ 8 + 3.1 Requirements ........................................... 8 + 3.2 Direct Entries ......................................... 9 + 3.2.1 UUCP Hosts .......................................... 9 + 3.2.2 Non-IP Hosts ........................................ 10 + 3.3 Delegated Subdomains ................................... 12 + 3.3.1 Schools ............................................. 12 + 3.3.2 State Agencies ...................................... 14 + 3.3.3 Federal Agencies .................................... 14 + 3.3.4 Delegation Requirement............................... 14 + 3.3.5 Delegation Procedures ............................... 15 + 3.3.6 Subdomain Contacts................................... 18 + 4. Database Information......................................... 19 + 4.1 Name Servers ........................................... 19 + 4.2 Zone files ............................................. 20 + 4.3 Resource Records ....................................... 21 + 4.3.1 A Records ........................................... 22 + 4.3.2 CNAME Records ....................................... 22 + 4.3.3 MX Records .......................................... 22 + 4.3.4 HINFO Records ....................................... 23 + 4.3.5 PTR Records ......................................... 23 + 4.4 Wildcards .............................................. 23 + 5. References .................................................. 24 + 6. Security Considerations ..................................... 25 + 7. Author's Address ............................................ 25 + Appendix-I: US Domain Names BNF................................. 26 + Appendix-II: US Domain Questionnaire for Host Entry.............. 28 + + + +Cooper & Postel [Page 1] + +RFC 1386 The US Domain December 1992 + + +1. INTRODUCTION + + 1.1 The Internet Domain Name System + + The Domain Name System (DNS) provides for the translation between + host names 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 assigned by the Network Information Center + (Hostmaster@NIC.DDN.MIL). + + 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 registration 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 host name to address mappings were maintained by the + Network Information Center (NIC) in a single file, called HOSTS.TXT, + which was FTPed by all the hosts on the Internet. The network + population was changing in character. The timeshared 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 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 hierarcy levels. A design using a + distributed database and generalized resources was implemented. + + The domain system provides standard formats for resource data, + + + +Cooper & Postel [Page 2] + +RFC 1386 The US Domain December 1992 + + + standard methods for querying the database, and standard methods 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. + + Even though the intention was that any educational institution any + where 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, similiary 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 it's own way about organizing its domain, and many + have. + + Their are no plans of putting all of the organizational domains .EDU + .GOV .COM etc., under .US. + + However, there are some states registered in the .GOV domain (11 by 2 + letter code), and 3 by full names) + + ca.gov la.gov ohio.gov va.gov + co.gov md.gov or.gov wa.gov + hawaii.gov nc.gov sc.gov + ia.gov ny.gov texas.gov + + 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 ".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. + + + + + + + + +Cooper & Postel [Page 3] + +RFC 1386 The US Domain December 1992 + + + 1.3 The US Domain + + The US Domain is an official top-level domain in the DNS of the + Internet community. It is registered with the Network Information + Center. 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 NIC 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, private schools, libraries, county agencies, and + city utilities, to name a few. + + The administration of the US Domain was managed solely by the Domain + Registrar in the past. However, due to the increase of hosts, + administration of subdomains is being delegated to others. + + Any computer in the United States may be registered in the US Domain. + +2. NAMING STRUCTURE + + The US Domain hierarchy is based on political geography. The + namespace under .US is the state namespace, then the city namespace, + then organization or computer name and so on. + + For example: + + SPK.WA.US + VANC.WA.US + + 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. + + + +Cooper & Postel [Page 4] + +RFC 1386 The US Domain December 1992 + + + The use of un-registered names is not effective and causes problems + for other users. Inventing your own name and using it without + registering is not a good idea. + + 2.1 State Codes + + The state codes are the two letter US Postal abbreviations. + + 2.2 City Codes or Locality Names + + Cities may be named (designated) by their full name (spelled out with + hyphens replacing spaces (e.g., Los-Angeles or New-York)), or by a + city code. The first choice is the full city name, the second choice + is the city codes from Western Union's "City Mnemonics" list, and a + third choice is a code for your city chosen by the applicant. + However, it is very desirable that all users in the same city use the + same designator for the city. + + Abbreviated city names are a good idea, particularly when the city + name is long, as there is much to type already. One of the problems + is that the city codes in the Western Union City Mnemonics list are + sometimes not very good abbreviations. Users sometimes tend to + prefer abbreviations that are commonly used already from that region. + Such as SF for San Francisco, MPK for Menlo Park. + + Exceptions have been made in the abbreviations, even though this + causes extra work to keep track of these abbreviations. One + abbreviation for one city. Applicants are told what codes are + currently in use, however, if a city code is not used yet, and they + would prefer to use a different code that is more common among the + natives, then the new code is allowed. However, once it's + registered, then everyone else who registers in that city will have + to use that code or spell out the full city name. + + Some applicants have tried to get a copy of the Western Union City + Mnemonics code list but it is no longer available from Western Union. + However, we do have a copy but it is not online. If you are + requesting an abbreviated city code please let us know and we will + gladly look it up for you. + + 2.3 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 + + + + + +Cooper & Postel [Page 5] + +RFC 1386 The US Domain December 1992 + + + For large entities like large corporations with multiple facilities + in several cities or states this often seems like a 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. + + For example: IBM.Armonk.NY.US + + + EXAMPLES OF THE NAMING STRUCTURE IN THE US DOMAIN + + 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 + + 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 + + + + + + +Cooper & Postel [Page 6] + +RFC 1386 The US Domain December 1992 + + + CITY | COUNTY + ============== + + Police.CITY.Culver-City.CA.US <==== a city department + Fire-Dept.CITY.Los-Angeles.CA.US <==== a city department + Fire-Dept.COUNTY.Los-Angeles.CA.US <==== a county department + + REGIONAL | DISTRICT | LIBRARY + ============================= + + SCAQMD.DISTRICT.CA.US <==== a regional district + Bunker-Hill-Improvement.DISTRICT.LA.CA.US <==== a local district + + Huntington.LIB.LA.US <==== a private library + Venice.LA-City.LIB.CA.US <==== a city library + MDR.LA-County.LIB.CA.US <==== a county library + + K12 | CC | STATE UNIV | PRIVATE SCHOOLS + ======================================= + + Los-Angeles.UC.STATE.CA.US <==== UCLA + Berkeley.UC.STATE.CA.US <==== "CAL" + Irvine.UC.STATE.CA.US <==== University of Calif. Irvine + Santa-Cruz.UC.STATE.CA.US <==== University of Calif. Santa Cruz + Northridge.CSU.STATE.CA.US <==== Calif. State. Univ. Northridge + Fullerton.CSU.STATE.CA.US <==== Calif. State. Univ. Fullerton + Sonoma.CSU.STATE.CA.US <==== Calif. State. Univ. Sonoma + + SMCC.Santa-Monica.CC.CA.US <==== a public community college + Trade-Tech.Los-Angeles.CC.CA.US <==== a public community college + + Hamilton.High.LA-Unified.K12.CA.US <==== a public K12 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 + + St-Monica.High.Santa-Monica.CA.US <==== a private high school + St-Monica.Elem.Santa-Monica.CA.US <==== a private elem. school + Crossroads-School.Santa-Monica.CA.US <==== a private school + Mary-Ellens.Montessori-School.LA.CA.US <==== a private school + Leland-Stanford-Jr-Univ.Stanford.CA.US <==== a private school + Loyola-Marymount-Univ.Los-Angeles.CA.US <==== a private school + + + + + + + + + + +Cooper & Postel [Page 7] + +RFC 1386 The US Domain December 1992 + + + When appropriate, subdomains are delegated and partioned in various + categories, such as: + + K12..US = kindegarten thru 12th grade + CC..US = community colleges + LIB..US = libraries + STATE..US = state government agencies + .FED.US = federal government agencies + + The Appendix-I contains the current US Domain Names BNF, but in + actuality, the names under these subdomains may vary according to the + decision of the administrators of these subdomains. + + 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 host name. Cities and in some cases counties are used. + +3. REGISTRATION + + 3.1 Requirements + + Anyone requesting to register a host in the US Domain is sent a copy + of the US Domain policy and procedure, and must fill out a US Domain + questionnaire. + + The US Domain template, is similar to the NIC Domain template + however, it is not the same. To request a copy of the US Domain + questionnaire, send a message to the US Domain registrar (us- + domain@isi.edu). + + Note: If you are registering a name in a delegated zone + (see Section 3.3.6). Please register with the + contact for that zone. + + The key people must have electronic mailboxes (that work). Please + provide all the information indicated in the "Administrator" and + "Technical Contact" slot. This person 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 e-mail address. This is necessary in case something goes + wrong. + + + + +Cooper & Postel [Page 8] + +RFC 1386 The US Domain December 1992 + + + 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. + + 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, turn around time for registering a host is + usually a day or two. The nameservers are updated anywhere from 12 + to 24 hours later. + + There are two ways to be registered in the US Domain, directly, or by + delegation. + + 3.2 Direct Entries + + Direct entry in the database of the US Domain appeals most to + individuals and small companies. 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. + + 3.2.1 UUCP 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 + 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, 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 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 9] + +RFC 1386 The US Domain December 1992 + + + This 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. + + For example: bah.rochester.ny.us + host1.bah.rochester.ny.us + host2.bah.rochester.ny.us + + 3.2.2 NON-IP Hosts + + To use US Domain names for non-IP hosts, there must be a forwarder + host that is an IP host. There must be an adminstrative 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 + + + +Cooper & Postel [Page 10] + +RFC 1386 The US Domain December 1992 + + + this: + "your-host" MX 10 "forwarder" + + This must be entered by the US Domain administrator. + + In the "forwarder" routing tables there must be information 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 11] + +RFC 1386 The US Domain December 1992 + + + 3.3 Delegated Subdomains + + 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. + + Delegation of cities, companies within cities, schools (K12), + community colleges (CC), libraries (LIB), state government (STATE), + and federal government agencies, departments, etc., is acceptable and + practical. + + For a delegated portion of the namespace, 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 ..US + name space, and someone else from a state government agency may have + the .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 ok. + + Delegation of the whole State namespace is not yet implemented. The + delegated part of the name space is in the form of: + + .STATE..US. + .K12..US. + .CC..US. + .LIB..US. + ....US. + .CITY...US. + ..FED.US. + + 3.3.1 Schools + + As schools begin to join the Internet, there ought to be a consistent + scheme for naming them. A "K12" name branch has been established in + each state in the US Domain for this purpose. + + Public schools are usually organized by districts which can be larger + or smaller than a city or county. + + + + +Cooper & Postel [Page 12] + +RFC 1386 The US Domain December 1992 + + + It makes sense to name schools within districts. However 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. + + 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 when they are needed, if the school's name is + unique without such keywords don't use them. + + Typical K12 school names currently used are like: + + IVY.PRS.K12.NJ.US + DMHS.JCPS.K12.KY.US + OHS.EUNION.K12.CA.US + BOHS.BREA.K12.CA.US + + These names could be long. Given the large number of schools, + organizing by school district and state seems appropriate. When + there are many things to name some of the names must 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 + + 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 + Northridge.CSU.STATE.CA.US <== a state university + + If a school has a bunch of PCs, then each PC should have a name. + Suppose they are named "alpha", "beta", ... then if they belong to 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 + ... + + + + + + +Cooper & Postel [Page 13] + +RFC 1386 The US Domain December 1992 + + + 3.2.2 State Agencies + + US Domain namespace has been delegated to the state goverment + agencies. For example, in the State of Minnesota, the subdomain is + STATE.MN.US + + This means that the person running the namservers for state.mn.us are + responsible for naming agencies, of the state govermnent. For + example: + + 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 + + 3.3.3 Federal Agencies + + A federal namespace has been delegated to 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 + + 3.3.4 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 Domain Name System. This + requirement is easily satisified if the technical contact + already runs some other nameservers. + + 2) Organizations requesting delegations must provide at least two + independent (robust and reliable) DNS name servers in + physically separate locations on the Internet. + + + + +Cooper & Postel [Page 14] + +RFC 1386 The US Domain December 1992 + + + 3) The subdomain must accept all applicants on an equal basis. + + 4) The subdomain must provide timely processing of requests. 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). + + 3.3.5 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. + + 2) Note: In the past there was the concept of a "coordinator" for + a group or a club or "Domain Park". They would arrange to + coordinate the registration of all the computers used by + members of the club and forward all the information for the + group to the US Domain Administrator. Most coordinators have + moved into the position of administrator of that now delegated + subdomain. + + 3) Add the new technical contact to the "us-dom-adm" mailing list + for distributing updates to the US Domain policies and + procedures, or other pertinent information. + + 4) 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. + + + + + + + + + + + + + + + + + + +Cooper & Postel [Page 15] + +RFC 1386 The US Domain December 1992 + + + 5) Send them a copy of the zone file so their initial zone file + is identical to ours. For example: + + mil.wi.us. 86400 SOA spool.mu.edu. manager.spool.mu.edu. ( + 920904 ;serial + 28800 ;refresh + 14400 ;retry + 3600000 ;expire + 86400 ) ;minim + + mil.wi.us. 86400 NS spool.mu.edu. + spool.mu.edu. 50400 A 134.48.1.31 + mil.wi.us. 86400 NS sophie.mscs.mu.edu. + + sophie.mscs.mu.edu. 50400 A 134.48.4.6 + solaria.mil.wi.us. 86400 HINFO Sun 3/60 SunOs + solaria.mil.wi.us. 86400 MX 10 spool.mu.edu. + nthomas.mil.wi.us. 86400 HINFO 386 Clone DOS + nthomas.mil.wi.us. 86400 MX 10 spool.mu.edu. + rwmke.mil.wi.us. 86400 HINFO UNIX PC UNIX + rwmke.mil.wi.us. 86400 MX 10 spool.mu.edu. + milestn.mil.wi.us. 86400 HINFO PC AT ENIX + milestn.mil.wi.us. 86400 MX 10 spool.mu.edu. + dawley.mil.wi.us. 86400 HINFO 386 Clone DOS + dawley.mil.wi.us. 86400 MX 10 spool.mu.edu. + ... + ------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + + +Cooper & Postel [Page 16] + +RFC 1386 The US Domain December 1992 + + + 6) The US Domain zone file must have the following records, + showing the name, address, e-mail, and phone number of the + technical contact for the delegated subdomain and the name of + the delegated name space and the names of the nameservers. + + ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; + ; + ;Delegated zone: .mil.wi.us + ;Contact: Steven Goodman + ; manager@spool.mu.edu + ; Marquette University + ; (414) 288-6734 + + mil.wi.us. 604800 NS SPOOL.MU.EDU. + 604800 NS SOPHIE.MSCS.MU.EDU. + + ; A glue record is not needed this time. Glue records are + ; needed when the name of the server is a subdomain of the + ; delegated domain. + ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; + + 7) 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. + + 8) 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. + + + + + + + + + + + + + + + + + + + + + +Cooper & Postel [Page 17] + +RFC 1386 The US Domain December 1992 + + + 3.3.6 Subdomain Contacts + + Approximately 680 individual hosts are registered, but we have + delegated the following portions of the namespace. We do not know + how many hosts are registered under each of these subsdomains. + + DELEGATED ZONE CONTACT + ============== ======= + + TUCSON.AZ.US leonard@arizona.edu + SF.CA.US sf-hostmaster@apple.com + PREMENOS.SF.CA.US jenkins@premenos.sf.ca.us + SCVL.CA.US sinster@scintilla.capitola.ca.us + SANTA-CRUZ.CA.US sinster@scintilla.capitola.ca.us + APTOS.CA.US sinster@scintilla.capitola.ca.us + CAMPBELL.CA.US sinster@scintilla.capitola.ca.us + CAPITOLA.CA.US sinster@scintilla.capitola.ca.us + FELTON.CA.US sinster@scintilla.capitola.ca.us + ZAYANTE.CA.US sinster@scintilla.capitola.ca.us + BOULDER-CREEK.CA.US sinster@scintilla.capitola.ca.us + DARWIN.PTVY.CA.US brian@angband.stanford.edu + LOGAN-HS.UNIONCITY.CA.US cjw@marmot.nersc.gov + BOULDER.CO.US trent@XOR.COM + COLOSPGS.CO.US trent@XOR.COM + DENVER.CO.US trent@XOR.COM + DVR.CO.US trent@XOR.COM + CHI.IL.US matt@oddjob.uchicago.edu + EUGENE.OR.US meyer@oregon.uoregon.edu + SPRINGFIELD.OR.US meyer@oregon.uoregon.edu + MULTNOMAH.LIB.OR.US brianw@polaris.admin.ogi.edu + PGH.PA.US ecd@CERT.ORG + SPK.WA.US root@dogear.spk.wa.us + MIL.WI.US manager@spool.mu.edu + ATL.GA.US charvey@gatech.gatech.edu + Mt-PARK.GA.US charvey@gatech.gatech.edu + CLARKSTON.GA.US charvey@gatech.gatech.edu + STATE.MN.US dfazio@mr.net + MNPL.FRB.FED.US dfazio@mr.net + + K12.CA.US mdm@NIC.CSU.NET + CC.CA.US mdm@NIC.CSU.NET + K12.MI.US sandra.s.waite@um.cc.umich.edu + K12.TX.US bmanning@is.rice.edu + K12.NJ.US becker@nisc.jvnc.net + K12.MS.US fwp@msstate.edu + dmhs.jcps.K12.KY.US lentner@sura.net + TIES.K12.MN.US dfazio@mr.net + + + + +Cooper & Postel [Page 18] + +RFC 1386 The US Domain December 1992 + + + The following MD.US counties have been delegated to + (butler@brl.mil). + + AL.MD.US. Allegany + AA.MD.US. Anne Arundel + BA.MD.US. Baltimore + CAL.MD.US. Calvert + CAR.MD.US. Caroline + CE.MD.US. Cecil + CH.MD.US. Charles + DO.MD.US. Dorchester + FR.MD.US. Frederick + GA.MD.US. Garrett + HA.MD.US. Harford + HO.MD.US. Howard + KE.MD.US. Kent + MO.MD.US. Montgomery + PG.MD.US. Prince George"s + QA.MD.US. Queen Anne's + SM.MD.US. St. Mary's + SO.MD.US. Somerset + TA.MD.US. Talbot + WA.MD.US. Washington + WI.MD.US. Wicomico + WO.MD.US. Worcester + +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. + + + + + + + + +Cooper & Postel [Page 19] + +RFC 1386 The US Domain December 1992 + + + The US Domain is currently supported by six name servers. + + venera.isi.edu + ns.isi.edu + ns.hercules.csl.sri.com + nnsc.nsf.net + ns.uu.net + adm.brl.mil + + 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). + + 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 + namservers 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 + + + + + + +Cooper & Postel [Page 20] + +RFC 1386 The US Domain December 1992 + + + 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. + + [] [] + + 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 + + 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. + + + + + + + + + + + + +Cooper & Postel [Page 21] + +RFC 1386 The US Domain December 1992 + + + 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. + + 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. + + + + + +Cooper & Postel [Page 22] + +RFC 1386 The US Domain December 1992 + + + 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 RFC 1340. 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) + + 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 "*.", where + is any domain name. The wildcards potentially apply to + descendents of , but not to 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 + + + +Cooper & Postel [Page 23] + +RFC 1386 The US Domain December 1992 + + + following RRs might be entered into the .US zone. + + dwp.la.ca.us MX 10 ELROY.JPL.NASA.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. + +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. + + + + +Cooper & Postel [Page 24] + +RFC 1386 The US Domain December 1992 + + +6. SECURITY CONSIDERATIONS + + Security issues are not discussed in this memo. + +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 25] + +RFC 1386 The US Domain December 1992 + + + APPENDIX-I: US DOMAIN NAMES BNF + ================================ + + ::= + + ::= | + + + ::= + + ::= | + | + + + ::= + + ::= | + | + | + + + ::= | + | + | + + + ::= + + ::= + + ::= + + ::= + + + +Cooper & Postel [Page 26] + +RFC 1386 The US Domain December 1992 + + + ::= + + ::= + + + ::= "CITY" + + ::= "COUNTY" | "TOWNSHIP" | "PARISH" + + ::= "." + + ::= "FED" + + ::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB" + + ::= "STATE" | "COMMONWEALTH" + + ::= "US" + + + Note: "K12" may be used for public school districts, only. + and "CC" may be used only for public community colleges, + and "LIB" can only be used by libraries. + + + + + + + + + + + + + + + + + + + + + + +Cooper & Postel [Page 27] + +RFC 1386 The US Domain December 1992 + + + APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY + + +To register a host in the US domain, the following information must be +sent to the US Domain Registrar (Us-Domain@ISI.EDU). Questions may be +sent by electronic mail to the above address, or by phone to +Ann Cooper (310-822-1511). + + +(1) The name of the top-level domain to join. + + For example: US + + +(2) The name of the administrative head of the organization, including + title, mailing address, phone number, organization, and network + mailbox. This is the contact point for administrative and policy + questions about the domain. In the case of a research project, + this should be the principal investigator. + + For example: + + Administrator + + Organization The NetWorthy Corporation + Name Penelope Q. Sassafrass + Title President + Mail Address The NetWorthy Corporation + 4676 Andrews Way, Suite 100 + Santa Clara, CA 94302-1212 + Phone Number (415) 123-4567 + Net Mailbox Sassafrass@ECHO.TNC.COM + + + + + + + + + + + + + + + + + + + +Cooper & Postel [Page 28] + +RFC 1386 The US Domain December 1992 + + +(3) The name of the technical contact for the entry, including title, + mailing address, phone number, organization, and network mailbox. + This is the contact point for problems concerning the domain or + zone, as well as for updating information about the domain or zone. + + For example: + + Technical Contact + + Organization The NetWorthy Corporation + Name Ansel A. Aardvark + Title Executive Director + Mail Address The NetWorthy Corporation + 4676 Andrews Way, Suite 100 + Santa Clara, CA. 94302-1212 + Phone Number (415) 123-6789 + Net Mailbox Aardvark@ECHO.TNC.COM + + +(4) The name of the host. This is the name that will be used in tables + and lists associating the domain with the domain server addresses. + [While, from a technical standpoint, domain names can be quite long + (programmers beware), shorter names are easier for people to cope + with.] + + For example: NetWorthy.Santa-Clara.CA.US + + Or: Alpha.NetWorthy.Santa-Clara.CA.US + Beta.NetWorthy.Santa-Clara.CA.US + + +(5) If this machine is not directly on the internet, how does it + communicate with the Internet. Through UUCP, CREN, etc? Which + forwarding host? + + For example: The host "Networthy.Santa-Clara.CA.US" uses UUCP + to connect to "RELAY.ISI.EDU" which is an Internet host. + + The administrator of RELAY.ISI.EDU must agree to be the + forwarding host for Networthy.Santa-Clara.CA.US, and the + forwarding host must know a delivery method and route to it. + No double MXing. + + + + + + + + + +Cooper & Postel [Page 29] + +RFC 1386 The US Domain December 1992 + + + If you are requesting an indirect connection, that is, a Mail + Exchanger (MX) record, what is the name and mailbox of the + administrator of the forwarding host. + + For example:John Smith + js@RELAY.ISI.EDU + + +(6) Please describe your organization 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. + + +(7) What Domain Name System (DNS) Resource Records (RR) and values are + to be entered. + + a. A Internet Address (internet hosts only) + b. HINFO Host Information, Machine System + c. WKS Well Known Services, Protocols, Ports (internet hosts only) + d. MX Mail Exchanger (required for UUCP, and CREN hosts) + + An example of RRs for an internet host. + + NetWorthy.Santa-Clara.CA.US IN A 128.9.3.123 + IN HINFO SUN-3/11OC UNIX + IN MX 10 ISI.EDU + IN WKS 128.9.3.123. UDP (echo + tftp) + IN WKS 128.9.3.133. TCP (telnet + ftp + tftp + finger) + + An example of RRs for a non-internet host. + + Beta.NetWorthy.Santa-Clara.CA.US MX 10 RELAY.ISI.EDU + HINFO SUN-3/11OC UNIX + + + + + + + + + + + +Cooper & Postel [Page 30] + +RFC 1386 The US Domain December 1992 + + +(8) Where is the IN-ADDR pointer record to be entered. (For internet + hosts only.) It is your responsibility to see that this is done. + Contact the administrator of the IP network your host is on. The + US Domain administration does not administer the network and cannot + make these entries in the DNS database. + + For example: + + 123.3.9.128.IN-ADDR.ARPA. PTR NetWorthy.Santa-Clara.CA.US + + Who is the contact for the zone of the IN-ADDR.ARPA data, where + this record will be entered? + + +(9) What Time to Live (TTL)? TTL is the time (in seconds) that a + resolver will use the data it got from the domain server before it + asks it again for the data. A typical TTL is One Week 604800. + (NOTE: TTL is not applicable to non-Internet hosts.) + + For example: + + One Week 604800 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Cooper & Postel [Page 31] + \ No newline at end of file -- cgit v1.2.3