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?