Re: [ietf-provreg] Revision of 4310

[Andrew Sullivan <ajs@shinkuro.com>]

On Tue, Jan 26, 2010 at 11:13:44AM -0500, James Gould wrote:

> What is the fundamental difference between a deactivate and a remove?  It
> sounds like exactly the same from a DNS perspective and the TTL.  The
> emergency key rollover use case that you present will be handled exactly the
> same way if the client were to remove the DS from the Registry as opposed to
> deactivating it and than later removing it.  The deactivate from my
> understanding will not remove it from the zone any faster then the existing
> remove.  Please explain the difference.

It's the other way around.  Having a bad key around that you're not
using does no harm.  But _adding_ a key isn't instant either.

If I validate your key, I look up the DS from the parent.  That DS
RRSet ends up cached in the cacheing resolver in front of me.

If you now add a new DNSKEY in an emergency, and stop using your old
key, then the DS that is cached is still the one I use when
validating.

Now, if you have a short TTL on your own DNSKEY record, your old
DNSKEY will expire from my cache quickly.

But AFAIK, no TLD allows clients to set the TTL on RRs in the parent
zone.

That means that the fastest you can roll your key is the maximum TTL
on the DNSKEY or DS records.  So if the parent has long TTLs, you're
stuck with the TTL on the DS record.

Now, if you can add a DS into the parent _before_ you add the DNSKEY
to your zone, then the DNSKEY need not actually be in your zone when
the DS is available in the parent.

Now, some zone operators have said they want to validate that the
DNSKEY is available in the child before publishing the corresponding
DS in the parent.  But if EPP were to offer a mechanism whereby you
could say, "I want you to have this DS record in the DS RRSet, but
_don't_ expect a DNSKEY in the child yet," then the parent would know
not to perform that check when adding the DS record.  (By policy, I
suppose, the "activation" bit could cause the check against the
child.)

So that's the use case.  I don't know how important this is to
operators, however.

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to ietf-provreg-request@cafax.se