www.ncbi.nlm.nih.gov / pubmed

[Casey Deccio]

On Wed, Aug 18, 2010 at 9:48 AM, Dave Sparro <dsparro at 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