Re: Journal of Internet Disasters
-----Original Message----- From: Paul Vixie <paul@vix.com> To: nanog@merit.edu <nanog@merit.edu> Date: Saturday, November 14, 1998 1:12 AM Subject: Re: Journal of Internet Disasters [...]
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...
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.)
On Sat, 14 Nov 1998, Paul A Vixie wrote:
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"; };
That would be an excellent idea, and could be useful for lots of things. Where do I sign up? :-) /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell (800) 299-1288 v CTO (925) 377-1212 v NameSecure (925) 377-1414 f Coming to the ISPF-II? The Forum for ISPs by ISPs http://www.ispf.com \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Two warnings: 1. this is about name server operations not router operations. 2. there is a shameless plea for money at the end. Hit "D" now.
zone "com" { type slave; trigger { on soa-change; cmd "lynx -batch ftp://.../com.zone.gz > com.zone.gz"; }; load "gzcat com.zone.gz"; };
That would be an excellent idea, and could be useful for lots of things.
It's already drifted a bit. Probably shape is now: zone "com" { type slave; fetch "dig @198.41.0.4 com axfr"; load "cat"; file "com.zone"; }; This leaves named in charge of choosing temporary file names, renaming them, and so on. The above "fetch" and "load" would be implied if they were missing but "masters { 198.41.0.4; };" were specified. Probably that means "fetch" has to be a list of commands rather than a single one (sigh). The earlier example becomes: zone "com" { type slave; fetch "lynx -batch ftp://.../com.zone.gz"; load "gzcat"; file "com.zone"; }; As for triggers, they're useful but probably will come later. Note that "dig" puts the trailing SOA into its AXFR output, so named's loader will have to learn how to ignore it. I'm looking forward to removing all evidence of named-xfer from the BIND source pool. (Bleah.)
Where do I sign up? :-)
Come with PO# in hand to drc@isc.org and ask for a BIND support contract. (We both know that ISC will answer support questions whether someone pays for it or not, but paying us does in fact move you to the front of the queue.)
participants (3)
-
Mathias Koerber -
Patrick Greenwell -
Paul A Vixie