On Tue, Nov 2, 2010 at 10:21 AM, Brian J. Murrell <br...@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 _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
