rndc (and now nsupdate too)

[Reindl Harald]

Am 31.07.2014 um 21:08 schrieb /dev/rob0:
> On Thu, Jul 31, 2014 at 05:56:08PM +0200, Reindl Harald wrote:
>> 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

zone file *editing*?

sorry, no, i developed 2008 a interface to create all zone files based
on database records, write the complete zone content in a main table
with a textfiled and a second textfiled where translation for NAT/WAN
zones happens and so there is and never was a reason to *edit* a
zone file

it is created from scratch when changes in a zone happen and cronjobs
only pull zones with the "updated-field" set to 1

that infrastructure provides a stable API for mailserver and other
backends and at the end the realted zone is created from scratch

only the fact having a 1:1 NAT and only edit records once to feed
internal and external nameservers with one action and the fact you
can change global properties like TTL if not overriden per domain
and change A-records in any zone base on our own domain working
like a CNAME but still be an A record justifies that

6 years for some hundret domains as auth nameserver proves me right

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 246 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140731/3a22c622/attachment.bin>