Zitat von Barry Margolin <bar...@alum.mit.edu>:
In article <mailman.265.1285967251.555.bind-us...@lists.isc.org>,
lst_ho...@kwsoft.de wrote:
Zitat von Alan Clegg <acl...@isc.org>:
> On 10/1/2010 4:50 PM, lst_ho...@kwsoft.de wrote:
>
>> Sorry for being unclear. We want the SERVFAIL as it should be for
>> invalid DNSSEC data *in all cases* eg. even if a client ask with the
>> cdflag (checking disable) set.
>
> CD means "don't check", so you can't by definition.
>
> AlanC
>
That i was afraid of. It's a pitty that there is no way to save the
downstream clients from stupid resolvers/downstream caches.
Since CD is not set by default, a "stupid resolver" that doesn't know
about DNSSEC won't set it. Someone has to go out of their way to
request this behavior.
I have detected this because we have a internal Bind 9.4 act as
caching resolver forwarding to our border Bind 9.7 which is also a
caching resolver and has DNSSEC enabled. If the internal Bind 9.4 is
not explicitely configured to use DNSSEC (dnssec-enable yes; dnssec
validation yes;) it will set CD and therefore by default makes the
DNSSEC on the border useless.
So the problem are not resolvers unaware of DNSSEC but resolvers with
inappropriate defaults or configured wrong by accident. Additionally
this problem is not easy detectable as it can occur far downstream. So
i would say it is a valid concern for network operators to make it
possibe to force obeying DNSSEC at the border.
Regards
Andreas
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
