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. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
