Re: Revision of 4310

Andrew,

Ok, so you¹re saying the difference is that the active flag only drives the
server validation of the DNSKEY but the server would still publish it.  The
term active and inactive is sort of misleading in this case.  An ³inactive²
DS (or key) does not exclude the DS from being published in the zone, but
simply removes the validation.  So why would the client ever ³activate² a
DS, if the validation is being done as part of a server policy and the
active flag controls the application of the policy?  The client would most
likely want the server to do what they want and always set the flag to
false.  In either case would a better name of the attribute be ³validate²
instead of ³active²?

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
[email protected]
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, proprietary and/or
Registry  Sensitive information intended solely for the recipient and, thus
may not be  retransmitted, reproduced or disclosed without the prior written
consent of  VeriSign Naming and Directory Services.  If you have received
this e-mail message in error, please notify the sender immediately by
telephone or reply e-mail and destroy the original message without making a
copy.  Thank you.



From: Andrew Sullivan <[email protected]>
Date: Tue, 26 Jan 2010 11:41:21 -0500
To: EPP Provreg <[email protected]>
Subject: Re: [ietf-provreg] Revision of 4310

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
[email protected]
Shinkuro, Inc.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
List run by majordomo software.  For (Un-)subscription and similar details
send "help" to [email protected]