Subject: Re: [dnsext] New defence to Kaminsky attack

From: bert hubert <[email-masked]>
Date: Tue, 13 Apr 2010 21:08:29 +0200

On Tue, Apr 13, 2010 at 6:11 PM, George Barwood
<[email-masked]> wrote:
> Correct. Rule 2 below specifies that this NS record is not accepted,
> since it is not "strictly below the Bailiwick". That should work.

Ok - but I think this breaks down when someone uses
'123www.powerdns.com' to spoof the powerdns.com nameservers, in other
words, a 'sibling attack'.

This would deliver a SOA, but would still be a zone.

Or am I wrong?

   Bert

---

From: bert hubert <[email-masked]>
Date: Tue, 13 Apr 2010 17:17:57 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hi George,

I want to implement this strategy, but I'm not quite seeing how it
would work. This is in all likelihood because of me.

When you query 123.www.example.com, the authentic answer comes in
carrying an NXDOMAIN error status, and a SOA record for example.com.

This teaches us that there is no www.example.com zone and no
123.www.example.com zone (because in that case, either we would've
gotten a response, or a delegation).

Now we mark www.example.com as 'not a zone'.

When we now get an NS record for www.example.com (from an attacker),
in response to a query for 124.www.example.com, we ignore that record,
since we've stored that www.example.com is not a zone.

Ok - this works.

However, what about if you get a new NS record for 'example.com'?
Normally we would accept 'more specifics', and this needs to be
blocked too.

Or does your proposal deal with this situation too?

I'm aiming to implement your strategy, but I would appreciate your thoughts!

    Bert

On Tue, Mar 16, 2010 at 5:14 PM, George Barwood
<[email-masked]> wrote:
> I think I have discovered a new defence to the Kaminsky attack that avoids
> any extra queries in normal operation.
>
> A typical Kaminsky attack is to attack a domain, say
>
> www.example.com
>
> by asking a series of questions
>
> <random>.www.example.com
>
> and sending spoof referral responses ( "Phantom Referrals" ) with a
> delegation to a machine controlled by the attacker, e.g.
>
> www.example.com NS ns1.bad.net
>
> The true response will be NxDomain, normally with a SOA record
>
> example.com SOA ......
>
> To defend, when we get a NxDomain response, we mark the domains below the
> zone with a NZ flag ( "Not a Zone" ).
> If there is no SOA record ( should be unusual ), we assume the zone is the
> Bailiwick ( the Owner of the NS record
> that was used to select the name server for the query ).
>
> If unexpectedly we later get a NS record for a NZ domain, we reject NS the
> record, clear the NZ flag, and retry ( if necessary ).
>
> Complete Acceptance rules
> ====================
> When reading a response, only the following records are accepted
>
> (1) Records in the Answer section of an Authoritative response (AA=1) that
> have
> Owner = QNAME ( the domain of the Question ).
>
> (2) NS records in the Authority section that have Owner strictly below the
> Bailiwick,
> and with the Owner NZ flag clear.
>
> (3) A / AAAA records in the Additional section that resolve an accepted NS
> record.
>
> HTH,
> -- George
>