bug in bind-9.3.2-P2 - SERVFAIL?

[Brian Kerr]

On 8/22/07, Mark Andrews <Mark_Andrews at isc.org> wrote:

...

> > > Our internal bind-9.3.2-P2 servers insist on querying ns2.example.com
> > > it appears, and are quiting on SERVFAIL instead of trying the next
> > > server - networking is fine. A dig +trace always works from our
> > > internal dns servers. Could this be a possible bug in bind-9.3.2-P2?
>
>         named does go onto the next server.

In this failure mode named may in fact go on to the next server.
Unfortunately the valid responses from ns1.example.com are never being
returned when querying the nameservers in question that we believe are
experiencing some kind of bug.  That is where the problem lies.  One
out of the three servers is returning results yet BIND is for whatever
reason not resolving queries for known working A records.  Again, a
dig +trace www.example.com returns results immediately.  Doing a dig
against the BIND servers that are broken results in a timeout.

I will try running tcpdump to capture whether or not BIND is
contacting the ns1 or not.

...

> > It appears to only affect BIND when views are enabled.  There is one
> > authoritative server out of the three that is responding with valid
> > records as Wes indicated.
>
>         I suspect that you are talking to the wrong view on ns2.example.com
>         or one of the views on ns2.example.com doesn't have the zone loaded.
>         You need to work out why ns2.example.com is returniong SERVFAIL.

Sorry I wasn't clear about the view setup.  It is simply an internal /
external view setup.  No configuration for the example.com domain or
any of its network paths exists in the BIND configuration that is
experiencing this failure mode.  The internal hosts are allowed
recursion on any, external hosts are restricted to a specific set of
zones.

It seems that disabling this internal/external view appears to fix the
issue, however.

Thanks,
Brian