Warren Kumari warren at kumari.net
Thu May 10 15:50:30 UTC 2012

On May 10, 2012, at 11:20 AM, Daniel Ryšlink wrote:

> On 05/10/2012 04:33 PM, Barry Margolin wrote:
>> In article<mailman.748.1336659466.63724.bind-users at lists.isc.org>,
>>  Tony Finch<dot at dotat.at>  wrote:
>>> Barry Margolin<barmar at alum.mit.edu>  wrote:
>>>> [Validation is] only untroublesome until someone screws things up on
>>>> their auth server.  When one of your users can't access something.gov,
>>>> they'll complain to YOU, even though it's mostly out of your hands.
>>>> This is true for other problems on auth servers as well, of course.  But
>>>> DNSSEC is new enough that there tend to be more failures of this kind,
>>>> even by organizations that until now have seemed to know what they're
>>>> doing.
>>> Some of the early DNSSEC deployments (especially in .gov) did not use good
>>> tooling. That's much less of a problem now. See for instance the big
>>> DNSSEC deployments in Sweden, Czech, Brazil.
>>> Even third party DNSSEC screwups have not caused us much trouble.
>> Every week or two someone complains in the Comcast Help Forum about
>> being unable to resolve some .gov address, and the usual cause is that
>> the domain operator messed up their DNSSEC.
>> But I agree that it's not as frequent as it was 6 months ago.  It also
>> helps that Comcast can now work around it by configuring exceptions to
>> DNSSEC checking.
> What's the point of DNSSec when resolver administrators configure exceptions on regular basis? If you can't be sure when your resolver does or does not validate, why having signed zones in the first place? It's just seems to be another "shared illusion of security" similar to PKI.

Nope -- Comcast does a large amount of checking before turning off validation for a failing domain. 
This is (IMO) more secure than the alternative, which is to simply leave it failing, and have users move to a non-validatiing resolver instead…


> _____________
> __________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

More information about the bind-users mailing list