Subject: [dnsext] Timing down a zone

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Nov 2008 08:14:23 -0600

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Thu, 20 Nov 2008 14:41:10 +0000

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Nov 2008 08:58:52 -0600

Zone expiry has nothing to do with DNSSEC.

The problem ought to be solved for the pre-DNSSEC case (backward 
compatibility if you will) and make sure it works with DNSSEC added 
(future proofing).

It's not lunch time here in Minnesota.

---

From: [email-masked]
Date: Thu, 20 Nov 2008 15:47:29 +0000

so ... there is a nomenclature problem.  "we" are not expiring the
 zone - we are trying to find a way to signal to the DNS that the
 crypt signature expiration is at time "foo".  - right?

--bill (its lunch time somewhere)

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Nov 2008 11:13:31 -0600

No, I don't believe so.

We already have a way to indicate signature expiration (in an existing RRSIG).

The problem is a slave re-learning the zone from other slaves and 
thus resetting the (EXPIRE=) time until zone expiry.