-----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----- _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
