Strange Problem querying delegated zone

[Kevin Darcy]

Eric Langheinrich wrote:
>  
>
> I'm running into a strange problem and am hoping someone might be able to
> give me at least some direction regarding what to look at. 
>
> I have bind setup and the name server on my box. /etc/resolve.conf lists
> 127.0.0.1 as the name server. Bind is authoritative for a single domain (for
> internal use only) with three subzone delegations to rbldnsd for blacklists
> running on 127.0.0.253.
>
> The problem I am experiencing is when I attempt to query one of the
> delegated zones, the first query works beautifully, but any subsequent
> queries result in SERVFAIL responses. If I stop querying for some period of
> time (say a minute) I can then successfully run a single query against the
> delegated zones and again any subsequent queries fail. During the time where
> bind returns SERVFAIL, I am able to query directly against the rbldnsd
> server running on 127.0.0.253. 
>
>   
Typically this behavior is the result of the "apex" NS records (the ones 
in the zone itself, rather than in the delegations of the zone) being 
bogus. Since the apex NS records are considered more "credible" than the 
delegation NS records, they replace the (delegation) NS records in the 
cache. If they're bogus, those cached NS records will cause a SERVFAIL 
response until they time out of the cache, at which time named will 
follow the delegations again, get the answer, and cache the bogus NS 
records again, thus starting another cycle of SERVFAIL.

What NS records are returned for the zone if you query rbldnsd directly? 
Are they valid and resolvable?

Another approach is to dump your cache as soon as you get a SERVFAIL. 
Look in the cache dump and see what NS records you have for the rbldnsd 
zones.

If rbldnsd is not capable of providing valid NS records (I don't 
remember if it is, it's been some time since I've worked with rbldnsd), 
then you may have to resort to forwarding the rbldnsd zones instead of 
relying on delegations/iterative-resolution. This may be one of those 
special circumstances -- nameserver instances residing on a single 
server, with software limitations inhibiting normal iterative resolution 
-- where forwarding might actually be appropriate.

- Kevin