error (broken trust chain) resolving

[Brian J. Murrell]

Casey Deccio <casey <at> deccio.net> writes:
>  
> 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.

None of which appear to be the case for this example-case domain "sa-
trusted.bondedsender.org" as far as I have been able to determine with my 
"green" DNSSEC skills.

> Yes, bondedsender.org is an insecure delegation.

So from what I have been able to learn so far, there shouldn't be any legitimate 
reason why one should be getting broken trust chain errors about a domain that 
has been insecurely delegated, yes?  I mean there is no security in the 
delegation to be broken, right?

> 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.

I might be able to set up a shadow bind installation that mirrors the 
configuration of primary resolver here to do some debugging.  Do you have any 
suggestions as to which debug flags/levels to set to get some meaningful 
information?  Once set up, simply doing some digs with +dnssec against the 
configured server should suffice, yes?

b.