Re: [ietf-provreg] Revision of 4310

[James Gould <jgould@verisign.com>]

Title: Re: [ietf-provreg] Revision of 4310

Andrew,

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.

Thanks,

-- 


JG 

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
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 <ajs@shinkuro.com>
Date: Tue, 26 Jan 2010 09:51:23 -0500
To: EPP Provreg <ietf-provreg@cafax.se>
Subject: Re: [ietf-provreg] Revision of 4310

On Tue, Jan 26, 2010 at 09:44:40AM -0500, James Gould wrote:
> Andrew,
>
> I don¹t understand why the client wouldn¹t just add the DS when it becomes
> active to the server instead of pre-publishing and activating.  Adding an

Because of caches, and the TTL on the parent zone which is not
controllable by the client.

If you have to do an emergency key rollover, you _can't_ stop using
your old key until the longest TTL in the system without your zone
validating bogus.  If the parent at the start only has the old DS, and
you've yanked the corresponding DNSKEY because you know it to be
compromised, then anyone who hits a cache containing the old DS will
get it until it has expired.

If the parent-held DS RRSet contains a DS corresponding to a new
DNSKEY, then you can cycle that DNSKEY in immediately.  You might not
have been using it, or even publishing it in the DNSKEY RRSet because
you might have wanted to keep your response size reasonably small.

The EPP extension as it stands just doesn't support this option.

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