On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparro <dspa...@gmail.com> wrote: > On 8/18/2010 8:30 AM, Phil Mayers wrote: >> >> ...since the "ncbi" zone is an unsigned child zone, there needs to be an >> NSEC/NSEC3 record to prove the absence of the DS record, and have a >> secure delegation to an unsigned child zone. > > > It sounds to me like DNSSEC validation is working as designed. If your DNS > server's users are complaining about not being able to resolve something > that fails validation, the question you need to ask is do your end-users > really want you to do DNSSEC validation for them? > > If you're asking for a workaround for when validation fails, there's not > much point to doing the validation. >
Insecure delegations are not a work-around, but are rather a provision for delegated child zones that have not implemented DNSSEC. The parent zone (and its authoritative servers) must be properly configured to handle authenticated denial of existence using NSEC or NSEC3. Specifically, they must use these RRs to prove the non-existence of a DS RR for an unsigned child zone, whose existence would otherwise indicate a secure delegation. If the proper NSEC/NSEC3 RRs are not returned, or are not thought to be authentic, then there is a broken chain because the resolver cannot prove that the delegation is insecure. In the following diagram, note the diamond-shaped NSEC3 node, whose presence (when properly authenticated) proves the insecure delegation to ncbi.nlm.nih.gov: http://dnsviz.net/d/www.ncbi.nlm.nih.gov/dnssec/ Regards, Casey _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
