On Tue, 28 Apr 2009, Antoin Verschuren wrote:
I assume KSK, not ZSK is meant here? I don't think ZSK handovers should
ever be needed (see below)
The gaining registrar adds the losing's registrar's public KSK in their
zone.
(can be done without cooperation). They then add their own KSK and ZSK,
Where do you add these ?
In the gaining DNS-operator's yet unpublished and unvalidated zone, or the
losing DNS-operator's currently published and validated zone (which means
cooperation by the losing registrar).
I meant the gaining dns operator.
Remember: doing the transfer means changing the child zone (the NS set
changes), and thus signing these new records with the currently published and
cached ZSK.
I don't think they need to be signed with the old cached ZSK? Either you have
the data,
and it was validated so you don't re-validate, or you fetch it again. f you
fetch it
again, you either fetch it from the new path of trust (because the parent had
short/sane
TTL's on the NS/DS records, or you fetch it from the old source (due to NS with
long ttl).
In the latter case, you can get data signed with the ols ZSK, since you are at
the
losing dns operator anyway.
Next, the DS has changed, but anything cached and
signed with the old (cached) KSK is still considered valid.
So how would that work if the old key is still cached, and a new record pops up
that is signed with the new key but not with the old one ?
You can only get to those records if you have updated NS/DS records ending up
at the
gaining dns operator. And you would be verifying the NS records at the new dns
operator using the new DS you got, so you can trust that new dnskey.
Or would that be handled by having 2 DS records at the parent ?
Maybe, but right now I can't see the case for two DS records anymore :P
Would a validator go back to the parent to get the new DS record ?
Only if it needs to build a new path of trust. But it either had an old one,
or to get to the NS records i got the new one. Either way the data you
asked for has a trust path?
I would be very interested in this scenario, but I think that while writing it
down you'll see that with current caching behavior, there would always be a
scenario that fails to validate.
DNSKEY and other RR's of the same zone are not always cached with the same TTL.
But if it is cached, it does not need revalidation. If it is not cached, it
follows either the old or the new path of trust, depending on whether the NS/DS
records have expired from the cache?
The case of cached data by long evil TTL's of ZSK's that don't exist
anymore
(or for short ones that don't exist where no maliciousness is involved)
could
be handled by validators by simple removing any signed data from the cache
for
which no valid key (through dnssec validation) can be found and optionally
retry to obtain that data with exponential back off.
So that would mean changing a validator's behaviour from what a resolver is
currently doing...
Looking back, and talking to Wouter, my statement did not make much sense.
Either the data is already validated and cached, or it is not present.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
