Re: SoC Feature Creeper and Performance Czar Tasks

[doug () hcsw org]

Hi nmap-dev!

On Sat, May 13, 2006 at 10:55:13PM -0700 or thereabouts, Fyodor wrote:
> o Add parallel traceroute support to Nmap.  It should come after the
>   port scanning and host enumeration sections, and utilize a
>   port/protocol that Nmap has found to be accessible on the particular
>   target.  Multiple hosts should be done in parallel (as with most
>   Nmap scans), and multiple probes done in parallel too.  The Nmap
>   parallel rDNS infrastructure should be used to look up the
>   intermediate hosts (unless -n was specified), because that system
>   does caching (be sure to verify that they are indeed being cached,
>   as many of the intermediate hosts will be repeated for each
>   machine).

When the rDNS infrastructure was being developed I remember talking
to Fyodor about implementing this caching feature but AFAIK it was
never actually implemented in the rDNS code. Since, currently, Nmap
only looks up the name of each IP *at most once* we won't derive
any benefit from caching responses anyways.

Fyodor makes a good observation that reverse DNS caching is probably
necessary for a decent parallel traceroute implementation. I also think
he's right and the rDNS infrastructure is a good system to use.

Luckily, the rDNS infrastructure contains a hash table data structure
of the IP->name mappings found in the following files:

Unix: /etc/hosts

Windows:
   for 95/98/Me: WINDOWS_DIR\hosts
   for NT/2000/XP: WINDOWS_DIR\system32\drivers\etc\hosts

This data structure would also be well suited to caching responses
from nameservers. Overall, this shouldn't be that difficult of a task.

However, DNS caching has a few little nuances to it:

  * We also need to cache NXDOMAINs (aka "negative caching")
  * CNAMEs add another level of indirection, which also must be cached
  * Do we cache SERVFAILs?

So, to anyone who wants to use the rDNS infrastructure for cool new
features like parallel traceroute, shoot me an email and we can
figure this out optimally.

Doug



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev