North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?

  • From: James Hess
  • Date: Sat Jul 26 17:55:34 2008

On Thu, Jul 24, 2008 at 8:35 AM, Joe Greco <[email protected]> wrote:
> If the old code system could result in an infected name server in 11
> seconds, this "fix" looks to me to be at best a dangerous and risky
> exercise at merely reducing the odds.  Some criminal enterprise will
> figure out that you've only reduced the odds to 1/64000 of what they
> were, but the facts are that if you can redirect some major ISP's
> resolver to punt www.chase.com or www.citibank.com at your $evil server,

Provided the attacker cannot run 'tcpdump' or similar and _see_ the
target server's
DNS traffic,  perhaps cache itself could become a defense mechanism...

Whenever a user of a DNS server requests a lookup for a cached entry
nearing expiration,
give the user the cached entry, but, also perform a background lookup
to renew the cache:
only accept the DNS response, to that special query, if it has the
same data as what is
already cached.

Nameservers could incorporate poison detection...
Listen on 200 random fake
ports (in addition to the true query ports);  if a response ever
arrives at a fake
port, then it must be an attack, read the "identified" attack packet,
log the attack event, mark the RRs mentioned in the packet as
"poison being attempted"  for 6 hours; for such domains always request and
collect   _two_  good responses  (instead of one),  with a 60 second timeout,
before caching a lookup.

The attacker must now guess nearly 64-bits in a short amount of time,
to be successful.
Once a good lookup is received, discard the normal TTL and hold the good answer
cached and immutable, for 6 hours  (_then_ start decreasing the TTL normally).


--
When the patch also prevents caching additional sections, for a  DNS label
previously cached, this type of sustained brute force should not be feasible:
when the name targetted for poisoning must be the name that is being looked up.
It is a much larger reduction than 1:64000

Since then the vulnerability to poisoning only exists when a name has not yet
been cached: sustained brute force cannot occur  (there is an element of waiting
a long time, for the proper cached entry to expire).

Once a DNS request occurs for the target name followed by the
legitimate response
winning, an attacker has to wait until the proper cached entry expires, before
any poisoning effort could be successful.


--
-J