On 7/31/2014 3:08 PM, /dev/rob0 wrote:
On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote:
Am 31.07.2014 um 17:41 schrieb /dev/rob0:
On Thu, Jul 31, 2014 at 01:32:03PM +0200, Reindl Harald wrote:
i am doing reloads of named with "killall -HUP named" just
because i disabled rndc completly for security reasons and
configurations are generated with own software only needs
named to reload
Hmm, rndc is securable. You don't have to open it to the
snip
You're losing a lot of new features without rndc. This is a
"throwing out the baby with the bathwater" sort of solution.
Sure, this is what you are familiar with and what works for
you, but to disable rndc isn't good advice for readers of
this list. ISC is moving on
don't get me wrong but if someone creates *any* bind
configuration and zone-files with self developed software
... that someone is almost surely doing it wrong. "Zone files"?
there are no features rndc could provide and so disable
something you don't use is the way to go instead make is
secure with other switches
The proper tool to manage named configuration and operation, and
which in the best Unix ethic is well suited for automation, is
rndc(8).
The proper tool to manage zone data is nsupdate(8). Likewise well
suited for automation.
Unfortunately, it seems that no one with an adequate understanding of
BIND has written and released a good management frontend. Too many
of them are still wallowing around in zone file editing rather than
nsupdate and (as it seems from this thread) sending of signals rather
than rndc.
Written? Yes. Released? Unfortunately not. It's intellectual property of
my employer.
Even with the nice GUI frontend of Infoblox, we still use our homegrown,
crudely-formatted web frontend for the vast majority of changes
(Infoblox being the backend of that frontend), since
a) our existing users are accustomed to it,
b) it's simple enough that even novices can get up to speed on it
quickly, without the possibility of causing major disruption,
c) the lack of significant eye-candy means it still runs well even in
slow and/or high-latency locations,
d) it has a more robust ACL system that I haven't seen rivaled in any
commercial product, and
e) other stuff I've added over the years, like automatic
external-to-internal sync'ing, and so forth
- Kevin
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
