[Unbound-users] Caching 'invalid response' or at least knowing not to look it up again...

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Karl,

On 09/15/2012 10:04 AM, Karl Pielorz wrote:
> 
> Hi,
> 
> 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",
> e.g.
> 
> " 15-Sep-2012 06:02:08.484 resolver: notice: DNS format error from 
> 195.189.226.227#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.

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQVs+kAAoJEJ9vHC1+BF+N+yQP/Rwf4wI81bdmKHgdfTJLvsVw
CF78sKBLDAaNLDpuIv/8n0DbbyMMyCwbZ9dq1sqr56ZrMQO8xyizzCJK3qDTTJ9B
YsXUnKe6mB9Awa/LEhPQmP4suFA7DZ0J5EM3UVatMAB19xUtgDQNftkW1aurQyEu
D4laGVRgtIkCZY4TE8szlCDDm2N+vm1vl9SAURYuoc2t+OM0qRC0hWMB7FN6cH3R
nKZNA3ER9GzE91SWxfwO65ClnqrJKi7yOj+xp5Dw3K+iQZq4fBQUE5Y7aAISqSsa
9tm09Jp8JZV+wYgr+2oD71XhY4SPa6RbDSGoCGM0zyroE+y1ThkPOfVyOil6DoVX
IyVb2nn+0ONQ0GrqNi6zOYBoI/lczLMEU5c04DIG12PCX15TVw6JwI/R+WaPxtKH
QkeF8M+JhekF2QU6O4EgWMYpit4q+MBqrn3InRb5qpI6MjySK3UAPZAUBDBrJb79
Ytyx3VLG8sfXQo8Q65/LMGQDdwf0ATBD8vPmGmqzjt3RPNE/l8SKCdLLXnnRfBUs
xx1wv4o2CqPUA6hbwc4M7KlONP9SqnwNq8MeWjqK9LBKJYyoiH/D2cwQAySDPnO/
jJsTfctDxEC/li/bOUb1Os9VFwH9XRm1EbY7jqPmOZRM4tryJnjgm6PNl1LEmjNh
YWUrjRHYTyQPHGy8FS9M
=d+rN
-----END PGP SIGNATURE-----