[BlueOnyx:11630] Re: BX BIND files

[George F. Nemeyer]

On Sat, 27 Oct 2012, Michael Stauber wrote:

First, thank you for all the in-depth detail!  It explains a LOT about the
agony I was having over things I was seeing.  I was gong crazy over the
fact that DNS was *WORKING* just fine, but when I added a new (secondary)
zone to the GUI, it was in the GUI list, but *noplace* in the actual bind
config or zone data...even though on *some* boxes, it all worked fine, and
on the box I was working with it worked fine on *that* on up until about a
month ago.  I discovered a lot of query errors for the new domain when
looking at a log file on the machine.  Fortunately, since the box was only
one of several DNS servers for the domain, the domain itself wasn't dead.

I actually got to the point where I erased *all* the DNS files, jail dirs,
and BIND packages on the box and re-installed from scratch...including the
base-dns sausalito stuff, and let the CCE regenerate the zone files just
to see where they got put.  I knew the CCE stored at least enough of the
secondary info to re-populate the new config file, and as soon as BIND was
running, it would pull down the data from the master(s).

In past years, the RH chroot seemed so problematic, that on RH boxes well
before the Cobalt days, I'd throw out the whole chroot mess and run with a
fresh compiled 'stock' BIND in the 'usual' places.  For a time, there
seemed to be a new bind every week, and trying to make the latest one work
in the RH environment was just too much of a pain.  I like simple!  [Do
NOT ask me what I think of PAM! :) ]

Also, when the stream of CERT alerts and updates tapered off, the root
exploits in BIND that the jail was created to prevent had mostly been
patched away anyhow, so a 'plain' BIND install seemed secure enough. I've
not heard of any major issues with it for years now, and at least some
distros have abandoned the jail.

It does beg a possibly rhetorical question:  Does BIND even *need* a
chroot jail now?

That being said, I realize that for BX, as long as the RH/CentOS default
is to have one, it makes sense to have BX follow suit and just let the RH
repo updates do any BIND updates without having to change and re-release
BX-unique BIND versions.


Regarding the use of the GUI to store all the various records,  I use the
BX boxes only for secondaries, keeping one non-BX box as master from which
all the rest get updates.  ... Because secondaries are simple.

This is primarily because I'm an old-school guy that just likes to create
edit a zone file from a template with a text editor.  That way, all the
info is in one place, and easily viewable as a whole.  Of course, I
typically have to re-learn just what has to have dots and other little
things, but the template helps with that.

To be honest, I find the 'enter an A record' kind of interface that
Cobalt/BQ/BX has to be *terribly* confusing without opening the actual
resulting file afterward to look at.  It just seems to break the entry
process up into such tiny bits that you loose the big picture.

It might make more sense to have and call a totally stand-alone DNS zone
editor that does all the hand-holding and sanity checking, and then let
that hand over entire completed zone files to BX.  BX could then just
store/display the zones as appropriate, with any UI 'EDIT' just
re-summoning the external editor.  As you indicated, trying to mash all
that into the existing sausalito structure seems a really massive
undertaking!

I'd personally vote for a more 'complete zone picture' sort of editor.
There might even be something out there already...I'll poke around some to
see what I can scare up and pass the info back.

If re-doing the DNS UI ever comes off the back burner, I'd be more than
happy to be a beta tester.  I'm not a programmer, but I've dealt a lot in
user interfaces, and seem to have a knack for finding bugs by trying what
(at least to me) seems obvious.

=^_^=  Tigerwolf