On 30 jun 2009, at 16.43, Mark Andrews wrote:
This is simultaneous roll of KSK and ZSK keys. You introduce
the keys the *same* way as you would with a single operator.
The new operator generates new keys. The are added to the
existing DNSKEY RRset and the resulting RRset is signed by
all the KSKs (old and new). DS are added to the parent for
then new KSKs. Wait for the pre-change DS and DNSKEYs to
expire from caches. You use the new ZSK keys to sign the
zone content. If you are changing servers as well you make
the the old servers serve the new zone content. Once all
the old zone content has timed out of caches you remove the
old keys. If you changed servers this is the time to
decommision the zone on the old servers.
I do not think this will work, as I do not think the old zone
maintainer have interest in cooperating. He is hopefully continuing to
host the old version of the zone for a while, and the question is what
happens in the overlap, whether the content of the parent zone helps
etc.
I think we have the following states, but first background.
We have the registry, that is the zone maintainer of the parent zone.
We have a registrar that only do things "on behalf of the registrant".
The registrant changes zone maintainer, from A to B. There is no
cooperation between them, and the change from A to B implies both NS,
KSK and ZSK changes. We have NSA, NSB, KSKA, KSKB, ZSKA and ZSKB.
Once again, A is not cooperating.
Question is now, what should B do to make the change from A to B as
smooth as possible?
On NSA we have the "old zone" that contain part from the records also
ZSKA and KSKA, and the zone is signed with ZSKA.
On NSB we have the ability to place "the old zone", but we can only
sign with ZSKB.
In the parent zone, we can add DS for KSKB without removing DS for KSKA.
We of course have TTLs and a mix of cached and non-cached records all
over the place.
Now...
I was hoping that by adding the DS for KSKB to the parent, and having
B signing the old zone with ZSKB, that would minimize the blackout.
NSA is removed from the parent zone, and from that point in time, only
caches have the info that NSA exists, so only from caches you will
find NSA.
After a while, the old NS records (NSA) will have timed out, and only
actual content (including KSKA and ZSKA and SIG etc) will be cached
here and there.
Queries that hit the parent in the meantime will see DS for both KSKA
and KSKB, but only NS that refer to the nameservers that B run, and
there you find a zone only signed with ZSKB. No signatures made with
ZSKA.
Queries that hit NSA will find data only signed with ZSKA, while DS in
parent exists for both KSKA and KSKB (if re-fetched).
After all data has timed out from the old zone (including old sig's
made with ZSKA), one can remove KSKA and ZSKA from zone, and remove DS
referring to KSKA from parent.
I.e. I thought that as long as one of the DS in the parent zone refer
to a KSK that in turn sign a ZSK that sign the zone, things will be
fine. So by having DS referring to both old and new KSK, we will be
ok, although only one of the trust chains will exist at each point in
time (for each validating client).
Now, there might be cases when partial data is fetched from NSA and
NSB, but how bad can it get, as signatures comes with the record, and
the signatures are related to either ZSKA or ZSKB? If ZSK-material is
fetched from NSA, while KSK data is fetched form NSB? Then of course
there is no chain of trust.
But what is the risk for that? And to be honest, I do not see any way
out of this, without cooperation from both NSA and NSB.
Patrik
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
