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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
