Subject: Re: secondary behavior with DNSSEC

From: [email-masked] (Ted Lindgreen)
Date: Thu, 20 Mar 2003 11:37:57 +0100

[Quoting Miek Gieben, on Mar 20, 11:25, in "secondary behavior w ..."]

> One of the secondaries for the signed .nl zone has not been updated for some
> time now. The signatures it carries are expired on March 10. This means that
> whoever was using this server only gets bad (authoritative) data for .nl.
> If this was for real .nl would have dropped of the earth for all user of this
> nameserver.

A way to prevent this from happening may be to choose
the "expire" time in the SOA more carefully:

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

This way, the out-dated secondary would return "SERVFAIL" instead
of authoritatively returning expired signatures.

In practical values: in the experimental DNSSEC .nl zone we re-sign
daily, the signatures live 7 days, thus the expire time should be 6
days (which is much less than the current actual value of 4 weeks!).

I think this should be documented in a BCP.

-- ted
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Peter Koch <[email-masked]>
Date: Thu, 20 Mar 2003 12:40:04 +0100

> the "expire" time in the SOA more carefully:

Which is the first time we have an upper bound for the expire value.

> 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?

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

-Peter

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Mar 2003 17:19:49 -0800

>the "expire" time in the SOA more carefully:

The zone expiry time should be set to cover the span of time which a 
secondary can reliably serve a zone in the absence of a responsive 
master.

It's fairly obvious that a secondary, in the absence of a responsive 
master, can only operate until the signatures expire.

Problem:  the expiry time is relative to the last time the zone is 
refreshed, the signatures expire at an absolute time.  Hmmm.

Okay, I don't have a quick answer here.  Rats.

But don't link the two clocks together.  Expiry is relative, needs no 
synchronized time source.  Expiration is absolute, needs a 
coordinated time.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer