This is a discussion on Re: DNSSEC - Signature Only vs the MX/A issue. - DNS ; bert hubert wrote: > On Mon, Dec 04, 2006 at 04:20:50PM -0500, David Blacka wrote: >> I feel compelled to point out that NSEC3 isn't that complicated to >> actually *do*. If it is complex, it is complex to analyze. ...
bert hubert wrote:
> On Mon, Dec 04, 2006 at 04:20:50PM -0500, David Blacka wrote:
>> I feel compelled to point out that NSEC3 isn't that complicated to
>> actually *do*. If it is complex, it is complex to analyze. That is, it
>> can be hard to convince yourself that it works without a bit of mental
> It has a 51 page draft, and it details only *non*-existence.
> I am referring to NSEC3 non-existence proofs. Perhaps I missed something,
> but messages like:
> "In practice, then, we must show an NSEC3 record that encloses the hash of
> x.C, one that encloses the hash of *.C, and any RR owned by C (which could
> be an NSEC3, in which case it would be owned by the hash of C). A resolver
> verifying this proof would have to try longer and longer closest enclosers
> to determine which was being demonstrated as C, if an NSEC3 is presented.
> If any other RR was used, then C would be the owner. Once C has been
> determined, the resolver can easily check x.C and *.C against the proof."
> .. look rather like I need to solve for a system of constraints within my
> But perhaps this applied to a previous draft, of perhaps I am dense (most
> likely). The mind boggles however at the failure modes implied by the
> wording quoted above.
I don't see why. All its saying, admittedly at great length, is that you
have to determine the closest encloser.
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.