[21435] in North American Network Operators' Group
Re: Journal of Internet Disasters
daemon@ATHENA.MIT.EDU (Paul A Vixie)
Sat Nov 14 12:42:53 1998
To: nanog@merit.edu
In-reply-to: Your message of "Sat, 14 Nov 1998 08:17:13 +0800."
<055001be0f64$221377c0$f4db7fcb@dean.koerber.org>
Date: Sat, 14 Nov 1998 09:23:58 -0800
From: 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.)
