A lot of this depends how much overlap you have with keys
and the frequency of key changeover.
The rollover draft is looking at a method to support this
by automating some / all of it. Feed back on that would be
useful.
As for your comment about unreachable children. COM is not
a good place to look for this statistic. COM has suffered
and still suffers from speculation. It also suffer from
a lack of management from above with zones allowed to be
created w/ no operational servers. If the parent zone
enforces that there are operational servers *before* a
zone is delegated the problems go down.
Mark
> Hi,
>
> First some background:
>
> Since the beginning of this year NLnet Labs is working in a CENTRE
> working group to install of DNSSEC in the ccTLD zones of .se, .de,
> and .nl. We encountered a number of technical problems, but these
> proved to be solvable. Now we are focussing on the organisational
> aspects.
>
> We have run into an organisational problem for which we have not
> found an acceptabel solution. The problem lies in the SIG record
> over the zone KEY.
>
> The problem:
>
> In the implementation of both Bind-8.2.2p5 and Bind-9 this SIG
> record, which is generated by the parent, must be put into the
> child zone (and may also be put into the parent zone).
>
> Despite numerous attempts, we have sofar not found a solution to
> synchronize a KEY update in a ccTLD zonefile with the necessary SIG
> updates of the millions of zonefiles of its children. From experience
> we know that a certain percentage of children can not be reached in
> time to do this properly.
> According to Cricket Liu (at the DNSSEC workshop in Sweden), the
> percentage of unreachable children is estimated to be as high as 20%
> for the .com zone. For some highly organized ccTLDs this percentage
> may be smaller, but will still present a hugh number of zones.
> Another number of child nameserver systems, may be temporily
> unreachable due to network- or systemproblems, also preventing
> timely synchronization.
>
> The result is, that with every key-refresh of the large TLDs many
> thousands and perhaps hundreds of thousands of zones will suddenly
> have bad SIGs and will drop from the Internet.
>
> A similar problem exists when signatures expire. Although this
> problem is solvable (with overlapping validity) it will cause a
> enormous (administratic) burden on registries, registrants and
> zone-administrators.
>
> The question:
>
> Miek Gieben, one of the people from NLnet Labs working on the
> procedural issues of DNSSEC at ccTLDs, has asked on the dnsext en
> dnsops list, why the current Bind implementations require the
> parents SIG over the zone-KEY to be present in the child zone.
>
> Reason to ask this, is that there seems no security-technical reason
> to have this SIG in the parent zonefile instead.
> Having this SIG in the parent zone file, and only there, would solve
> both above problems. (Then, like all other SIGs, also this SIG will
> be in the same zonefile as the KEY which is used to generate it, and
> synchronization is automatic).
>
> >From responses by Edward Lewis, Mats Dufberg, and Jim Reid, we
> understand that the current interpretation of RFC 2535 requires
> the parents SIG over the childs zone-key to be in the childzone.
>
> We now have a problem for which I ask advice from the community.
> I see two possibilities:
> 1. We go ahead, and accept the administratic burden and also that
> a large number of zones drop from the Internet now and then.
> 2. We change the interpretation of RFC 2535.
>
> As for 1, I guess that many (large) TLDs and/or its registrants will
> not be able to implement DNSSEC and that many domainholders will
> prefer being unsecure over the risk of disappearing completely.
>
> As for 2, I'm unsure what the implications are.
>
> Please advice,
> -- Ted.
>
--
Mark Andrews, Nominum Inc.
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
