lists.isc.org rDNS failed, DNSSEC?
rob0 at gmx.co.uk
Tue Feb 28 17:26:40 UTC 2012
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
> 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
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))
> - 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
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
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
More information about the bind-users