rfc1033.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,230 行 · 第 1/3 页

WKS (Well Known Services)

           <host> [<ttl>] [<class>] WKS <address> <protocol> <services>

   The WKS record is used to list Well Known Services a host provides.
   WKS's are defined to be services on port numbers below 256.  The WKS
   record lists what services are available at a certain address using a
   certain protocol.  The common protocols are TCP or UDP.  A sample WKS
   record for a host offering the same services on all address would
   look like:

   Official protocol names can be found in the latest Assigned Numbers
   RFC, the latest of which is RFC-1010.

           SRI-NIC.ARPA.   WKS  10.0.0.51  TCP  TELNET FTP SMTP
                           WKS  10.0.0.51  UDP  TIME
                           WKS  26.0.0.73  TCP  TELNET FTP SMTP
                           WKS  26.0.0.73  UDP  TIME

MX (Mail Exchanger)  (See RFC-974 for more details.)

           <name>   [<ttl>] [<class>]   MX   <preference>   <host>

   MX records specify where mail for a domain name should be delivered.
   There may be multiple MX records for a particular name.  The
   preference value specifies the order a mailer should try multiple MX
   records when delivering mail.  Zero is the highest preference.
   Multiple records for the same name may have the same preference.



Lottor                                                          [Page 8]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


   A host BAR.FOO.COM may want its mail to be delivered to the host
   PO.FOO.COM and would then use the MX record:

           BAR.FOO.COM.    MX      10      PO.FOO.COM.

   A host BAZ.FOO.COM may want its mail to be delivered to one of three
   different machines, in the following order:

           BAZ.FOO.COM.    MX      10      PO1.FOO.COM.
                           MX      20      PO2.FOO.COM.
                           MX      30      PO3.FOO.COM.

   An entire domain of hosts not connected to the Internet may want
   their mail to go through a mail gateway that knows how to deliver
   mail to them.  If they would like mail addressed to any host in the
   domain FOO.COM to go through the mail gateway they might use:

           FOO.COM.        MX       10     RELAY.CS.NET.
           *.FOO.COM.      MX       20     RELAY.CS.NET.

   Note that you can specify a wildcard in the MX record to match on
   anything in FOO.COM, but that it won't match a plain FOO.COM.

IN-ADDR.ARPA

   The structure of names in the domain system is set up in a
   hierarchical way such that the address of a name can be found by
   tracing down the domain tree contacting a server for each label of
   the name.  Because of this 'indexing' based on name, there is no easy
   way to translate a host address back into its host name.

   In order to do the reverse translation easily, a domain was created
   that uses hosts' addresses as part of a name that then points to the
   data for that host.  In this way, there is now an 'index' to hosts'
   RRs based on their address.  This address mapping domain is called
   IN-ADDR.ARPA.  Within that domain are subdomains for each network,
   based on network number.  Also, for consistency and natural
   groupings, the 4 octets of a host number are reversed.

   For example, the ARPANET is net 10.  That means there is a domain
   called 10.IN-ADDR.ARPA.  Within this domain there is a PTR RR at
   51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
   (who's address is 10.0.0.51).  Since the NIC is also on the MILNET
   (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
   ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA.  The format
   of these special pointers is defined below along with the examples
   for the NIC.




Lottor                                                          [Page 9]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


PTR

           <special-name>   [<ttl>] [<class>]   PTR   <name>

   The PTR record is used to let special names point to some other
   location in the domain tree.  They are mainly used in the IN-
   ADDR.ARPA records for translation of addresses to names.  PTR's
   should use official names and not aliases.

   For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
   would have the following records in the respective zone files for net
   10 and net 26:

           51.0.0.10.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
           73.0.0.26.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.

GATEWAY PTR's

   The IN-ADDR tree is also used to locate gateways on a particular
   network.  Gateways have the same kind of PTR RRs as hosts (as above)
   but in addition they have other PTRs used to locate them by network
   number alone.  These records have only 1, 2, or 3 octets as part of
   the name depending on whether they are class A, B, or C networks,
   respectively.

   Lets take the SRI-CSL gateway for example.  It connects 3 different
   networks, one class A, one class B and one class C.  It will have the
   standard RR's for a host in the CSL.SRI.COM zone:

           GW.CSL.SRI.COM.    A    10.2.0.2
                              A    128.18.1.1
                              A    192.12.33.2

   Also, in 3 different zones (one for each network), it will have one
   of the following number to name translation pointers:

           2.0.2.10.IN-ADDR.ARPA.      PTR   GW.CSL.SRI.COM.
           1.1.18.128.IN-ADDR.ARPA.    PTR   GW.CSL.SRI.COM.
           1.33.12.192.IN-ADDR.ARPA.   PTR   GW.CSL.SRI.COM.

   In addition, in each of the same 3 zones will be one of the following
   gateway location pointers:

           10.IN-ADDR.ARPA.            PTR   GW.CSL.SRI.COM.
           18.128.IN-ADDR.ARPA.        PTR   GW.CSL.SRI.COM.
           33.12.192.IN-ADDR.ARPA.     PTR   GW.CSL.SRI.COM.





Lottor                                                         [Page 10]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


INSTRUCTIONS

   Adding a subdomain.

      To add a new subdomain to your domain:

         Setup the other domain server and/or the new zone file.

         Add an NS record for each server of the new domain to the zone
         file of the parent domain.

         Add any necessary glue RRs.

   Adding a host.

      To add a new host to your zone files:

         Edit the appropriate zone file for the domain the host is in.

         Add an entry for each address of the host.

         Optionally add CNAME, HINFO, WKS, and MX records.

         Add the reverse IN-ADDR entry for each host address in the
         appropriate zone files for each network the host in on.

   Deleting a host.

      To delete a host from the zone files:

         Remove all the hosts' resource records from the zone file of
         the domain the host is in.

         Remove all the hosts' PTR records from the IN-ADDR zone files
         for each network the host was on.

   Adding gateways.

         Follow instructions for adding a host.

         Add the gateway location PTR records for each network the
         gateway is on.

   Deleting gateways.

         Follow instructions for deleting a host.

         Also delete the gateway location PTR records for each network



Lottor                                                         [Page 11]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


         the gateway was on.

COMPLAINTS

   These are the suggested steps you should take if you are having
   problems that you believe are caused by someone else's name server:


   1.  Complain privately to the responsible person for the domain.  You
   can find their mailing address in the SOA record for the domain.

   2.  Complain publicly to the responsible person for the domain.

   3.  Ask the NIC for the administrative person responsible for the
   domain.  Complain.  You can also find domain contacts on the NIC in
   the file NETINFO:DOMAIN-CONTACTS.TXT

   4.  Complain to the parent domain authorities.

   5.  Ask the parent authorities to excommunicate the domain.































Lottor                                                         [Page 12]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


EXAMPLE DOMAIN SERVER DATABASE FILES

   The following examples show how zone files are set up for a typical
   organization.  SRI will be used as the example organization.  SRI has
   decided to divided their domain SRI.COM into a few subdomains, one
   for each group that wants one.  The subdomains are CSL and ISTC.

   Note the following interesting items:

      There are both hosts and domains under SRI.COM.

      CSL.SRI.COM is both a domain name and a host name.

      All the domains are serviced by the same pair of domain servers.

      All hosts at SRI are on net 128.18 except hosts in the CSL domain
      which are on net 192.12.33.  Note that a domain does not have to
      correspond to a physical network.

      The examples do not necessarily correspond to actual data in use
      by the SRI domain.

                       SRI Domain Organization

                               +-------+
                               |  COM  |
                               +-------+
                                   |
                               +-------+
                               |  SRI  |
                               +-------+
                                   |
                        +----------++-----------+
                        |           |           |
                    +-------+    +------+   +-------+
                    |  CSL  |    | ISTC |   | Hosts |
                    +-------+    +------+   +-------+
                        |           |
                    +-------+    +-------+
                    | Hosts |    | Hosts |
                    +-------+    +-------+










Lottor                                                         [Page 13]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


   [File "CONFIG.CMD".  Since bootstrap files are not standardized, this
   file is presented using a pseudo configuration file syntax.]

   load root server list             from file ROOT.SERVERS
   load zone SRI.COM.                from file SRI.ZONE
   load zone CSL.SRI.COM.            from file CSL.ZONE
   load zone ISTC.SRI.COM.           from file ISTC.ZONE
   load zone 18.128.IN-ADDR.ARPA.    from file SRINET.ZONE
   load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE










































Lottor                                                         [Page 14]

RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987


   [File "ROOT.SERVERS".  Again, the format of this file is not
   standardized.]

   ;list of possible root servers
   SRI-NIC.ARPA       10.0.0.51    26.0.0.73
   C.ISI.EDU          10.0.0.52
   BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
   A.ISI.EDU          26.3.0.103