[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: dnssec@cafax.se
From: Olaf Kolkman <OKolkman@ripe.net>
Date: Wed, 04 Jul 2001 10:18:44 +0200
In-reply-to: Your message of Tue, 03 Jul 2001 17:11:07 EDT. <5.1.0.14.2.20010703170058.02557ec0@localhost>
Sender: owner-dnssec@cafax.se
Subject: Re: ttl problems in DNSSEC


I think I now understand what needs to happen to not have things
break.

Let me redescribe and simplify the problem description. (The example in
our first mail was much to complicated and we made a wrong assumption
while describing it. e.g. we where confused on where things are
cached. Roy pointed out that only authoritative data with may be
cached).

OK here I go.

We start with a verifying resolver(VR) that sits behind a DMZ in which
there is a non dnssec aware caching forwarders (DMZ). An nameserver
(NS) on the net does a rollover.

This is the problem we tried to tackle: Shortly after a rollover the
VR may want to verify data signed with S++2 but is not able to get
K++2 since K++1 sits in the cache of DMZ1.


The numbers indicate the TTLs. VR does not cache since it does not
receive authoritative data.

Before rollover

VR                 DMZ                   NS
K++1               K++1    20            K++1
S++1(A)            S++1(A) 10            S++1(A)

At t=10 the rollover happens and the S++1(A) expires from DMZ's cache.

VR                 DMZ                   NS
--                 K++1   10             K++2
--                                       S++2(A)


If at t=11 VR queries for A and the SIG RRset it will get S++2(A) to
verify the sit it do a query for the Keyset. Since the DMZ still has
K++1 cached VR will not be able to verify S++2(A).

VR                 DMZ	                 NS
S++2(A)            K++1    9             K++2
                   S++2(A) 10            S++2(A)


Now  Olafur Gudmundsson <ogud@ogud.com> wrote:

 * The real problem here is that K++1 was removed before data signed with it
 * expired from caches, this MUST only be done in emergency.
 * In most cases K++1 should remain in the keyset long enough for zone signed
 * by K++2 to propagate to slaves and then time out in caches.

I think that the problem is not that K++1 is removed but that the data
is not signed with S++1.

IMO this is the solution: After the rollover NS MUST sigh the data in
it's zone with both keys for a period that is at least the TTL of the
old key (K++1)

So at t=10 again

VR             DMZ                  NS
--             K++1 10              K++2
--                                  S++1(A)
                                    S++2(A)

If VR queries for A, the SIG RRset and the Key RRset it will get K++1
from the cache and S++1(A) and S++2(A) via the cache from NS and will
be able to verify the data.

So at t=11

VR             DMZ                    NS
K++1           K++1     9             K++2
S++1(A)        S++1(A)  10            S++1(A)
S++2(A)        S++2(A)  10            S++2(A)

Signing with both keys after the rollover is a requirement for
successful rollover of resolvers. 
(draft-ietf-dnsop-resolver-rollover-00.txt)

I'm considering to add this example to that draft. 


-Olaf


PS. If DMZ is a non DNSSEC aware forwarder, VR needs to do 3 queries
for A, KEY and SIG  ... is that true? In all cases?  

Home | Date list | Subject list