North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Journal of Internet Disasters

  • From: Paul A Vixie
  • Date: Mon Nov 16 13:57:32 1998

Two warnings:

1. this is about name server operations not router operations.
2. there is a shameless plea for money at the end.

Hit "D" now.

> > 	zone "com" {
> > 		type slave;
> > 		trigger {
> > 			on soa-change;
> > 			cmd "lynx -batch ftp://.../com.zone.gz > com.zone.gz";
> > 		};
> > 		load "gzcat com.zone.gz";
> > 	};
> 
> That would be an excellent idea, and could be useful for lots of things.

It's already drifted a bit.  Probably shape is now:

	zone "com" {
		type slave;
		fetch "dig @198.41.0.4 com axfr";
		load "cat";
		file "com.zone";
	};

This leaves named in charge of choosing temporary file names, renaming them,
and so on.  The above "fetch" and "load" would be implied if they were missing
but "masters { 198.41.0.4; };" were specified.  Probably that means "fetch"
has to be a list of commands rather than a single one (sigh).

The earlier example becomes:

	zone "com" {
		type slave;
		fetch "lynx -batch ftp://.../com.zone.gz";;
		load "gzcat";
		file "com.zone";
	};

As for triggers, they're useful but probably will come later.

Note that "dig" puts the trailing SOA into its AXFR output, so named's loader
will have to learn how to ignore it.  I'm looking forward to removing all
evidence of named-xfer from the BIND source pool.  (Bleah.)

> Where do I sign up? :-)

Come with PO# in hand to [email protected] and ask for a BIND support contract.
(We both know that ISC will answer support questions whether someone pays for
it or not, but paying us does in fact move you to the front of the queue.)