bind package 9.16_12 reads from /cf/named, but changes in the GUI are written to /var/etc/named

BlankMan

@gertjan I was afraid that if I went to a newer version of pfSense things might have changed and I would not be able to restore my config from the 2.4.3 backup of it I had. So I reinstalled 2.4.3 and even though the installer grabbed the config off the SSD, I again restored the config manually, because...

As it was with the reinstalled 2.4.3 and the installer restored config, I discovered it did not restore the Bind zone files for each domain. So I restored the config I had and found that config backup did not backup the zone files either. I landed up recreating them from scratch. PITA and a lot of down time due to no DNS for my domains. I didn't think to separately, manually, backup the zone files but now I am doing that.

I did then upgrade to 2.4.5 but still now on 2.4.5-Release-p1 it is not giving me an option to upgrade to 2.6.0, it says "The system is on the latest version". And based on the recent Bind trouble due to no zone files, I'm not inclined at the moment to do an upgrade and have to deal with more Bind issues...

And thanks for the tip on not installing/upgrading packages if not on the newest version, I will keep that in mind. This was kind of an emergency, I needed to get things back online as quickly as possible and did not want to make changes to add more complexity to the task.

That said, my 2.4.5 version is only showing the 9.14_12 version of Bind to install and not the 9.16_12 version, so that makes it appear that the installer knows what package version are for what pfSense version. So I understand why you say don't install/upgrade packages unless on the most current version of pfSense but if the installer is keeping track of what goes with what I question why not then?

tbahn

@blankman The backup of the bind package is stored in the "Package Manager" backup area (or "All"), not in "DNS Resolver", nor in "DNS Forwarder".

The renaming I did and described in the main post proofed for me that the files (zone DBs etc.) are generated from the bind package or its GUI, but the information shown in the GUI and used to generate these files must be stored elsewhere (in a database?).

BlankMan

@tbahn It's good to know the link you did in case I run into that.

"Package Manager" backup area? I'm not sure what you are referring to.

The backup I'm referring to is the Diagnostics -> Backup & Restore and it was an "All" backup. Is that what you are referring to?

I'm probably doing something wrong with zone files anyway and you're probably going to tell me that I am.

I cannot create zone files in the GUI. When I create one, and there's one there right now, I can leave, come back and edit it, but it never gets loaded.

And, when I fill in all the fields, and I'm at the bottom the "Resulting Zone Config File" window never gets populated with anything. It's greyed out and empty.

So, I manually put the zone files in /cf/named/etc/namedb and put the zone information in Global Settings so they get loaded.

I don't think I'm doing it the right way, the pfSense way, and I would love to do it the pfSense way if I could get creating the zone in the GUI to load.

tbahn

@riso I had to check this "off-time": Yes, it still runs after reboot, but it takes minutes for the named service to start.

I couldn't find anything in the logs, but I assume, it could be the same attempts and timeouts as when I updated the package.

tbahn

@blankman Where you select "All": the field is labeled "Backup Area". :-)

I'm no specialist by any means for "bind on pfSense", more a self-educated practitioner. Perhaps someone with more systematic knowledge can aid you further.

I exclusively used the Bind GUI to setup bind with ACLs, views and some zones. So, it's doable.

As far as I understand now, this configuration is stored elsewhere and the configuration files under /cf/named are generated, when you save the zones.

One thing I discovered: You seem to have to save twice: one time in the zone itself, one time in the list of zones. At least, only with this second save (in the table of zones page), the changes are propagated to other DNS servers with slave copies of the zones.

viktor_g

the fix will be in the next BIND version (soon):
https://redmine.pfsense.org/issues/12869#note-7

riso

@tbahn thank you
in my case, this workaround did not survive the server restart, I had to do it again
@viktor_g thanks for the quick fix :)

tbahn

@viktor_g Thank you for fixing and notifying us.

jaltman

I can confirm that 9.16_13 fixes the problem.
Thank you.

dld_r00f

I have inverted situation with BIND.
pfSense 2.6.0 with BIND 9.16_12 (10 zones with DNSSEC Inline Signing and Backup Keys flags) work as usual.
After upgrading to 9.16_13 it stopped signing DNSSEC. New BIND try to find keys at /var/etc/named/etc/namedb/keys istead of /cf/named/etc/namedb/keys.

Stupid situation: I have a working backup with a previous package version. But this is completely useless with the new version of the package. So I can’t just reinstall the system, it won’t work, because the current version of the package is broken.

And insanely long BIND loading of course (link).

dld_r00f

This post is deleted!

bingo600

@dld_r00f

Wouldn't a "quick & ugly" hack be to make a symlink of the existing file to the "wanted file" ??

ln -s <existing> <wanted>

dld_r00f

@bingo600
If you know the problem, then there are many ways to solve it :)
I just copied all my dnssec keys to /var/etc/named/etc/namedb/keys. I think the symlink worked too.
In my case, I spent about 4 hours to figure out what was causing the problem.

viktor_g

Redmine issue created:
https://redmine.pfsense.org/issues/13002