error (broken trust chain) resolving

[Casey Deccio]

On Tue, Nov 2, 2010 at 10:21 AM, Brian J. Murrell <brian at interlinx.bc.ca> wrote:
> Alan Clegg <aclegg <at> isc.org> writes:
>>
>> On 11/2/2010 8:11 AM, Brian J. Murrell wrote:
>> >
>> > named error (broken trust chain) resolving '133.168.163.66.sa-
>> > trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
>
>> There isn't a chain of signed DS records that lead from a trust anchor
>> to the thing that you are trying to resolve.
>
> So basically it just means that one or more zones from . down to the thing I'm
> trying to resolve has not been DNSSECized?  i.e. no zone keys, signing, etc.?
>

There is a difference between a "broken" trust chain and a trust chain
that securely "ends" before reaching the name being queried.  The
latter is referred to as an insecure delegation, and, as you suggest,
will be pervasive while DNSSEC deployment grows.  The result is an
answer that simply cannot be verified because there is provably no
path for validation.  Such is treated by the resolver as "insecure".

However, a broken chain means that the validating resolver expects a
chain to exist, but the chain does not extend properly.  This could be
because of expired signatures, missing DNSKEYs, etc.  This results in
SERVFAIL.

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?

Casey