This Bind9 error ONLY happens if the selected zone has its allow-update defined (also called dynamic zone) to something other than none; option. And an error occurs when an attempt is made to perform "Apply Zone" URL action in "Bind DNS Server" Edit Master Zone webpage.
In "Edit Master Zone" webpage, attempts to perform by clicking "Apply Zone" hyperlink resulted in a cryptic error web page:
/usr/share/webmin/bind8/restart_zone.cgi | 15 | WebminCore::error
(eval 44) | 6 | (eval)
/usr/share/webmin/miniserv.pl | 2431 | (eval)
/usr/share/webmin/miniserv.pl | 943 | miniserv::handle_request
Debugging revealed that webmin.debug with debug_enabled=1, debug_what_cmd=1 option (in /etc/webmin/config) reported:
bind8 CMD "cmd=rndc -c /etc/bind/rndc.conf reload example\.com IN red-view "
From BASH shell, performed this command manually with verbose option shows:
# rndc -c /etc/bind/rndc.conf -V -V -V reload example.com IN red-view
create memory context
create socket manager
create task manager
create task
create logging context
setting log tag
creating log channel
enabling log channel
create parser
get default key
get config key list
decode base64 secret
reload
post event
using server 127.0.0.1 (127.0.0.1#953)
create socket
bind socket
connect
create message
render message
schedule recv
send message
parse message
create message
render message
schedule recv
send message
parse message
rndc: 'reload' failed: dynamic zone. # Error message
WORKAROUND
The workaround to this Bind9-specific error is to perform a freeze, reload, thaw, ESPECIALLY when using Bind DNS View concept.
# rndc -c /etc/bind/rndc.conf freeze example.com IN red-view
# rndc -c /etc/bind/rndc.conf reload example.com IN red-view
# rndc -c /etc/bind/rndc.conf thaw example.com IN red-view
In actuality, it is far safer to perform the freeze, reload, thaw RNDC command sequence for dynamic zone using rndc reload command (read on for more detail logic).
Running webmin 1.890
Some comments about this:
Basically, a new logic for using the RNDC command sequence of freeze, reload, thaw shall only be done if its zone (and within its view) have set its allow-update to something other than none or did not set the allow-update (Bind reference) at all.
We don't want to "needlessly" perform freeze-reload-thaw on non-dynamic zones.
Thanks, I'll roll back that patch.
Just a note that having been using dynamic zone updates for a few years, there appear to be corner cases where BIND can get its journal files out of sync, then refuses to update zones, maybe related to restarts without clean shutdowns. Freezing and thawing doesn't then work. After fighting such problems, I now have a daily cron job : rndc sync -clean and no more problems - ugly but it works.
Oh, yeah. I should have mentioned that too. Yes.
I think it pertains to reboot and or sudden named daemon death.
I have a script that takes care of my problem for my bastion host running 2 ISC Bind and an ISC DHCP server.
Most helpful comment
Just a note that having been using dynamic zone updates for a few years, there appear to be corner cases where BIND can get its journal files out of sync, then refuses to update zones, maybe related to restarts without clean shutdowns. Freezing and thawing doesn't then work. After fighting such problems, I now have a daily cron job : rndc sync -clean and no more problems - ugly but it works.