php-library added -> Re: rndc (and now nsupdate too)

Sat Aug 2 00:39:29 UTC 2014

> 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
____________________________________________________________________________

'dns_zones' is the only relevant data for the cronjobs
on the nameservers and contains for the two LAN servers
the complete zone-files in 'zone_content_lan' and for
the external 'zone_content'

the goal here was keep the cronjobs as dumb as possible
they don't need access to the records-table and even not
the library with the DNS details, they only need to
know if and which zone-content to fetch, write out to the
zone file, keep the zone-list in "named.conf" recent and
reload named in case of changes

these zone records are created with the data in 'dns_entries'
combined with global defaults applying to all zones, that way
you can prepare ip-changes by lower the TTL in a config file
and force re-creation of all zones and later raise the TTL

basicly 'zone_content' is generated and a static replacement
array from the config translates WAN IP's to internal ones
since the cisco router don't like access with public IP's
from inside or if DNS ALG is active it mangeles DNS traffic
____________________________________________________________________________

'dns_entrys': well, thats the data you work with in the
webinterface and each change re-creates the zone in the
database, at that time not touching BIND at all
____________________________________________________________________________

CREATE TABLE `dns_meta` (
  `prikey` smallint(4) unsigned NOT NULL AUTO_INCREMENT,
  `changes_master` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `changes_slave` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `gui_lock` tinyint(1) unsigned NOT NULL DEFAULT '0',
  PRIMARY KEY (`prikey`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci ROW_FORMAT=COMPRESSED;

CREATE TABLE `dns_zones` (
  `zone_id` mediumint(6) unsigned NOT NULL AUTO_INCREMENT,
  `zone_name` varchar(255) COLLATE latin1_german1_ci NOT NULL,
  `zone_content` text COLLATE latin1_german1_ci NOT NULL,
  `zone_content_lan` text COLLATE latin1_german1_ci NOT NULL,
  `zone_new_master` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `zone_new_slave` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `zone_serial` varchar(100) COLLATE latin1_german1_ci NOT NULL,
  `zone_spf_strict` tinyint(1) unsigned NOT NULL,
  `zone_client_id` smallint(4) unsigned NOT NULL,
  `zone_ttl` mediumint(6) unsigned NOT NULL,
  PRIMARY KEY (`zone_id`),
  UNIQUE KEY `zone_name` (`zone_name`),
  KEY `cron_idx` (`zone_new_master`,`zone_new_slave`),
  KEY `zone_client_id` (`zone_client_id`),
  KEY `zone_serial` (`zone_serial`),
  KEY `zone_id` (`zone_id`,`zone_serial`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci ROW_FORMAT=COMPRESSED;

CREATE TABLE `dns_entrys` (
  `entry_id` mediumint(6) unsigned NOT NULL AUTO_INCREMENT,
  `entry_zone_id` mediumint(6) unsigned NOT NULL DEFAULT '0',
  `entry_zone_cleartext` varchar(255) COLLATE latin1_german1_ci NOT NULL,
  `entry_type` varchar(255) COLLATE latin1_german1_ci NOT NULL,
  `entry_name` varchar(255) COLLATE latin1_german1_ci NOT NULL,
  `entry_value` varchar(255) COLLATE latin1_german1_ci NOT NULL,
  `entry_comment` varchar(255) COLLATE latin1_german1_ci NOT NULL,
  `entry_mac` varchar(18) COLLATE latin1_german1_ci NOT NULL,
  PRIMARY KEY (`entry_id`),
  KEY `entry_zone_id` (`entry_zone_id`),
  KEY `zone_type_idx` (`entry_zone_cleartext`,`entry_type`),
  KEY `entry_type` (`entry_type`,`entry_value`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci ROW_FORMAT=COMPRESSED;

Am 01.08.2014 um 18:34 schrieb Victoria Risk:
> 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 <dot at dotat.at> wrote:
> 
>> Mike Hoskins (michoski) <michoski at cisco.com> wrote:
>>> Tony Finch <dot at dotat.at> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: library.tar.bz2
Type: application/x-bzip
Size: 11501 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20140802/f625491a/attachment-0002.bin>
-------------- 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/20140802/f625491a/attachment-0003.bin>