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