Date:        Wed, 10 Sep 2003 20:53:40 +0900
    From:        itojun@iijlab.net
    Message-ID:  <20030910115340.188218A@coconut.itojun.org>

  | 	i would suggest you to see what dnsspoof(8) in dsniff package is
  | 	capable of.

And how exactly are you thinking that random IDs in DNS queries
is going to make the slightest bit of difference to that?

  |	the attacks are real, and unpredictable ID is an important
  | 	protection.  the real world is much scarier place than you think.

I know how scary it is.   I simply cannot believe that the ID makes
any realistic difference, in anything other than artificial conditions.

For an attack where this could matter to work, you have to pustulate a
scenario where the attacker knows what query you're going to make, and
when, and then is able to get a reply sent quicker than your local DNS
cache.   And that the attacker can't just send so many replies with
different IDs that their probability of hitting the right one is high.

The latter may have been an important safety factor allowing random IDs
to help in the 10Mbps ethernet days, but with 100Mbps (which everyone
uses now) or faster, sending all 64K answers (every possible ID) is
feasible   If the attacker is too far away from the attacked node for
that to work, they're not going to be able to expect success with this
kind of attack anyway - they won't be able to get the timing close enough.

Anything that is actually depending upon any DNS query beng safe for
anything that really matters (where there's no other safeguard, and it
is plausible to assume that the attacker knows what query is going to
be made) really has to be doing something better than hoping that the
ID is going to be unguessable enough to help - it simply isn't.

dan@geek.com.au said:
  | an important protection in the real world where you can't rely on someone
  | else's server infrastructure supporting stronger protections (like TSIG),
  | unfortunately. 

These days, no-one really ever needs to rely upon someone else's server
infrastructure - running your own DNS cache is trivial, and that you certainly
could protect with TSIG (I kind of doubt that NetBSD's ancient libc
resolver knows anything about TSIG, but that's just a SMOP).

kre

ps: if someone is really trying to cause a client to get bad DNS information,
the place to attack is the cache the client uses, not the client itself.
It is orders of magnitude easier to get the cache to accept, and then
regurgitate, bad information than it is to get the correct reply to a
client at just the right time.   This libc really good random ID stuff
makes no difference to anything at all that matters for DNS queries - it
simply adds overhead.