gbindadmin settings differ from that of bind9 package

I'm not sure this is a bug. With gbindadmin, you can specify where your DNS stuff is and everything works fine from then on.

Maybe you're right, maybe not. Maybe it's not a bug. If it is a feature, it's a wrong one, I think.
Is the tool intended to make the things easier? Suppose you're a teacher far from IT. You must not know anything of file hierarchy of the service. Look at Microsoft DNS - it's easy to setup! While BIND is a puzzle, and gbindadmin is a puzzle too. (puzzle * puzzle) = (puzzle ^ 2).
Is it the Ubuntu mission to complicate things? I don't think so.

If you're a teacher being asked to deal with DNS, your schools has problems that a front-end cannot solve.

I'm not a teacher. I said, "SUPPOSE you're a teacher".
The front-end must not make things complicated. First of all, it MUST have settings coordinated with its back-end. Don't you think so?

Yes, it's a bug, or more accurately a whole mess of bugs, probably in both bind9 and in gbindadmin, but especially in gbindadmin. Changing bind to match gbindadmin would be a huge exercise of the tail wagging the dog. The administrative tool should follow the underlying program, not the other way around.

gbindadmin assumes that bind will be run in a secure manner. As it ships from Ubuntu, the default install of bind9 is to run with suid root, and not in a chroot jail, both of which are deprecated in the bind9 documentation. The fix is as follows:

-OPTIONS=""
+OPTIONS="-u bind -t /var/lib/named/ -c /etc/bind/named.conf"

(see /etc/init.d/bind9)

The default command channel in gbindadmin's named.conf (127.0.0.1) seems to cause conflicts. It should be changed to 127.0.0.3 (or whatever you favorite number is. I got the number from the bind9-doc documentation), and a setting created that will allow for a configurable control address. (The same setting should be used when gbindadmin writes the zone files, too.)

gbindadmin's install script should check to see what the OPTIONS are (the pun was begging to be used) and offer to change the OPTIONS, preferably with an editable field because there are so many different possible use cases with bind.

gbindadmin's default chroot should be /var/lib/named instead of /var/named. There exists already a setting to change it, but out of the box, the config should "just work".

gbindadmin should put the named.conf file in /etc/bind/named.conf instead of /etc/named.conf, and should add a setting that allows for customizable path to named.conf. The workaround for now is to use a hardlink between the two (for some reason, a symlink won't work), viz:

# ln $CHROOTDIR/bind/named.conf $CHROOTDIR/named.conf # I may not be correct on the actual variable name; but you get the idea.

Similarly, the rndc key generation (i.e., rndc-confgen) is asymetric between bind9 and gbindadmin. The default key length of bind9's install script, rndc-confgen, and gbindadmin should all be 256, as it is in gbindadmin, IMHO. But whatever key length you pick, it should be the same between the three of them. Further, both bind9 and gbindadmin should run rndc-confgen with the correct options, to wit:

# rndc-confgen -u bind -a -b 256 -s 127.0.0.3 -t /var/lib/named -c /etc/bind/rndc.key

gbindadmin's "Reload Zones" function is also broken, I think because of the same wrong paths and unset options for the "rndc reload" command as for the rndc-confgen originally.

gbindadmin's named.conf file seems to be broken on the keys, too. I had to delete the "key" stanza and remove the reference to the rndc_key in the "controls" stanza. The following is what the controls stanza looks like after the change:

#controls {
# inet 127.0.0.3 allow { localhost ; } ;
#};

(obviously, without the comment marks).

Finally, the man page for gbindadmin should be corrected and expanded. Notably, the man page states that gbindadmin doesn't have any options, which is true insofar as the command line goes, but untrue insofar as configuration goes (see /etc/gbindadmin/settings.conf). Certainly at a minimum, the location and meaning of each of the settings should...

I should make clear that when I talk about the changes that should be made in gbindadmin's chroot jail, I really am speaking about whatever chroot jail where bind is running from. (Pardon the ending preposition.) Essentially, I'm saying that named should be run in the chroot /var/lib/named and configured as described above, whatever the tool is that's used to configure it.

There being more than one way to skin a cat, I don't really have an emotional connection to the final default configuration, but whatever the community consensus is, the tools should conform, should give the user the ability to make changes to the default, and should be documented.

Happy Trails,

Loye

The OPTIONS described above should be changed in /etc/default/bind9, per /etc/init.d/bind9, and IMO should be the default for a bind9 installation.

In my original post, the suggested workaround is malformed:
# ln $CHROOTDIR/bind/named.conf $CHROOTDIR/named.conf
should be:
# ln $CHROOTDIR/etc/bind/named.conf $CHROOTDIR/etc/named.conf

Happy Trails,

Loye

Glad to see rational and responsible man.
I use webmin now but I hope corrected gbindadmin will be useful for novices.

Bind9 installs unchrooted and running as root because I'm still working on how to detect the right way to deal with an upgrade so as to not break the installed base when they upgrade. ideas that deal with upgrades cleanly are welcome.

Marking Invalid for bind9 package as the request to run bind9 in a chroot by default is already recorded in bug 127184.

For gbindadmin, I'd suggest to make the default configuration to use the same directory as bind9.

Is this still relevant? It looks like gbindadmin has been replaced by gadmin-bind