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