bind package 9.16_12 reads from /cf/named, but changes in the GUI are written to /var/etc/named
-
I've updated bind package to 9.16_12 yesterday. Today I made some changes to two zones, the clients could not see, even after some time, service restarts, pfSense reboot etc.
I found, that the bind server uses the configuration files under /cf/named (as usual), but the changes I made were stored under /var/etc/named?!?
I compared this pfSense installation with another one with bind package to 9.16_11. There is no /var/etc/named folder.
I removed the bind package, renamed /cf/named to /cf/named-renamed and /var/etc/named to /var/etc/named-renamed, and reinstalled the bind package. /var/etc/named was recreated, but /cf/named not. named service would not start.
In order to get it running, I created a symbolic link using:
ln -s /var/etc/named /cf/namedNow the named service can be started again and the clients find the new DNS entries I made.
Assuming others will have similar problems, I wrote about it and my workaround. But I think, there must be a minor flaw in the bind package in version 9.16_12.
-
I just had to reload pfSense yesterday because something got corrupted during a power outage and it got into a reboot loop. (It is behind a UPS and generator, it's a long story.) I reloaded 2.4.3 and it grabbed the existing Bind config. I eventually upgraded it to 2.4.5 which it tells me is the latest and greatest.
I also reinstalled Bind and the version it installed and I am running is 9.14_12. So I'm wondering how you got 9.16_12 or is that a typo?
-
@blankman The current version of pfSense Community is 2.6.0 (see: https://www.pfsense.org/download/):
The current version of the bind package is 9.16_12 (in my pfSense's package manager):
-
Added to what @tbahn said : after installing an older pfSense version, no packages should be installed.
Instead of using a USB key with an older pfSense ISO, prepare a new key with the latest version : 2.6.0.
Add this widget on on the dashboard :
and now you know, as soon as you login, that a new version is awaiting.
( packages should not be upgraded / installed as long as you didn't update / upgrade )See here : Auto update check, checks for updates to base system + packages and sends email alerts : this script will send you a mail as soon as pfSense has an update, or one of the pfSEnse or FreeBSD packages.
-
@tbahn Hello, does this fix works after restart ?
Thanks -
@tbahn Thanks for the explanation. I did hear about 2.6.0 but my installation is not telling me about it being the latest like it has done for previous versions.
-
@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?
-
@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?).
-
@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.
-
@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.
-
@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.
-
the fix will be in the next BIND version (soon):
https://redmine.pfsense.org/issues/12869#note-7 -
-
@viktor_g Thank you for fixing and notifying us.
-
I can confirm that 9.16_13 fixes the problem.
Thank you. -
I have inverted situation with BIND.
pfSense 2.6.0 with BIND 9.16_12 (10 zones with DNSSECInline SigningandBackup Keysflags) 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/keysistead 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).
-
This post is deleted! -
Wouldn't a "quick & ugly" hack be to make a symlink of the existing file to the "wanted file" ??
ln -s <existing> <wanted>
-
@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. -
Redmine issue created:
https://redmine.pfsense.org/issues/13002
