分享
 
 
 

RFC1386 - The US Domain

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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

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,

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.

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.

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

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

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

When appropriate, subdomains are delegated and partioned in various

categories, such as:

K12.<state>.US = kindegarten thru 12th grade

CC.<state>.US = community colleges

LIB.<state>.US = libraries

STATE.<state>.US = state government agencies

<org-name>.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.

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.

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

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).

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 <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 ok.

Delegation of the whole State namespace is not yet implemented. The

delegated part of the name space is in the form of:

.STATE.<state>.US.

.K12.<state>.US.

.CC.<state>.US.

.LIB.<state>.US.

.<org-name>.<city>.<state>.US.

.CITY.<city-name>.<state>.US.

.<org-name>.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.

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

...

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.

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.

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.

...

-------------------------------------

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.

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

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.

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

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, RFC1034

and STD 13, RFC1035 (3,4). An RR has a standard format as shown.

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

The first field is always the name of the domain record. The second

field is an optional time to live field. This specifies how long

this data will be stored in the data base. The third field is the

address class; the class field specifies the protocol group most

often this is the Internet class "IN". The fourth field states the

type of the resource record. The fields after that are dependent on

the Type of RR. The fifth field is the data field which is defined

differently for each type and class of data. Here is a list of the

current commonly used types.

SOA Start of Authority

NS Name Server

A Internet Address

CNAME Canonical Name (nickname pointer)

HINFO Host Information

WKS Well Known Services

MX Mail Exchanger

PTR Pointer

What do the fields mean?

foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU.

(1) (2) (3) (4) (5)

1) domain name

2) time to live information

3) mail exchanger record

4) preference value to determine (if more than one

forwarder) which mailer to use first, lower number

higher preference

5) the Internet forwarding host.

4.3.1 A Records

Internet (IP) Address. The data for an "A" record is an Internet

address in a dotted decimal form. A sample "A" record might look

like:

venera.isi.edu. A 128.9.0.32

(name) (A) (address)

The name field is the machine name, and the address is the network

address. There should be only one "A" record for each address of a

host.

4.3.2 CNAME Records

Canonical Name resource record, CNAME, specifies an alias for a

canonical name. This is essentially a pointer to the official name

for the requested name. All other RRs appear under this official

name. A machine named FERNWOOD.MPK.CA.US may want to have the

nickname ANTERIOR.MPK.CA.US. In that case, the following RR would be

used:

anterior.mpk.ca.us. CNAME fernwood.mpk.ca.us.

(alias nickname) (canonical name)

Nicknames (the name associated with the RR is the nickname) may be

added for awhile when a host changes its name, usually because it

moves to another state. It helps to have this CNAME pointer so if

any mail comes to the old address it will get forwarded to the new

one. There cannot be any other RRs associated with a nickname of the

same class.

4.3.3 MX Records

Mail Exchanger records, MX, are used to specify a machine that knows

how to deliver mail to a machine that is not directly connected to

the Internet. For example, venera.isi.edu is the mail gateway that

knows how to deliver mail to foo.la.ca.us, but other machines on the

network cannot deliver mail directly to foo.la.ca.us. These two

machines may have a private connection or use a different transport

medium (such as uucp). The preference value (10) is the order that a

mailer should follow when there is more than one way to deliver mail

to a single machine. The lower the number the higher the preference.

foo.LA.CA.US. 604800 MX 10 Venera.ISI.EDU.

foo.LA.CA.US. 604800 MX 20 relay1.uu.net.

4.3.4 HINFO Records

Host information resource records, HINFO is for host specific data.

This lists the hardware and operating system that are running at the

listed host. It should be noted that a space separates the hardware

information and the operating system information. If you want to

include a space in the machine name you must quote the name. Host

information is not specific to any class, so ANY may be used for the

address class. There should be one HINFO record for each host.

acb.la.ca.us. HINFO VAX-11/780 UNIX

(Hardware) (Operating System)

The official HINFO types can be found in the latest Assigned Numbers

RFC, the most recent edition being RFC1340. 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 "*.<anydomain>", where

<anydomain> is any domain name. The wildcards potentially apply to

descendents of <anydomain>, but not to <anydomain> itself.

For example, suppose a large company located in California with a

large, non-IP/TCP, network wanted to create a mail gateway. If the

company was called DWP.LA.CA.US, and the IP/TCP capable gateway

machine (Internet forwarder) was called ELROY.JPL.NASA.GOV, the

following RRs might be entered into the .US zone.

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

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

The wildcard record *.DWP.LA.CA.US would cause an MX query for any

domain name ending in DWP.LA.CA.US to return an MX RR pointing at

ELROY.JPL.NASA.GOV. The entry without the "*" is needed so the host

dwp can be found.

In the US Domain, wildcard records are allowed in our zone files

under the organizational subdomain (and where noted otherwise) but no

wildcard records are allowed under the "City" or "State" domain.

The authors strongly believe that it is in everyone's

interest and good for the Internet to have each host

explicitly registered (that is, we believe that wildcards

should not be used), we also realize that not everyone

agrees with this belief. Thus, we will allow wildcard

records in the US Domain under groups or organizations.

For example, *.DWP.LA.CA.US.

The reason we feel single entries are the best is by the mere

fact that if anyone wanted to find one of the hosts in the

domain name system it would be there, and problems can be

detected more easily. When using wildcards records all the

hosts under a subdomain are hidden.

5. REFERENCES

[1] Stahl, M., "Domain Administrators Guide", RFC1032, SRI

International, November 1987.

[2] Lottor, M., "Domain Administrators Operations Guide" RFC1033,

SRI International, November 1987.

[3] Mockapetris, P., "Domain Names - Concepts and Facilities",

STD 13, RFC1034, ISI, November 1987.

[4] Mockapetris, P., "Domain Names - Implementation and

Specification", STD 13, RFC1035, 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, RFC974, BBN, January 1986.

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

APPENDIX-I: US DOMAIN NAMES BNF

================================

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

<us-name> ::= <state-name><dot><state-code>

<fed-name><dot><fed>

<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>

<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><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> ::= "CITY"

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

<dot> ::= "."

<fed> ::= "FED"

<agency> ::= "AGENCY" "DISTRICT" "K12" "CC" "LIB"

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

<us> ::= "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.

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

(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.

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

(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

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有