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

Reply via email to