rfc1537.txt

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

         foo.xx.      MX 100  gateway.xx.
                      MX 200  fallback.yy.
         *.foo.xx.    MX 100  gateway.xx.
                      MX 200  fallback.yy.
8. Hostnames

   People appear to sometimes look only at STD 11, RFC 822 to determine
   whether a particular hostname is correct or not. Hostnames should
   strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
   with *addresses* in addition conforming to RFC 822. As an example
   take "c&w.blues" which is perfectly legal according to RFC 822, but
   which can have quite surprising effects on particular systems, e.g.,
   "telnet c&w.blues" on a Unix system.

9. HINFO records

   There appears to be a common misunderstanding that one of the data
   fields (usually the second field) in HINFO records is optional. A
   recent scan of all reachable nameservers in only one country revealed
   some 300 incomplete HINFO records. Specifying two data fields in a
   HINFO record is mandatory (RFC 1033), but note that this does *not*
   mean that HINFO records themselves are mandatory.





Beertema                                                        [Page 5]

RFC 1537       Common DNS Data File Configuration Errors    October 1993


10. Safety measures and specialties

   Nameservers and resolvers aren't flawless. Bogus queries should be
   kept from being forwarded to the root servers, since they'll only
   lead to unnecessary intercontinental traffic. Known bogus queries
   that can easily be dealt with locally are queries for 0 and broadcast
   addresses.  To catch such queries, every nameserver should run
   primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
   files need only contain a SOA and an NS record.

   Also each nameserver should run primary for 0.0.127.in-addr.arpa;
   that zone file should contain a SOA and NS record and an entry:

         1    PTR     localhost.

   There has been extensive discussion about whether or not to append
   the local domain to it. The conclusion was that "localhost." would be
   the best solution; reasons given were:

   - "localhost" itself is used and expected to work on some systems.

   - translating 127.0.0.1 into "localhost.my_domain" can cause some
     software to connect to itself using the loopback interface when
     it didn't want to.

   Note that all domains that contain hosts should have a "localhost" A
   record in them.

   People maintaining zone files with the Serial number given in dotted
   decimal notation (e.g., when SCCS is used to maintain the files)
   should beware of a bug in all BIND versions: if the serial number is
   in Release.Version (dotted decimal) notation, then it is virtually
   impossible to change to a higher release: because of the wrong way
   that notation is turned into an integer, it results in a serial
   number that is LOWER than that of the former release.

   For this reason and because the Serial is an (unsigned) integer
   according to STD 13, RFC 1035, it is recommended not to use the
   dotted decimal notation. A recommended notation is to use the date
   (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
   or can be more than one change per day in a zone file.

   Very old versions of DNS resolver code have a bug that causes queries
   for A records with domain names like "192.16.184.3" to go out. This
   happens when users type in IP addresses and the resolver code does
   not catch this case before sending out a DNS query. This problem has
   been fixed in all resolver implementations known to us but if it
   still pops up it is very serious because all those queries will go to



Beertema                                                        [Page 6]

RFC 1537       Common DNS Data File Configuration Errors    October 1993


   the root servers looking for top level domains like "3" etc. It is
   strongly recommended to install the latest (publicly) available BIND
   version plus all available patches to get rid of these and other
   problems.

   Running secondary nameserver off another secondary nameserver is
   possible, but not recommended unless really necessary: there are
   known cases where it has led to problems like bogus TTL values. This
   can be caused by older or flawed implementations, but secondary
   nameservers in principle should always transfer their zones from the
   official primary nameserver.

11. Some general points

   The Domain Name System and nameserver are purely technical tools, not
   meant in any way to exert control or impose politics. The function of
   a naming authority is that of a clearing house. Anyone registering a
   subdomain under a particular (top level) domain becomes naming
   authority and therewith the sole responsible for that subdomain.
   Requests to enter MX or NS records concerning such a subdomain
   therefore always MUST be honored by the registrar of the next higher
   domain.

   Examples of practices that are not allowed are:

      - imposing specific mail routing (MX records) when registering
        a subdomain.

      - making registration of a subdomain dependent on to the use of
        certain networks or services.

      - using TXT records as a means of (free) commercial advertising.

   In the latter case a network service provider could decide to cut off
   a particular site until the offending TXT records have been removed
   from the site's zone file.

   Of course there are obvious cases where a naming authority can refuse
   to register a particular subdomain and can require a proposed name to
   be changed in order to get it registered (think of DEC trying to
   register a domain IBM.XX).

   There are also cases were one has to probe the authority of the
   person: sending in the application - not every systems manager should
   be able to register a domain name for a whole university.  The naming
   authority can impose certain extra rules as long as they don't
   violate or conflict with the rights and interest of the registrars of
   subdomains; a top level domain registrar may e.g., require that there



Beertema                                                        [Page 7]

RFC 1537       Common DNS Data File Configuration Errors    October 1993


   be primary subdomain "ac" and "co" only and that subdomains be
   registered under those primary subdomains.

   The naming authority can also interfere in exceptional cases like the
   one mentioned in point 4, e.g., by temporarily removing a domain's
   entry from the nameserver zone files; this of course should be done
   only with extreme care and only as a last resort.

   When adding NS records for subdomains, top level domain nameserver
   managers should realize that the people setting up the nameserver for
   a subdomain often are rather inexperienced and can make mistakes that
   can easily lead to the subdomain becoming completely unreachable or
   that can cause unnecessary DNS traffic (see point 1). It is therefore
   highly recommended that, prior to entering such an NS record, the
   (top level) nameserver manager does a couple of sanity checks on the
   new nameserver (SOA record and timers OK?, MX records present where
   needed? No obvious errors made? Listed secondary servers
   operational?). Things that cannot be caught though by such checks
   are:

      - resolvers set up to use external hosts as nameservers

      - nameservers set up to use external hosts as forwarders
        without permission from those hosts.

   Care should also be taken when registering 2-letter subdomains.
   Although this is allowed, an implication is that abbreviated
   addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
   and under that subdomain.  When requested to register such a domain,
   one should always notify the people of this consequence. As an
   example take the name "cs", which is commonly used for Computer
   Science departments: it is also the name of the top level domain for
   Czecho-Slovakia, so within the domain cs.foo.bar the [e-mail] is
   ambiguous in that in can denote both a user on the host
   host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
   (This example does not take into account the recent political changes
   in the mentioned country).

References

   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
       RFC 1034, USC/Information Sciences Institute, November 1987.

   [2] Mockapetris, P., "Domain Names Implementation and Specification",
       STD 13, RFC 1035, USC/Information Sciences Institute, November
       1987.





Beertema                                                        [Page 8]

RFC 1537       Common DNS Data File Configuration Errors    October 1993


   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
       974, CSNET CIC BBN, January 1986.

   [4] Gavron, E., "A Security Problem and Proposed Correction With
       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
       October 1993.

   [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
       USC/Information Sciences Institute, USC, October 1993.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Piet Beertema
   CWI
   Kruislaan 413
   NL-1098 SJ Amsterdam
   The Netherlands

   Phone: [phone]
   FAX:   [phone]
   EMail: [e-mail]


Editor's Address

   Anant Kumar
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey CA 90292-6695

   Phone:[phone]
   FAX:  [phone]
   EMail: [e-mail]













Beertema                                                        [Page 9]