Unbound: slow issues.

[W.C.A. Wijngaards]

-----BEGIN PGP SIGNED MESSAGE-----
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 217.11.57.53 1 AAAA IN
> www.edicron.com. 40.960788 iterator wait for 217.160.83.143 2 AAAA
> IN www.edicron.com.privacychain.ch. 10.932778 iterator wait for 
> 185.148.76.30 3 AAAA IN www.tubetown.de. 6.024901 iterator wait for
> 88.198.65.232 4 AAAA IN www.eurotubes.com. 11.084678 iterator wait
> for 208.109.255.22 5 AAAA IN www.tubemonger.com. 10.982738 iterator
> wait for 69.49.191.246 6 AAAA IN www.diyhifisupply.com. 40.981773
> iterator wait for 216.35.197.129 7 AAAA IN
> www.diyhifisupply.com.privacychain.ch. 10.954016 iterator wait for
> 185.148.76.30 8 AAAA IN www.hificollective.co.uk. 41.052734
> iterator wait for 212.67.202.2 9 AAAA IN
> www.hificollective.co.uk.privacychain.ch. 11.024719 iterator wait
> for 46.16.200.135
> 
> 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.
>> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJYEJ6uAAoJEJ9vHC1+BF+N1JEQAI9yHafucrI+VlF0xYS2LM+b
TEA2U6u5bOLe1m535X3EZ0gNYX/wB7h0S5BJ5pYJlAGk0oztIpnqFzSOxxQDnx+z
iRdwBELvWmlVMhKgDUrXYdfDhA5EXa/zjQuW3RR7K+BTaLooGEVP/sssjJ9DVoAM
NxNUztfJL/KO+aN077YMsA50ykmBMFsDHdyugcvk6AqhTcWJAbP1A6QIuBJcQzo4
vd0MBe6ZoXKUHX6kS3Z6dXYgfFXhgrZzodTRIfPo0hCgUCQ1FWOTEY5p8Ran8Ko5
KF4nOU3h/J2BlRaIwWg06WYb+N7eOqB2ffcR6n1CW5WjpA1Ea0YKnn3vafmlen+8
biw6SngdeAR7AM+r4eM+csLp4ycGbAK4P9rGu3C6RHi/bAdgiymosIDh6o0hldJU
bVeXym07fp5bozYdJhYxGTDX5dH8qgkSYHgSHfMcYzajm4Ye6H/+ANAU6wg1dyIP
oCez3uJ3lBcUm8idyLqiZ7RNjwbFAGo/mNMCZa11GXVRmS0SQT3mbt7V3d4tjB+S
O7OVS1Foj2IUCgpSBA3zb+9KcOMQmlZL2WFHKWN/2GgYVj+OCN3iAQ4ZgzUUL8FR
ECd2VZ4nsc0G0PpbSSjXoBvsYfInDwwgZy4c6y8cGKV5i3bMAyx3h/HWiytQidAP
2OL2eRrnpETW1yVSatiM
=RL/i
-----END PGP SIGNATURE-----