rfc1536.txt

bind 9.3结合mysql数据库


RFC 1536            Common DNS Implementation Errors        October 1993


A GOOD IMPLEMENTATION:

   BIND places an upper limit on the number of times it queries a
   server.  Both the stub-resolver and the full-service resolver code do
   this.  Also, since the full-service resolver estimates round-trip
   times and sorts name server addresses by these estimates, it does not
   query a dead server again, until and unless all the other servers in
   the list are dead too!  Further, BIND implements exponential back-off
   too.

FIXES:

      a. Set an upper limit on number of retransmissions.

      b. Measure round-trip time from servers (some estimate is better
         than none). Treat no response as a "very large" round-trip
         time.

      c. Maintain a weighted rtt estimate and decay the "large" value
         slowly, with time, so that the server is eventually tested
         again, but not after an indefinitely long period.

      d. Follow an exponential back-off scheme so that even if you do
         not restrict the number of queries, you do not overload the
         net excessively.

5. Cache Leaks:

   Every resource record returned by a server is cached for TTL seconds,
   where the TTL value is returned with the RR. Full-service (or stub)
   resolvers cache the RR and answer any queries based on this cached
   information, in the future, until the TTL expires. After that, one
   more query to the wide-area network gets the RR in cache again.

   Full-service resolvers might not implement this caching mechanism
   well. They might impose a limit on the cache size or might not
   interpret the TTL value correctly. In either case, queries repeated
   within a TTL period of a RR constitute a cache leak.

A GOOD/BAD IMPLEMENTATION:

   BIND has no restriction on the cache size and the size is governed by
   the limits on the virtual address space of the machine it is running
   on. BIND caches RRs for the duration of the TTL returned with each
   record.

   It does, however, not follow the RFCs with respect to interpretation
   of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses



Kumar, Postel, Neuman, Danzig & Miller                          [Page 7]

RFC 1536            Common DNS Implementation Errors        October 1993


   the minimum TTL value, for that zone, from the SOA record and caches
   it for that duration. This, though it saves some traffic on the
   wide-area network, is not correct behavior.

FIXES:

      a. Look over your caching mechanism to ensure TTLs are interpreted
         correctly.

      b. Do not restrict cache sizes (come on, memory is cheap!).
         Expired entries are reclaimed periodically, anyway. Of course,
         the cache size is bound to have some physical limit. But, when
         possible, this limit should be large (run your name server on
         a machine with a large amount of physical memory).

      c. Possibly, a mechanism is needed to flush the cache, when it is
         known or even suspected that the information has changed.

6. Name Error Bugs:

   This bug is very similar to the Zero Answer bug. A server returns an
   authoritative NXDOMAIN when the queried name is known to be bad, by
   the server authoritative for the domain, in the absence of negative
   caching. This authoritative NXDOMAIN response is usually accompanied
   by the SOA record for the domain, in the authority section.

   Resolvers should recognize that the name they queried for was a bad
   name and should stop querying further.

   Some resolvers might, however, not interpret this correctly and
   continue to query servers, expecting an answer record.

   Some applications, in fact, prompt NXDOMAIN answers! When given a
   perfectly good name to resolve, they append the local domain to it
   e.g., an application in the domain "foo.bar.com", when trying to
   resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
   "usc.edu.bar.com" and finally the good name "usc.edu". This causes at
   least two queries that return NXDOMAIN, for every good query. The
   problem is aggravated since the negative answers from the previous
   queries are not cached.  When the same name is sought again, the
   process repeats.

   Some DNS resolver implementations suffer from this problem, too. They
   append successive sub-parts of the local domain using an implicit
   searchlist mechanism, when certain conditions are satisfied and try
   the original name, only when this first set of iterations fails. This
   behavior recently caused pandemonium in the Internet when the domain
   "edu.com" was registered and a wildcard "CNAME" record placed at the



Kumar, Postel, Neuman, Danzig & Miller                          [Page 8]

RFC 1536            Common DNS Implementation Errors        October 1993


   top level. All machines from "com" domains trying to connect to hosts
   in the "edu" domain ended up with connections to the local machine in
   the "edu.com" domain!

GOOD/BAD IMPLEMENTATIONS:

   Some local versions of BIND already implement negative caching. They
   typically cache negative answers with a very small TTL, sufficient to
   answer a burst of queries spaced close together, as is typically
   seen.

   The next official public release of BIND (4.9.2) will have negative
   caching as an ifdef'd feature.

   The BIND resolver appends local domain to the given name, when one of
   two conditions is met:

      i.  The name has no periods and the flag RES_DEFNAME is set.
      ii. There is no trailing period and the flag RES_DNSRCH is set.

   The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
   BIND, but can be changed at compile time.

   Only if the name, so generated, returns an NXDOMAIN is the original
   name tried as a Fully Qualified Domain Name. And only if it contains
   at least one period.

FIXES:

      a. Fix the resolver code.

      b. Negative Caching. Negative caching servers will restrict the
         traffic seen on the wide-area network, even if not curb it
         altogether.

      c. Applications and resolvers should not append the local domain to
         names they seek to resolve, as far as possible. Names
         interspersed with periods should be treated as Fully Qualified
         Domain Names.

         In other words, Use searchlists only when explicitly specified.
         No implicit searchlists should be used. A name that contains
         any dots should first be tried as a FQDN and if that fails, with
         the local domain name (or searchlist if specified) appended. A
         name containing no dots can be appended with the searchlist right
         away, but once again, no implicit searchlists should be used.





Kumar, Postel, Neuman, Danzig & Miller                          [Page 9]

RFC 1536            Common DNS Implementation Errors        October 1993


   Associated with the name error bug is another problem where a server
   might return an authoritative NXDOMAIN, although the name is valid. A
   secondary server, on start-up, reads the zone information from the
   primary, through a zone transfer. While it is in the process of
   loading the zones, it does not have information about them, although
   it is authoritative for them.  Thus, any query for a name in that
   domain is answered with an NXDOMAIN response code. This problem might
   not be disastrous were it not for negative caching servers that cache
   this answer and so propagate incorrect information over the internet.

BAD IMPLEMENTATION:

   BIND apparently suffers from this problem.

   Also, a new name added to the primary database will take a while to
   propagate to the secondaries. Until that time, they will return
   NXDOMAIN answers for a good name. Negative caching servers store this
   answer, too and aggravate this problem further. This is probably a
   more general DNS problem but is apparently more harmful in this
   situation.

FIX:

      a. Servers should start answering only after loading all the zone
         data. A failed server is better than a server handing out
         incorrect information.

      b. Negative cache records for a very small time, sufficient only
         to ward off a burst of requests for the same bad name. This
         could be related to the round-trip time of the server from
         which the negative answer was received. Alternatively, a
         statistical measure of the amount of time for which queries
         for such names are received could be used. Minimum TTL value
         from the SOA record is not advisable since they tend to be
         pretty large.

      c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
         and implemented, to allow the primary server to inform
         secondaries that the database has been modified since it last
         transferred zone data.  To alleviate the problem of "too many
         zone transfers" that this might cause, Incremental Zone
         Transfers should also be part of DNS.  Also, the primary should
         not NOTIFY/PUSH with every update but bunch a good number
         together.







Kumar, Postel, Neuman, Danzig & Miller                         [Page 10]

RFC 1536            Common DNS Implementation Errors        October 1993


7. Format Errors:

   Some resolvers issue query packets that do not necessarily conform to
   standards as laid out in the relevant RFCs. This unnecessarily
   increases net traffic and wastes server time.

FIXES:

      a. Fix resolvers.

      b. Each resolver verify format of packets before sending them out,
         using a mechanism outside of the resolver. This is, obviously,
         needed only if step 1 cannot be followed.

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.

   [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] Beertema, P., "Common DNS Data File Configuration Errors", RFC
       1537, CWI, October 1993.

Security Considerations

   Security issues are not discussed in this memo.















Kumar, Postel, Neuman, Danzig & Miller                         [Page 11]

RFC 1536            Common DNS Implementation Errors        October 1993


Authors' Addresses

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

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


   Jon Postel
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey CA 90292-6695

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


   Cliff Neuman
   USC Information Sciences Institute
   4676 Admiralty Way
   Marina Del Rey CA 90292-6695

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


   Peter Danzig
   Computer Science Department
   University of Southern California
   University Park

   EMail: [e-mail]


   Steve Miller
   Computer Science Department
   University of Southern California
   University Park
   Los Angeles CA 90089

   EMail: [e-mail]




Kumar, Postel, Neuman, Danzig & Miller                         [Page 12]