Unbound: slow issues.

W.C.A. Wijngaards wouter at nlnetlabs.nl
Wed Oct 26 12:16:52 UTC 2016

Hash: SHA256

Hi Alex,

Your requestlist has AAAA queries in it, destined for IPv4 addresses.
 The wait times are very long; they look stalled.

Unbound generates AAAA queries internally, but only when do-ip6 is
enabled.  You have it disabled.

Your clients must therefore be the ones asking for AAAA records.  The
firewall is blocking query type AAAA?  Blocking a query type generates
this type of trouble.  Unbound cannot tell the difference between this
'random filtering' and a 'down server', and therefore must cease
sending traffic.  Also for your type A requests.  This causes
resolution to stop.

If you wanted to filter out queries on some sort of 'random' topic;
return a reply with an error code set.  Otherwise unbound can only
conclude the server is unreachable.

Best regards, Wouter

On 26/10/16 04:34, tailings--- via Unbound-users wrote:
> Following the advise I found out, while running "unbound-control 
> dump_requestlist", what seems to be Unbound trying to resolve IPV6 
> address instead IPV4.
> I do not have IPV6 configured on the server, and have "do-ip6: no" 
> explicitly in unbound.conf.
> thread #0 #   type cl name    seconds    module status 0    A IN
> blade.4t2.com. - iterator wait for 1 AAAA IN
> www.edicron.com. 40.960788 iterator wait for 2 AAAA
> IN www.edicron.com.privacychain.ch. 10.932778 iterator wait for 
> 3 AAAA IN www.tubetown.de. 6.024901 iterator wait for
> 4 AAAA IN www.eurotubes.com. 11.084678 iterator wait
> for 5 AAAA IN www.tubemonger.com. 10.982738 iterator
> wait for 6 AAAA IN www.diyhifisupply.com. 40.981773
> iterator wait for 7 AAAA IN
> www.diyhifisupply.com.privacychain.ch. 10.954016 iterator wait for
> 8 AAAA IN www.hificollective.co.uk. 41.052734
> iterator wait for 9 AAAA IN
> www.hificollective.co.uk.privacychain.ch. 11.024719 iterator wait
> for
> Thank you.
> On 25/10/16 13:28, Daniel Ryšlink via Unbound-users wrote:
>> For the record, I am also running the latest version of Unbound 
>> (1.5.10) on FreeBSD 10.3 with libevent compilation option, and I
>> have no problems whatsoever.
>> Recommended things to check:
>> - sysctl limits for network buffers, expecially TCP buffers,
>> since the penetration of DNSSec means that TCP based DNS traffic
>> is increasing.
>> - in case you use stateful firewall, check limits for max number
>> of states, since you can run out quite easily. Stateless rules
>> for DNS traffic are recommended. Also limit for maximum
>> fragmented packet limits.
>> - try to monitor your system resource usage, especially memory -
>> do you have enough? does the system swap during peaks in
>> traffic?
>> - check logs for messages concerning failures to send packets,
>> limits for various resources reached, etc
>> Also, my servers are constantly bombarded by bogus queries about
>> bogus domains featuring non-responsive authoritative nameservers
>> (targets of some  DDOS attack, if I understand it correctly), and
>> such queries can exhaust your resources rapidly, since each
>> unresolved TCP query consumes a portion of memory before it times
>> out. Use the command "unbound-control dump_requestlist" to check
>> what queries are being resolved during the time the server
>> appears to be non-responsive/slow. I had to implement a
>> countermeasure that recognizes these bogus queries and replies
>> with NXDOMAIN RCODE immediately, saving the resolver's memory for
>> legitimate traffic.
>> I am not saying that there cannot be a problem with the newest
>> version of Unbound, just reporting everything is fine here and
>> trying to provide some tips.

Version: GnuPG v2


More information about the Unbound-users mailing list