error (broken trust chain) resolving

[Casey Deccio]

On Wed, Nov 3, 2010 at 4:44 AM, Brian J. Murrell <brian at interlinx.bc.ca> wrote:
> Casey Deccio <casey <at> deccio.net> writes:
>>
>> However, a broken chain means that the validating resolver expects a
>> chain to exist, but the chain does not extend properly.
>
> How does a resolver come to this expectation?  What is happening that makes
> this situation any different than an insecure delegation?  If we take one of
> the examples from my original post:
>

This can happen in a number of different ways:  If any RRSIGs in the
chain of trust are bogus, expired, or missing.  If NSEC/NSEC3 records
are not provided or are insufficient to prove that no DS records exist
for an insecure delegation.  If DS RRs do exist, but none correspond
to any self-signing DNSKEYs in the child zone.  If DNSKEYs are not
returned by the resolver.

> named error (broken trust chain) resolving '133.168.163.66.sa-
> trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
>
> Where/why does it break?  Who's is breaking it?  I can see that org. is rife
> with DNSSEC data but that bondedsender.org. is completely void of it.  But
> surely that would be the case of a plain insecure delegation, yes?
>

Yes, bondedsender.org is an insecure delegation.

Reproducing these errors and analyzing the debug-level log messages
would be helpful since everything looks consistent from a DNSSEC
perspective, as far as I can see.

Casey