Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.


#1157 BIND module doesn't use rndc to stop named 9.2.1

Jamie Cameron

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


  • Jamie Cameron
    Jamie Cameron

    • status: open --> closed
  • Jamie Cameron
    Jamie Cameron

    Logged In: YES

    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

  • Jamie Cameron
    Jamie Cameron

    Logged In: YES

    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 but it
    still needs a lot of work!

  • Logged In: NO

    Thanks for the reference to dynbind; I've downloaded the module from, 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!


  • Jamie Cameron
    Jamie Cameron

    Logged In: YES

    Have a look at 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!

  • John Horne
    John Horne

    Logged In: YES

    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 '' 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

    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...