error (broken trust chain) resolving

Brian J. Murrell brian at
Wed Nov 3 11:44:18 UTC 2010

Casey Deccio <casey <at>> writes:
> There is a difference between a "broken" trust chain and a trust chain
> that securely "ends" before reaching the name being queried.

Ahhh.  That makes sense.

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

named error (broken trust chain) resolving '':

Where/why does it break?  Who's is breaking it?  I can see that org. is rife 
with DNSSEC data but that is completely void of it.  But 
surely that would be the case of a plain insecure delegation, yes?

> I'm assuming the error above refers to a broken chain, but it's hard
> to tell why without looking at the context, including cache contents
> at the time of the failure, etc.  The DNSSEC configuration (resulting
> in insecure answer) looks okay from my perspective.  Is the error
> persistent or was it a one-time deal?

Well given the particular one above is a dnsbl lookup it's difficult to say if 
I've even looked it up more than once.

Looking at the various occurrences I have it seems to be pervasive for reverse 
addr lookups in,, sa-,,,, looking for A and TXT records.

It also seems to occur quite frequently for AAAA lookups to domains like 
{seal,ocsp},, *,, and others.

Apart from that there are a few domains in which A, MX and PTR lookups return a 
broken chain, but nowhere near as much as the reverse addr lookups and the AAAA 
lookups above.


More information about the bind-users mailing list