Journal of Internet Disasters

Sat Nov 14 17:23:58 UTC 1998

> >other servers are more conservative, and had switched to manual daily FTP
> >of the COM zone longer ago than F has done.  (with manual daily FTP you
> >get the advantages of gzip, and of the pretense of "zone master" status
> >while you manually retry after timeouts.  AXFR needs those properties.)
> 
> wouldn't a new transfer type (AZFR/IZFR) be useful here, being basically
> AXFR/IXFR but piped through gzip on each end?
> 
> These would need to be negotiated (based onversion number) of course,
> but would help a lot with large zones like COM...

i've been working on something called ZXFR for 8.1.2++.  my concern is that
i don't want to standardize on gzip, but neither do i want to negotiate a
compression method and go through a full ietf turn to get it all approved,
and finally neither do i wish to just allocate my own type code and make this
a bind-only thing and write an FYI RFC on it.  greatest likelihood is that
i'll have a conscience attack and remove all the temporary ZXFR logic.

therefore i'm trying to externalize it, i.e.,

	zone "com" {
		type slave;
		trigger {
			on soa-change;
			cmd "lynx -batch ftp://.../com.zone.gz > com.zone.gz";
		};
		load "gzcat com.zone.gz";
	};

in this design, the old

	zone "com" {
		type slave;
		file "com.zone";
	};

syntax is grandfathered as syntactic sugar on top of

	zone "com" {
		type slave;
		trigger {
			on soa-change;
			cmd "named-xfer ... > com.zone";
		};
		load "cat com.zone";
	};

actually i'd probably nuke named-xfer in favour of dig but you get the idea.
(of course there are other triggers, like "on load", "on reload", "on boot",
"on expiry" and so on.)