Re: ttl problems in DNSSEC

[Roy Arends <Roy.Arends@nominum.com>]

On Thu, 28 Jun 2001, Miek Gieben wrote:

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

Hi Miek, Olaf and Stephan.

rfc2535,3.5 says the following

   Security aware DNS servers include KEY RRs as additional information
   in responses, where a KEY is available, in the following cases:

   (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
   name (perhaps just a zone key) SHOULD be included as additional
   information if space is available. If not all additional information
   will fit, type A and AAAA glue RRs have higher priority than KEY   
   RR(s).

If space is available..... Well, with EDNS0, space is available, next to
that, this part mentions SOA/NS.

   (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
   name (usually just a host RR and NOT the zone key (which usually
   would have a different name)) SHOULD be included if space is
   available.
 
This SHOULD refers to "NOT the zone key".

   On inclusion of A or AAAA RRs as additional information,
   the KEY RRset with the same name should also be included but with   
   lower priority than the A or AAAA RRs.
 
This refers to glue.

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

The server implementation is considered BAD if the server tries to verify
a sig with key-id 2 by using a key with key-id 1.

> What to do about this? Make the SHOULD a MUST in rfc2535? 

Which SHOULD ?

> Or discard a KEY whenever you discard the SIG made with that KEY?

Absolutely not. If I would for some reason discard a SIG over a RRset
(might be bad) over some RRset I might still trust a KEY.

In section 4.3 part 2:

     2. In other cases, a security aware resolver SHOULD verify the SIG
        RRs for the RRs of interest.  This may involve initiating
        additional queries for SIG or KEY RRs.........

Or:

When a key is lacking (ttl expired) in the caching resolver, it may query
for it. If the KEY does not exist (not in the zone AND not preconfigured
AND not cached), the SIG is considered BAD.

Conclusion: whenever a SIG is advertised, advertise the KEY in the zone
for the time the SIG is valid.

> regards,
> Miek Gieben
> Olaf Kolkman
> Stephan Jager

Regards,

Roy Arends
Nominum