Re: [DNSOP] DLVs and ITAR

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Holger Zuleger writes:
> 
> 
> Mark Andrews wrote:
> > In message <a06240800c6d44242ff9b@[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 [phone]
> 8
> >>
> >> As with IPv6, the problem with the deployment of frictionless surfaces is
> >> that they're not getting traction.
> >> _______________________________________________
> >> DNSOP mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Holger Zuleger / Zur Röderburg 6 / D-35315 Homberg/Ohm-Höingen /
> xmpp:[e-mail] / http://www.hznet.de / tel:[phone]
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]