To:
EPP Provreg <ietf-provreg@cafax.se>
From:
Andrew Sullivan <ajs@shinkuro.com>
Date:
Tue, 26 Jan 2010 09:51:23 -0500
Content-Disposition:
inline
In-Reply-To:
<C7846A08.3706B%jgould@verisign.com>
Mail-Followup-To:
Andrew Sullivan <ajs@shinkuro.com>,EPP Provreg <ietf-provreg@cafax.se>
Sender:
owner-ietf-provreg@cafax.se
User-Agent:
Mutt/1.5.18 (2008-05-17)
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