Frequent SERVFAIL: "nameservers now above QDOMAIN" (BIND 9.5.0-P2)

[JINMEI Tatuya / 神明達哉]

At Tue, 23 Sep 2008 17:03:47 +0200,
Bart Van den Broeck <bart at kuleuven.net> wrote:

> We are experiencing frequent SERVFAIL errors when recursively resolving names in 
> certain external zones, e.g. the zone su.se, on our BIND 9.5.0-P2 nameservers. 
> A failing query seems to go well until the response with the authoritative 
> nameservers for the zone is received.  Then, at debug level 3, we see the 
> following message in the log file:
> 
> fctx 0x4a5ab808(ns.su.se/A'): nameservers now above QDOMAIN
> 
> When the query happens to succeed, this message is not logged.  A network trace 
> shows, however, that the response received by our nameserver is in both cases 
> identical (except for order)!  Apparently, for an unknown reason, BIND sometimes 
> seems to give up early and returns SERVFAIL instead of doing the final query.
> 
> Possibly even stranger is the fact that flushing the cache of the nameserver 
> solves the problem for a while.
> 
> Does anybody have any idea on the cause or any suggestions to debug this 
> further?  Could this be related to the caching issue mentioned in the last 
> message in the thread "Re: LRU fail after switch 9.4.1 -> 9.5.0p1 ?" 
> (<http://marc.info/?l=bind-users&m=122123729916850&w=2>)?  (Cache is at the 
> default settings.)

Looks like so.  If this is the case, you'll be able to avoid the
problem by using 9.4.  Or, if you specify a sufficiently large size of
cache, the problem should happen at least (much) less frequently.

I'm considering fixing the underlying problem of the cache management
code.  Depending on development and release schedule timing, it will
be available in the next beta version of 9.5 (9.5.1b3, if any, or the
first beta of 9.5.2).

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.