In message <c6d0299b.15ca1%kim.dav...@icann.org>, Kim Davies writes: > Hi Mark, > > On 11/09/09 4:01 PM, "Mark Andrews" <ma...@isc.org> wrote: > >=20 > > IANA still has not provided timing guidance. > >=20 > > IANA can you please specifiy a maximum polling interval on this > > page and inform the TLD's using ITAR of what it is. A minimum > > polling interval would also be useful but is not crucial. > > I can't provide good guidance, because the ITAR is "live". If we get a vali= > d > add request then it goes in, if we have a valid remove request it comes out= > . > We could get three different changes in the span of an hour, or we could ge= > t > no requests in the span of a whole month. Revisions to the registry are not > batched into scheduled intervals, like, say, the root zone. Maybe they > should be?
When they happen is not the issue. It how often the people using the ITAR should be checking for changes that is the issue. With any key rollover there are timing constraints. For a ZSK you need to publish the ZSK at least one DNSKEY TTL before you depend on it (sign only with it). You also need to wait for all the authoritative severs to be serving the zone with that key in it before you start the timer. There are similar constrains on how to roll over a KSK. The old DS RRset needs to have cleared the caches before you depend on the new DS RRset. Similarly the old DNSKEY RRset needs to have cleared caches before you can depend on the new DNSKEY RRset. With the data in the DNS it is easy as you can see the TTL on the records. You will most probably publish DS's with 1 or 2 day ttls and everyone knows when the old data should have cleared caches. Publish new DNSKEY, publish new DS, wait at least the max TTL of the old DS/DNSSKEY TTLs. Remove old DS, remove old DNSKEY. The same thing should be happening with ITAR. Publish new DNSKEY, publish new DS, wait the prescribed period for the trust achors to be updated, remove old DS, remove old DNSKEY. At the moment no one knows how long to wait as you havn't told anyone what that period should be. Mark > Right now, since the initial activity populating the repository, there are > only a couple of ITAR change events per month, but we have no pattern as to > when they can occur. > > kim > -- 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
