Bind Occasionally Doesn't Resolve an Address
 

I'm running Bind 9.4.2 for a small internal network. Most of the time, it runs fine, but every now and again, it fails to resolve a single address. I haven't noticed any pattern to when this happens, or if there is a pattern to the names that don't resolve.

If I dig, from inside the network, to my NameServer, I don't get any information back. If I dig, to my VoIP adapter, which is between the cable modem and my server, and also running a NameServer, it resolves the address correctly.

If I re-start Bind, and try the same name again, now it will resolve correctly.

So, it looks like Bind, somehow, is using another server, upstream, that can't resolve the address, and doesn't try any others.

Is there any way I can resolve this, without waiting for it to happen, noticing that it's happening, and then bouncing Bind. Or is there any way I can trace this, to see where the issue is happening.

Cheers,
Eddie

When it stops resolving, what does

dig +trace

show? Is the nameserver trying the wrong upstream server?

Are you running a caching-only nameserver, or is it an authoritative server for your local network?

BTW, the actual domain name has been changed to protect the innocent. :o

Firstly, from my server:
Now, using the NameServer on my VoiP box:

I'm not 100% sure what you mean by your last question. Bind is used to provide name resolution, to my internal network, both for devices with fixed IPs, and for other devices after an IP is handed out by DHCP, which all works perfectly well. It is also the NameServer referred to by all the internal machines. But, it does not publish any information externally.

Cheers,
Eddie

> I'm not 100% sure what you mean by your last question.

Well, I was wondering if bind was only passing requests upstream or if it was configured to pass some requests upstream while resolving others itself. But from your description, since it resolves the remote address correctly after a restart, it doesn't sound like a configuration issue (eg, trying to answer even remote queries itself -- seems it is forwarding them upstream correctly).

Since it works after a restart, it can't be a config file issue (or at least *shouldn't* be).

But the one thing that would change after a restart would be that bind empties its cache.

Perhaps

rndc dumpdb

will show an errant entry for the domain in question? Failing that,

rndc flush

should flush the cache. If it works after that, it's a cache problem. So then it reduces to a problem of determining what invalid data is getting into the cache and from where.

I'm confused by your two examples - neither shows resolution of any names other than NS RR.s

Duhhhhh. I really need to get my glasses fixed, don't I. :cry:

This particular case really is a missing A record at the destination NS.

Guess I'll have to wait for another occurrence of my "mystery non-resolver" to try out the suggestions above.

Cheers,
Eddie

Also take note that the ANY query does not mean ALL RRs. It means essentially "give me what you have". It does not cause a name server to perform a zone transfer. Consider any foreign domain - one wouldn't expect an ANY query to either enumerate through an infinite number of possible queries, nor expect that the foreign domain will just hand over all of its RRs.