sslug-teknik team mailing list archive

[MONZ <monz@xxxxxxxxx>]

Simon Lodal wrote:
> Så jeg overvejede om de mon er relaterede ... og hvad den logbesked
> prøver at fortælle mig!

Fra /usr/doc/bindxxx/rfc/rfc2308 :

"NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
described in [RFC1035 Section 4.1.1] and the two terms are used
interchangeably in this document.

Du kan læse mere i rfc1536 :

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
   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!

Og videre:

   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.


   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.


Der står mere...
Måske har du et problem med en sekundær nameserver ved zonetransfers.
I en af rfc'erne (1536,2136,2308,2535) står der at nameservers ikke bør begynde
at svare queries før alle zones er overførte (transferred).
Kan måske ozze bare være et 'bad name'.
I 'less rfcxxxx' er det let at søge med '/NXDOMAIN' efter din fejl.
Der er en del muligheder, SVJ læser det er det enten pga. af en bug i bind,
eller en misforståelse af pri/sec. ns setup eller fejl i SOA record.
-- 
Mogens Valentin - mailto:monz@xxxxxxxxx - WWW: http://www.danbbs.dk/~monz/ 
Web, Programming, Network, Security - Guides for Linux, Xwindow and more..
Skaane/Sjaelland Linux User Group (4800++ members!) - http://www.sslug.dk/
Get a grip, get http://www.linux.org/, freedom of choice and free software