Bind upgrade producing errors on pfsense 2.5 upgrade

aligator638

Configuration:

unbound is listening on:
192.168.10.1
192.168.20.1
localhost
The control port is set to 953

bind is listening on
192.168.10.9
The control port is set to 8953
some zones are dynamic and updated by the dhcp service

pfblocker with dnsbl is enabled

The problem:

Upon rebooting the server, startup is really slow. This happened during and since the upgrade to version 21 (aka 2.5)

Investigation:
reboot the server and connect with the serial console and ssh
When server seems frozen run ps -aux | grep (various names here name/bind/rndc) on the ssh console
We notice rndc is being started multiple times (rndc freeze/thaw commands) and take a long time to complete (it seem to go over all defined bind zones) freeze/thaw operations are related to editing the zone files manually on a dynamic zone
We notice no new services are starting while bind is in this process loop
keep killing the rndc processes and the boot sequence will finish in a reasonable time
leave it running and pfsense will eventually finish starting (seems to depend on the number of zones configured in bind)

Possible causes:
rndc commands are being run before bind is started (rndc cannot start bind on its own)
rndc is using the wrong port
bind is started but control channel is on the wrong port

matthijs

@aligator638
I rather see this issue fixed, but a workaround can be installing the package "Shellcmd" and add the following line:

/usr/local/sbin/named -c /etc/namedb/named.conf -u bind -t /cf/named/

My system boots a lot faster/services starting faster with this workaround

aligator638

@matthijs it is a workaround but still what is meant by these commands ? Are they essential ? That is the question. IMHO pfsense is trying to do something with the zones at startup. like freeze - do something with the zone- thaw etc... bypassing this process could have some impact.

Gertjan

@aligator638 said in Bind upgrade producing errors on pfsense 2.5 upgrade:

IMHO pfsense is trying to do something with the zones at startup. like freeze - do something with the zone- thaw etc... bypassing this process could have some impact.

For that to work, named has to be started first ;)

That's what this :

@matthijs said in Bind upgrade producing errors on pfsense 2.5 upgrade:

/usr/local/sbin/named -c /etc/namedb/named.conf -u bind -t /cf/named

does.

matthijs

@gertjan

If you search your (backup) config file for the following lines:

<package>
<name>bind</name>
<internal_name>named</internal_name>

change it to:

You do not get the warning during config restore that named is now called bind in PFsense packages, and the packet re installation continues without errors or warnings

aligator638

@gertjan Yes, but this is the job of pfsense to start the service, I should not make a 3 hours long trip to console into the firewall and start the service manually every time a reboot is required.

Gertjan

@matthijs said in Bind upgrade producing errors on pfsense 2.5 upgrade:

You do not get the warning

No warnings .... as I'm not using bind / named.

@aligator638 said in Bind upgrade producing errors on pfsense 2.5 upgrade:

I should not make a 3 hours long trip to console

Don't we all have a "remote warrior VPN access" these days, to access the GUI from distance, and be able to SSH (a remote 'close to' console access) ??

johnpoz

@aligator638 said in Bind upgrade producing errors on pfsense 2.5 upgrade:

I should not make a 3 hours long trip to console

No offense - but if some install you manage is 3 hours away, and and you have not setup some sort of remote access, even via a out of band, etc. Your doing it wrong ;)

Could be as simple as open up gui/ssh on the wan of pfsense to your known remote IP.. I have this setup on an install that is only 30 minutes from me.. I can access the gui and ssh, from my known home IP..

To issues with upgrades of packages and stuff breaking or working different. It would not be possible for pfsense to simulate every possible config that a user might setup. So it is quite possible that a previous configuration that didn't throw errors, and worked before might have problems after an upgrade where package was changed or checks were put in place to help prevent non standard configs, etc.

I had an issue awhile back where freerad was working, I then upgraded it and it didn't - why because there was an issue in the previous version that allowed it to work how I had it configured - even though it was not right. When I upgraded it that bad config no longer worked, etc.

matthijs

It looks like the issue is resolved with the latest Bind package version 9.16_17

aligator638

I confirm the boot problem is gone on on my firewall

aligator638

Well one issue with the move to the new version. Previously bind was installed on my /cf now it is in /var/etc/named/etc/namedb/ a side effect, is whenever the router is restarted all my keys specified as global option will vanish

include "/etc/namedb/acme-keys.key";
include "/etc/namedb/ddns-key-inf.key";
include "/etc/namedb/ddns-key-sec.key";
include "/etc/namedb/ddns-key.key";

An idea would be to save them in the pfsense configuration.