rDNS failed, DNSSEC?

/dev/rob0 rob0 at
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
> 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 / 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))


> - 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.
-- -- system administration and consulting
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

More information about the bind-users mailing list