Re: ttl problems in DNSSEC

[Simon Josefsson <jas@extundo.com>]

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.

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