Subject: Re: secondary behavior with DNSSEC

From: [email-masked] (Ted Lindgreen)
Date: Thu, 20 Mar 2003 13:42:59 +0100

[Quoting Peter Koch, on Mar 20, 13:28, in "Re: secondary behavi ..."]

> > - suppose you re-sign the zone every X seconds
> > - and the lifetime of the signatures is Y seconds
> > then the expire value should be less or equal to Y-X.
> 
> Shouldn't that just be expire <= Y? If you (plan to) re-sign in 5 days,
> the lifetime is 7 days why should expire be 2 days only?

OK, let's just write it out:
With expire = Y:
 Suppose the last successful AXFR was on day 4. Then on day 7 the
 SIGs expire. From day 8 until day 12 the zone remains valid.

With expire = Y-X:
 Last successful AXFR was on day 4.
 On day 7 both SIGs expire and zone has turned invalid.

> In the general case, expire values should not shrink too much to avoid
> problems caused by unreachable masters, syntax errors in zone files etc.
> 
> > This way, the out-dated secondary would return "SERVFAIL" instead
> 
> This should also be documented, because 1034 and friends do not explicitly
> state what a server should do after the zone has expired. Nameservers
> have behaved differently in the past and SERVFAIL is not necessarily the
> best reaction from an operational perspective - e.g. if you face a "perfectly
> lame" delegation

I agree with the rest,
-- ted
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Peter Koch <[email-masked]>
Date: Thu, 20 Mar 2003 14:20:37 +0100

>  SIGs expire. From day 8 until day 12 the zone remains valid.

suppose last successful SOA check was on day 1. SIGs expire on day 7, zone
expires on day 8. That gives you 6 days to detect and fix the problem.

>  On day 7 both SIGs expire and zone has turned invalid.

That has zone already expired on day six.
With the new values, the zone expires on day three (1 + (7 - 5)).

So, you pay a rather high price to avoid handing out stale data (expired
signatures) from a server which may have a *temporary* problem.
What is worse (and for whom): expired SIGnatures (on old data) or an
expired zone? Since one of the primary reasons for zone expiration I've seen
is that someone introduced a syntax error at the primary master causing
that server to go non-authoritative (a BINDism, I must admit), I'd rather
have a longer window for problem detection at the risk of handing out
expired SIGs at a later point in time. Losing all secondaries at once is
tough.

At least, something needs to be said about the relation of X and Y.

-Peter

---

From: Rob Austein <[email-masked]>
Date: Thu, 20 Mar 2003 16:08:12 -0800

I agree that we need to give more thought to how sig expirations
interact with the several SOA timing parameters.  A short zone refresh
time isn't a problem per se when the network is healthy, since
resetting the zone expiration timer is a two-packet exchange under
ideal conditions when the zone hasn't changed.  So the tradeoff is
between data availability and verifiability (is that a word?  probably
shouldn't be...) when the refresh cycle isn't completing, and the
zone's expected churn rate may also be a factor.

Since the resolver's decision about what to do when sig validation
fails is ultimately a "local policy" issue, one can make a case either
way on how the zone should be configured to make the end users least
unhappy, depending on what one thinks the local policy might be.

Or perhaps I just need more coffee, or beer -- it is getting towards
the end of an IETF week....
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 21 Mar 2003 02:00:03 +0100

Is it way out of line to have the zone expire if one of the SIGs over
the SOA expires?

Seems like a reasonable thing to do. 

--Olaf

---

From: Rob Austein <[email-masked]>
Date: Thu, 20 Mar 2003 17:10:39 -0800

> Seems like a reasonable thing to do. 

Bit of a layering violation, isn't it?  I'd prefer just to advise the
zone admin as best we can on how to set the knobs we already have.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.