Hello,
First I had before on Unbound mailing list but they could not find the
real source of the problem. I am forward the messages in order to give
more information of what was already be tried.
I am having problems with Unbound on FreeBSD (first 10.3 and now 11)
what simple stop resolving from time to time when there is just on
client accessing it. If a second one is added it almost stop working
completely.
I am currently using Unbound from Ports in a Jail, but before it was
from Base on Host, with the same problem.
Using unbound-control when it stop working, I found out it is trying to
resolve IPv6 address instead IPv4:
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
It is relevant ot point out I do not have IPv6 configured anywhere, it
is disabled even on the router.
Thank you in advance.
Alex.
-------- Forwarded Message --------
Subject: Re: Unbound: slow issues.
Date: Wed, 26 Oct 2016 15:43:53 +0200
From: W.C.A. Wijngaards <wou...@nlnetlabs.nl>
To: taili...@gmx.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
I don't have a clue what is wrong here, maybe you are better off
asking on the mailing list with more freebSD or pfSense knowledge.
(you sent this to my email).
The unbound error means that the directory: statement does not work
after you have chrooted and then try to reread the unbound.conf again.
Make the directory value the absolute path that starts with the
chroot. This is not your problem, I think.
Since it works for others, it is likely the firewall or something
along those lines. Note that AAAA queries are a data type (with an
IPv6 address in it). They can be carried over IPv4 networks fine.
I don't see anything else wrong, but I also don't know about PF,
perhaps ask others about that.
Best regards, Wouter
On 26/10/16 15:06, taili...@gmx.com wrote:
Hello Wouter,
This is the problem I do not have IPV6 activated anywhere. It is
disabled even on router. Also, until this night my Gentoo Desktop
(the only client accessing Unbound, usually) did not even had IPV6
compiled in anything - /I rebuild the entire system and activated
the IPV6 flags during the last night, but it was after I sent this
e-mail/.
The only exception is a Macmini what I am using to test from a
second client and I assume it have IPV6 activated (but not a
address assigned), but it was not configured with the Unbound as
DNS since hours before I get what I posted.
This is my PF config - /unbound is installed on /dns_jail:
ext_if = "em0" int_if = "em1"
host_server = "192.168.0.200"
afp_jail = "192.168.0.210" dns_jail = "192.168.0.220" sql_jail =
"192.168.0.230" web_jail = "192.168.0.254"
tcp_pass_host = "{ 22 }"
tcp_pass_afp = "{ 548 }" tcp_pass_dns = "{ 53 }" tcp_pass_web = "{
80 443 }"
udp_pass_dns = "{ 53 }"
icmp_types = "echoreq"
table <fail2ban> persist table <bruteforce> persist table <local>
{ 192.168.0.0/24 }
set skip on lo0 set skip on lo1 set loginterface $ext_if
scrub out on $ext_if all fragment reassemble random-id scrub in on
$ext_if all fragment reassemble
antispoof log quick for $ext_if inet
block log all block quick from <bruteforce> block quick from
<fail2ban>
pass inet proto icmp all icmp-type $icmp_types keep state pass
inet proto icmp from <local> to any keep state
pass log on $ext_if inet proto tcp from any to any port ssh \
flags S/SA keep state \ (max-src-conn 100, max-src-conn-rate 15/5,
\ overload <bruteforce> flush global)
pass out all
pass in proto tcp from any to $web_jail port $tcp_pass_web
synproxy state
pass in quick proto tcp from <local> to $host_server port
$tcp_pass_host
pass in quick proto tcp from <local> to $dns_jail port
$tcp_pass_dns pass in quick proto udp from <local> to $dns_jail
port $udp_pass_dns
pass in quick proto tcp from <local> to $afp_jail port
$tcp_pass_afp
The only errors I found on Unbound log are:
Oct 23 15:18:51 unbound[2280:0] error: cannot chdir to directory:
(No such file or directory) Oct 25 22:36:08 unbound[1123:0] error:
cannot chdir to directory: (No such file or directory)
ls -l /usr/local/etc/unbound:
drwxr-xr-x 2 unbound unbound 3 Oct 23 02:37 conf.d
drwxr-xr-x 2 unbound unbound 3 Oct 23 02:58 log -rw-r--r-- 1
unbound unbound 3291 Oct 20 17:35 root.hints -rw-r--r-- 1
unbound wheel 759 Oct 26 00:50 root.key -rw-r--r-- 1
unbound unbound 1813 Oct 26 00:49 unbound.conf -rw-r--r-- 1
unbound unbound 29366 Oct 23 02:33 unbound.conf.sample srw-rw----
1 unbound unbound 0 Oct 26 00:50 unbound.ctl -rw-r--r-- 1
unbound unbound 5 Oct 26 00:50 unbound.pid
PS. Please, note I had the same problem when I was using Unbound
on the Host instead in a Jail. PS.2 May be interesting to point out
I also had the same problem early this year while I was trying
pfSense, but in another box.
Thank you!
On 26/10/16 10:16, W.C.A. Wijngaards via Unbound-users wrote: 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
iQIcBAEBCAAGBQJYELMZAAoJEJ9vHC1+BF+NsF0P/0bpcLga1AptO8S6ljUGTtjy
tnmqQsgy1mrTQf5ylT3OeqlMvw4N8dBoRTDzCeeG9TMxErl8IuaHf06pGhkZQana
g5RiA8A5bexLurlmSmg65hQpH0s+HaYOmJATC34kuC9QgddM9Cc034zrkbiRMnmG
EFvqqmsKJJwZ5lDRHbgHYYXV7VRL0RtxeeL6HW/P3fv1Vnh4I2OL5TLfscc0b6N/
nL79IRAYW7qMX7Oo0KpGARnA/IYJehXbRrIn7xg9LmOdfxmxxT+7PWBExVyGmi7j
0ROijBAH4AuZAUlyct5X+hnbxsgNfPQOvhwSmWoScJZ8+mBLHr9ShwSKEKd7lfAr
kUM16WiosnYg4D+EZmEdET4JuN+roizyaylbM83RzdFMgf3xwaO8UbwevQ5xWjao
vKtsOONfGSnl3dSzbJTO/8+XqC5jb8Ml6T7M1OZcXQxjoAncW2mjRGhADR8ok0nj
dMNM4wqbX+x2VTmQhTVIbyEc1ld7s0IoV1rgyomF7kx5JQ45QBVFYmBaJj/rT/LJ
h8oBD1azU8NSWc2SHfViUpbm9Dn1A17wt3719daqPL5+S5nYiGD7mg0ivGs4Fb1N
wgcPWQq3KqMJFtqtBKkzyHN5qHDbqyd8S7HZK8B4Q5kyB8slps618MExaK8FE3vg
GW76I5TQHa7/3fraSBgX
=bp4F
-----END PGP SIGNATURE-----
*Original message!!!*
Hello,
I am running Unbound on FreeBSD, initially 10.3 and now 11, I tried the one on
the FreeBSD Base, and now the Port (unbound-1.5.10) compiled with libevent
support.
The problem I am experiencing is, from time to time unbound become utterly slow
or do not resolve anything, or almost anything.
I did several changes on unbound.conf file and the problem now return about one
time a day when just me (one user) is using Unbound as resolver. If a second
user begin to using Unbound at same time it became slow as described until it
have just one user again.
I opened a post on FreeBSD forum, what have more information:
https://forums.freebsd.org/threads/57493/
I need to add I also tried without success to disable PF firewall looking for
any kind of firewall related issue. Also, this is my current unbound.conf:
# This file was generated by local-unbound-setup.
# Modifications will be overwritten.
server:
port: 53
username: unbound
directory: /usr/local/etc/unbound
chroot: /usr/local/etc/unbound
pidfile: /usr/local/etc/unbound/unbound.pid
auto-trust-anchor-file: /usr/local/etc/unbound/root.key
root-hints: "/usr/local/etc/unbound/root.hints"
logfile: log/unbound.log
log-time-ascii: yes
val-log-level: 2
do-ip6: no
do-tcp: yes
interface: 127.0.0.2
interface: 192.168.0.220
access-control: 127.0.0.2/16 allow
access-control: 192.168.0.0/24 allow
private-address: 192.168.0.0/24
private-domain: mydomain.com
qname-minimisation: yes
minimal-responses: no
hide-identity: yes
hide-version: yes
do-not-query-localhost: no
val-clean-additional: yes
harden-glue: yes
harden-dnssec-stripped: yes
unwanted-reply-threshold: 10000
prefetch: yes
prefetch-key: yes
cache-min-ttl: 3600
cache-max-ttl: 86400
num-threads: 4
msg-cache-slabs: 8
rrset-cache-slabs: 8
infra-cache-slabs: 8
key-cache-slabs: 8
rrset-cache-size: 100m
msg-cache-size: 50m
outgoing-range: 8192
num-queries-per-thread: 4096
so-rcvbuf: 1m
so-sndbuf: 1m
unblock-lan-zones: yes
insecure-lan-zones: yes
include: /usr/local/etc/unbound/conf.d/*.conf
#forward-zone:
# name: .
# forward-addr: 189.38.95.95
# forward-addr: 189.38.95.96
remote-control:
control-enable: yes
control-interface: /usr/local/etc/unbound/unbound.ctl
control-use-cert: no
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
