www.ncbi.nlm.nih.gov / pubmed

[Phil Mayers]

On 08/18/2010 06:55 PM, Dave Sparro wrote:
> 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.
>

I did, and I disagree that it misses the point.

I wanted a *short term* workaround for that zone, while the site fixed 
their DNSSEC. I had satisfied myself that it was a DNSSEC signing 
mistake, and faced an unpalatable choice - disable validation globally 
for the duration of a single site repair period (sacrificing the 
benefits of DNSSEC) or lose connectivity to that site. Had the site been 
more "important" to us, it would have been no "choice" at all - I would 
have been instructed to disable validation.

I think DNSSEC is very important, but I also think mistakes will happen, 
and that sites will want the ability to be forgiving for a grace period.