Re: rndc (and now nsupdate too)
Am 31.07.2014 21:08, schrieb /dev/rob0: The proper tool to manage named configuration and operation, and which in the best Unix ethic is well suited for automation, is rndc(8). You can not always use rndc. For example you can add and delete zones, but you can not modify zones via rndc. regards Klaus ___ 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
Re: php-library added -> Re: rndc (and now nsupdate too)
This recent thread, in which people are describing their scripts and GUI provisioning systems makes me think we should recruit a few of you who think you have a sweet provisioning system On 02.08.14 02:39, Reindl Harald wrote: at least i add the library i developed to maintain zone-files which needs translation of the comments, to be cleaned from some hacks depending on our domain and a replaced database layer which i can't publish I quite like MyDNS database format, although I did want to enhance it with RR's activiry range (start-end SOA, nice for iXFR) and things like foreign keys... unfortunately MyDNS-ng author changed it a bif different than I thought of. Also, I like PostgreSQL "inet" type , which I'd like to use for PTR and A/. Good API would be perfect for generating DNS records out of different systems for e.g. IP reservation or mail configuration... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. A day without sunshine is like, night. ___ 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
php-library added -> Re: rndc (and now nsupdate too)
> This recent thread, in which people are describing their scripts and > GUI provisioning systems makes me think we should recruit a few of > you who think you have a sweet provisioning system at least i add the library i developed to maintain zone-files which needs translation of the comments, to be cleaned from some hacks depending on our domain and a replaced database layer which i can't publish watch for '$this->db' and $GLOBALS['cl_api']->log() using a global log-api from the CMS-system wrapped around it feel free to use the code for whatever you want, adopt it, laugh about it, delete it :-) sorry no way to make the GUI parts public they are hard wired with internal CMS software and libs i fear the "it seems that no one with an adequate understanding of BIND has written and released a good management frontend" comes because they which did wrapped it around existing infrastructure and can't make it public nor is it written in a generic way then there comes the security point of view - keep the code tiny and only support what you really need avoids a lot of complexity leading in questionable security decisions but makes it also less useable for other environments at least i post the table-structure below and maybe give some ideas helping others, 6 years production and survive a global IP change on the network showed the ideas working great surely, if you have thounds of really large zones it may not scale that perfect, not the case here, up to 1000 zones a no-brainer my development as example started because there is no software out there which supports the grade of automatism i wanted while they make no sense in a different environment and it was developed after FTP/Apache/Asterisk backends all using a inhouse framework startet 2003 and extended with dns functionality 2008 one of the primary design decisions was to also generate PTR-records and feed pseudo-static DHCP ranges by add the MAC to a name/ip-pair and generate the dhcpd.conf with that which gone that far to discover the network with arp commands and add the MAC to the existing A-records made by hand, new machine: change that MAC field and there things start to get "hackish", "thelounge.net" itself has the complete structure seperated and needs to be maintained twice and only the internal cronjobs care about MAC/DHCP on the other hand the basic tool to generate complete zone files out of a single table and write them in the "zone-table" was AFIR written in one night (followed by fine-tuning and extended with special record-types like TXT/SPF and zone delegation on-demand) later automatic generation of SPF records where added if there is a MX pointing to a machine inside our own domain or create or "v=spf1 -all" if there is no MX, special handling of subdomains with MX records if they point inside our domain and skip them if point outside the next thing which is "hackish" -> maintain email-autodiscovery with means DNS records as well as a apache-vhost, if you want to have all that features most working fully automated and just send cron-mails in the style of "i did this and that, below the diff of the config" you need to design much more carefully and invest a lot of more work by carry repsonsiblity in case of changes after you publish it and 3rd parties started to rely on not break their setup *that* responsibility makes it so hard to publish backends because you lose the freedom of "we re-design our infrastructure for whatever reason and add as much hacks as needed temporary in the code for automatic transitions and cleanup later frankly you can test that stuff by make a DB dump, stop the cronjobs while play around with "live-data", re-play whatever you plan and finally -> restore the sql-dump, fire the changes again and start cronjobs "named.conf" is a mix of "template" for most configurations and contains a [panel_records] line which finally is replaced by all the zones to load and if they are slave/master that template exists 4 times LAN master LAN slave WAN master WAN slave the configuration of the cronjob also needs to exist 4 times since it must define master/slave and in case of slave who is the master that's perfect as it is, but makes it less generic for other environments, here the appeal is you can practically write any option you need in the configuration without refelect it in the admin-backend, the webinterface is only used for create a new zone with the most used default records and magage records 'dns_meta': the 'changes'-fields are first fetched by the cronjobs and if the are 0 nothing else is done, 'gui_lock' is set to 1 by start apply changes so if two people work at the same time in a backend (two admins here) no collisions ___
Re: rndc (and now nsupdate too)
This recent thread, in which people are describing their scripts and GUI provisioning systems makes me think we should recruit a few of you who think you have a sweet provisioning system, to do a WebEX and describe it for everyone else who is looking for a better system. At the RIPE meeting in Poland I saw a GUI front end for updating resource records that a French university network team had created and a very impressive system using Ansible to rapidly transform a NSD auth server into a BIND auth server and back again (including translating zone files). There are a number of tools and cookbooks out there, if the tool you use is not one you developed, but it is public domain, open source or otherwise freely available and you think it is really helpful, it would be useful for others to hear about that too. If you have a reasonably full-featured, effective, free provisioning system that could be shared and successfully used in another environment, and you are willing to do a presentation on it (perhaps share an hour slot with one other person), please email me unicast. If we get any volunteers, we’ll schedule something and advertise it back here on bind-users. Vicky Product Manager, isc.org On Aug 1, 2014, at 9:09 AM, Tony Finch wrote: > Mike Hoskins (michoski) wrote: >> Tony Finch wrote: >>> >>> In our setup, changes made in the database are turned into an nsupdate >>> script, so we don't need to bounce the name server and we can use >>> BIND's automatic signing. >> >> no argument on nsupdate, but even if you copy files around...you don't >> need to bounce the nameserver, unless rndc reload is what you mean (when i >> hear bounce i think stop/start). > > Sorry, I was being imprecise. When I said "bounce" I meant any kind of > config change action that makes named do more work than is necessary to > change the contents of the zone. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > FitzRoy: Westerly or southwesterly veering northwesterly, 4 or 5, increasing 6 > or 7 for a time in east. Slight or moderate, becoming moderate or rough in > east. Rain or thundery showers. Good, occasionally poor. > ___ > 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 ___ 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
Re: rndc (and now nsupdate too)
Mike Hoskins (michoski) wrote: > Tony Finch wrote: > > > >In our setup, changes made in the database are turned into an nsupdate > >script, so we don't need to bounce the name server and we can use > >BIND's automatic signing. > > no argument on nsupdate, but even if you copy files around...you don't > need to bounce the nameserver, unless rndc reload is what you mean (when i > hear bounce i think stop/start). Sorry, I was being imprecise. When I said "bounce" I meant any kind of config change action that makes named do more work than is necessary to change the contents of the zone. Tony. -- f.anthony.n.finchhttp://dotat.at/ FitzRoy: Westerly or southwesterly veering northwesterly, 4 or 5, increasing 6 or 7 for a time in east. Slight or moderate, becoming moderate or rough in east. Rain or thundery showers. Good, occasionally poor. ___ 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
Re: rndc (and now nsupdate too)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, On 01.08.14 15:58 Reindl Harald wrote: > the whole discussion about rndc or not rndc follow up therads and > side-threads startet after that reply below from me yesterday and > whoever brought "bounce" in the game did also not understand the > context of the discussion Calm down, everyone. Please. I did not intend to start a thread that long and, uhm, intense... My (simplified) conclusion: In most setups, using rndc is the right way, because most people do not know its advantages or the disadvantages of killing the daemon. But there is a german saying "Ausnahmen bestätigen die Regel", which could be translated as 'exceptions prove the rule'. So, those (exceptions) who really do know what they are doing can workaround rndc. Regards, Johannes - -- Multiple exclamation marks are a sure sign of diseased mind. (Terry Pratchett) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/ iEYEARECAAYFAlPbpn0ACgkQzi3gQ/xETbK4qACeLHAGdp/yPjidlOHlMHpO+gw9 HjIAoIyYpqXq4MOuNCu6OkpHuvWbsFwL =FrGZ -END PGP 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
Re: rndc (and now nsupdate too)
Am 01.08.2014 um 15:44 schrieb Mike Hoskins (michoski): >>> no argument on nsupdate, but even if you copy files around...you don't >>> need to bounce the nameserver, unless rndc reload is what you mean >>> (when i >>> hear bounce i think stop/start) >> >> since when is -SIGHUP stop/start? > > i suspect a language barrier, since if you read what i typed i never said > that. in fact, i'm not sure you read what Tony typed either. > > "bouncing a daemon" often means stop/start. whether you rndc reload or > HUP, such a restart is not needed on zone changes. my entire point is > that a costly full restart is not needed, even without nsupdate. > > i'm sure Tony knows this, and simply wanted to clarify for posterity in > the thread archive. no it is *not* a language barrier you are simply missing the context the whole discussion about rndc or not rndc follow up therads and side-threads startet after that reply below from me yesterday and whoever brought "bounce" in the game did also not understand the context of the discussion all the threads about "rndc" refer to that below! Weitergeleitete Nachricht Betreff: Re: rndc (and now nsupdate too) Datum: Thu, 31 Jul 2014 14:08:48 -0500 Von: /dev/rob0 Antwort an: bind-users@lists.isc.org Organisation: RTFM An: bind-users@lists.isc.org 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 Weitergeleitete Nachricht Betreff: Re: Reload BIND to listen on additional interface? Datum: Thu, 31 Jul 2014 13:32:03 +0200 Von: Reindl Harald An: bind-users@lists.isc.org Am 31.07.2014 um 13:24 schrieb Johannes Kastl: > in the quest to use a master behind a Router with changing IPs, I set > up a VPN and told bind on both sides to listen on the additional VPN-IPs. > > But, sometimes they are not available at bind startup or the VPN loses > connection. So, when the VPN connection is ready again, I can let > OpenVPN run a script. My idea was to use this script to tell bind, > that it can now bind to the interface again. > > Question now is, which (rndc) command does that? Does a ârndc > reconfigâ tell BIND to newly bind to the interfaces? 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 pretty sure it will also force look for new interfaces or gone ones [root@srv-rhsoft:~]$ tail named.log #31-Jul-2014 13:30:05.016 general: automatic empty zone: D.F.IP6.ARPA 31-Jul-2014 13:30:05.016 general: automatic empty zone: 8.E.F.IP6.ARPA 31-Jul-2014 13:30:05.016 general: automatic empty zone: 9.E.F.IP6.ARPA 31-Jul-2014 13:30:05.016 general: automatic empty zone: A.E.F.IP6.ARPA 31-Jul-2014 13:30:05.016 general: automatic empty zone: B.E.F.IP6.ARPA 31-Jul-2014 13:30:05.016 general: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA 31-Jul-2014 13:30:05.037 general: reloading configuration succeeded 31-Jul-2014 13:30:05.039 general: reloading zones succeeded 31-Jul-2014 13:30:05.057 general: all zones loaded 31-Jul-2014 13:30:05.057 general: running [root@srv-rhsoft:~]$ killall -HUP named [root@srv-rhsoft:~]$ tail named.log 31-Jul-2014 13:30:26.443 general: automatic empty zone: D.F.IP6.ARPA 31-Jul-2014 13:30:26.443 general: automatic empty zone: 8.E.F.IP6.ARPA 31-Jul-2014 13:30:26.443 general: automatic empty zone: 9.E.F.IP6.ARPA 31-Jul-2014 13:30:26.443 general: automatic empty zone: A.E.F.IP6.ARPA 31-Jul-2014 13:30:26.443 general: automatic empty zone: B.E.F.IP6.ARPA 31-Jul-2014 13:30:26.443 general: automatic empty zone: 8.B.D.0.1.0.0.2.IP6.ARPA 31-Jul-2014 13:30:26.446 general: reloading configuration succeeded 31-Jul-2014 13:30:26.447 general: reloading zones succeeded 31-Jul-2014 13:30:26.464 general: all zones loaded 31-Jul-2014 13:30:26.464 general: running 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
Re: rndc (and now nsupdate too)
-Original Message- From: Reindl Harald Organization: the lounge interactive design Date: Friday, August 1, 2014 at 9:23 AM To: "bind-users@lists.isc.org" Subject: Re: rndc (and now nsupdate too) > >Am 01.08.2014 um 15:14 schrieb Mike Hoskins (michoski): >> From: Tony Finch >> Date: Friday, August 1, 2014 at 5:31 AM >> To: Reindl Harald >> Cc: "bind-users@lists.isc.org" >> Subject: Re: rndc (and now nsupdate too) >> >>> Reindl Harald wrote: >>>> Am 31.07.2014 um 21:08 schrieb /dev/rob0: >>>>> >>>>> The proper tool to manage zone data is nsupdate(8). Likewise well >>>>> suited for automation. >>>> >>>> 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 >>> >>> In our setup, changes made in the database are turned into an nsupdate >>> script, so we don't need to bounce the name server and we can use >>> BIND's automatic signing. >> >> no argument on nsupdate, but even if you copy files around...you don't >> need to bounce the nameserver, unless rndc reload is what you mean >>(when i >> hear bounce i think stop/start) > >since when is -SIGHUP stop/start? i suspect a language barrier, since if you read what i typed i never said that. in fact, i'm not sure you read what Tony typed either. "bouncing a daemon" often means stop/start. whether you rndc reload or HUP, such a restart is not needed on zone changes. my entire point is that a costly full restart is not needed, even without nsupdate. i'm sure Tony knows this, and simply wanted to clarify for posterity in the thread archive. ___ 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
Re: rndc (and now nsupdate too)
Am 01.08.2014 um 15:14 schrieb Mike Hoskins (michoski): > From: Tony Finch > Date: Friday, August 1, 2014 at 5:31 AM > To: Reindl Harald > Cc: "bind-users@lists.isc.org" > Subject: Re: rndc (and now nsupdate too) > >> Reindl Harald wrote: >>> Am 31.07.2014 um 21:08 schrieb /dev/rob0: >>>> >>>> The proper tool to manage zone data is nsupdate(8). Likewise well >>>> suited for automation. >>> >>> 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 >> >> In our setup, changes made in the database are turned into an nsupdate >> script, so we don't need to bounce the name server and we can use >> BIND's automatic signing. > > no argument on nsupdate, but even if you copy files around...you don't > need to bounce the nameserver, unless rndc reload is what you mean (when i > hear bounce i think stop/start) since when is -SIGHUP stop/start? http://en.wikipedia.org/wiki/Unix_signal SIGHUP Many daemons will reload their configuration files and reopen their logfiles instead of exiting when receiving this signal.[4] nohup is a command to make a command ignore the signal. [root@srv-rhsoft:~]$ killall -SIGHUP named [root@srv-rhsoft:~]$ cat named.log 01-Aug-2014 15:21:01.598 general: received SIGHUP signal to reload zones 01-Aug-2014 15:21:01.598 general: loading configuration from '/etc/named.conf' 01-Aug-2014 15:21:01.599 general: using default UDP/IPv4 port range: [1024, 65535] 01-Aug-2014 15:21:01.599 general: using default UDP/IPv6 port range: [1024, 65535] 01-Aug-2014 15:21:01.599 network: no IPv6 interfaces found 01-Aug-2014 15:21:01.613 general: sizing zone task pool based on 9 zones 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
Re: rndc (and now nsupdate too)
-Original Message- From: Tony Finch Date: Friday, August 1, 2014 at 5:31 AM To: Reindl Harald Cc: "bind-users@lists.isc.org" Subject: Re: rndc (and now nsupdate too) >Reindl Harald wrote: >> Am 31.07.2014 um 21:08 schrieb /dev/rob0: >> > >> > The proper tool to manage zone data is nsupdate(8). Likewise well >> > suited for automation. >> >> 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 > >In our setup, changes made in the database are turned into an nsupdate >script, so we don't need to bounce the name server and we can use >BIND's automatic signing. no argument on nsupdate, but even if you copy files around...you don't need to bounce the nameserver, unless rndc reload is what you mean (when i hear bounce i think stop/start). ___ 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
Re: rndc (and now nsupdate too)
Reindl Harald wrote: > Am 31.07.2014 um 21:08 schrieb /dev/rob0: > > > > The proper tool to manage zone data is nsupdate(8). Likewise well > > suited for automation. > > 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 In our setup, changes made in the database are turned into an nsupdate script, so we don't need to bounce the name server and we can use BIND's automatic signing. Tony. -- f.anthony.n.finchhttp://dotat.at/ Sole: Southwest 3 or 4 veering northwest 5 or 6. Slight or moderate, becoming moderate or rough in west. Rain or showers. Moderate or good. ___ 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
Re: rndc (and now nsupdate too)
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
Re: rndc (and now nsupdate too)
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
Re: rndc (and now nsupdate too)
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. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ 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
