Unbound: slow issues.

[tailings at gmx.com]

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.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20161026/918099b0/attachment.htm>