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'm not sure that the length of the draft is totally correlative to the
complexity of the protocol. It certainly took some words and examples
to cover all of the cases, however.
> 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
I don't think that text appears in the any version of the draft.
In any case, all it is actually saying is that you have to iteratively
hash a known, finite series of names in order to determine the closest
encloser. The series of names is the qname, followed by all ancestors
of qname up to and including the zone apex (which you know).
> 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.
The actual proof follows a fairly simple algorithm.
Sr. Engineer VeriSign Infrastructure Product Engineering
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.