In message <c6d3b6d8.15d4d%kim.dav...@icann.org>, Kim Davies writes: > Hi Mark, > > On 11/09/09 4:47 PM, "Mark Andrews" <ma...@isc.org> wrote: > >=20 > > Publish new DNSKEY, publish new DS, wait at least the max TTL of > > the old DS/DNSSKEY TTLs. Remove old DS, remove old DNSKEY. > >=20 > > 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. > >=20 > > At the moment no one knows how long to wait as you havn't told > > anyone what that period should be. > > Are you suggesting ITAR needs to add TTLs, or ITAR should be somehow > technically enforce sufficiently long overlap periods, or should just > provide rules that TLD operators are expected to abide by?
Provide rules that both the TLD's and consumers are expected to abide by. This should prevent disconnects like what happened here from occuring. TLD's will need to wait between submitting the new key to IANA and removing the old key or validation will break. This is irrespective of whether IANA is publishing the ITAR or only updating the root zone. If you wish to maintain consistancy of operations as you transition from ITAR to root zone updates only I would recommed you make this delay match the TTL you expect to use for the DS records in the root zone then tell the consumers of the ITAR that they need to ensure that update their trust anchors within this period. > The assumption right now is it is for the TLD operators to act responsibly > and make changes as appropriate. The problem is that no one has defined what is appropriate. We are all working in a information vacumn. The 1 week poll was choosen assuming TLD operators would follow RFC 5011 timings as they don't yet have a signed parent zone and would inform IANA in a timely manner. Neither of these assumptions turned out to be true. > ITAR is just an oblivious republisher of > data that they have submitted, and has subsequently verified is genuine. It > seems to me the problems you describe are ones of encouraging best practice > amongst TLD operators, rather than a specific defect in ITAR. ITAR is missing the information that would be available when the root is signed which is timing. ITAR is special as it is in a position to provide that as IANA is producer of both ITAR and the root zone. There are generic issues for the operations of TAR's here which need to be explored but they are not applicable to ITAR. Mark -- 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
