On Sep 14, 2009, at 12:01 PM, Kim Davies wrote:
Hi Mark, On 11/09/09 4:47 PM, "Mark Andrews" <[email protected]> wrote: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.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?
I would say that the latter would be sufficient, but it would be rules that the TLD operators *and* ITAR consumers would have to abide by.
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.
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.
The assumption right now is it is for the TLD operators to act responsibly and make changes as appropriate. 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 practiceamongst TLD operators, rather than a specific defect in ITAR.
But without any timing advice, it is quite difficult for TLD operators to know if they are acting responsibly or not.
-- David Blacka <[email protected]> Sr. Engineer VeriSign Platform Product Development
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
