ttl problems in DNSSEC

[Miek Gieben <miekg@nlnetlabs.nl>]

Hi,

After a little get together a RIPE, we have the following question:

Notation is used as specified in draft-resolver-rollover-dnsopt-ietf-00.txt
(will probably be on ietf.org today, K++1 means key with key-id 1,
S++1(A) means the sig with K++1 over record set A)

In rfc2335, section 3.5 it states that KEY should be included in the
additional section. So they won't always be there.

Consider a local nameserver on a LAN. The LAN is connected to the
outside by two caching forwarders on a DMZ, both do DNSSEC and cache,
but are of different implementation.  The forwarders do loadsharing.
And suppose there is a zone on the Net with the following content:
(the numbers indicate the TTL's)

        A       10
        S++1(A) 10
        K++1    20

The local nameserver on the LAN makes a query for the A record of the
zone. This query is handled by DMZ1, after this query the caches are
as follows:

local           DMZ1            DMZ2
A       10      A       10      <empty>
S++1(A) 10      S++1(A) 10
K++1    20      K++1    20

After 11 seconds the zone on the Net decides to use a new key (K++2)
for their zone:
        A       10
        S++2(A) 10
        K++2    20

The caches on the LAN will drop the RR with the TTL of 10:
local           DMZ1            DMZ2
K++1    20      K++1    20      <empty>

Next there is a new query to the local nameserver for the A record,
this request is handled by DMZ2! This time the KEY isn't included in
the respons (this DMZ2 does not implement the SHOULD). So the local
nameserver doesn't get the new key (K++2).

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?

regards,
Miek Gieben
Olaf Kolkman
Stephan Jager