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.
