If it's fully standalone in Unbound that should be possible, though I don't know what kind of time frame we'd be looking at.
I haven't kept an eye on it but last I saw it required passing in the https requests from something else like an nginx proxy setup but from the look of those docs they seem to have native support now. The library they mentioned is present on pfSense and is a dependency of Unbound already (the ports option DOH is enabled) so all the backend parts appear to be present, just the GUI/PHP config code would need to be implemented.
The larger problem is that it's going to want to use port 443 which complicates GUI access and makes it trickier to use in practice.
@johnpoz Thanks again john. Decided to by-pass the whole local network and plugged the internet straight into Wireshark. Couldn't find any DNS packets! Did a factory reset and assigned Snort to the LAN interface and all is good! Thanks for your help.
unbound-checkconf returns unbound-checkconf: no errors in /usr/local/etc/unbound/unbound.conf
Runing " unbound-checkconf" will check the default /usr/local/etc/unbound/unbound.conf, a file that exists, but it is just a demo file.
The real "unbound.conf", the one unbound for pfSense is using, is here/var/unbound/
Your unbound is restating every couple of minutes.
If these restarts happen to often, then the start code can overlap with another startup. Then one of then can fail and you see the error shown.
Disabling "DHCP registration" is one of the first things to try.
Jan 11 13:01:48 unbound 63374 [63374:0] info: service stopped (unbound 1.12.0).
and a small instance (< 1 second) :
Jan 11 13:01:48 unbound 63374 [63374:0] notice: Restart of unbound 1.12.0.
To make a long story, go to the Unbound / Resolver settings page and uncheck this :
Stick a post-it on the pfSense box that says :
"Check the resolver logs again after 48 hours and see how many stops/restarts happened the last 48 hours".
If you find "a couple" or even less : issue solved.
I have the SG-2220 and do not have this issue. I know this doesn't help a whole lot but someone suggested it could be hardware specific. I hadn't used my SG-2220 for about two years due to divorce and just recently got it going again which is what led me here. I did have this problem and when I did an update when it came out I still had some troubles but not this trouble. I did a factory reset twice and for whatever reason the second reset is what made everything happy. I started with all new settings and didn't restore a thing. I know this doesn't necessarily help a whole lot, but I wanted to offer additional relevant info. It isn't failing on my Netgate SG-2220. What can you do with that? I don't know exactly, but I don't think it is just the software. It might be hardware specific race conditions as another user noted.
Musste leider feststellen, dass "meine" Lösung wohl nur eine gewisse Zeit funktioniert. Irgendwann scheint es so, dass Windows den "ersten" DNS-Server nicht mehr nutzt und daher interne Namen nicht mehr auflöst.
Habe daher vorerst auf IPs umgestellt.
Now testing the SG-2100 with 23.05.1 for the similar setup but with multiple Wireguards instead of multiple OpenVPNs.
Unbound starts correctly.
I am guessing that Wireguard is faster than OpenVPN starting at boot.
@gertjan DNS settings appear to be defaults and yes /etc/hosts has the override entries. I experienced 2 issues.
DNS overrides not resolving for hosts on LAN. This is working after I forced reload of override settings and has not recurred. But I need to check again after next reboot.
DNS overrides not resolving with pfSense Diagnostics / DNS Lookup tool. I cannot be sure if this worked prior to update but it doesn’t work now. Oddly, the pfSense Diagnostics / Ping tool resolves these hosts just fine. I would expect same behavior for both and consider this a bug. The pfSense DNS Lookup tool should resolve the same as pfSense gives LAN clients.
Additional info: The DHCP client alias names are also in /etc/hosts and are not resolved by the DNS Lookup tool but are resolved by the Ping tool. Looks like the DNS Lookup tool only uses the upstream DNS servers. Almost seems like the tool needs a switch to enable local DNS entries to mimic what LAN client requests would receive. More helpful would be to always show both the internal and upstream result.
OK, problem solved! I noticed that the disk was at 100% It seems the Suricata logs had filled the drive, so I enabled the hard limit for their log size, disk usage dropped to 56% and DNS now starts :o)
Maybe a more obvious warning if the disk fills up or more useful logging for the DNS service would be a useful addition in the future?
Thanks for that... I had seen the DNS hostname boxes, but must've missed the text below indicating that they're related to DoT. Something might want to be mentioned on the DNS Resolver page at the SSL/TLS checkbox too, that for best security the hostnames for the servers should be entered on System > General.
LAN TCP/UDP * * !LAN Address DNS LAN Addr (i found using 127.0.0.1 didn't work, but it did with LAN addr)
** PS it is not a tin foil hat, when you live in a country where big law firms criminally intimidate and extort (for 3yrs relentlessly) exorbitant amounts of money because you play 50sec of a movie - consider yourself lucky your lawyers haven't woken up to that scam **
I did disable the DHCP registration and also the OpenVPN clients checkboxes as suggested by @Gertjan .
In addition to that, I also updated my VPN client settings to add multiple servers -- in case my VPN provider decides to change IP addresses or if they simply decommission the server that I am connecting to.
I haven't seen any issues since then. So it was a combination of those two things that fixed it for me. Obviously if you don't use a VPN provider, then the second part wouldn't apply to you.
The DHCP log keeps getting spammed by DHCP6 client:
Nov 5 17:12:53 dhcp6c 97216 Sending Solicit
Nov 5 17:12:54 dhcp6c 97216 Sending Request
Nov 5 17:12:54 dhcp6c 97216 dhcp6c Received REQUEST
Nov 5 17:12:54 dhcp6c 97216 status code for NA-0: no addresses
Nov 5 17:12:55 dhcp6c 97216 Sending Solicit
Nov 5 17:12:57 dhcp6c 97216 Sending Request
Nov 5 17:12:57 dhcp6c 97216 dhcp6c Received REQUEST
Nov 5 17:12:57 dhcp6c 97216 status code for NA-0: no addresses
Nov 5 17:12:58 dhcp6c 97216 Sending Solicit
Nov 5 17:12:59 dhcp6c 97216 Sending Request
Nov 5 17:13:00 dhcp6c 97216 dhcp6c Received REQUEST
Nov 5 17:13:00 dhcp6c 97216 status code for NA-0: no addresses
Nov 5 17:13:02 dhcp6c 97216 Sending Solicit
Nov 5 17:13:03 dhcp6c 97216 Sending Request
Nov 5 17:13:03 dhcp6c 97216 dhcp6c Received REQUEST
Nov 5 17:13:03 dhcp6c 97216 status code for NA-0: no addresses
My WAN connection uses DHCP6 and I confimed IPv6 connectivity.
WAN has an address and IPv6 is routed as expected.
I lost IPv6 connectivity and the spamming of DHCP log by DHCP6 client stopped.
So I reconnected WAN and the spamming was back.
Nov 5 17:26:20 dhcp6c 97216 Start address release
Nov 5 17:26:20 dhcp6c 97216 Sending Release
Nov 5 17:26:20 dhcp6c 97216 remove an address 2003:REDACTED:d1d4/64 on igb0
Nov 5 17:26:20 dhcp6c 97216 dhcp6c Received RELEASE
Nov 5 17:26:20 dhcp6c 97216 status code: success
Nov 5 17:26:21 dhcp6c 97216 exiting
Nov 5 17:30:56 dhcp6c 74412 failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Nov 5 17:30:56 dhcp6c 74412 failed initialize control message authentication
Nov 5 17:30:56 dhcp6c 74412 skip opening control port
Nov 5 17:30:57 dhcp6c 74510 Sending Solicit
Nov 5 17:30:58 dhcp6c 74510 Sending Request
Nov 5 17:30:58 dhcp6c 74510 dhcp6c Received REQUEST
Nov 5 17:30:58 dhcp6c 74510 add an address 2003:REDACTED:d1d4/64 on igb0
Nov 5 17:30:58 dhcp6c 74510 status code for NA-0: no addresses
Nov 5 17:31:00 dhcp6c 74510 Sending Solicit
Nov 5 17:31:01 dhcp6c 74510 Sending Solicit
Nov 5 17:31:03 dhcp6c 74510 Sending Solicit
Nov 5 17:31:07 dhcp6c 74510 Sending Solicit
Nov 5 17:31:15 dhcp6c 74510 Sending Solicit
Nov 5 17:31:32 dhcp6c 74510 Sending Solicit
Nov 5 17:31:33 dhcp6c 74510 Sending Request
Nov 5 17:31:33 dhcp6c 74510 dhcp6c Received REQUEST
Nov 5 17:31:33 dhcp6c 74510 status code for NA-0: no addresses
Nov 5 17:31:35 dhcp6c 74510 Sending Solicit
Nov 5 17:31:36 dhcp6c 74510 Sending Request
Nov 5 17:31:36 dhcp6c 74510 dhcp6c Received REQUEST
Nov 5 17:31:36 dhcp6c 74510 status code for NA-0: no addresses
Nov 5 17:31:37 dhcp6c 74510 Sending Solicit
Nov 5 17:31:38 dhcp6c 74510 Sending Request
Nov 5 17:31:38 dhcp6c 74510 dhcp6c Received REQUEST
Nov 5 17:31:38 dhcp6c 74510 status code for NA-0: no addresses
Nov 5 17:31:40 dhcp6c 74510 Sending Solicit
Nov 5 17:31:41 dhcp6c 74510 Sending Request
Nov 5 17:31:41 dhcp6c 74510 dhcp6c Received REQUEST
Nov 5 17:31:41 dhcp6c 74510 status code for NA-0: no addresses
Nov 5 17:31:43 dhcp6c 74510 Sending Solicit
Nov 5 17:31:44 dhcp6c 74510 Sending Request
Nov 5 17:31:44 dhcp6c 74510 dhcp6c Received REQUEST
Nov 5 17:31:44 dhcp6c 74510 status code for NA-0: no addresses
Nov 5 17:31:46 dhcp6c 74510 Sending Solicit
Nov 5 17:31:47 dhcp6c 74510 Sending Request
Nov 5 17:31:47 dhcp6c 74510 dhcp6c Received REQUEST
Nov 5 17:31:47 dhcp6c 74510 status code for NA-0: no addresses
Then restart unbound (resolver) and DHCP servers one by one - pause and observe behaviour in logs after each start.
After starting only unbound with DHCP Registration and Static DHCP disabled unbound gets restarted every time dhcp6c is logging "Sending Solicit"
So I checked my WAN settings and compared it to another pfSense firewall I am running with the same ISP (Deutsche Telekom Business).
Under DHCP6 Client Configuration there is an option called Request only an IPv6 prefix (Only request an IPv6 prefix, do not request an IPv6 address).
After enabling the checkbox the spamming of DHCP logs by DHCP6 client stopped and unbound is running without getting restarted.
DHCP servers are also running again with no issues.
I have no idea why it was working fine for 2+ years without the "Request only an IPv6 prefix" option checked.
Maybe the ISP changed some settings on their side.
Thank you very much @Gertjan for pointing me in the right direction.
I hate to dig up a long dead thread, but I was wondering if this ever got resolved (other than reinstalling Pfsense and restoring from a working config.
Having a similar issue actually on my machine.
Little more background: these issues started with an attempted install of a freeRadius package. It was having trouble, giving similar "assigning address" errors (didn't screenshot at the time. apologies). I gave up, thought nothing of it, and removed the freeradius package and then my pfblockerng dns blacklist started giving me trouble. I restored to a config that I knew was working, but that also did not solve the problem. I've tried reinstalling pfblocker, totally deleting the config, and resetting it up, rebooting the whole pfsense box, and continue to get the same error.
I still could reinstall pfsense from scratch, and then restore that config file, but have there been any updates?