Hello,
Presently experimenting with key-rollover scenario's (and timing)
and it seems that both drafts should be somewhat more specific about
which TTL (Mekking), whose (which RRset's) expiration time (Morris),
is actually meant !
To make a long story short :
ZSK rollover timing must take into account max TTL of any *other* then
DNSKEY RRset
in the zone. Details below, example at the end of this email.
ZSK double-sign rollover :
Step 1 : new ZSK, RRSIG's generated with new ZSK added simultaneously to
the zone
Step 2 : old ZSK, RRSIG's generated with old ZSK removed simultaneously
from the zone
The timing between both steps needs to take TTL into account,
as both drafts indicate :
Quoting from draft Mekking :
>>>
The information for Ks must be published long enough to ensure that
the information have reached all validators that may have RRsets from
this zone cached. At the point in time that the DNSKEY RRset
including Ks has been propagated and Ks is said to be Known (Tkno).
---
At the point in time that the other RRsets including signatures of Ks
have been propagated (Tsaf), Ks is said to be Safe.
<<<
Before the "---" (I added) the text refers to the DNSKEY RRset (and its
TTL).
The last line, implicitly refers to TTL of RRSIG's (generated with the new
key),
and that TTL is actually the TTL of the RRset it signs - *not* the TTL of
the DNSKEY !
Quoting from draft Morris :
<<<
TTLsig Time to live of an RRSIG record.
>>>
TTLsig is used in calculating minimum delay,
but to avoid misunderstanding (I misunderstood, but practice thought me
differently)
it could be clarified that the TTL of an RRSIG is actually the TTL of the
RRset it signs.
While the draft of M. Mekking tries to bring more details
in the timelines, some wrong impression can be given.
Extract from the timeline for double-sign :
>>>
Ks | | | | |
- RRSIG | |DcacheZ|----|-------|---
- DNSKEY | |DcacheK|----|-------|---
| | | | |
Tgen Tpub Tkno
Tact Tsaf
<<<
DcacheK includes, in its definition, the TTL of the DNSKEY RRset;
and DcacheZ includes the "TTL" (no further specification).
But the timeline can be misleading by suggesting they are identical,
which they need not be !
Unfortunately including this detail will make the timeline even
more complicated (- sorry, Matthijs, but in the end the effort
should be worthwhile, if people avoid mistakes. Good job !)
As I misinterpreted myself, I stumbled over the scenario with
longer TTLs for eg SOA record (eg 1 week), then for DNSKEY RRset (eg 1
day).
Event 1 : before the start of zsk rollover
A caching name server fetches SOA
--> in the cache : SOA + RRSIG with TTL of 1 week
(old) DNSKEY + RRSIG with TTL of 1 day
Event 2 : ZSK rollover completed in 3 days
--> after the rollover, the old ZSK is no longer published
--> in the cache : SOA + RRSIG with TTL of 1 week - time needed for
this rollover
((old) DNSKEY + its RRSIG have expired from cache)
Now a validating *forwarding* name server addresses this cache
--> it receives : (cached) SOA + (old) RRSIG (no need to refresh, not
expired)
(fresh) (new) ZSK
and *fails* to validate correctly.
Incidentally, the validating caching name server with only
the SOA and the (old) RRSIG in its cache,
still returns answers with AD set
(though it also can no longer fetch the old ZSK for validation).
In my setup, that name server is Bind 9.7.
I assume the result of correct validation is also cached.
Seems OK to me, don't known if this is RFC prescribed or implementation.
Kind regards,
Marc Lampo
Security Officer
EURid
Woluwelaan 150
1831 Diegem - Belgium
[email protected]
http://www.eurid.eu
Want a .eu web address in your own language? Find out how so you dont
miss out!
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
