Unbound: slow issues.
wouter at nlnetlabs.nl
Wed Oct 26 12:16:52 UTC 2016
-----BEGIN PGP SIGNED MESSAGE-----
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 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 for
> 18.104.22.168 3 AAAA IN www.tubetown.de. 6.024901 iterator wait for
> 22.214.171.124 4 AAAA IN www.eurotubes.com. 11.084678 iterator wait
> for 126.96.36.199 5 AAAA IN www.tubemonger.com. 10.982738 iterator
> wait for 188.8.131.52 6 AAAA IN www.diyhifisupply.com. 40.981773
> iterator wait for 184.108.40.206 7 AAAA IN
> www.diyhifisupply.com.privacychain.ch. 10.954016 iterator wait for
> 220.127.116.11 8 AAAA IN www.hificollective.co.uk. 41.052734
> iterator wait for 18.104.22.168 9 AAAA IN
> www.hificollective.co.uk.privacychain.ch. 11.024719 iterator wait
> for 22.214.171.124
> 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
>> - 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
-----END PGP SIGNATURE-----
More information about the Unbound-users