Metazones or Something Else?

John Anderson johna at ccbill.com
Wed Aug 6 19:39:47 UTC 2014


> 
> Personally I'd like to extend UPDATE
> 
> 	allow-addzone { acl; };	 
> 	allow-delzone { acl; };
> e.g.
> 	nsupdate
> 	new zone
> 	server addresss [port]
> 	key name:secret
> 	[masters <list>]
> 	[allow-query <acl>]
> 	[allow-transfer <acl>]
> 	[allow-update <acl>]
> 	[conf text]
> 	[conf text]
> 	[conf text]
> 	[zone data for master]
> 	send
> 
> 	nsupdate
> 	del zone
> 	key name:secret
> 	send
> 
> Where "new" is a EDNS options which optionally has master addresses / 
> names allow-query is a EDNS acl option of subtype query [default any; 
> if missing] allow-transfer is a EDNS acl option of subtype transfer 
> [default any; if missing] allow-update is a EDNS acl option of subtype 
> update [default none; if missing] conf is a EDNS which contains other 
> configuration data for a zone
> 
> Mark
> 
> In message <20140805164053.GA11778 at fantomas.sk>, Matus UHLAR - fantomas writes:
> > On 05.08.14 11:43, Brian Cuttler wrote:
> > >The slave trusts the master, for zone files, but creating a new 
> > >zone?
> > 
> > hmmm, when a meta-zone is signed by trusted key, why not? :-) using 
> > notifies and IXFR would be even more great...

This looks very interesting, and would likely do the trick.   While waiting to see what is incorporated into named, I'm going to attempt to implement metazone as originally describe by P. Vixie.  We are using NicTool's API to translate SOAP requests into persistent SQL, and then NicTool's scripts will convert the information in the SQL database into named compatible zone files.

I'm going to attach some triggers at the SQL level, so when the API creates a new "zone" entry in the SQL table, that zone entry will get inserted as a record in the "metazone" entry in the SQL tables.    So when the scripts compile the SQL into zone files, a metazone file will be created as Vixie's white-paper describes.   Then I'll likely use a python or perl to convert the information in the metazone to named.conf fragments and HUP named.   The conversion will take place based on inotify events.     So in short, NicTool will convert SQL to named.conf master and zone files.  One of those zone files will be in the metazone format.   NicTool will export these files to the stealth master DNS servers.   Each slave will be manually configured to sync/allow-update of the metazone.  So the metazone information will be transmitted to each slave via DNS IXFR, in-band.  Once the metazone is XFR'd to each slave, and written to disk, an inotify event will trigger a script which will read in the metazone file, and generate stub configuration in something like /etc/named.conf.d/*.conf files, and it will finish by sending a HUP to named.   After reloading, named on the slaves will have knowledge of the new zones created on the masters, and will initiate an AXFR of those zones.

I'll be more than happy to share my work and architecture when I'm done.

John A.


More information about the bind-users mailing list