Unbound: slow issues.
tailings at gmx.com
tailings at gmx.com
Wed Oct 26 04:34:19 CEST 2016
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.
# type cl name seconds module status
0 A IN blade.4t2.com. - iterator wait for 184.108.40.206
1 AAAA IN www.edicron.com. 40.960788 iterator wait for 220.127.116.11
2 AAAA IN www.edicron.com.privacychain.ch. 10.932778 iterator wait
3 AAAA IN www.tubetown.de. 6.024901 iterator wait for 18.104.22.168
4 AAAA IN www.eurotubes.com. 11.084678 iterator wait for 22.214.171.124
5 AAAA IN www.tubemonger.com. 10.982738 iterator wait for 126.96.36.199
6 AAAA IN www.diyhifisupply.com. 40.981773 iterator wait for
7 AAAA IN www.diyhifisupply.com.privacychain.ch. 10.954016 iterator
wait for 188.8.131.52
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 184.108.40.206
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...
More information about the Unbound-users