error (broken trust chain) resolving
Casey Deccio
casey at deccio.net
Wed Nov 3 18:34:20 UTC 2010
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
More information about the bind-users
mailing list