[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Mats Dufberg <dufberg@nic-se.se>
Cc: dnsop@cafax.se
From: ted@tednet.nl (Ted Lindgreen)
Date: Sat, 14 Oct 2000 11:56:43 +0200
In-Reply-To: "Mats Dufberg's message as of Oct 14, 9:48"
Reply-To: Ted.Lindgreen@tednet.nl
Sender: owner-dnsop@cafax.se
Subject: Re: DNSSEC and Parent SIG in Child zone

[Quoting Mats Dufberg, on Oct 14,  9:48, in "Re: DNSSEC and Paren ..."]
> On Fri, 13 Oct 2000, Edward Lewis wrote:
> 
> > BTW - do the top level delegators want to be storing the KEY's for all of
> > the children zone's?  I thought this would be a thing to avoid.
> 
> That would increase the size of the TLD zone many times. That would
> probably delay the implementation of DNSsec in TDL zones.

-  At installation time of DNSsec in TDL zones, most of the subzones
   will not be secure (yet). So, NULL-KEY records for most of the
   children will be in the TLD zone at startup anyway.
-  It is not only the KEY that bothers, the generation and maintenance
   of the the SIG over the KEY is more of a problem. So, although a real
   KEY is somewhat larger than a NULL-KEY, this makes little difference.
-  Although the size of the TLD zone and other technical issues are a
   concern, it is the organizational (administratic and legal) burden
   that comes with DNSsec that scares the TLD registries most.

So, zonefile size is not a strong reason to avoid having parent
signed child-KEYs in parent zones.

If the organizational burden would be less, that would be a
strong reason.

But sofar, with all scenarios we have been working out, we found
that the organizational burden for a registry when storing and
signing the child-KEY in their zone is little different or even
less compared with storing and signing them in an off-line database.
We also worked out scenarios where the parent does not store the
child-KEYs at all, and signs them on out-of-band requests.
This seems OK at first sight, but we found the burden comes back
even stronger when the TLD needs to refresh its own KEY.

But perhaps we have overlooked some better scenario?  If so, please
help us out!

If there is no better scenario, then storing (and signing) child KEYs
in parent zonefiles is something that will happen at TLDs.

And the question remains: is there a strong reason why the
parent-SIG must be duplicated in the child-zone?

If not, that would help the implementation of DNSsec in TDL zones
enormously. This is, because we have not found a solid solution to
guarantee that parent-SIGs in child-zones are in sync with the parent
KEY always. And if out of sync, child-zones will drop of the Internet
and the registries can expect damage claims and other horror.
Perhaps also here we overlooked the better solution, so if you
sees this solution, please tell us.

Regards,
-- Ted.

Home | Date list | Subject list