2.1-BETA0 -> 2.1-BETA1 unbound won't install
-
At the beginning of the /usr/local/etc/rc.d/unbound_monitor.sh script, there is the following:
**PROCS=
/bin/pgrep -f unbound_monitor.sh | wc -l | awk '{print $1}'if [ ${PROCS} -gt [color=red]2 ]; then
echo "There are another unbound monitor proccess running"
exit 0
fi**
Shouldn't it be:**PROCS=
/bin/pgrep -f unbound_monitor.sh | wc -l | awk '{print $1}'if [ ${PROCS} -gt [color=red]1 ]; then
echo "There are other unbound monitor proccess running"
exit 0
fi**
??? -
Still reloads every hour, I cannot find a reason for that. The only thing I found out was that I have to issue```
unbound-control reloadAnother problem is that my DMZ on opt1 is missing the option``` domain-name-servers 192.168.1.254; ```in /var/dhcpd/etc/dhcpd.conf when I use unbound. I have opt1 defined as Network interface in unbound configuration and I can "dig" it from the DMZ. Using the system forwarder the option is there. -
unbound_monitor.sh was not working with last change, I changed the logic a bit and the way it's called and released 1.4.20_5. Let me know if you find any issues. I tested it on nanobsd and full installation.
-
I found the reason for the unbound reloads on my syslog server. Why would dhcpleases do this?
May 1 07:29:20 pfsense dhcpleases: Sending HUP signal to dns daemon(36838) May 1 07:29:20 pfsense unbound: [36838:0] info: service stopped (unbound 1.4.20).And domain-name-servers is still missing from my opt1 DHCPD config as stated in my reply above.
Other than that, everything looks good now, only one monitor process.
Thanks for looking into this! -
I found the reason for the unbound reloads on my syslog server. Why would dhcpleases do this?
PERHAPS it sends a signal to the local DNS to tell it the local name to IP address mapping has changed and the local DNS should read the updated information.
-
Hmm, but I have not enabled "Register DHCP static mappings". What else could cause this?
-
Hmm, but I have not enabled "Register DHCP static mappings". What else could cause this?
Perhaps it is trying to register a DHCP dynamic mapping! The thread at http://forum.pfsense.org/index.php/topic,33240.msg suggests dhcpleases sends a signal to the DNS to update the DNS registrations.
DNS forwarder has an option Register DHCP leases in DNS forwarder. Do you have the equivalent set in Unbound? I don't know about Unbound and don't run it - does it "inherit" DNS forwarder settings?
Maybe Unbound shouldn't stop when it gets a signal from dhcpleases.
-
Thanks wallabybob, now I was able to solve it:
I had to turn DNS Forwarder back on, uncheck
"Register DHCP leases in DNS forwarder"
turn it off again and finally reboot. Otherwise dhcpleases would not pick up the change.
It (or something else) filled
/var/etc/hosts
with many of these:# dhcpleases automatically entered # dhcpleases automatically entered # dhcpleases automatically enteredNow they don't show up anymore an unbound runs uninterrupted.
Thanks again for the help!
-
I found the reason for the unbound reloads on my syslog server. Why would dhcpleases do this?
May 1 07:29:20 pfsense dhcpleases: Sending HUP signal to dns daemon(36838) May 1 07:29:20 pfsense unbound: [36838:0] info: service stopped (unbound 1.4.20).And domain-name-servers is still missing from my opt1 DHCPD config as stated in my reply above.
Other than that, everything looks good now, only one monitor process.
Thanks for looking into this!Just to make sure, does this issue still persist? If yes, could you send more details about it?
-
Hi Renato,
thanks for asking!
the reload issue was tracked down, please see post #55 for the details. Maybe something could be done about it by clearing the system DNS forwarder's config when it's diabled? Or by making "Register DHCP leases in DNS forwarder" an option in unbound an syncing it with the system setting?
The "domain-name-servers" entry still does not get configured for my opt1 as it does when using the system DNS forwarder. As a workaround I configured this entry in my DHCP config for opt1 now. What details do you need? I guess it can be easily reproduced by configuring an opt1 interface, enabling DHCP Server/Unbound for that interface and looking at /var/dhcpd/etc/dhcpd.conf. It should be missing the domain-name-servers entry for the opt1 IP.
-
the reload issue was tracked down, please see post #55 for the details. Maybe something could be done about it by clearing the system DNS forwarder's config when it's diabled? Or by making "Register DHCP leases in DNS forwarder" an option in unbound an syncing it with the system setting?
I pushed a fix for this, it was not being checked if DNS Fowarder was enabled or not. It should be fine on current 2.1 code.
The "domain-name-servers" entry still does not get configured for my opt1 as it does when using the system DNS forwarder. As a workaround I configured this entry in my DHCP config for opt1 now. What details do you need? I guess it can be easily reproduced by configuring an opt1 interface, enabling DHCP Server/Unbound for that interface and looking at /var/dhcpd/etc/dhcpd.conf. It should be missing the domain-name-servers entry for the opt1 IP.
It's done automatically for DNS Forwarder but not for unbound, the only way is to configure it on DHCP config, as you already did.
-
Hi everyone, does this mean Unbound has now been fixed to work with PfSense 2.1?
-
-
Thanks Renato
-
Could we have an option to turn off IPv6 support?
pfSense does not handle IPv6 DNSSEC queries if they get fragmented (i.e. when using a tunnel broker for IPv6 access):May 24 13:54:27 vpn pf: 00:01:05.283725 rule 5/0(match): block in on gif0: (hlim 59, next-header Fragment (44) payload length: 1240) 2001:500:1b::1 > 2001:xxxx:xxxx:xxxx::2: frag (0x82af3ff7:0|1232) 53 > 39396: 34110*- 7/0/1 info. DNSKEY[|domain] May 24 13:54:27 vpn pf: 00:00:00.000123 rule 5/0(match): block in on gif0: (hlim 59, next-header Fragment (44) payload length: 413) 2001:500:1b::1 > 2001:xxxx:xxxx:xxxx::2: frag (0x82af3ff7:1232|405)btw, the first line looks odd in when you view it in the web gui. It only shows 53 and 39396 as source and destination, not the IPs.
