Re: DNSSEC and Parent SIG in Child zone

[Mark.Andrews@nominum.com]

	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: Mark.Andrews@nominum.com