Stub Zone Behavior?

[Ray Van Dolson]

Have a resolver at a branch office with a view containing a stub zone
as follows:

    zone "domain.com." IN {
        type stub;
        masters { 10.216.11.6; 10.58.4.1; 10.50.4.32; };
        file "stub/domain.com";
        forwarders {};
    };

Other notes:

- "domain.com" is an Active Directory zone.
- Running bind-9.8.2-0.47.rc1.el6.x86_64 (RHEL6)

This setup seemed to work fine for many months, but within the last two
or so has randomly started returning no answers for only certain
queries (well the SOA stuff is returned) until I rndc flush on the
system after which response returns to normal for a period of time.

After trying a few things without success, I changed the zone type to
forward instead of stub (with the servers used as masters in the stub
config as the forwarders) and this has seemed to solved the problem.

As I understand it, stub zones work by pulling down SOA, NS and "glue"
for the NS from one of the masters into a local zone file and then
queries to the domain are answered by querying one of the authoritative
servers defined in the stub zone.

My working theory is that BIND will randomly choose one of the NS
servers to get an answer from, and since our NS list is very long with
the servers scattered across the globe, perhaps BIND chooses one which
doesn't respond quickly enough or at all (or maybe badly?) and then
caches that negative or absent response.

Probably in this case the forward type works just as well for our local
clients at the office (I believe answers for "forward" zones can also
be cached locally...), so am inclined to stand pat with this config but
would still love to understand what might have caused the original
stub setup to fail.

Ray