Re: [dnsext] Timing down a zone

[bmanning@vacation.karoshi.com]

so i guess I am at a loss here.  what does it mean to "expire" a zone?
seems like at least two varients here:

	) the tradtional view - the zone data "goes away"
	) the new view - the sig lifetime timesout 

nd the problem is getting/keeping these two in sync.  Or am I out to
lunch still?

--bill


On Thu, Nov 20, 2008 at 08:14:23AM -0600, Edward Lewis wrote:
> The thread asking for adoption of draft-andrews-dnsext-expire-00.txt 
> has already spun into a thread of ideas.  Separating this off into 
> it's own thread.
> 
> We can't muck with the SOA RR - that would void the DNSSEC RRSIG. 
> More significantly, it constitutes a change to the zone, hence 
> restarting the expiry anyway.
> 
> The trouble with sticking a record in the zone is that the record 
> would either be a statement of absolute time or relative time.  The 
> former is a concept alien to DNS except in DNSSEC and TSIG.  (Adding 
> new concepts into the protocol should not be done lightly.)  The 
> latter would presumably mean we are ticking down a value and 
> rewriting the record - again this is a change to the zone, a new 
> serial number is needed and then a new expiry.
> 
> Note that authoritative servers today are required to only tick down 
> to the expiry, nothing else.  Not the data in the zone.
> 
> Perhaps this is not a real problem.  (Unless the draft has some 
> case.)  Let's say a server is serving serial number 1001 with an 
> expiry of 10000 seconds.  In what way would that expiry ever be 
> restarted?  I really can't think of one - if the server ever sees a 
> NOTIFY or asks for a zone transfer and gets the same serial number 
> (1001), it should be updating or resetting the zone.  I.e., a server 
> ought to "load" a serial number only once ever (module the wrap 
> around thing).
> 
> But if there is a reason why a server could be "tricked into" 
> restarting the expiry timer, I'd look to what else is out there.
> 
> We have a precedent for transferring a timer inspite of not wanting 
> to change the original record in the RRSIG.  The TTL fields are 
> already expected to decline, the RRSIG carries the original one.
> 
> I would suggest that a "remaining until expiry" option be in EDNS0 (a 
> control plane feature in the control plane fields) attached to an XFR 
> request and reply.  That keeps this out of the zone (no serial number 
> change) and let's use avoid the introduction of absolute time outside 
> of the DNSSEC/TSIG areas.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> Never confuse activity with progress.  Activity pays more.
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>