Does pfSense 2.6 Development patch the Unbound DNS restart issue?
-
I'm a home labber that had previously used pfSense for over 10 years. However, I have a use case in the last year that has stopped me from running it.
I do a lot of VM testing with many virtual hosts in my lab. This requires me to spin up new VMs constantly and I have a script in place that always configures them with a predictable naming scheme so that I can quickly connect to the VMs I need.
In order for me to use this without having to set hundreds of manual DHCP static entries, I need to leave "register DHCP leases" enabled. However when I do this, pfSense restarts Unbound every time a DHCP lease is created or renewed. This causes a loss of any DNS cache and also causes a brief DNS outage while dnsbl lists all reload just due to a DHCP renewal.
Can anyone comment if this is fixed in the 2.6 Dev snapshots?
-
@pfsvrb I haven't looked at any dev snapshots but it's not in the 21.09 release notes that I see nor is the redmine complete. Workaround is generally to set a longer lease time, perhaps with a larger subnet mask.
-
@steveits Thank you for the heads up on the redmine issue, I didn't realize it had been open so long! It looks like it just gets perpetually pushed over and over, which is unfortunate.
I did try a longer lease time but that still doesn't help me when I tear down 30+ VMs, rebuild new ones with new MACs, and then they all boot storm and request a new IP. I was then running in to issues where I was running out of IPs as I was waiting for the old leases to expire out.
I guess I'll just keep an eye on that redmine thread and hopefully it eventually gets fixed? It's been open for 6 years so I have my doubts.
-
I don't think your experience is too far outside the norm. I've also got a training lab setup that spins up 70 VMs all separated on different vswitches.
unbound does take a little bump.
At least on the training lab, nobody really cares if DNS blips out for a bit; it isn't handling several hundred outbound connections to the webs. -
@skogs Unfortunately in my case this is the single firewall for my whole network and the family definitely notices. At this point its more just an annoyance that this is the only firewall that produces this behavior. Literally any of the other options out there don't do this. It seems this issue gets ignored as a corner case but in my use case, it's kind of a deal breaker. :(
-
@pfsvrb said in Does pfSense 2.6 Development patch the Unbound DNS restart issue?:
I do a lot of VM testing with many virtual hosts in my lab. This requires me to spin up new VMs constantly and I have a script in place that always configures them with a predictable naming scheme so that I can quickly connect to the VMs I need.
Ok, why not ....
And then :@pfsvrb said in Does pfSense 2.6 Development patch the Unbound DNS restart issue?:
in my case this is the single firewall for my whole network and the family definitely notices.
You have boat loads of VM's, right ?
What about a centralized pFsense - and give it two LANs : one for your family, and another one (why not a VM ? ^^) that handles your activity. You can have the best of both worlds. Your virtual (second) pfSense's DNS activity wont bother the family any more.Consider "when activating "DHCP Registration" unbound gets restarted" :
I've an idea : What about this one :
Give unbound ports like 54 and the control port 954.
This way, unbound 'works' without actually doing something.
Now, take a crash course about how to make use of bind (name daemon or named), 'the big DNS - do everything".
bind reads the /etc/hosts file, every time et detect that it changed, without the need to restart.
The /etc/hosts file is updated with the info from the pfSense DHCP lease server, and it's the "dhcpleases" pfSense program takes case of this. When it updates the /etc/hosts file, it's this program that restarts unbound - with the known nasty side effect.
So : keep unbound running, but disable its usage by giving it other, none default ports 53 and 953.
Install bind, it will use ports 53 and 953, and make it the default resolver.
bind is not easy to handle. One need to know what DNS is - nothing just you thinking that you know what DNS is. But, it's manageable - and ones set up, your fine.
Now, the "DHCP leases / unbound" issue won't bother you any more, DNS (bind) keeps running. -
Snapshots have a newer version of Unbound which is supposed to be better, though we still have some reports of crashes. It's less than it was in the past, but still more than we'd like.
We may end up moving snapshots back to Unbound 1.12.x as we have for the last couple releases but that hasn't been finalized yet. We'd prefer to keep using the latest version if we can.
-
@gertjan Good idea.
I will confess that my training sim lab does have a separate bind server for the slightly more important parts. The only place I don't have a secondary local DNS server is at home too.
I've also done other things to separate the roles, but it would be nice if unbound would just stop taking a dump when it updates. I think the last 15 years or so we've gotten accustomed to state/config reloads...not sure why these particular combinations aren't capable of a service unbound reload. :)
@jimp thank you for the update! -
Looks like we'll be sticking with Unbound 1.13.x. We checked around internally yesterday and even the people who could reliably reproduce crashes on 1.13.x before could not do so on 21.09 since the last Unbound update.
We still have plans to correct how records are handled in Unbound in the near future, but at the moment it seems to have stabilized with the existing method.
