[Unbound-users] Caching 'invalid response' or at least knowing not to look it up again...
wouter at nlnetlabs.nl
Mon Sep 17 07:22:16 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On 09/15/2012 10:04 AM, Karl Pielorz wrote:
> We're running Unbound 1.4.18 on a number of FreeBSD machines now -
> and this generally, seems to be running well.
> Initially we had an issue with our forwarders being 'overrun' for
> queries when domains were invalid - this was fixed by setting our
> "forward only" unbound.conf to use 'forward-first: no'
Glad to hear that it works well now.
> However, our BIND based forwarders (which unbound forwards onto)
> still see a large percentage of queries for domains, which they
> cannot resolve properly - and therefore return "invalid response",
> " 15-Sep-2012 06:02:08.484 resolver: notice: DNS format error from
> 126.96.36.199#53 resolving iumdoctors.com/NS for client
> 192.168.0.2#5828: invalid response "
Yes if unbound was to resolve this domain itself, it would also create
a failure (from a quick look).
> Unbound running on 192.168.0.2 will keep asking for data about
> "iumdoctors.com" quite often, for quite a while. This may well be
> in response to software on that host, asking a lot for NS records
> for 'iumdoctors.com'.
> Is there any setting in 1.4.18 that we can use to tell Unbound to
> cache the fact this query failed / gave an invalid response, so it
> can answer to clients for say the next 5 or 10 minutes from cache -
> without bothering the main forwarders?
There is no setting in the config file, but there is a constant in the
software code, in util/data/msgparse.h:78, NORR_TTL. You can change
this to a higher value and recompile if you want to store failed
queries for a longer time.
> This would dramatically cut the number of these queries being
> issued against our forwarders.
But, the problem with a large timeout here, and the reason for this
'fairly short but nonzero value' there is now, is that for many
queries, a retry may solve the situation. A large value here would
turn a temporary failure that would otherwise be unnoticed after it
works a minute later, into a longterm failure.
> We did look at this before - but were more concerned with other
> issues (which as I said were resolved by setting 'forward-first:
> no') - now the system has been running a while, we can see that the
> query load on BIND has been reduced, but by caching this kind of
> lookup it'd drop even further.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
-----END PGP SIGNATURE-----
More information about the Unbound-users