In message <4aaf6094.3090...@hznet.de>, Holger Zuleger writes: > > > Mark Andrews wrote: > > 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. > To nit pick again: wait *old* DS ttl. > The problem here is that you don't know the exact point in time, when > the new DS is published by the parent. The timer starts when *all* the > authoritative servers of the parent zone publish the new DS record. > > For sure, you can dig for the new DS, but in the world of anycast name > servers you can't be sure that the DS is distributed to all of them.
If you are going to be that picky then it is old expire + old DS ttl after the serial has changed to allow all stealth slaves to have caught up or to have stop serving the zone hoping there isn't a loop in the zone transfer graph or they are all transfering from the primary master because no-one wanted the EDNS EXPIRE option that would have addressed that issue. > > 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-546 > 8 > >> > >> 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 > > -- > Holger Zuleger / Zur Röderburg 6 / D-35315 Homberg/Ohm-Höingen / > xmpp:h...@jabber.hznet.de / http://www.hznet.de / tel:+49 6633 642022 -- 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
