rfc1912.txt

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

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      CNAME   mary
           mary            IN      A       1.2.3.4


   This is often attempted by inexperienced administrators as an obvious
   way to allow your domain name to also be a host.  However, DNS
   servers like BIND will see the CNAME and refuse to add any other
   resources for that name.  Since no other records are allowed to
   coexist with a CNAME, the NS entries are ignored.  Therefore all the
   hosts in the podunk.xx domain are ignored as well!

   If you want to have your domain also be a host, do the following:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      A       1.2.3.4
           mary            IN      A       1.2.3.4

   Don't go overboard with CNAMEs.  Use them when renaming hosts, but
   plan to get rid of them (and inform your users).  However CNAMEs are
   useful (and encouraged) for generalized names for servers -- `ftp'
   for your ftp server, `www' for your Web server, `gopher' for your
   Gopher server, `news' for your Usenet news server, etc.

   Don't forget to delete the CNAMEs associated with a host if you
   delete the host it is an alias for.  Such "stale CNAMEs" are a waste
   of resources.








Barr                         Informational                      [Page 6]

RFC 1912                   Common DNS Errors               February 1996


   Don't use CNAMEs in combination with RRs which point to other names
   like MX, CNAME, PTR and NS.  (PTR is an exception if you want to
   implement classless in-addr delegation.)  For example, this is
   strongly discouraged:

           podunk.xx.      IN      MX      mailhost
           mailhost        IN      CNAME   mary
           mary            IN      A       1.2.3.4


   [RFC 1034] in section 3.6.2 says this should not be done, and [RFC
   974] explicitly states that MX records shall not point to an alias
   defined by a CNAME.  This results in unnecessary indirection in
   accessing the data, and DNS resolvers and servers need to work more
   to get the answer.  If you really want to do this, you can accomplish
   the same thing by using a preprocessor such as m4 on your host files.

   Also, having chained records such as CNAMEs pointing to CNAMEs may
   make administration issues easier, but is known to tickle bugs in
   some resolvers that fail to check loops correctly.  As a result some
   hosts may not be able to resolve such names.

   Having NS records pointing to a CNAME is bad and may conflict badly
   with current BIND servers.  In fact, current BIND implementations
   will ignore such records, possibly leading to a lame delegation.
   There is a certain amount of security checking done in BIND to
   prevent spoofing DNS NS records.  Also, older BIND servers reportedly
   will get caught in an infinite query loop trying to figure out the
   address for the aliased nameserver, causing a continuous stream of
   DNS requests to be sent.

2.5 MX records

   It is a good idea to give every host an MX record, even if it points
   to itself!  Some mailers will cache MX records, but will always need
   to check for an MX before sending mail.  If a site does not have an
   MX, then every piece of mail may result in one more resolver query,
   since the answer to the MX query often also contains the IP addresses
   of the MX hosts.  Internet SMTP mailers are required by [RFC 1123] to
   support the MX mechanism.

   Put MX records even on hosts that aren't intended to send or receive
   e-mail.  If there is a security problem involving one of these hosts,
   some people will mistakenly send mail to postmaster or root at the
   site without checking first to see if it is a "real" host or just a
   terminal or personal computer that's not set up to accept e-mail.  If
   you give it an MX record, then the e-mail can be redirected to a real
   person.  Otherwise mail can just sit in a queue for hours or days



Barr                         Informational                      [Page 7]

RFC 1912                   Common DNS Errors               February 1996


   until the mailer gives up trying to send it.

   Don't forget that whenever you add an MX record, you need to inform
   the target mailer if it is to treat the first host as "local".  (The
   "Cw" flag in sendmail, for example)

   If you add an MX record which points to an external host (e.g., for
   the purposes of backup mail routing) be sure to ask permission from
   that site first.  Otherwise that site could get rather upset and take
   action (like throw your mail away, or appeal to higher authorities
   like your parent DNS administrator or network provider.)

2.6 Other Resource Records

2.6.1 WKS

   WKS records are deprecated in [RFC 1123].  They serve no known useful
   function, except internally among LISP machines.  Don't use them.

2.6.2 HINFO

   On the issue HINFO records, some will argue that these is a security
   problem (by broadcasting what vendor hardware and operating system
   you so people can run systematic attacks on known vendor security
   holes).  If you do use them, you should keep up to date with known
   vendor security problems.  However, they serve a useful purpose.
   Don't forget that HINFO requires two arguments, the hardware type,
   and the operating system.

   HINFO is sometimes abused to provide other information.  The record
   is meant to provide specific information about the machine itself.
   If you need to express other information about the host in the DNS,
   use TXT.

2.6.3 TXT

   TXT records have no specific definition.  You can put most anything
   in them.  Some use it for a generic description of the host, some put
   specific information like its location, primary user, or maybe even a
   phone number.

2.6.4 RP

   RP records are relatively new.  They are used to specify an e-mail
   address (see first paragraph of section 2.2)  of the "Responsible
   Person" of the host, and the name of a TXT record where you can get
   more information.  See [RFC 1183].




Barr                         Informational                      [Page 8]

RFC 1912                   Common DNS Errors               February 1996


2.7 Wildcard records

   Wildcard MXs are useful mostly for non IP-connected sites.  A common
   mistake is thinking that a wildcard MX for a zone will apply to all
   hosts in the zone.  A wildcard MX will apply only to names in the
   zone which aren't listed in the DNS at all.  e.g.,

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
           mary            IN      A       1.2.3.4
           *.podunk.xx.    IN      MX      5 sue

   Mail for mary.podunk.xx will be sent to itself for delivery.  Only
   mail for jane.podunk.xx or any hosts you don't see above will be sent
   to the MX.  For most Internet sites, wildcard MX records are not
   useful.  You need to put explicit MX records on every host.

   Wildcard MXs can be bad, because they make some operations succeed
   when they should fail instead.  Consider the case where someone in
   the domain "widget.com" tries to send mail to "joe@larry".  If the
   host "larry" doesn't actually exist, the mail should in fact bounce
   immediately.  But because of domain searching the address gets
   resolved to "larry.widget.com", and because of the wildcard MX this
   is a valid address according to DNS.  Or perhaps someone simply made
   a typo in the hostname portion of the address.  The mail message then
   gets routed to the mail host, which then rejects the mail with
   strange error messages like "I refuse to talk to myself" or "Local
   configuration error".

   Wildcard MX records are good for when you have a large number of
   hosts which are not directly Internet-connected (for example, behind
   a firewall) and for administrative or political reasons it is too
   difficult to have individual MX records for every host, or to force
   all e-mail addresses to be "hidden" behind one or more domain names.
   In that case, you must divide your DNS into two parts, an internal
   DNS, and an external DNS.  The external DNS will have only a few
   hosts and explicit MX records, and one or more wildcard MXs for each
   internal domain.  Internally the DNS will be complete, with all
   explicit MX records and no wildcards.

   Wildcard As and CNAMEs are possible too, and are really confusing to
   users, and a potential nightmare if used without thinking first.  It
   could result (due again to domain searching) in any telnet/ftp
   attempts from within the domain to unknown hosts to be directed to
   one address.  One such wildcard CNAME (in *.edu.com) caused
   Internet-wide loss of services and potential security nightmares due
   to unexpected interactions with domain searching.  It resulted in
   swift fixes, and even an RFC ([RFC 1535]) documenting the problem.



Barr                         Informational                      [Page 9]

RFC 1912                   Common DNS Errors               February 1996


2.8 Authority and Delegation Errors (NS records)

   You are required to have at least two nameservers for every domain,
   though more is preferred.  Have secondaries outside your network.  If
   the secondary isn't under your control, periodically check up on them
   and make sure they're getting current zone data from you.  Queries to
   their nameserver about your hosts should always result in an
   "authoritative" response.  If not, this is called a "lame
   delegation".  A lame delegations exists when a nameserver is
   delegated responsibility for providing nameservice for a zone (via NS
   records) but is not performing nameservice for that zone (usually
   because it is not set up as a primary or secondary for the zone).

   The "classic" lame delegation can be illustrated in this example:

           podunk.xx.      IN      NS      ns1.podunk.xx.
                           IN      NS      ns0.widget.com.

   "podunk.xx" is a new domain which has recently been created, and
   "ns1.podunk.xx" has been set up to perform nameservice for the zone.
   They haven't quite finished everything yet and haven't made sure that
   the hostmaster at "ns0.widget.com" has set up to be a proper
   secondary, and thus has no information about the podunk.xx domain,
   even though the DNS says it is supposed to.  Various things can
   happen depending on which nameserver is used.  At best, extra DNS
   traffic will result from a lame delegation.  At worst, you can get
   unresolved hosts and bounced e-mail.

   Also, sometimes a nameserver is moved to another host or removed from
   the list of secondaries.  Unfortunately due to caching of NS records,
   many sites will still think that a host is a secondary after that
   host has stopped providing nameservice.  In order to prevent lame
   delegations while the cache is being aged, continue to provide
   nameservice on the old nameserver for the length of the maximum of
   the minimum plus refresh times for the zone and the parent zone.
   (See section 2.2)

   Whenever a primary or secondary is removed or changed, it takes a
   fair amount of human coordination among the parties involved.  (The
   site itself, it's parent, and the site hosting the secondary)  When a
   primary moves, make sure all secondaries have their named.boot files
   updated and their servers reloaded.  When a secondary moves, make
   sure the address records at both the primary and parent level are
   changed.

   It's also been reported that some distant sites like to pick popular
   nameservers like "ns.uu.net" and just add it to their list of NS
   records in hopes that they will magically perform additional



Barr                         Informational                     [Page 10]

RFC 1912                   Common DNS Errors               February 1996


   nameservice for them.  This is an even worse form of lame delegation,
   since this adds traffic to an already busy nameserver.  Please
   contact the hostmasters of sites which have lame delegations.
   Various tools can be used to detect or actively find lame
   delegations.  See the list of contributed software in the BIND
   distribution.

   Make sure your parent domain has the same NS records for your zone as
   you do.  (Don't forget your in-addr.arpa zones too!).  Do not list
   too many (7 is the recommended maximum), as this just makes things
   harder to manage and is only really necessary for very popular top-
   level or root zones.  You also run the risk of overflowing the 512-
   byte limit of a UDP packet in the response to an NS query.  If this
   happens, resolvers will "fall back" to using TCP requests, resulting
   in increased load on your nameserver.

   It's important when picking geographic locations for secondary
   nameservers to minimize latency as well as increase reliability.
   Keep in mind network topologies.  For example if your site is on the
   other end of a slow local or international link, consider a secondary
   on the other side of the link to decrease average latency.  Contact
   your Internet service provider or parent domain contact for more
   information about secondaries which may be available to you.

3. BIND operation

   This section discusses common problems people have in the actual
   operation of the nameserver (specifically, BIND).  Not only must the
   data be correct as explained above, but the nameserver must be
   operated correctly for the data to be made available.

3.1 Serial numbers

   Each zone has a serial number associated with it.  Its use is for