RFC 1480
The US Domain
1. Introduction โจ
RFC number: 1480 Title: The US Domain Authors: A. Cooper and J. Postel Category: Informational (it's giving "for your info," not a standard) ๐ Date: June 1993 Obsoletes: 1386 Updates: none listed in the title block
Status of This Memo
This memo gives info to the Internet community. It is not a specification of an Internet standard. Distribution of this memo is unlimited. ๐
Table of Contents
1. Introduction ................................................ 2
1.1 The Internet Domain Name System......................... 2
1.2 Top-Level Domains....................................... 3
1.3 The US Domain .......................................... 4
2. Naming Structure ............................................ 4
2.1 State Codes ............................................ 8
2.2 Locality Names.......................................... 8
2.3 Schools ................................................ 10
2.4 State Agencies.......................................... 15
2.5 Federal Agencies ....................................... 15
2.6 Distributed National Institutes......................... 15
2.7 General Independent Entities............................ 16
2.8 Examples of Names....................................... 17
3. Registration ................................................ 20
3.1 Requirements ........................................... 20
3.2 Direct Entries ......................................... 21
3.2.1 IP-Hosts............................................. 21
3.2.2 Non-IP Hosts ........................................ 21
3.3 Delegated Subdomains ................................... 24
3.3.1 Delegation Requirement............................... 26
3.3.2 Delegation Procedures ............................... 28
3.3.3 Subdomain Contacts................................... 29
4. Database Information......................................... 30
4.1 Name Servers ........................................... 30
4.2 Zone files ............................................. 30
4.3 Resource Records ....................................... 31
4.3.1 "A" Records ......................................... 32
4.3.2 CNAME Records ....................................... 32
4.3.3 MX Records .......................................... 33
4.3.4 HINFO Records ....................................... 33
4.3.5 PTR Records ......................................... 33
4.4 Wildcards .............................................. 34
5. References .................................................. 35
6. Security Considerations ..................................... 35
7. Authors' Addresses .......................................... 36
Appendix-I: US Domain Names BNF................................. 37
Appendix-II: US Domain Questionnaire ............................ 42
1.1. The Internet Domain Name System
Okay so the Domain Name System (DNS) is the thing that translates hostnames into addresses. On the Internet, that means turning a name like "venera.isi.edu" into an IP address like "128.9.0.32". ๐ฆ It's a set of protocols plus databases. The protocols define the syntax and semantics of a query language for asking questions about information stored under DNS-style names. The databases are distributed and replicated, so there's no dependence on one central server, and every part of the database is served by at least two servers. Iconic redundancy ๐
Assigning those 32-bit IP addresses is a separate activity. The central Internet Registry delegates them to regional authorities (like the RIPE NCC for Europe) and to network providers. ๐ธ
To get a network number assigned, contact your network service provider or your regional registration authority. If you can't figure out who that is (or as a last resort), you can reach the central Internet Registry at Hostmaster@INTERNIC.NET. ๐ฌ
Beyond names for hosts on the Internet, DNS also lets you register DNS-style names for hosts you can reach through electronic mail via gateways or mail relays. Those records point to an Internet host (one with an IP address) that acts as a mail forwarder for the registered host. For example, "bah.rochester.ny.us" is registered in the DNS with a pointer to the mail relay "relay1.uu.net". That type of pointer is called an MX record. This gives email users one uniform mail addressing syntax and hides the underlying network boundaries from them. โจ
So why was the domain system even invented? Internet growth, babe ๐ The hostname-to-address mappings were kept in one file called HOSTS.TXT, maintained by the InterNIC, and every host on the Internet FTP'd it. The network was changing too. The time-share hosts of the original ARPANET were being replaced by local networks of workstations. Local organizations were running their own names and addresses but had to wait for the NIC to edit HOSTS.TXT before anyone outside could see the changes. Orgs also wanted some local structure in the name space. Applications were getting more sophisticated and needed a general-purpose name service. So a hierarchical name space was developed, roughly matching organizational structure, where "." marks the boundary between hierarchy levels. It was built as a distributed database with generalized resources. ๐ง
DNS provides standard formats for resource data, standard methods for querying the database, and standard methods for name servers to refresh their local data from other name servers. ๐
1.2. Top-Level Domains
The top-level domains in the DNS are EDU, COM, GOV, MIL, ORG, INT, and NET, plus all the 2-letter country codes from the ISO-3166 list of countries. The IANA (Internet Assigned Numbers Authority) manages the creation of new top-level domains, and you can reach it at IANA@ISI.EDU. ๐
Even though the original plan was that any educational institution anywhere in the world could register under EDU, in practice only institutions in the United States have registered there, and the same goes for COM (commercial). Other countries put everything under their 2-letter country code, often with some subdivision. For example, in Korea (KR) the second-level names are AC (academic community), CO (commercial), GO (government), and RE (research). Each country can go its own way about organizing its domain, and many have. ๐
There are no current plans to put all the organizational domains (EDU, GOV, COM, and so on) under US. Those name tokens aren't used in the US Domain, to avoid confusion. ๐
Right now, only four-year colleges and universities are registering in the EDU domain. All other schools register in the US Domain. ๐
There are also concerns about how big the other top-level domains are (especially COM), and ideas for restructuring are being considered. ๐ญ
Other names sometimes show up as top-level domain names. Some people have made up DNS-style names without coordinating with or registering through DNS management. Names that typically pop up are BITNET, UUCP, and two-letter continent codes like "NA" for North America (which clashes with the official Internet code for Namibia). ๐
For example, the DNS-style name "KA7EEJ.CO.USA.NA" is used in the amateur radio network. These addresses are never supposed to show up on the Internet, but they occasionally do. The amateur radio network people created their own naming scheme, and it sometimes interferes with Internet addresses. ๐ป
1.3. The US Domain
The US Domain is an official top-level domain in the DNS of the Internet community. Its domain administrators are Jon Postel and Ann Westine Cooper at the Information Sciences Institute of the University of Southern California (USC-ISI). ๐ซถ
US is the ISO-3166 2-letter country code for the United States, so the US Domain is established as a top-level domain and registered with the InterNIC the same way other country domains are. ๐บ๐ธ
Because US organizations mostly registered in the EDU and COM domains, the US Domain got little use at first. Back then, the computers registered in the US Domain were mainly owned by small companies or individuals with computers at home. But the US Domain has grown, and it now registers hosts in federal government agencies, state government agencies, K12 schools, community colleges, technical and vocational schools, private schools, libraries, and city and county government agencies, just to name a few. ๐ฅ
At first, the Domain Registrar managed the US Domain alone. Because registrations increased, administration of subdomains is now being delegated to others. ๐ธ
Any computer in the United States may be registered in the US Domain. โจ
"CO" is the branch for county government agencies ๐๏ธ, and it sits as a subdomain under the "locality" name (like Los Angeles). For example: Fire-Dept.CO.San-Diego.CA.US. ๐
"K12" is for public school districts ๐. Private schools can use the special name "PVT" in place of a district name, so you'd get <school-name>.K12.<state>.US and <school-name>.PVT.K12.<state>.US ๐
"CC" is for community colleges ๐. This branch was set up for all the statewide community colleges, like <school-name>.CC.<state>.US. โจ
"TEC" is for technical and vocational schools and colleges ๐ ๏ธ. Something like <school-name>.TEC.<state>.US ๐ง
"LIB" is for libraries only ๐, including state, regional, city, and county ones. For example: <lib-name>.LIB.<state>.US ๐ธ
"STATE" is for state government agencies ๐ข. For example: <org-name>.STATE.<state>.US ๐
"GEN" is the catch-all for general independent entities ๐. It's for things that don't fit neatly into any other branch, the kinds of things that might otherwise sit under ORG at the top level. It's best not to reuse the top-level keywords (ORG, EDU, COM, etc.) here so nobody gets confused. GEN is for things like statewide organizations, clubs, or domain parks. For example: <org-name>.GEN.<state-code>.US ๐ฆ
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VIEW OF SECOND LEVEL DOMAINS UNDER US
+-------+
| US |
+-------+
|
+----------------------------------+
| | | | |
+-----+ +-----+ +-----+ +-----+ +-----+
| FED | | DNI | | TX | | SD | | CA |
+-----+ +-----+ +-----+ +-----+ +-----+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
SCHOOL AND LIBRARY VIEW
+-----+
| CA |
+-----+
|
+------------------------------------------------+
| | | | |
+-----+ +-----+ +-----+ +-------------+ +-----+
| K12 | | CC | | TEC | | LOS ANGELES | | LIB |
+-----+ +-----+ +-----+ +-------------+ +-----+
/ \ /|\ /|\ /|\ /|\
+--------+ +---+ +---+ +--------+ +----------+ +------+
|sch dist| |PVT| |SJC| |WM TRADE| |pvt school| |MALIBU|
+--------+ +---+ +---+ +--------+ +----------+ +------+
/|\ /|\
+--------+ +--------+
|sch name| |sch name|
+--------+ +--------+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VIEW OF STATE, REGIONAL, and GENERAL AGENCIES
+-----+
| CA |
+-----+
|
+-------------------------+
| | |
+-------+ +--------+ +-----+
| STATE | |DISTRICT| | GEN |
+-------+ +--------+ +-----+
/|\ /|\ /|\
+--------+ +------+ +---------+
|CALTRANS| |SCAQMD| |domain pk|
---------+ +------+ +---------+
|
+--------+
|TCEW100E|
+--------+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
VIEW OF LOCALITY
+-----+
| CA |
+-----+
|
+-----------------------------------+
| |
+-------------------------+ +----------------+
| LOS ANGELES | | SANTA MONICA |
+-------------------------+ +----------------+
/ | | /|\ | /|\
/ | | | | |
+---+ +--+ +--+ +-----------+ +--+ +---+
|bus| |CI| |CO| | pvt school| |CI| |bus|
+---+ +--+ +--+ +-----------+ +--+ +---+
/\ | |
/ \ | +------------+
/ \ | |HARBOR GUARD|
/ \ | +------------+
+-----+ +-----+ +-----+ +----+
|FIRE | |ADMIN| |PARKS| |FIRE|
+-----+ +-----+ +-----+ +----+
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2.1. State Codes ๐บ๏ธ
The state codes are the two-letter US Postal abbreviations. For example: "CA" is California. ๐ด
2.2. Locality Names ๐๏ธ
Inside the state namespace there are "locality" names. Some of them may be cities, some may be counties, and some may be local names that aren't incorporated entities.
Registered names under "locality" could look like this:
<hostname>.CI.<locality>.<state>.US ==> city gov't agency
<hostname>.CO.<locality>.<state>.US, ==> county gov't agency
<hostname>.<locality>.<state>.US ==> businesses
When the locality is a county, there's a branch under the locality name called "county" or "CO", and the county government uses it. Businesses register directly under the locality name. ๐ผ
Under a city locality name there's a "city" or "CI" branch for city government agencies. As usual, businesses and private schools may register directly under the city name. ๐ซ
If a county and a city share the same locality name, that's totally fine, because the "CO" or "CI" keyword keeps the names unique. Where I live, the county has a fire department and the city has its own, so they could have names like these:
Fire-Dept.CI.Los-Angeles.CA.US
Fire-Dept.CO.Los-Angeles.CA.US
Cities can be named by their full name, spelled out with hyphens replacing spaces (e.g., Los-Angeles or Fort-Collins), or by a city code. The first choice is the full city name. In some cases it may make sense to use a well-known city abbreviation that everyone in the locality recognizes. Still, it's really important that all users in the same city use the same designator for it. In other words, any particular locality should have just one DNS name. ๐
Some people want names tied to a bigger metro area or region, like the "Bay Area" or "Tri-Cities". The catch is that these names aren't necessarily unique within a state. The best move here is to use the larger metropolitan city in your hostname. Cities and counties are used.
Should all the names be obvious? Trying to make them obvious is desirable, and also impossible. At some point, the obviously right name for an organization will already be taken. As the system grows, that happens more and more often. Ease of use for the end user matters, but a higher priority is a system that actually works. That means manageability needs a lot of consideration. ๐ ๏ธ
DNS was created to split the job of keeping track of hosts on the Internet into manageable chunks. ๐งฉ
The happy result is that splitting things up makes names easier to keep unique and encourages logical grouping. What counts as a "logical grouping," though, always depends on who's looking. ๐
Lots of levels of delegation are needed to keep zone files manageable. Lots of sections of the namespace are needed so unique names can be added easily. ๐ฐ
Way back in the olden days, when the Internet was invented, some people thought an 8-bit network number would be more than enough to number every network that would ever exist. Today there are over 10,000 networks operating on the Internet, and people argue about whether the doubling time is 2 years or 4 years. ๐ญ
One concern is that things will keep growing dramatically, which will require more subdivision of domain name management. Maybe the plan for the US Domain is overkill on growth planning, but there has never been too much planning for growth. ๐ฑ
When things get bigger, names have to get longer. One argument goes like this: with only 8-character names, where each position can be a-z, 0-9, or -, you get 37**8 = 3,512,479,453,921, or 3.5 trillion possible names. It's a great argument, but how many of us actually want names like xs4gp-7q? It's like license plates. Sure, some people get the vanity plate they want, but a lot more people who want something specific can't have it because someone else got there first. Structure and longer names also let more people get their "obviously right" name. ๐
2.3. Schools ๐ซ
K12 schools are connecting to the Internet and registering in the Internet DNS. The IANA made a decision (after consulting the new InterNIC Internet Registry and the Federal Networking Council (FNC)) to send these school registrations to the US domain, using the naming structure described here. ๐งพ
We need competent, experienced volunteers to step up and act as third and perhaps fourth level registries, and to run delegated portions of the DNS. ๐โโ๏ธ
There are two reasons for registering schools in the US Domain: (1) uniqueness of names, and (2) management of the database. ๐
- Name Uniqueness:
There are many "Washington" high schools, but only one can be Washington.EDU. (Actually, none can be, since that name is already used by a university.) If every school tried to register directly under EDU, there would be tons of name conflicts. ๐ฅ
Also, in some districts the same school name is used at different levels, like Washington Elementary School and Washington High School. We suggest that when necessary, the keywords "Elementary", "Middle", and "High" be used to tell these schools apart. Those keywords should only be used when they're needed. If the school's name is unique without them, skip them. โจ
- Database Management:
One goal of DNS is to split up the management of the name database into small pieces. Each piece (or "zone" in DNS terminology) could be managed by a separate administrator. If every high school went into the EDU domain, the EDU zone file, which is already huge, would grow even bigger and might become unmanageable. ๐
For both of these reasons, structure has to be introduced into names. Structure gives common names a context where they can be unique, and it divides up the management responsibility. ๐
The US Domain already has a framework in place and has registered many schools in this structured scheme. The general form is:
<school>.<district>.K12.<state>.US.
For example: Hamilton.LA-Unified.K12.CA.US ๐ฆ
Okay so public schools are usually organized into districts, and districts can be bigger or smaller than a city or county ๐ซโจ. The Portland school district in Oregon is in three or four counties, and each of those counties also has non-Portland districts ๐คฏ.
It makes sense to name schools inside their districts ๐. BUT districts often share a name with a city or county, so there has to be a way to tell a school district name apart from some other kind of locality name. That's where the keyword "K12" comes in ๐.
Here are some typical K12 school names being used right now:
IVY.PRS.K12.NJ.US
DMHS.JCPS.K12.KY.US
OHS.EUNION.K12.CA.US
BOHS.BREA.K12.CA.US
Ngl these names are way longer than the old shorter names in the EDU domain ๐ญ, but those short ones would not have lasted long. Tons of schools would find that their "obviously correct" name had already been taken by some other school ๐.
When there are a lot of things to name, some names are going to be long ๐ง. Sometimes there are good abbreviations to use. For example, Hamilton High School in Los Angeles could be:
Hami.Hi.LA.K12.CA.US
If a school has a bunch of PCs, each PC should have a name ๐ป. Say they're named "alpha", "beta", ... and they belong to a school named "Lincoln.High.Lakewood.K12.CA.US". Then their names would be:
alpha.Lincoln.High.Lakewood.K12.CA.US.
beta.Lincoln.High.Lakewood.K12.CA.US
...
The K12 subdomain gives two points where a branch of the database can be handed off to different administrators: the K12 Administrator for each state, and the district administrator for each district within a state ๐.
The US Domain Administrator will delegate a branch of the US domain to an appropriate party ๐ฆ. Sometimes that's a particular school, a school district, or even all of K12 for a state.
Managing a K12 branch or sub-branch can be delegated to an appropriate volunteer ๐ซถ. We expect these delegations of the schools' DNS service might eventually move to someone else who is "more appropriate" from an administrative organizational point of view. The "obvious" state agency to run the schools' DNS branch may take some time to get up to speed on Internetting ๐. In the meantime, the more advanced schools can get up and running ๐.
Special Schools and Service Units
In many states, there are special schools that are not in districts. These are run directly by the state or by consortiums ๐. There are also service units that provide "educational services", ranging from books and computers to janitorial supplies and building maintenance ๐งน. Often these service units don't have a one-to-one relationship with districts.
There's some concern about naming these schools and service units inside the naming structure for schools set out in this memo ๐. There are several possibilities. For a state with many service units, creating a "pseudo district" ESU (or whatever the common terminology is in that state) is an option. For example, the Johnson service unit could be JOHNSON.ESU.K12.CA.US. For a state with a few such service units (and avoiding conflicts with district names), the service units could sit directly under K12. For example:
TIES.K12.MN.US
The special public funded schools can be handled in a similar way ๐
. If there are many special schools in a state, a "pseudo district" should be established and all the special schools listed under it. For example, suppose there's a "pseudo district" in Massachusetts called SPCL, and a special school called the Progressive Computer Institute. Then that school could be named PCI.SPCL.K12.MA.US. If there are only a few special schools, they can be listed directly under K12 (avoiding name conflicts with district names). For example, the California Academy of Math and Science is CAMS.K12.CA.US. CAMS is sponsored by seven schools, the California Department of Education, and a University ๐.
"PVT" Private Schools
Private schools can be thought of as businesses ๐ผ. Public schools live in districts, and districts give a natural organizational structure for naming and delegation. For private schools there are no districts, and they really do operate like businesses. But lots of people get upset at the thought of their kids in a private school being in a business category and not in K12 with the rest of the children ๐ค. So to accommodate both public and private schools, we've added an artificial district called private or "PVT" to each state's K12 branch ๐. This gives a private school the option of registering like a business under "locality", or in the PVT.K12.<state-code>.US branch.
For example:
Crossroads.PVT.K12.CA.US
Crossroads-Santa-Monica.CA.US
A public school "Oak High" in the "Woodward" school district in California would have a name like Oak-High.Woodward.K12.CA.US.
A private school "Old Trail" in Pasadena, California could use the <locality> based name Old-Trail.Pasadena.CA.US or the private school base name Old-Trail.PVT.K12.CA.US.
Some people suggest that, instead of a special pseudo district PVT, private schools should use a locality name. One reason to use district names is that, over time, it seems likely that school district administrators will take over running the DNS for their district ๐ง. One needs to be able to delegate at that branch point. One implication of delegation is that the delegatee is now in charge of a chunk of the name space and will be registering new names. To keep names unique, you can't have two different people registering new things below identically named branches ๐.
For example, if there's a school district named Pasadena and a city named Pasadena, the branch of the name space PASADENA.K12.CA.US might be delegated to the administrator of that public school district. If a private school in Pasadena wanted to be registered in the DNS, it would have to get the public school district administrator to do it (perhaps unlikely), or not be in the K12 branch at all (unless there's the PVT pseudo district) ๐ฌ.
So, if private schools are registered by <school>.<locality>.K12.<state-code>.US and public schools are registered by <school>.<district>.K12.<state-code>.US, there can't be any locality names that are the same as district names. Otherwise the delegation of these will get very tricky later ๐.
If everything is done by locality names rather than district names, and public and private schools are mixed together, then finding an appropriate party to delegate the locality to may be difficult ๐ซ .
Another suggestion was that private schools be registered directly under K12, while public schools must be under a district under K12. This would require the operator of the K12 branch to register all districts and private schools himself (checking for name uniqueness). He couldn't easily delegate the registration of the private schools to anyone else ๐ตโ๐ซ.
Community Colleges and Technical Schools
To tell Community Colleges and Technical/Vocational schools apart, the keywords "CC" and "TEC" have been created ๐.
Some School Examples
Hamilton.High.LA-Unified.K12.CA.US <== a public school
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <== a public school
John-Muir.Middle.Santa-Monica.K12.CA.US <== a public school
Crossroads-School.Santa-Monica.CA.US <== a private school
SMCC.CC.CA.US <== a community college
TECMCC.CC.CA.US <== a community college
Brick-and-Basket-Institute.TEC.CA.US <== a technical college
Northridge.CSU.STATE.CA.US <== a state university
2.4. State Agencies ๐๏ธ
Several states are setting up networks to connect the offices of state government agencies ๐. The hosts in these networks should be registered under the STATE.<state-code>.US branch.
A US Domain name space has been set up for state government agencies. For example, in the State of Minnesota, the subdomain is STATE.MN.US.
State Agencies:
---------------
Senate.STATE.MN.US <== State Senate
MDH.STATE.MN.US <== Dept. of Health
CALTRANS.STATE.CA.US <== Dept. of Transportation
DMV.STATE.CA.US <== Dept. of Motor Vehicles
2.5. Federal Agencies ๐บ๐ธ
A federal name space has been set up for federal government agencies. For example, the subdomain for the Federal Reserve Bank of Minneapolis is MNPL.FRB.FED.US. Other examples are listed below ๐.
Federal Government Agencies:
---------------------------
Senate.FED.US <==== US Senate
DOD.FED.US <==== US Defense Dept.
USPS.FED.US <==== US Postal Service
VA.FED.US <==== US Veterans Administration
IRS.FED.US <==== US Internal Revenue Service
Yosemite.NPS.Interior.FED.US <==== A Federal agency
2.6. Distributed National Institutes ๐
The "DNI" branch was created directly under the top-level US. It's for organizations that span state, regional, and other organizational boundaries, are national in scope, and have distributed facilities ๐บ๏ธ. An example:
Distributed National Institutes:
--------------------------------
MetaCenter.DNI.US <==== The MetaCenter Supercomputer Centers
The MetaCenter domain covers the four NSF sponsored supercomputer centers. These are:
San Diego Supercomputer Center (SDSC)
National Center for Supercomputing Applications (NCSA)
Pittsburgh Supercomputing Center (PSC)
Cornell Theory Center (CTC)
The MetaCenter Network will let applications and services like file systems and archival storage run in a distributed way ๐. That way, the resources at the four centers appear integrated and "seamless" to the people using them โจ.
2.7. General Independent Entities ๐งบ
This name space was created for organizations that don't really fit anywhere else, like state-wide associations, clubs, and "domain parks". Think of it as the miscellaneous category ๐ฆ.
The examples are state-wide clubs. For example, the Garden Club of Arizona might want to be GARDEN.GEN.AZ.US. A club like this has members from all over the state and isn't associated with any one city (or locality) ๐ธ. Another example is "domain parks" that have been set up until now as entities in ORG. For example, there's LONESTAR.ORG, a kind of computer club in Texas with lots of dial-in computers registered ๐ป. In the US Domain, an entity like that might have a name like LONESTAR.GEN.TX.US.
Organizations registered in GEN may typically be non-profit entities ๐ค. These organizations don't fit in a <locality>, and they aren't a school, library, or state agency. Ordinary businesses are not registered in GEN ๐ โโ๏ธ.
Some people suggest these kinds of organizations are just like all the other things and ought to be registered under some <locality>. That may be true, but sometimes one just can't convince the applicant that it's the right thing to do ๐ฅบ. One can argue that any organization has a headquarters, an office, or something else that's in a fixed place, so the organization could be registered at that place ๐.
Okay so some people be like "why even bother with a token?" ๐ค Like, why not just park these entities right under the <state-code>? Here's the tea: without a token, you can't hand off registering these entities to someone who isn't the person running the <state-code>. ๐ And you really want that delegation for two reasons, name uniqueness ๐ and operational management ๐ ๏ธ. A token makes both way easier. Iconic. ๐
General Independent Entities:
-----------------------------
CAL-Comp-Club.GEN.CA.US <==== The Computer Club of California
2.8 Examples of Names ๐ฆ
For small entities like individuals or small businesses, picking a locality-based name is usually no problem at all. โจ For example: Zuckys.Santa-Monica.CA.US ๐
Big corporations with multiple facilities in several cities or states? Okay, this one can feel like an unreasonable constraint ๐ค, especially compared to just registering directly in the COM domain. BUT a company does have a headquarters office in one particular locality, so it could register with that name. Example: IBM.Armonk.NY.US ๐
PRIVATE (business or individual)
================================
Camp-Curry.Yosemite.CA.US <==== a business
IBM.Armonk.NY.US <==== a business
Dogwood.atl.GA.US <==== a business
Geo-Petrellis.Culver-City.CA.US <==== a restaurant
Zuckys.Santa-Monica.CA.US <==== a restaurant
Joe-Josts.Long-Beach.CA.US <==== a bar
Holodek.Santa-Cruz.CA.US <==== a personal computer
FEDERAL
=======
Senate.FED.US <==== US Senate
DOD.FED.US <==== US Defense Dept.
DOT.FED.US <==== US Transportation Dept.
USPS.FED.US <==== US Postal Service
VA.FED.US <==== US Veterans Administration
IRS.FED.US <==== US Internal Revenue Service
Yosemite.NPS.Interior.FED.US <==== a federal agency
MNPL.FRB.FED.US. <==== US Fed. Reserve Bank of Minneapolis
STATE
=====
Senate.STATE.MN.US <==== state Senate
House.STATE.MN.US <==== state House of Reps
MDH.STATE.MN.US <==== state Health Dept.
HUD.STATE.CA.US <==== state House and Urban Dev. Dept.
DOT.STATE.MN.US <==== state Transportation Dept.
CALTRANS.STATE.CA.US <==== state Transportation Dept.
DMV.STATE.CA.US <==== state Motor Vehicles Dept.
Culver-City.DMV.STATE.CA.US <==== a local office of DMV
DNI (distributed national Institutes)
======================================
METACENTER.DNI.US <==== a distributed nat'l Inst.
GEN (General Independent Entities)
==================================
GARDEN.GEN.AZ.US <==== a garden club of Arizona
CITY | CI | COUNTY | CO (locality)
==================================
Parks.CI.Culver-City.CA.US <==== a city department
Fire-Dept.CI.Los-Angeles.CA.US <==== a city department
Fire-Dept.CO.Los-Angeles.CA.US <==== a county department
Planning.CO.Fulton.GA.US. <==== a county department
Main.Library.CI.Los-Angeles.CA.US <==== a city department
MDR.Library.CO.Los-Angeles.CA.US <==== a county department
TOWNSHIP | PARISH (locality)
============================
Police.TOWNSHIP.Green.OH.US <==== a township department
Administration.PARISH.Lafayette.LA.US <==== a parish department
DISTRICT | LIBRARY (agency)
============================
SCAQMD.DISTRICT.CA.US <==== a regional district
Bunker-Hill-Improvement.DISTRICT.LA.CA.US <==== a local district
Huntington.LIB.CA.US <==== a private library
Venice.LA-City.LIB.CA.US <==== a city library
MDR.LA-County.LIB.CA.US <==== a county library
K12 | PRIVATE SCHOOLS (PVT) | CC | TEC
======================================
Hamilton.High.LA-Unified.K12.CA.US <==== a public school
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <==== a public K12 school
John-Muir.Middle.Santa-Monica.K12.CA.US <==== a public K12 school
Culver-High.CCSD.K12.CA.US <==== a public K12 school
St-Monica.High.Santa-Monica.CA.US <==== a private school
Crossroads-School.Santa-Monica.CA.US <==== a private school
Mary-Ellens.Montessori-School.LA.CA.US <==== a private school
Progress-Learning-Center.PVT.K12.CA.US <==== a private school
SMCC.Santa-Monica.CC.CA.US <==== a public community college
Trade-Tech.Los-Angeles.CC.CA.US <==== a public community college
Valley.Los-Angeles.CC.CA.US <==== a public community college
Brick-and-Basket-Institute.TEC.CA.US <== a technical college
When it makes sense, subdomains get delegated and partitioned into categories like these: ๐งฉ
<locality>.<state>.US = city/locality based names
K12.<state>.US = kindergarten thru 12th grade
PVT.K12.<state.US = private kindergarten thru 12th grade
CC.<state>.US = community colleges
TEC.<state>.US = technical or vocational schools
LIB.<state>.US = libraries
STATE.<state>.US = state government agencies
<org-name>.FED.US = federal government agencies
<org-name>.DNI.US = distributed national institutes
<org-name>.GEN.<state>.US. = statewide assoc,clubs,domain parks
The Appendix-I contains the current US Domain Names BNF. ๐
3. REGISTRATION ๐ฌ
Okay, so there are two types of registrations. ๐ Option one is Delegation, where a branch of the US Domain is handed off to an organization running name servers to support that branch. Option two is Direct Registration, where the info goes straight into the main database. ๐ฆ
In Direct Registration there are two cases: (a) an IP-host (one with an IP address), and (b) a non-IP host (for example, a UUCP host). Any particular registration will involve any one of these three situations. โจ
3.1 Requirements
Anyone who wants to register a host in the US Domain gets sent a copy of the "Instructions for the US Domain Template", and must fill out a US Domain template. ๐
The US Domain template is similar to the InterNIC Domain template, but it is not the same, so don't mix them up ๐. To request a copy of the US Domain template, send a message to the US Domain registrar at us-domain@isi.edu.
If you are registering a name in a delegated zone, please register with the contact for that zone. ๐ You can FTP the file in-notes/us-domain-delegated.txt from venera.isi.edu, via anonymous FTP. This info is also available by email from RFC-INFO@ISI.EDU. Put this as the only text in the message: Help: us_domain_delegated_domains
The key people must have electronic mailboxes (that work). ๐ซ Please provide all the information indicated in the "Administrator" and "Technical Contact" slots.
The administrator is the point of contact for any administrative and policy questions about the domain. Usually this is the person who manages the organization being registered. ๐
The technical contact can also be the administrator, or the systems person, or someone who is familiar with the technical details of the Internet. The technical contact should have a valid working email address, because this is necessary in case something goes wrong. ๐ซถ
It is important that your "Return-Path" and "From" fields indicate an Internet-style address. UUCP-style addresses such as host1!user will not work. That's fine within the UUCP world, but not the Internet. ๐ If you want people on the Internet to be able to send mail to you, your return path needs to be an Internet-style address such as host1!user@Internet.gateway.host or user@Internet.gateway.host.
It is also possible to register through one of the Internet service providers that have established working relationships with the US Domain Administrator. ๐ค
If everything checks out, the turnaround time for registering a host is usually a few days. The name servers are updated anywhere from 12 to 24 hours later. โฐ
There are two ways to be registered in the US Domain, directly, or by delegation. ๐
3.2 Direct Entries
Direct entry in the database of the US Domain appeals most to individuals and small companies. ๐ธ You may fill out the application and send it directly to the US Domain Administrator. If you are in an area where the zone is delegated to someone else, your request will be forwarded to the zone administrator for your registration. Or, you may send the form directly to the manager of a delegated zone (see Section 3.1). ๐ง
3.2.1 IP-Hosts
These are hosts with IP addresses which correspond to "A" records in the DNS database. ๐
3.2.2 Non-IP Hosts
Many applicants have hosts in the UUCP world. Some are one hop away, and some are two and three hops away from their "Internet Forwarder". This is acceptable! ๐ฅฐ What is important is getting an Internet host to be your forwarder.
If you do not already have an Internet forwarder, there are several businesses that provide this service for a fee, such as:
UUNET.UU.NET(postmaster@uunet.uu.net)- PSI (
postmaster@UU2.PSI.COM) - CERFNET (
help@cerf.net)
Sometimes local colleges in your area are already on the Internet and may be willing to act as an Internet Forwarder. You would need to work this out with the systems administrator, as we cannot make these arrangements for you. ๐
Although we work with UUCP service providers, the Internet US Domain registration is not affiliated with the registration of UUCP Map entries. The UUCP map entry does not provide us with sufficient information. ๐บ๏ธ If you do not have a copy of the US Domain questionnaire template, please send a message to us-domain@isi.edu and request one. See Appendix-II.
The example below is not an appropriate registration for the US Domain. ๐ซ
#N starl
#S Amiga 2500; AmigaDOS 2.04; Dillon's AmigaUUCP 1.15D
#O Starlight BBS
#C Stephen Baker
#E starl!sbaker
#T +1 305 378 1161
#P 1107 SW 200th St #303B Miami, Fl. 33157
#L 25 47 N / 88 10 W [city]
#R
#U mthvax
#W starl!sbaker (Stephen Baker); Mon Feb 24 19:58:24 EST 1992
starl mthvax(DAILY)
If you are registering your host as a central site for a USENET group where other UUCP sites will feed from you, that's fine. ๐ฐ These UUCP sites do not need to register. However, if the other sites become a subdomain of your hostname, then we will need to register them individually or add a wildcard record. (See Section 4.4. Wildcards.) ๐
For example: bah.rochester.ny.us
host1.bah.rochester.ny.us
host2.bah.rochester.ny.us
To use US Domain names for non-IP hosts, there must be a forwarder host that is an IP host. There must also be an administrative agreement and a technical procedure for relaying mail between the non-IP host and the forwarder host. ๐ฎ
Case 1:
-------
Okay so, picture this: your host isn't on the Internet proper, but it chats directly with a buddy who is ๐ซถ
+----------+ +---------+ | |
|your-host |---UUCP-----|forwarder|----IP/TCP--| INTERNET |
+----------+ +---------+ | |
+-----------------+
The forwarder MUST be an IP host on the Internet ๐ and you MUST ask "forwarder" if they're willing to be the Internet forwarder for "your-host" ๐
In the US Domain of the DNS database there MUST be an entry like this (only the US Domain Administrator can add it ๐):
"your-host" MX 10 "forwarder"
In the "forwarder" routing tables there MUST be information about "your-host", with a rule like: if I see mail for "your-host", I will send it via UUCP by calling phone number "123-4567" ๐โจ
Case 2
This one is giving multi-hop energy ๐ฆ Your host talks to another host, that talks to another host, that finally talks to an IP host. So there are multiple hops between you and the Internet ๐ธ
+-----------------+
+----------+ +---------+ | |
|path-host |---UUCP-----|forwarder|----IP/TCP--| INTERNET |
+----------+ +---------+ | |
| +-----------------+
UUCP
|
+----------+
|your-host |
+----------+
Again, the forwarder MUST be an IP host on the Internet ๐ You MUST ask "forwarder" if they're willing to be the Internet Forwarder for "Your-Host", and you MUST ask "path-host" to relay your mail ๐
In the US Domain of the DNS Database there MUST be an entry like this:
"your-host" MX 10 "forwarder"
This MUST be entered by the US Domain Administrator ๐
In the "forwarder" routing tables there MUST be information about "your-host", with a rule like: if I see mail for "your-host", I will send it via UUCP to "path-host" by calling phone number "123-4567". And "path-host" MUST also know how to relay the mail to "your-host" ๐ง
Note: It is assumed that "path-host" is already MXed to "forwarder". It is not appropriate to ask to MX "your-host" to "path-host" (this is sometimes called double MXing) ๐ The host on the right hand side of an MX entry MUST be a host on the Internet with an IP address (e.g., 128.9.2.32). No double MXing, bestie, it's a vibe-killer ๐
3.3. Delegated Subdomains
Many branches of the US Domain are delegated ๐ There MUST be a knowledgeable and competent technical contact, familiar with the Internet DNS. This requirement is easily satisified if the technical contact already runs some other name servers ๐
Examples of delegations are K12.TX.US for the Kindergarten through 12th Grade public schools in Texas, the locality berkeley.ca.us, or the LIB.MN.US branch for the libraries in Minnesota ๐๐
The administrator of the US Domain is responsible for the assignment of all the DNS names that end with .US. Of course, one person or even one group can't handle all this in the long run, so portions of the name space are delegated to others ๐ซถ
The major concern in selecting a designated manager for a domain is that it be able to carry out the necessary responsibilities, and have the ability to do an equitable, just, honest, and competent job โจ
The key requirement is that for each domain there MUST be a designated manager for supervising that domain's name space ๐
These designated authorities are trustees for the delegated domain, and have a duty to serve the community ๐ธ
The designated manager is the trustee of the domain for the domain itself and the global Internet community ๐
Concerns about "rights" and "ownership" of domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community ๐
The designated manager MUST be equitable to all groups in the domain that request domain names ๐ซถ
This means that the same rules are applied to all requests. All requests MUST be processed in a nondiscriminatory fashion, and academic and commercial (and other) users are treated on an equal basis. No bias SHALL be shown regarding requests that may come from customers of some other business related to the manager, e.g., no preferential service for customers of a particular data network provider ๐ โโ๏ธ There can be no requirement that a particular mail system (or other application), protocol, or product be used ๐
There are no requirements on subdomains beyond the requirements on higher-level domains themselves. That is, the requirements are applied recursively. In particular, all subdomains SHALL be allowed to operate their own domain name servers, providing in them whatever information the subdomain manager sees fit (as long as it is true and correct) ๐ง
Significantly interested parties in the domain SHOULD agree that the designated manager is the appropriate party ๐ฆ
The US Domain Administrator tries to have any contending parties reach agreement among themselves, and generally takes no action to change things unless all the contending parties agree. Only in cases where the designated manager has substantially neglected their responsibilities would the US Domain Administrator step in ๐
The designated manager MUST do a satisfactory job of operating the DNS service for the domain ๐
That is, the actual management of the assigning of domain names, delegating subdomains and operating name servers MUST be done with technical competence. This includes keeping the US Domain Administrator or other higher-level domain managers advised of the status of the domain, responding to requests in a timely manner, and operating the database with accuracy, robustness, and resilience ๐ฅ
There MUST be a primary and a secondary name server that have IP connectivity to the Internet and can be easily checked for operational status and database accuracy by the US Domain Administrator ๐ก๏ธ
One of the aspects of having two name servers for each domain (or zone) is robustness ๐ One concern under this heading is that the name service not go out entirely if there is a local power failure (earthquake, tornado, or other disaster) ๐ช๏ธ
Name Servers SHOULD be in distinctly separate physical locations. It is appropriate to have more than two name servers, but there MUST be at least two ๐
For any transfer of the designated manager trusteeship from one organization to another, the higher-level domain manager MUST receive communications from both the old organization and the new organization that assure the US Domain Administrator that the transfer is mutually agreed, and that the new organization understands its responsibilities ๐ค
It is also very helpful for the US Domain Administrator to receive communications from other parties that may be concerned or affected by the transfer ๐ซถ
Delegation of cities, companies within cities, schools (K12), community colleges (CC), libraries (LIB), state government (STATE), and federal government agencies (FED), etc., is acceptable and practical ๐๏ธ
For a delegated portion of the name space, for example a city, no alterations can be made to that name, no abbreviations added, etc. unless applied for โ
Sometimes there may be two people running name servers in the same city because different portions of the name space have been delegated to them. For example, someone may be delegated the <city>.<state>.US name space, and someone else from a state government agency may have the .STATE.<state>.US portion. For example, Fred may run the name servers for Sacramento.CA.US and Joe may run the name servers for STATE.CA.US in Sacramento ๐ฏ
If a company would like to have wildcard records added, or run their own name servers in a city that we have delegated name space to, this is acceptable ๐
Delegation of the whole State name space is not yet implemented. The delegated part of the name space is in the form of:
.<locality>.<state>.US.
.CI.<locality>.<state>.US.
.CO.<locality>.<state>.US.
.STATE.<state>.US.
.K12.<state>.US.
PVT.K12.<state>.US.
.CC.<state>.US.
.TEC.<state>.US.
.LIB.<state>.US.
.GEN.<state>.US.
.DNI.US.
.FED.US.
3.3.1. Delegation Requirements
When a subdomain is delegated, the following requirements MUST be met ๐
- 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 ๐
- Organizations requesting delegations MUST provide at least two independent (robust and reliable) DNS name servers in physically separate locations on the Internet ๐
- The subdomain MUST accept all applicants on an equal basis ๐ซถ
- The subdomain MUST provide timely processing of requests. To do this, it is helpful to have several individuals knowledgeable about the procedures, so that operations are not delayed due to one person's unavailability (for example, by being on vacation) ๐๏ธ
- The subdomain manager MUST tell the US Domain Administrator when there are changes in the name servers that SHOULD be reflected in the US Domain zone files, or changes in the contact information ๐
K12 Administrators
In the long term, registering schools will be a big job ๐ซ So you need to have in mind delegating parts of the work to various school districts. If you can delegate every school district in the state, then you are finished, except for checking that they are all operating correctly โจ Initially, though, you'll have quite a bit to do with educating people, helping them choose names, and getting name servers arranged ๐ง You are responsible for seeing that the naming of schools follows the guidelines suggested in this memo ๐
All K12 Administrators will initially be responsible for managing the "pseudo district" PVT for private schools. Private schools have the option of registering as <school-name>.PVT.K12.<state>.US or as a business under the city based names ๐
Locality Administrators
If you have been delegated a locality subdomain, you will be responsible for registering not only businesses directly under the locality, but also city and county agencies under the "CI" and "CO" branches ๐๏ธ When appropriate, these branches SHOULD be delegated.
If you want, you may spell out "CITY" instead of "CI" or "COUNTY" instead of "CO", but you MUST be consistent and use only one or the other in a given locality. The whole city government SHOULD be under one branch ๐
WHOIS Database
Only the second and third level delegated name spaces will be entered in the WHOIS database. For example, K12.CA.US would have an entry in WHOIS. Anything under K12.CA.US will not be listed ๐ The US Domain Administrator will send the information that you supplied on your US Domain template to the InterNIC. It is the hope that in the future, each delegated subdomain will provide its own WHOIS directory database for its branch ๐
3.3.2. Delegation Procedures
The procedure that is followed when a subdomain is delegated includes the following steps:
Okay bestie, here's the rest of the delegation checklist ๐ Every step matters, so don't skip any ๐ซถ
- Check the technical contact's DNS experience ๐ง Make sure the delegation is actually needed โจ and that the contact has the info about the US Domain and the suggested naming structure ๐ You need two contacts with email addresses because something can go wrong, and you want a backup, periodt ๐
- Add the new technical contact to the
us-dom-admmailing list ๐ฌ That's where updates about US Domain policies and procedures get shared ๐ฆ - Delete any hosts from our zone file that belong in the newly delegated subdomain ๐๏ธ and make sure those hosts show up in their zone file instead ๐ธ
- Send them a copy of the zone file so their starting zone file is identical to ours ๐ฏโโ๏ธ For example:
mil.wi.us. 69582 SOA spool.mu.edu.
manager.spool.mu.edu. (
930119 ;serial
28800 ;refresh
14400 ;retry
3600000 ;expire
86400 ) ;minim
mil.wi.us. 69582 NS spool.mu.edu.
spool.mu.edu. 85483 A 134.48.1.31
mil.wi.us. 69582 NS sophie.mscs.mu.edu.
sophie.mscs.mu.edu. 85483 A 134.48.4.6
solaria.mil.wi.us. 69582 HINFO Sun 3/60 SunOs
solaria.mil.wi.us. 69582 MX 10 spool.mu.edu.
nthomas.mil.wi.us. 69582 HINFO 386 Clone DOS
nthomas.mil.wi.us. 69582 MX 10 spool.mu.edu.
rwmke.mil.wi.us. 69582 HINFO UNIX PC UNIX
rwmke.mil.wi.us. 69582 MX 10 spool.mu.edu.
milestn.mil.wi.us. 69582 MX 10 spool.mu.edu.
nrunner.mil.wi.us. 69582 HINFO MacIntosh System 7
nrunner.mil.wi.us. 69582 MX 10 spool.mu.edu.
dawley.mil.wi.us. 69582 HINFO 386 Clone DOS
dawley.mil.wi.us. 69582 MX 10 spool.mu.edu.
...
- The US Domain zone file must have the following records ๐ They show the name, address, email, and phone number of the technical contact for the delegated subdomain, plus the name of the delegated name space and the names of the name servers ๐ซง
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
;Contact: Joseph Klein (tjk@spool.mu.edu)
; Marquette University
; (414) 288-6734
;
;Delegate mil.wi.us zone
mil.wi.us. 604800 NS SPOOL.MU.EDU.
604800 NS SOPHIE.MSCS.MU.EDU.
; A glue record is not needed this time. Glue records are
; needed when the name of the server is a subdomain of the
; delegated domain.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
- Check that the delegated subdomain's name servers are up and running โก and make sure the delegated hosts are installed in their zone file ๐ป Then, and only then, delete any hosts from the US Domain zone file that belong in the newly delegated subdomain ๐
- Tell the technical contact of the newly delegated subdomain that wildcard records are allowed in the zone file under the organizational subdomain ๐ but no wildcard records are allowed under the "city" or "state" domain ๐ซ
- Make sure every administrator has a copy of this RFC and follows the guidelines set forth in it ๐โจ
3.3.3 Subdomain Contacts ๐
The number of hosts registered under each subdomain is unknown ๐คทโโ๏ธ For info on the delegated domains and the contacts, check out Section 3.1 ๐ง
4. DATABASE INFORMATION โจ
4.1. Name Servers
Okay so name servers are the storage units for the whole domain database ๐๏ธ๐. The database gets chopped into chunks called zones, and those zones get spread across the name servers. Name servers can have a bunch of optional functions and pull data from different sources, but their essential job (the thing they absolutely slay at) is answering queries using the data in their zones. A response can always be generated from local data alone, and it either contains the answer or a referral to other name servers that are "closer" to the info you want ๐ฆ.
A given zone is available from several name servers so it stays up even when a host or communication link fails ๐. Every zone is required to be available on at least two servers, and many zones have way more redundancy than that ๐ซถ.
The US Domain is currently supported by seven name servers:
venera.isi.edu
ns.isi.edu
rs.internic.net
ns.csl.sri.com
ns.uu.net
adm.brl.mil
excalibur.usc.edu
4.2 Zone Files
A "zone" is a registry of domains kept by a particular organization ๐. A zone registry is "authoritative", which means the master copy is kept by the zone organization, and that copy is, by definition, always up-to-date โจ. Copies of this registry may be distributed elsewhere and kept in caches, but those caches are not authoritative and may be out-of-date ๐.
Every zone has at least one node, and therefore at least one domain name, for which it is authoritative, and all of the nodes in a particular zone are connected ๐. Given the tree structure, every zone has a highest node that is closer to the root than any other node in the zone. The name of this node is often used to identify the zone. The data that describes a zone has four major parts:
- Authoritative data for all nodes within the zone.
- Data that defines the top node of the zone (can be thought of as part of the authoritative data).
- Data that describes delegated subzones, i.e., cuts around the bottom of the zone,
- Data that allows access to name servers for subzones (sometimes called "glue" data).
The zone administrator has to maintain the zones at all the name servers that are authoritative for the zone. When changes are made, they must be distributed to all of the name servers ๐ฌ.
Copies of the zone files are not available unless you are on the Internet ๐. To look at the zone files, use the "dig" program of the DNS domain name system ๐.
dig @nshost host-your-checking axfr
4.3 Resource Records
Records in the zone data files are called resource records (RRs) ๐ . The standard resource records (RR) are specified in STD 13, RFC 1034 and STD 13, RFC 1035 (3,4). An RR has a standard format, shown here:
<name> [<ttl>] [<class>] <type> <data>
The first field is always the name of the domain record. The second field is an optional time to live field, which specifies how long this data will be stored in the database โณ. The third field is the address class. The class field specifies the protocol group, and most often this is the Internet class "IN" ๐. The fourth field states the type of the resource record, and the fields after that depend on the type of RR. The fifth field is the data field, which is defined differently for each type and class of data. Here's a list of the current commonly used types:
SOA Start of Authority
NS Name Server
A Internet Address
CNAME Canonical Name (nickname pointer)
HINFO Host Information
WKS Well Known Services
MX Mail Exchanger
PTR Pointer
So what do the fields mean? Let's break it down with this example ๐:
foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU.
(1) (2) (3) (4) (5)
- domain name
- time to live information
- mail exchanger record
- preference value to determine (if more than one forwarder) which mailer to use first, lower number higher preference
- the Internet forwarding host.
4.3.1 "A" Records
An "A" record holds an Internet (IP) address ๐ธ. The data for an "A" record is an Internet address in dotted decimal form. A sample "A" record looks like this:
venera.isi.edu. A 128.9.0.32
(name) (A) (address)
The name field is the machine name, and the address is the network address. There should be only one "A" record for each address of a host.
4.3.2 CNAME Records
A Canonical Name resource record, CNAME, specifies an alias for a canonical name. It's essentially a pointer to the official name for the requested name, and all other RRs appear under this official name ๐. Say a machine named FERNWOOD.MPK.CA.US wants the nickname ANTERIOR.MPK.CA.US. In that case, this RR would be used:
anterior.mpk.ca.us. CNAME fernwood.mpk.ca.us.
(alias nickname) (canonical name)
Nicknames (where the name attached to the RR is the nickname) may be kept around for a while when a host changes its name, usually because it moves to another state ๐. It helps to have this CNAME pointer, so if any mail comes to the old address, it gets forwarded to the new one ๐. There cannot be any other RRs associated with a nickname of the same class.
4.3.3 MX Records
Mail Exchanger records, MX, are used to specify a machine that knows how to deliver mail to a machine that isn't directly connected to the Internet ๐ฎ. For example, venera.isi.edu is the mail gateway that knows how to deliver mail to foo.la.ca.us, but other machines on the network can't deliver mail directly to foo.la.ca.us ๐ค. These two machines might have a private connection or use a different transport medium (such as uucp). The preference value (10) is the order a mailer should follow when there's more than one way to deliver mail to a single machine. The lower the number, the higher the preference ๐.
foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU.
foo.LA.CA.US. 604800 MX 20 relay1.uu.net.
4.3.4 HINFO Records
Host information resource records, HINFO, hold host-specific data ๐ง. They list the hardware and operating system running on the listed host. It should be noted that a space separates the hardware information from the operating system information. If you want to include a space in the machine name, you must quote the name. Host information isn't specific to any class, so ANY may be used for the address class. There should be one HINFO record for each host.
acb.la.ca.us. HINFO VAX-11/780 UNIX
(Hardware) (Operating System)
The official HINFO types can be found in the latest Assigned Numbers RFC, the most recent edition being STD 2, RFC 1340 [9]. The hardware type is called the Machine Name, and the software type is called the System Name ๐ง .
The information users supply about this is often inconsistent or incomplete ๐. Please follow the terms in the current "Assigned Numbers".
4.3.5 PTR Records
A Domain Name Pointer record, PTR, lets special names point to some other location in the domain database ๐. These are typically used for setting up reverse pointers in the special IN-ADDR.ARPA domain. PTR names should be unique to the zone.
0.0.9.128.in-addr.arpa PTR isi-net.isi.edu.
(special name) (real name)
A PTR record is to be added to the IN-ADDR.ARPA domain for every "A" record registered in the US Domain ๐. These PTR records need to be added by the administrator of the network where the host is connected. The US Domain Administration does not administer the network and cannot make these entries in the DNS database, so it's not on them ๐ .
4.4 Wildcards
Wildcard records take the form "*.<anydomain>", where <anydomain> is any domain name ๐. The wildcards potentially apply to descendants of <anydomain>, but not to <anydomain> itself.
Let's say a big company in California with a large, non-IP/TCP network wants to create a mail gateway ๐ข. If the company is called DWP.LA.CA.US, and the IP/TCP capable gateway machine (Internet forwarder) is called ELROY.JPL.NASA.GOV, these RRs might be entered into the .US zone:
dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV
*.dwp.la.ca.us MX 10 ELROY.JPL.NASA.GOV
The wildcard record *.DWP.LA.CA.US would cause an MX query for any domain name ending in DWP.LA.CA.US to return an MX RR pointing at ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host dwp can be found ๐.
In the US Domain, wildcard records are allowed in zone files under the organizational subdomain (and where noted otherwise), but no wildcard records are allowed under the "City" or "State" domain ๐ซ.
The authors strongly believe that it is in everyone's interest and good for the Internet to have each host explicitly registered (that is, we believe that wildcards should not be used). We also realize that not everyone agrees with this belief. Thus, we will allow wildcard records in the US Domain under groups or organizations, for example *.DWP.LA.CA.US. ๐ซถ
The reason we feel single entries are the best is simply that if anyone wanted to find one of the hosts in the domain name system, it would be there, and problems can be detected more easily. When wildcard records are used, all the hosts under a subdomain are hidden ๐.
5. REFERENCES
- [1] Stahl, M., "Domain Administrators Guide", RFC 1032, SRI International, November 1987.
- [2] Lottor, M., "Domain Administrators Operations Guide" RFC 1033, SRI International, November 1987.
- [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, ISI, November 1987.
- [4] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, ISI, November 1987.
- [5] Dunlap, K., "Name Server Operations Guide for Bind, Release 4.3", UC Berkeley, SMM:11-3.
- [6] Partridge, C., "Mail Routing and the Domain Name System", STD 14, RFC 974, BBN, January 1986.
- [7] Albitz, P., C. Liu, "DNS and Bind" Help for UNIX System Administrators, O'Reilly and Associates, Inc., October 1992.
- [8] ACM SIGUCCS Networking Taskforce, "Connecting to the Internet - What Connecting Institutions Should Anticipate", FYI 16, RFC 1359, August 1992.
- [9] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, ISI, July 1992.
6. Security Considerations ๐จ
Okay, bestie, this is the big one ๐ญ. Security issues are not discussed in this memo. Not a single word, so please don't go looking for them here ๐.
7. Authors' Addresses ๐
Here's who to DM about this one, bestie ๐
Ann Cooper
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 1-310-822-1511
Email: cooper@isi.edu
Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: 1-310-822-1511
Email: postel@isi.edu
APPENDIX-I: US DOMAIN NAMES BNF ๐บ๏ธ
Okay, this is the grammar that builds every US domain name, and it's honestly kind of iconic. Here it is, verbatim:
<us-domain-name> ::= <us-name><dot><us>
<us-name> ::= <state-name><dot><state-code> |
<fed-name><dot><fed>
<dni-name><dot><dni>
<state-code> ::= <the two-letter code of a state from the
zip code directory>
<state-name> ::= <local-name><dot><locality> |
<state-agency-name><dot><state> |
<regional-agency-name><dot><agency>
<fed-name> ::= <the dotted hierarchical name of a US
federal government agency>
<dni-name> ::= <the dotted hierarchical name of a
distributed national institution>
<locality> ::= <the full name of a city from the
zip code directory> |
<a short code name for a city> |
<the full name of a county, township,
or parish> |
<other well known and commonly used
locality name>
<local-name> ::= <entity-name> |
<city-name><dot><city> |
<county-name><dot><county> |
<local-agency-name><dot><local-agency>
<state-agency-name> ::= <the dotted hierarchical name of a state
government agency>
<regional-agency-name> ::= <the dotted hierarchical name of a
special agency or district not an
element of the state government and
typically larger than a single city or
county, for example, the Southern
California Air Quality Management District>
<entity-name> ::= <the dotted hierarchical name of an
entity within a city, for example: a
company, business, private school, club,
organization, or individual>
<city-name> ::= <the dotted hierarchical name of a city
government agency>
<county-name> ::= <the dotted hierarchical name of a county,
township, or parish government agency>
<local-agency-name> ::= <the dotted hierarchical name of a special
agency or district not an element of a
city or county government and typically
equal or smaller than a single city or
county, for example, the Bunker Hill
Improvement District>
<city> ::= "CI" | "CITY"
<county> ::= "CO" | "COUNTY" | "TOWNSHIP" | "PARISH"
<dot> ::= "."
<fed> ::= "FED"
<dni> ::= "DNI"
<state> ::= "STATE" | "COMMONWEALTH"
<agency> ::= "AGENCY" | "DISTRICT" | "K12" | "CC" | "LIB" |
"GEN" | "TEC"
<local-agency> ::= "AGENCY" | "DISTRICT"
<us> ::= "US"
Now the notes, which are where all the good tea is ๐ซ
Within States:
K12may be used for public school districts. A special namePVTcan be used in the place of a school district name for private schools.CCmay be used only for public community colleges.LIBmay be only used by libraries.TECis used only for technical and vocational schools and colleges.GENis for general independent entities, that is, organizations that don't really fit anywhere else (such as statewide associations, clubs, and "domain parks").STATEmay be used only for state government entities.
Below US, parallel to States:
FEDis for agencies of the federal government.DNIis for distributed national institutes: organizations that span state, regional, and other organizational boundaries, that are national in scope, and that have distributed facilities.
Examples: ๐ง
Geo-Petrellis.Culver-City.CA.US <== resturant
Joe-Josts.Long-Beach.CA.US <== bar
IBM.Armonk.NY.US <== business
Camp-Curry.Yosemite.CA.US <== business
Yosemite.NPS.Interior.FED.US <== federal agency
Senate.FED.US <== US Senate
DOD.FED.US <== US Defense Dept.
DOT.FED.US <== US Transportation Dept.
MNPL.FRB.FED.US <== the Minneapolis branch of
the Federal Reserve Bank
MetaCenter.DNI.US <== distributed Nat'l Inst
Senate.STATE.MN.US <== state Senate
House.STATE.MN.US <== state House of Reps
Assembly.STATE.CA.US <== state Assembly
MDH.STATE.MN.US <== state Health Dept.
DOT.STATE.MN.US <== state Transportation Dept
CALTRANS.STATE.CA.US <== state Transportation Dept
DMV.STATE.CA.US <== state Motor Vehicles Dept
Culver-City.DMV.STATE.CA.US <== local office of DMV
Police.CI.Culver-City.CA.US <== city department
Fire-Dept.CI.Los-Angeles.CA.US <== city department
Fire-Dept.CO.Los-Angeles.CA.US <== county department
Main.Library.CI.Los-Angeles.CA.US <== city department
MDR.Library.CO.Los-Angeles.CA.US <== county department
Huntington.LIB.CA.US <== private library
SMCC.Santa-Monica.CC.CA.US <== public community college
Trade-Tech.Los-Angeles.CC.CA.US <== public community college
Valley.Los-Angeles.CC.CA.US <== public community college
Hamilton.High.LA-Unified.K12.CA.US <== public school
Sherman-Oaks.Elem.LA-Unified.K12.CA.US <== public school
John-Muir.Middle.Santa-Monica.K12.CA.US <== public school
St-Monicas.High.Santa-Monica.CA.US <== private school
Crossroads-School.Santa-Monica.CA.US <== private school
Mary-Ellens-Montessori-School.LA.CA.US <== private school
Progress-Learning-Center.PVT.K12.CA.US <== private school
Brick-and-Basket-Institute.TEC.CA.US <== technical college
Bunker-Hill.DISTRICT.Los-Angeles.CA.US <== local district
SCAQMD.DISTRICT.CA.US <== regional district
Berkeley.UC.STATE.CA.US <== "CAL"
Los-Angeles.UC.STATE.CA.US <== UCLA
Irvine.UC.STATE.CA.US <== UC Irvine
Northridge.CSU.STATE.CA.US <== CSUN
Los-Angeles.CSU.STATE.CA.US <== Cal State LA
Leland-Stanford-Jr-University.Stanford.CA.US <== private school
# APPENDIX-II: US DOMAIN QUESTIONNAIRE FOR HOST ENTRY ๐
Okay, so to register a host in the US domain, you have to send the US Domain Template to the US Domain Registrar at US-Domain@ISI.EDU ๐ The first few pages explain each question on the attached template. **Fill out the two page template at the end.** You can send questions by email to that same address, or call Ann Cooper at USC/Information Sciences Institute, (310) 822-1511.
**(1)** Tell them whether this is a new application, a modification to an existing registration, or a deletion.
**(2)** This is the name of the domain. It's the name that shows up in tables and lists linking the domain to the domain server addresses. See RFC 1480 - The US Domain for more details. Here are the formats:
```
<host>.<city/locality>.<state>.US. = city/locality based names
<school>.<district>.K12.<state>.US. = kindergarten thru 12th grade
<school>.PVT.K12.<state>.US. = private K thru 12th grade
<school>.<locality>.<state>.US. = PVT sch opt: locality names
<school>.CC.<state>.US. = community colleges
<school>.TEC.<state>.US. = technical or vocational schools
<lib-name>.LIB.<state>.US. = libraries
<org-name>.STATE.<state>.US. = state government agencies
<org-name>.FED.US. = federal government agencies
<org-name>.DNI.US. = distributed national institutes
<org>.GEN.<state>.US. = statewide assoc,clubs,domain parks
For example: networthy.santa-clara.ca.us.
```
**(3)** This is the name of the entity being represented, meaning the organization being named. For example: The Networthy Corporation. Not the name of the organization submitting the request.
**(4)** Describe the domain briefly. For example: The Networthy Corporation is a consulting organization of people working with UNIX and the C language in an electronic networking environment. It sponsors two technical conferences annually and distributes a bimonthly newsletter.
**(5)** The date you expect the domain to be fully operational.
For every registration, we need both the Administrative and the Technical contacts of a domain (questions 6 & 7), and we MUST have a network mailbox for each. If you have a NIC handle (a unique NIC database identifier), please enter it. (If you don't know what a NIC handle is, leave it blank.) Also include the title, mailing address, phone number, organization, and network mailbox.
**(6)** The name of the administrative head of the "organization". The administrator is the contact point for administrative and policy questions about the domain. The Domain administrator should work closely with the personnel he has designated as the "technical contact" for his domain. In this example, the Domain Administrator would be the Administrator of the Networthy Corporation, not the Administrator of the organization running the name server (unless it is the same person).
**(7)** The name of the technical and zone contact. The technical and zone contact handles the technical aspects of maintaining the domain's name server and resolver software, and database files. He keeps the name server running. More than likely, this person would be the technical contact running the primary name server.
> ***********************************************************************
>
> PLEASE READ: There are several types of registrations.
>
> (a) Delegation (i.e., a portion of the US Domain name space is given to an organization running name servers to support that branch; For example, K12.TX.US, for all K12 schools in Texas). For (a) answer questions 8 and 9.
>
> (b) Direct Registration of an IP Host. For (b) answer question 10.
>
> (c) Direct Registration of a non-IP Host. For (c) answer question 11 and 12.
>
> ***********************************************************************
---
**QUESTIONS FOR DELEGATIONS** ๐ซถ
**(8)** PRIMARY SERVER Information. It is required to supply both the Contact information as well as hardware/software information of the primary name server.
**(9)\*** SECONDARY SERVER Information. It is required to supply the hardware and software information of all secondary name servers.
Domains must provide at least two independent servers that provide the domain service for translating names to addresses for hosts in this domain. If you are applying for a domain and a network number assignment simultaneously, and a host on your proposed network will be used as a server for the domain, you must wait until you receive your
Okay so, a host on your brand-new network can't be your server until that network number is actually assigned, and you've given that server its address. Otherwise you have to wait before sending in the domain application ๐ซถ Also, putting your servers in physically separate places and on different PSNs and/or networks is strongly recommended ๐ธ
> NOTE: For those applicants not able to run name servers, or for non-IP hosts the Name Server information is not applicable. (See #10 and #11).
---
# (10) Questions for direct IP hosts ๐
> (If you answered 8 & 9 do not answer 10, 11, or 12).
What Domain Name System (DNS) Resource Records (RR) and values are to be entered for your IP host (must have an "A" record) ๐
```
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Example: RRs for an INTERNET hosts.
(a) DOMAIN NAME (required)...: Networthy.Santa-Clara.CA.US.
(b) IP ADDRESS (required)....: A 128.9.3.123 (required)
(c) HARDWARE (opt)...........: SUN-3/11O
(d) OPERATING SYS (opt)......: UNIX
(e) WKS (opt)........: 128.9.3.123. UDP (echo tftp) TCP (ftp)
(f) MX (opt).................: 10 RELAY.ISI.EDU.
```
Okay, this one is your job, bestie ๐
You have to make sure an IN-ADDR pointer record is entered in the DNS database. (For Internet hosts only.) Ask the administrator of the IP network your host is on to do it. The US Domain administration doesn't run the network and can't make these entries in the DNS database, so don't go asking them ๐
---
# (11) Questions for non-IP hosts (such as UUCP) ๐
Lots of applicants have hosts in the UUCP world. Some are one hop away from their "Internet Forwarder," some are two or three hops away, and that's totally fine โจ What really matters is getting an Internet host to be your forwarder. If you don't already have one, there are several businesses that provide this service for a fee (see RFC 1359 - Connecting to the Internet What Connecting Institutions Should Anticipate, ACM SIGUCCS, August 1992). Sometimes local colleges in your area are already on the Internet and might be willing to act as an Internet Forwarder. You'd need to work that out with the systems administrator, since we can't make these arrangements for you ๐ซ
## (11) Internet Forwarding Host Information ๐ฆ
**(11a) What is the name of your Internet forwarding host?**
For example: The host Yacht-Club.MDR.CA.US uses UUCP to connect to RELAY.ISI.EDU which is an Internet host. (i.e., RELAY.ISI.EDU is the forwarding host).
**(11b) What is the name of your contact person at forwarding host?**
The Administrator of RELAY.ISI.EDU must agree to be the forwarding host for Yacht-Club.MDR.CA.US, and the forwarding host must know a delivery method and route to Networthy. No double MXing. ๐
โโ๏ธ
**(11c) What is the mailbox of your contact?**
What is the mailbox of the administrator of the forwarding host.
```
Example: Contact Name......: John Smith
Contact Email.....: js@RELAY.ISI.EDU
```
(12) What Domain Name System (DNS) Resource Records (RR) and values are to be entered for your NON-IP host. ๐
```
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Example: RRs for a NON-IP host (uucp).
(a) DOMAIN NAME (required).....: Yacht-Club.MDR.CA.US.
(b) HARDWARE (opt).............: SUN-3/11O
(c) OPERATING SYS (opt)........: UNIX
(d) MX (required)..............: 10 RELAY.ISI.EDU.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```
> **PLEASE ALLOW AT LEAST 8 WORKING DAYS FOR PROCESSING THIS APPLICATION** โณ
---
## US Domain template ๐
Please send the following two-page template to **Us-Domain@isi.edu**. Fields marked with an asterisk (*) can be copied as many times as you need. (For example: if you had two phone numbers for the Administrative Contact, you'd use the same number "6h" twice.) **PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY.** ๐ฅน
```
US DOMAIN TEMPLATE [6/93]
PLEASE SUBMIT THE FOLLOWING TWO PAGE TEMPLATE TO (Us-Domain@isi.edu).
Sections or fields of this form marked with an asterisk (*) may be
copied as many times as necessary. (For example: If you had two phone
numbers for the Administrative Contact, you would use the same number
"6h" twice. PLEASE DO NOT ALTER THIS APPLICATION IN ANY WAY.
=====================================================================
1. REGISTRATION TYPE
(N)ew (M)odify (D)elete..:
2.* FULLY-QUALIFIED DOMAIN NAME:
3. ORGANIZATION INFORMATION
3a. Organization Name.....:
3b. Address Line 1........:
3b. Address Line 2........:
3c. City..................:
3d. State.................:
3e. Zip/Code..............:
4. DESCRIPTION OF ORG/DOMAIN:
5. Date Operational......:
6. ADMINISTRATIVE CONTACT OF ORG/DOMAIN
6a. NIChandle (if known)..:
6b. Whole Name............:
6c. Organization Name.....:
6d. Address Line 1........:
6d. Address Line 2........:
6e. City..................:
6f. State.................:
6g. Zip/Code..............:
6h.* Voice Phone...........:
6i.* Electronic Mailbox....:
7. TECHNICAL AND ZONE CONTACT
7a. NIChandle (if known)..:
7b. Whole Name............:
7c. Organization Name.....:
7d. Address Line 1........:
7d. Address Line 2........:
7e. City..................:
7f. State.................:
7g. Zip/Code..............:
7h.* Voice Phone...........:
7i.* Electronic Mailbox....:
FILL OUT QUESTIONS 8 AND 9 FOR DELEGATIONS ONLY (i.e., those
organizations running name servers for a branch of the US Domain
name space, for example: k12.<state>.us).
8. PRIMARY SERVER: CONTACT INFO, HOSTNAME, NETADDRESS
8a. NIChandle (if known)..:
8b. Whole Name............:
8c. Organization Name.....:
8d. Address Line 1........:
8d. Address Line 2........:
8e. City..................:
8f. State.................:
8g. Zip/Code..............:
8h.* Voice Phone...........:
8i.* Electronic Mailbox....:
8j. Hostname..............:
8k.* IP Address............:
8l.* HARDWARE..............:
8m.* OPERATING SYS.........:
9. * SECONDARY SERVER: HOSTNAME, NETADDRESS
9a.* Hostname..............:
9b.* IP Address............:
9c.* HARDWARE..............:
9d.* OPERATING SYS.........:
FILL OUT QUESTION 10 FOR DIRECT REGISTRATIONS IP HOSTS
10. RESOURCE RECORDS (RRs) FOR IP INTERNET HOSTS
10a. DOMAIN NAME...........:
10b.* IP ADDRESS (required).:
10c. HARDWARE..............:
10d. OPERATING SYS.........:
10e. WKS ..................:
10f.* MX....................:
FILL OUT QUESTIONS 11 AND 12 FOR NON-IP HOSTS (such as UUCP)
11. FORWARDING HOST INFORMATION
11a. Forwarding Host......:
11b. Contact Name.........:
11c. Contact Email........:
12. RESOURCE RECORDS (RRs) FOR NON-IP HOSTS (UUCP)
12a. DOMAIN NAME...........:
12b. HARDWARE..............:
12c. OPERATING SYS.........:
12d.* MX (required).........:
```
๐ฆ where this page comes from
- ietf: rfc1480 1993-06
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms