In message <a06240800c6d44242f...@[10.31.200.153]>, Edward Lewis writes: > At 14:45 -0400 9/14/09, David Blacka wrote: > > >I think it works to simply say this: > > > > * The ITAR should be checked for changes once per 24 hour period. > > > >Then: > > > > * consumers (e.g., dlv.isc.org, me) will know to check at least > >once per day; > > * TLD operators would know to pre-publish the new DS at least 24 hours > > before doing the KSK roll. > > Plus an allowance for TTLs. > > It's a bit more complicated I think, unless I missed a fine point in > the message. > > To nit pick: "TLD operators would know to pre-publish the new DS" is > incorrect per se - the DS set for a zone is authoritative at the > parent. > > When I want to change a SEP, first I plan to have it in my DNSKEY set > for a long enough period to satisfy at least RFC 5011 and the time it > takes for all caches to time out all DNSKEY set versions prior to the > new SEP-to-be.
Iff the zone being managed according to RFC5011. RFC5011 is not required for zones that that have a secure parent. RFC 5011 is a real pain and unless you have a reason to use it I would not recommend saying you are following RFC 5011. With a secure parent there are several different strategies that can be used to roll a DNSKEY cleanly. Add the new DNSKEY. Add the new DS to the parent zone. Wait for both the old DS and DNSKEY RRsets to expire from caches. Remove the old DS and the old DNSKEY. Add new DNSKEY, wait DNSKEY TTL, replace old DS with new DS, wait DS ttl, remove old DNSKEY. Generate DNSKEY, publish new DS, wait DS ttl, replace DNSKEY, wait DNSKEY ttl, remove old DS. ** This is not compatible with how ITAR is defined to work. Note all of these have a wait "DS ttl" after the new DS is published. Consumers of ITAR need to update in this window. > Next I add the new SEP signature to the DNSKEY set and ask the parent > to change the DS record in my DS RRSet. Change means take out the > old and put in the new (per algorithm/etc.). I don't remove anything > at this point. You will break validators which use different caches for DNSKEY and DS lookups doing this. > I don't think the parent's TTL considerations matter because I am > placing two SEP's in to play while waiting. As soon as I see the new > DS record appear in the zone (and the old DS gone), I start a timer > based on my TTL for the DNSKEY set. Once that timer expires I > RFC5011-revoke the old SEP (and sign the whole key set with old and > new SEP key). DS ttl always come into play. You need to assume a validator can be using different caches to retieve the DS and DNSKEY RRsets. > According to RFC 5011 rules I then remove the old SEP and any > signature at the appropriate time. > > >As it is, I don't expect any TLD operator to have any idea of how > >long they must pre-publish, nor any consumer to know how often to > >poll IANA for any changes. > > Polling is suboptimal when an event is anticipated but it is a good > catch all to avoid missing an event notification. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > As with IPv6, the problem with the deployment of frictionless surfaces is > that they're not getting traction. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
