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

[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