#1157 BIND module doesn't use rndc to stop named 9.2.1
OS: Red Hat 7.3, fully patched
DNS: BIND 9.2.1
Webmin 1.080
BIND 9.2.1 uses journal files to track dynamic DNS
changes and also during zone transfers to a slave BIND
server. In order to properly flush the journal files to the
corresponding zone files at named shutdown,
"/usr/sbin/rndc stop" must be used; if a simple kill signal
is sent, named won't flush the journals and at the next
named startup, it will complain that the journal(s) are
out of sync with the zones.
From looking at the various /usr/libexec/webmin/bind8/
and /etc/webmin/bind8 config scripts, it appears that
webmin is using /etc/init.d/named to shutdown named;
this script doesn't use rndc either. I've already sent in a
report to Red Hat about that.
(This need to use rndc to cleanly shut down bind is new to
bind9; bind8 would delete the journal files after
periodically writing their contents to the zone files. bind9
doesn't do this anymore due to the journals being used in
zone transfers as well as dynamic updates.)
Don Kennedy
dkennedy@pdghightower.com
Logged In: YES
user_id=129364
Even though there is an entry in the config files for a stop
command, the module doesn't actually have an option to stop
BIND, so it is never used! However, if I ever add such an
feature I will keep your suggestion in mind ..
Logged In: NO
Sorry for the delay in getting back to you..
I guess I didn't state my
original issue clearly enough: Webmin incorrectly processes updates
to bind9's zone files when named is actively using journal files. Webmin-
based updates to named if journal files exist will result in the restarted
named complaining that it can't use the updated zone files, and therefore
the resulting DNS is incomplete - the updates files aren't read in when
named restarts.
The solution for bind9 is different than the current
"change files, stop named, start named" processing for bind8. Webmin
needs to use rndc to stop named, then delete any .jnl files, then allow the
user to make changes, then restart named. Any changes to zone files
have to be done while named is stopped (a strong reason why sites using
bind9 should have a slave DNS server).
Minimizing the named
downtime would be complicated; you'd need to keep track of the user's
zone changes, then merge them into the zone files after rndc has shut
down named and named has (possibly) changed the zone files with the
latest journal information.
- Don Kennedy
(dkennedy@pdghightower.com)
Logged In: YES
user_id=129364
Actually, what is really needed is a module that can use the
nsupdate command to modify dynamic zones directly .. That
would solve the problem completely, and avoid the hassle of
merging zone files. A partial module like this has been
written (available at webmin.thirdpartymodules.com) but it
still needs a lot of work!
Logged In: NO
Thanks for the reference to dynbind; I've downloaded the module from
webmin.thirdpartymodules.com, I'll see what I can make of it and try to
update it as needed.
I've not worked on Webmin modules before,
if you have any general module authoring pointers (or hints on working on
dynbind) you can pass along, I'd appreciate it!
Don
Kennedy
dkennedy@pdghightower.com
Logged In: YES
user_id=129364
Have a look at http://www.webmin.com/modules.html for
docs on writing your own modules.
The biggest problem with dynbind at the moment is that it
relys on nslookup to get the list of records, which is not
available (or doesn't work) with BIND 9!
Logged In: YES
user_id=665381
Woah! I have just started to use the dynbind module as well,
and have made a few changes (more like 'tidy-ups') to it
already. I tried the 'dnamic dns update ' module but that
seemed to lack more than it had going for it - whilst the
add/delete/modify interface was okay, it didn't show the
zones and their records. In that respect it was a guess as
to whether an entry existed or not. It seemed better to
start with dynbind and work with that. Also I could not
contact the modules author - email rejected, also I have had
no reply from their postmasters. Could be the guy is simply
not working on the module or at 'tbits.org' any more.
The problem I have is that we are a bind 9 site and we want
to move to dynamic dns. In that respect parts of the bind 8
code, using nslookup for example, is not required (bind
9.2.1 has no 'nslookup ls -d' command for zone transfers for
example).
The current module seems to have been adapted from the bind
8 static dns module - I am guessing here, but that is what
it looks like. So do we keep dynbind as an all dancing bind
8, bind 9, static and dynamic dns module - which is nice in
theory but could be a big module! Also any bug fixes for
static bind 8 or 9 would have to be incorporated into
dynbind as well as the present static dns modules.
Writing a new bind 9 module for static and dynamic dns is
also a big task, but may be easiest just to start with
dynbind and fix it up with respect to nslookup and the like.
Again bugs would have to be fixed in both the static and
dynamic versions.
Writing a bind 9 only-dynamic dns module would be the most
ideal for me - since that's all we use - but requires
back-porting bugs already listed in this database, as well
as rewriting a lot of dynbind. Again, existing and new bugs
would have be ported to both the static and dynamic modules.
What do you all think? I am willing to put time into this
since it is something we require, but I am unsure in which
direction to proceed. Secondly I don't want to start
something if others are likewise working on dynamic dns.
Should we move this onto the main mailing list? It is also
difficult for me to see what *is* required or available with
bind 8 since we don't use it anymore. I could stick it on a
test server...
John.