On 2/28/12 9:26 AM, "/dev/rob0" <r...@gmx.co.uk> wrote:
> On Tue, Feb 28, 2012 at 01:16:16PM +0100, Marc Lampo wrote:
>> First of all : I do not deny DNSSEC adds a challenge for administrators.
>> They must understand that adding this additional SECurity aspect,
>> will generate extra work (keygeneration/re-generation/signing and
>> re-signing).
Similar to compiling, enabling, maintaining SSH when telnet always came
enabled by default in inetd.conf. ;-) That's automatic these days.
> Speaking of course from my own lowly perspective, this thread (I
> started it) has made me much more cautious in proceeding with
> deployment of DNSSEC, and I am strongly considering disabling
> verification on my resolvers.
Yes, I think timing is everything.
>> How popular are these attacks against which DNSSEC offers
>> protection ? From what I can see, my view being limited, the most
>> 'effective', for lack of a better word, in 2011 were not DNS
>> related. Social engineering, making people "do" something (click
>> URL, open attachment) is a far more effective way, for attackers,
>> to get their thing done.
It wasn't just 2011, social engineering has always been a trump card. There
are a lot of papers on spearphishing and the like (or watch Sneakers)...
but, alas, that's another thread.
>> Does this mean we don't have to put the safety belt on ?
>> I daresay : no.
>
> Your analogy is weak, because while a safety belt has only minor
> drawbacks, DNSSEC verification has been quite intrusive for me, and
> AFAIK only a source of problems, not benefits.
Well, sometimes... One drawback of a safety belt (being EMT trained) is
that if you careen off a bridge (or end up in water some other way, it
happens) the device sometimes malfunctions and you can't get out of the car.
Drowning has always been one of my fears -- it's why I took swimming lessons
early and avoided the Navy -- it's not a minor drawback for most. That
said, they make $5 belt cutters you can keep in your glove box which
mitigates this concern. The right tools can make all the difference.
> (Granted, if there was a benefit, namely to be protected from hostile
> data, I wouldn't know the difference easily.)
>
<snip>
>
> Doing DNSSEC verification in 2012 is lopsided the other way. You
> cannot resolve the names you need sometimes. You're probably not
> receiving any actual protection from spoofing.
I feel similarly. I do see risk in the non DNSSEC world (thanks to Kaminsky
and others), but not so common or devastating to justify the cost and
associated risks of deployment today. I think the right tools (inline
signing!) will reduce TCO and generally make more folks jump onboard.
>> Attackers constantly look for new ways, therefore if an attacker
>> comes up with an approach that becomes popular because of
>> ease/speed/effectiveness and that approach would have been
>> prevented by DNSSEC, we would have been happy that we already
>> deployed DNSSEC.
>
> I suppose, but then I don't really worry much, personally, about the
> kind of naughty things a DNS spoofer might do. I have no money, so
> giving them my bank credentials won't do them any good. :)
For small shops or personal domains, it's ultimately up to the
owner/administrator to decide... You are right, the risk may not be a
concern at all in some cases. However, making it easier to do when the risk
is present is somewhere I'm happy to see ISC making progress.
--
I have never met a man so ignorant that
I couldn't learn something from him.
-- Galileo Galilei
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
