Re: ttl problems in DNSSEC

[Miek Gieben <miekg@nlnetlabs.nl>]

[On 28 Jun, 2001, Simon Josefsson wrote in " Re: ttl problems in DNSSEC "]
> Miek Gieben <miekg@nlnetlabs.nl> writes:
> 
> > So the caches become:
> > local           DMZ1            DMZ2
> > K++1    20      K++1    20      A       10
> > S++2(A) 10                      S++2(A) 10
> > A       10                      K++2    20
> > 
> > Now the local nameserver tries to verify the S++2(A) with the K++1,
> > which will not work, thus A is considered BAD. 
> > 
> > What to do about this? Make the SHOULD a MUST in rfc2535? Or discard a
> > KEY whenever you discard the SIG made with that KEY?
> 
> With reservations that I'm not awake yet: If a technical solution [1]
> isn't used, this seem to be something for the BCP: When changing zone
> signing keys, a key-rollover period (larger than any TTL in the zone)
> should be used, where all data is signed by both the old and the new
> key.  If the key was changed because it was compromised, you would
> probably want things to fail.
> 
> In this case DMZ2 would also receive S++1(A), which is possible to
> verify using K++1, and Bob's your uncle.
if there is no technical solution I also think this should be in 
the BCP.

> [1]: perhaps the resolver is able to detect this situation by
> comparing the key tag field on S++2(A) with K++1, and then try get
> more recent data.
then you propose that if data is BAD an extra query for the key most be
done? I'm afraid this will yield too many extra queries...

grtz Miek