error (broken trust chain) resolving

[Brian J. Murrell]

Casey Deccio <casey <at> deccio.net> 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 '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?

> 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 bb.barracudacentral.org, sa-accredit.habeas.com, sa-
trusted.bondedsender.org, rbl-plus.mail-abuse.org, relays.mail-abuse.org, 
dialups.mail-abuse.org, blackholes.mail-abuse.org looking for A and TXT records.

It also seems to occur quite frequently for AAAA lookups to domains like 
{seal,ocsp}.verisign.net, login.facebook.com, *.slashdot.org, 
newswww.bbc.net.uk, 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.

Cheers,
b.