[Pdns-users] DNS poisoning and spoof-nearmiss-max

[J Knight]

On 7/29/2008 at 5:20 PM, "bert hubert" <bert.hubert at netherlabs.nl> wrote:

> Hi J,

> Please find my answers below.

> On Tue, Jul 29, 2008 at 05:00:34PM -0400, J Knight wrote:

>> Shouldn't the default for this parameter be "1" instead of "20"?

> Sometimes you get back really old answers, which would invalidate things.

ah...

> Also, setting it to '1' makes it really easy to deny service. Even 20
> attempts will not get you close to guessing the one source port/query id
> combination out of 4 billion that works. 

yeah, nearly 32 bits of randomness are safe enough on its own.

> But another number might be better. 20 is certainly not dangerous.

>> How well does the Recursor aggregate/avoid duplicate queries for
>> the same RR going out, to avoid a birthday attack?

> Perfectly, throught query chaining.

great.

>> There is a "chain-resends" statistics variable (not documented
>> in http://doc.powerdns.com/recursor-stats.html , along with
>> several other variables found in rec_channel_rec.cc : what
>> are case-mismatches , shunted-queries, noshunt-* , why
>> is throttled-outqueries duplicating throttled-out ?) suggesting
>> tracking of this.

> Chain-resends is documented on that page. Case-mismatches, shunted-queries,
> noshunt* are statistics for experimental PowerDNS recursor modules that are
> currently disabled. The statistics sit there at zero.

oops. but what exactly does a chain-resend indicate?
Is it the number of client requests arriving while an outstanding request
for the same requested RR is currently in progress (querying remote NS)?
(Think impatient Windows resolver client resending requests too often)

> Case-mismatches is an implementation of Paul Vixie's 'dns-0x20' draft. This
> might be enabled at some point.

nice. And this could easily add 20 bits of randomness for
average-sized queries. But reading tcpdumps could become a pain in our eye!
Got a switch to turn it on now?


>> What does the Recursor actually do if the counter exceeds the
>> configured limit?
>> - abandon the query and return SERVFAIL to all clients?
>> - abandon the query and return nothing to all clients?
>> - wait X seconds and retry the outgoing query to the same NS?
>>   or to another NS for the zone?

> The query is considered to have generated an error, and the next server will
> be tried. If there are no others to try, SERVFAIL to all clients.

If there's a running poisoning attack already, isn't it likely that you're
already receiving spoofed responses for all other NS in the zone, and are
likely to run into the limit real quick? There's a better way to deal
with this situation. Indeed, you already mentioned it in your IETF draft -
see part 9.3 :)

And on that note: how well are you randomizing selection of one of multiple
nameservers in a zone to conduct your query? It appears that some resolvers
are NOT randomizing that selection properly, which makes the spoofing attack
far easier, particularly for high-value domains that tend to have large
numbers of nameservers in all their zones.



>> I am reading through http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-05.txt
>> for some interesting ideas...

> Check who wrote it :-) 

Why do you think I am here and mention that URL - someone's got to do the horn-tooting
for you: Nice work, Bert (and Remco) :)

And the URL above is no longer available - as this went to version -06 yesterday :
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-06.txt


Thank you,

Jamie