Re: Journal of Internet Disasters

[Paul A Vixie <paul () vix com>]

> > 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.)