www.ncbi.nlm.nih.gov / pubmed

[Dave Sparro]

On 8/18/2010 1:12 PM, Casey Deccio wrote:
> 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/
>

It seems to me that the OP wanted a work-around to the fact that his end 
users couldn't use the website due to a validation failure.
It still seems to me that working around that situation misses the point 
of using DNSSEC.

-- 
Dave