@gertjan Yesterday, I could change that, now it seems it's working how it should be. Thank you so much for your help.

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. Thanks again.

@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.

@chrcoluk said in Unbound stability is worrying: Obviously the proper fix is to deal with the configuration that is over stressing the memory in the system, but as a quick workaround in the mean time just enable swap. I usually enable swap on all my systems, just to act as a buffer for these types of moments. Not sure if swapping to an 8gb flash drive is the best idea....

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.

@johnpoz dnsleaktest.com shows the IP address of my vpn provider. whether you select standard or extended, it then shows results in the IP of my ISP connection. my config is as follows System DNS Servers DNS Servers 1.1.1.1 firewall WAN DNS Server Override unchecked Disable DNS Forwarder checked DNS Resolver enable checked Network Interfaces LAN / VLAN Outgoing Interfaces Localhost system transparent DNSSEC checked Use SSL/TLS outgoing checked DHCP Register checked Static DHCP checked Advanced Privacy Hide ID checked Hide Version checked Query Name checked Prefetch Support checked prefetch DNS key checked harden DNSSEC checked Experimental Bit 0x20 checked Routing WAN Default Route Rules TCP/UDP * * LAN Address DNS allow TCP/UDP * * !Firewall DNS block TCP/UDP * * VPNBYPASS * WAN none TCP/UDP * * !LAN * ExpressVPN none NAT 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 **

@brad-edmondson said in Unbound stops resolving intermittently: have short DHCP leases 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.

Solved it guys, did some googling on that SSL error and found another post here: In /var/unbound Delete dnsbl_cert.pem unbound_control.key unbound_control.pem unbound_server.key unbound_server.pem Reboot and run force update/reload. DNSBL now up and running. Thanks for the help in diagnosing guys.

Hi and thank you for your reply. When I stop unbound and check for running processes there is no unbound running. [2.4.4-RELEASE][admin@gateway.REDACTED.TLD]/root: ps ax | grep unbound 21735 0 S+ 0:00.00 grep unbound [2.4.4-RELEASE][admin@gateway.REDACTED.TLD]/root: After stopping all DHCP servers the following processes are running: [2.4.4-RELEASE][admin@gateway.REDACTED.TLD]/root: ps ax | grep dhcp 4049 - S 0:00.00 /bin/sh /var/etc/dhcp6c_wan_script.sh 56033 - Ss 618:49.04 /usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -l /tmp/haproxy_chroot/var/run/log -P /var/run/syslog.pid -f /etc/syslog.conf 97216 - Ss 0:01.42 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_pppoe0.pid pppoe0 14705 0 S+ 0:00.00 grep dhcp [2.4.4-RELEASE][admin@gateway.REDACTED.TLD]/root: 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. After killing 97216 - Ss 0:01.42 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf -p /var/run/dhcp6c_pppoe0.pid pppoe0 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 @Gertjan said in DNS Resolver & DHCP Server are constantly restarting: and thus dhcpleases should not run. Or, it's that process that restart unbound - see your own logs. dhcpleases was running because I enabled it again after disabling didn't change the behaiviour. @Gertjan said in DNS Resolver & DHCP Server are constantly restarting: 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.

@dragoangel thanks a lot it works now.

Hey all. 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?