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]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.