Bind 9 resolver timeout and ncache behaviour
stefan.puiu at gmail.com
Sun Jan 28 14:21:56 UTC 2007
I'm pretty sure at least some of those questions have been asked and
answered before, here are some links to older posts on the subject
(for questions 1 and 2):
This one describes the situation as of December 2001, and points to
where in the code you can find the exact info:
The ordering of nameservers is done according to RTT now, but
otherwise when I checked the code mentioned above there weren't that
Regarding 3, but if you reproduce that behaviour on a local BIND
server and then dump the cache, you should be able to see also the
ncache entries. What I've noticed is that negative answers carry the
SOA of the zone in which the record would belong if it existed, and
the last number in the SOA is the default negative TTL. However, if
that is larger than the max-ncache-ttl (which is 10800 (3 hours) by
default in BIND 9.3), then it is truncated to that. Here's how a
negative response shows up in named_dump.db after 'rndc dumpdb':
invalid.domain.blb. 10656 \-ANY ;-$NXDOMAIN
gigi.bogus. 10645 \-ANY ;-$NXDOMAIN
Notice the 'NXDOMAIN'. The initial TTL was 10800.
Regarding 4, I guess that's also easy to try - however, it's not a
rule that the stub resolver times out last, sometimes it can time out
before BIND. When BIND times out first, I would expect an NXDOMAIN
answer to be sent.
Also, is there any reason why you must use forwarders?
On 1/25/07, Nick Garfield <Nicholas.Garfield at cern.ch> wrote:
> (1) How long is the timeout period of a forwarded request?
> (2) Are there any retries?
> (3) If a query is timed out from all servers in the forwarders list is
> the failed request then marked down as an error and stored in the
> negative cache? If so, for how long?
> (4) The client's resolver probably has a longer timeout than the caching
> named. When the caching named has a timeout what does the caching named
> return to the client's resolver - nothing or an error message?
More information about the bind-users