On Wed, Nov 3, 2010 at 4:44 AM, Brian J. Murrell <br...@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 _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
