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