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
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
