On Wed, Aug 27, 2008 at 06:54:53PM -0400, Dean Anderson wrote:
I suggest you review the past emails and the RFC's to find out what is
meant by a 'non-verifying DNSSEC cache'.
I have a passing familiarity with the RFCs, and the phrase
non-verifying DNSSEC cache, and even non-verifying, appears
On Fri, Aug 22, 2008 at 11:53:02AM -0700,
David Conrad [EMAIL PROTECTED] wrote
a message of 1187 lines which said:
It is a bit dated as it was originally written
before the IPv6 glue was added to the roots. If there is interest in
pursuing this, I could take a stab at another revision.
On Thu, 28 Aug 2008, Brian Dickson wrote:
(I would posit that the folks generating the DNSKEY will also
want to generate the DS hash on their known, trusted signing tools
instead of trusting the parent w/ the DNSKEY materials)
Well, here's why:
- The DS is a deterministic
On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
The DS may be provided by the operator of the subordinate zone, or built
by the parent operator,
most likely the latter.
thats an interesting premise.
why do you think this will be the case?
On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
The DS may be provided by the operator of the subordinate zone, or built
by the parent operator,
most likely the latter.
thats an interesting premise.
why do you think this will be the case?
On Fri, Aug 29, 2008 at 10:23:53AM +1000, Mark Andrews wrote:
- The parent is already trusted with DNSSEC tools, since the parent is
signing the parent's zone (including the DS record!)
assuming facts not in evidence. there is active discussion
about having unsigned zones
- The parent is already trusted with DNSSEC tools, since the parent is
signing the parent's zone (including the DS record!)
assuming facts not in evidence. there is active discussion
about having unsigned zones w/ DS records included.
Well you are not talking
