To:
Ted Lindgreen <ted@tednet.nl>
Cc:
Roy Arends <Roy.Arends@nominum.com>, DNSEXT WG Mailing list <namedroppers@ops.ietf.org>, dnssec@cafax.se
From:
Roy Arends <Roy.Arends@nominum.com>
Date:
Wed, 6 Jun 2001 14:14:39 +0200 (CEST)
Delivery-Date:
Wed Jun 6 23:10:36 2001
In-Reply-To:
<200106060902.LAA29046@omval.tednet.nl>
Sender:
owner-dnssec@cafax.se
Subject:
Re: null DK records at the parent
On Wed, 6 Jun 2001, Ted Lindgreen wrote: > [Quoting Roy Arends, on Jun 6, 2:20, in "Re: null DK records ..."] > > > In any case, important is when a child is bad: > > only if the parent states that a child is secure, and the child can > > not offer valid signatures. Defining valid in this case: No sigs or > > corrupt sigs. > > Yes, indeed this is the important question, however, the answer > given is incompleet, I'm affraid: > - If the parent states that a child is secured, then not only must > the child have valid sigs, but also the KEY that the child has > used must be checked. Usually (on-tree validation) by checking > the parental SIG over that KEY. Yes, I fixed this in my second posting. > The real questions are: > 1. How does a (secured) parent state that a child is secure, and > how if it is not secured? Important is, that this is done in > a manner that can be implemented and maintained in real-life > situations (think of large TLDs). > 2. How does a resolver find this out in a predictible manner from > possible second- and third-hand cached information? > > I don't have all the answers, but for now, I have concluded: > - Following RFC2535, with NULL-KEYs @ parent and real KEYs @ child > makes 1 very difficult. > - Using the SIG@parent idea solves the problems in 1, but > introduces problems in 2. > - The idea of the DELS RR seems to solve the problems in 1, > without introducing problems in 2. This doesn't state anything new or clearifies your opinion on null-DK records at the parent. I assume DELS RRs and DK RRs are similar ? Regards, Roy Arends Nominum