[rbldnsd] RFC: Data expire support

[Jeff Chan]

On Monday, December 19, 2005, 1:52:43 AM, Michael Tokarev wrote:
> Well...  A dataset can consists of more than one file (which is
> very handy at times), including local additions (like metadata),
> and including locally-added SOA record (which is normal for
> mirroring a dnsbl locally).

> As I mentioned before, each file in a dataset can have its own
> demands for the expire time (when combining different "kinds"
> of data into one dataset).

> Which 'file update time' you're referring to above?  A smallest
> (ie, 'oldest') in the set (like, locally updated metadata addition)?

> Also, when a file is rsync'ed from remote site, unless you specify
> -t rsync option (everyone should be using it, right?), it will have
> current time as a timestamp, not 'created' time.

> I'm all for using SOA expire field, but there are several problems
> with that, mentioned in my first email...  And the more I think
> about all this, the less chances I see to use "normal" expire time
> from SOA.

All good points, but I would still tend to defer to the original
zone file SOA, assuming there is one.  The expire in principle
should be meaningful and what the authors of the data intend to
be authoritative for the expiration time.

When it's possible to determine a local SOA, then the local SOA
could take precedence.

Jeff C.
-- 
Jeff Chan
mailto:jeffc at surbl.org
http://www.surbl.org/