although already solved for me, but for the records, I’m posting this here:
Yesterday I’ve upgraded from core 139 to core 144. I’m using HOSTS entries alot, configured within WebIF. The website stores those entries here in an intermediate file : /var/ipfire/main/hosts.
After modifying or adding a new entries, IPFire generates the final hosts file based upon this file and automatically adds some PTR-records, if needed.
With core 139 the intermediate file looked like this, at least on my machine and I did not edit it manually so far, some example lines:
After rebooting IPFire as soon as core 144 update finished, I noticed that DNS was not working at all.
I tried to reboot IPFire again, and since this did not help either, I restarted unbound in a shell session. I noticed that unbound threw many errors then, e.g. complaining about the word static or similar undefined things.
Soon, I knew the source of those errors and deleted the file /var/ipfire/main/hosts and restarted unbound. Guess what? No problems occurred
Now, that the source of the unbound issue was found, I added a new host entry from within WebIF and had a quick look into the resulting file /var/ipfire/main/hosts.
I noticed that IPFire added a new keyword to the end of this entry which was not there before core 144, e.g:
You noticed the word off at the end? So far this keyword was missing, see above. This word corresponds to the WebIF option PTR. This one forces unbound to create a PTR-record for resolving IP-addresses (I’m not the expert here, but read about this). Resolving IP-addresses perfectly worked before the upgrade, so I assumed unbound creates such a record anyway - at least while on core 139.
Back to topic again: I manually edited the backed up /var/ipfire/main/hosts and added the keyword off at the end of each line.
Afterwards, I forced IPfire re-create the final host file by using the command
and restarted unbound again
Since then, no issues with DNS and of course no issues. Task solved and everyone is happy again at home