Re: Revision of 4310
James Gould <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Message-ID | <C7847EE8.37081%[email protected]> |
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 [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 09:51:23 -0500 To: EPP Provreg <[email protected]> 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 [email protected] Shinkuro, Inc. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to [email protected]