rfc1480.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,581 行 · 第 1/5 页

          "your-host"  MX  10  "forwarder"

   This must be entered by the US Domain Administrator.

   In the "forwarder" routing tables there must be information about
   "your-host" with a rule like: If I see mail for "your-host" I will
   send it via UUCP to "path-host" by calling phone number "123-4567".
   and "path-host" must also know how to relay the mail to "your-host".

   Note: It is assumed that "path-host" is already MXed to "forwarder".
   It is not appropriate to ask to MX "your-host" to "path-host" (this
   is sometimes called double MXing).  The host on the right hand side
   of an MX entry must be a host on the Internet with an IP address
   (e.g., 128.9.2.32).






Cooper & Postel                                                [Page 23]

RFC 1480                     The US Domain                     June 1993


   3.3  Delegated Subdomains

   Many branches of the US Domain are delegated. There must be a
   knowledgeable and competent technical contact, familiar with the
   Internet DNS.  This requirement is easily satisified if the technical
   contact already runs some other name servers.

   Examples of delegations are K12.TX.US for the Kindergarten through
   12th Grade public schools in Texas, the locality "berkeley.ca.us", or
   the LIB.MN.US branch for the libraries in Minnesota.

   The administrator of the US Domain is responsible for the assignment
   of all the DNS names that end with ".US".  Of course, one person or
   even one group can't handle all this in the long run so portions of
   the name space are delegated to others.

   The major concern in selecting a designated manager for a domain is
   that it be able to carry out the necessary responsibilities, and have
   the ability to do an equitable, just, honest, and competent job.

   The key requirement is that for each domain there be a designated
   manager for supervising that domain's name space.

   These designated authorities are trustees for the delegated domain,
   and have a duty to serve the community.

   The designated manager is the trustee of the domain for the domain
   itself and the global Internet community.

   Concerns about "rights" and "ownership" of domains are inappropriate.
   It is appropriate to be concerned about "responsibilities" and
   "service" to the community.

   The designated manager must be equitable to all groups in the domain
   that request domain names.

   This means that the same rules are applied to all requests.  All
   requests must be processed in a nondiscriminatory fashion, and
   academic and commercial (and other) users are treated on an equal
   basis.  No bias shall be shown regarding requests that may come from
   customers of some other business related to the manager -- e.g., no
   preferential service for customers of a particular data network
   provider.  There can be no requirement that a particular mail system
   (or other application), protocol, or product be used.

   There are no requirements on subdomains beyond the requirements on
   higher-level domains themselves.  That is, the requirements are
   applied recursively.  In particular, all subdomains shall be allowed



Cooper & Postel                                                [Page 24]

RFC 1480                     The US Domain                     June 1993


   to operate their own domain name servers, providing in them whatever
   information the subdomain manager sees fit (as long as it is true and
   correct).

   Significantly interested parties in the domain should agree that the
   designated manager is the appropriate party.

   The US Domain Administrator tries to have any contending parties
   reach agreement among themselves, and generally takes no action to
   change things unless all the contending parties agree; only in cases
   where the designated manager has substantially neglected their
   responsibilities would the US Domain Administrator step in.

   The designated manager must do a satisfactory job of operating the
   DNS service for the domain.

   That is, the actual management of the assigning of domain names,
   delegating subdomains and operating name servers must be done with
   technical competence.  This includes keeping the US Domain
   Administrator or other higher-level domain managers advised of the
   status of the domain, responding to requests in a timely manner, and
   operating the database with accuracy, robustness, and resilience.

   There must be a primary and a secondary name server that have IP
   connectivity to the Internet and can be easily checked for
   operational status and database accuracy by the US Domain
   Administrator.

   One of the aspects of having two name servers for each domain (or
   zone), is for robustness.  One concern under this heading is that the
   name service not go out entirely if there is a local power failure
   (earthquake, tornado, or other disaster).

   Name Servers should be in distinctly separate physical locations.  It
   is appropriate to have more than two name servers, but there must be
   at least two.

   For any transfer of the designated manager trusteeship from one
   organization to another, the higher-level domain manager must receive
   communications from both the old organization and the new
   organization that assures the US Domain Administrator that the
   transfer in mutually agreed, and that the new organization
   understands its responsibilities.

   It is also very helpful for the US Domain Administrator to receive
   communications from other parties that may be concerned or affected
   by the transfer.




Cooper & Postel                                                [Page 25]

RFC 1480                     The US Domain                     June 1993


   Delegation of cities, companies within cities, schools (K12),
   community colleges (CC), libraries (LIB), state government (STATE),
   and federal government agencies (FED), etc., is acceptable and
   practical.

   For a delegated portion of the name space, for example a city, no
   alterations can be made to that name, no abbreviations added, etc.
   unless applied for.

   Sometimes there may be two people running name servers in the same
   city because different portions of the name space has been delegated
   to them.  For example, someone may be delegated the <city>.<state>.US
   name space, and someone else from a state government agency may have
   the .STATE.<state>.US, portion.  For example, Fred may run the name
   servers for Sacramento.CA.US and Joe may run the name servers for
   STATE.CA.US in Sacramento.

   If a company would like to have wildcard records added, or run their
   own name servers in a city that we have delegated name space to, this
   is acceptable.

   Delegation of the whole State name space is not yet implemented.  The
   delegated part of the name space is in the form of:

               .<locality>.<state>.US.
            .CI.<locality>.<state>.US.
            .CO.<locality>.<state>.US.
                    .STATE.<state>.US.
                      .K12.<state>.US.
                   PVT.K12.<state>.US.
                       .CC.<state>.US.
                      .TEC.<state>.US.
                      .LIB.<state>.US.
                      .GEN.<state>.US.
                              .DNI.US.
                              .FED.US.

   3.3.1.  Delegation Requirements

   When a subdomain is delegated, the following requirements must be
   met:

      1)  There must be a knowledgeable and competent technical contact,
          familiar with the Internet DNS.  This requirement is easily
          satisified if the technical contact already runs some other
          name servers.





Cooper & Postel                                                [Page 26]

RFC 1480                     The US Domain                     June 1993


      2)  Organizations requesting delegations must provide at least two
          independent (robust and reliable) DNS name servers in
          physically separate locations on the Internet.

      3)  The subdomain must accept all applicants on an equal basis.

      4)  The subdomain must provide timely processing of requests.  To
          do this, it is helpful to have several individuals
          knowledgeable about the procedures so that the operations are
          not delayed due to one persons unavailability (for example, by
          being on vacation).

      5)  The subdomain manager must tell the US Domain Administrator
          when there are changes in the name servers that should be
          reflected in the US Domain zone files, or changes in the
          contact information.

   K12 Administrators

      In the long term, registering schools will be a big job.  So you
      need to have in mind delegating parts of the work to various
      school districts.  If you can delegate every school district in
      the state then you are finished, except for checking that they are
      all operating correctly.  However, initially you will have quite a
      bit to do with educating people, helping them choose names and
      getting name servers arranged.  You are responsible for seeing
      that the naming of schools follow the guidelines suggested in this
      memo.

      All K12 Administrators will initially be responsible for managing
      the "pseudo district" PVT for private schools.  Private schools
      have the option of registering as <school-name>.PVT.K12.<state>.US
      or as a business under the city based names.

   Locality Administrators

      If you have been delegated a locality subdomain, you will be
      responsible for registering not only businesses directly under the
      locality, but city and county agencies under the "CI" and "CO"
      branches.  When appropriate these branches should be delegated.

      If you want, you may spell out "CITY" instead of "CI" or "COUNTY"
      instead of "CO", but you must be consistent and use only one or
      the other in a given locality.  The whole city government should
      be under one branch.






Cooper & Postel                                                [Page 27]

RFC 1480                     The US Domain                     June 1993


   WHOIS Database

      Only the second and third level delegated name spaces will be
      entered in the WHOIS database.  For example, K12.CA.US would have
      an entry in WHOIS.  Anything under K12.CA.US will not be listed.
      The US Domain Administrator will send the information that you
      supplied on your US Domain template to the InterNIC.  It is the
      hope that in the future, each delegated subdomain will provide
      their own WHOIS directory database for their branch.

   3.3.2  Delegation Procedures

   The procedure that is followed when a subdomain is delegated includes
   the following steps:

      1)  Evaluate the technical contact's experience with DNS.  Make
          sure there is a need for the proposed delegation.  Make sure
          the technical contact has the information about the US Domain
          and the suggested naming structure.  Two contacts with email
          addresses are necessary in case something goes wrong.

      2)  Add the new technical contact to the "us-dom-adm" mailing list
          for distributing updates concerning the US Domain policies and
          procedures.

      3)  Delete any hosts from our zone file that belongs in the newly
          delegated subdomain and make sure they now have the hosts in
          their zone file.

      4)  Send them a copy of the zone file so their initial zone file
          is identical to ours. For example:

          mil.wi.us.      69582   SOA     spool.mu.edu.
                                          manager.spool.mu.edu. (
                                  930119  ;serial
                                  28800   ;refresh
                                  14400   ;retry
                                  3600000 ;expire
                                  86400 ) ;minim

          mil.wi.us.      69582   NS      spool.mu.edu.
          spool.mu.edu.   85483   A       134.48.1.31
          mil.wi.us.      69582   NS      sophie.mscs.mu.edu.
          sophie.mscs.mu.edu.     85483   A       134.48.4.6
          solaria.mil.wi.us.      69582   HINFO   Sun 3/60 SunOs
          solaria.mil.wi.us.      69582   MX      10 spool.mu.edu.
          nthomas.mil.wi.us.      69582   HINFO   386 Clone DOS
          nthomas.mil.wi.us.      69582   MX      10 spool.mu.edu.



Cooper & Postel                                                [Page 28]

RFC 1480                     The US Domain                     June 1993


          rwmke.mil.wi.us.        69582   HINFO   UNIX PC UNIX
          rwmke.mil.wi.us.        69582   MX      10 spool.mu.edu.
          milestn.mil.wi.us.      69582   MX      10 spool.mu.edu.
          nrunner.mil.wi.us.      69582   HINFO   MacIntosh System 7
          nrunner.mil.wi.us.      69582   MX      10 spool.mu.edu.
          dawley.mil.wi.us.       69582   HINFO   386 Clone DOS
          dawley.mil.wi.us.