On Tue, Feb 28, 2012 at 01:16:16PM +0100, Marc Lampo wrote: > Please allow a, partly/mostly, non-technical feedback > as security officer for a tld (.eu) > > 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). > Point taken, but let me come back on those later. > > The (non-technical) response : > When I get in my car, I put my safety belt on. > (I know some may point at undesired effects, > and I do not want to have that discussion in this list), > but the point is : > I do hope I will never need the protection offered by the safety belt, > but "if", then I'll be happy I took the precaution. > > The similarity to DNSSEC is that we all hope we will not need the > protection it offers, > but "if" an attacker finds it interesting to attempt to exploit, > I will be glad I took the precaution of activating DNSSEC.
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. > 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. > > > 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. (Granted, if there was a benefit, namely to be protected from hostile data, I wouldn't know the difference easily.) In a wreck wearing a safety belt, you may get bruised along the belt line, but afterwards you get to look up at the glass in front of you and not see where your gashed, bloody forehead struck. Clear cut trade, minor annoyance for significant benefit. 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. Last night I was unable to check the weather forecast, because the fine folks at NOAA.gov / weather.gov broke their DNSSEC. Lo and behold today I see fresh RRSIG records. They only last a week. I suppose there are different classes of failures; unfortunately on the resolver, there is only one result, SERVFAIL, to cover all. It would be better if there was a way to distinguish the "oops, admin bungled DNSSEC" errors from the ones which are more likely to be indicative of spoofing. The hardest part of that might be to decide which is which. IME the one that bites us most often is that of the expired RRSIG. If we could log that but go ahead and accept the data, most of the pain would stop. If the KSK does not match the parent's DS, or if there is a DS but the zone is unsigned, maybe we are looking at a real attack. Still not likely, but more likely than the case of the expired RRSIG. > 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. :) > To conclude (some technical) suggestions : > - when offering DNSSEC on authoritative name servers, > try to rely on automation (like scripts). > (rather than humans to type - and re-type - the same commands > over and over) > - allow yourself a period of testing. > Do *not* immediately have DS information put in the parent zone > (thus completing the chain-of-trust > but also : making validation mandatory. > After all : this is a *test* period) > ((look how TLDs migrate towards DNSSEC. > Exactly the same : > first offer DNSKEYs and RRSIGs, but no DS in the root-zone)) Agreed. > - and may I also plead for validation on caching/forwarding name > servers ? Because it makes no sense to add signatures that can > be validated to DNS replies, if the signatures are simply > ignored. At this point, those of us who do the validation are the ones who are suffering. I think we need something like a softfail, at least for expired RRSIGs. I don't know if it is possible to make that distinction, however. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: _______________________________________________ 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
