Re: Nmap 4.21ALPHA4 DNS resolve timeout

[Henrik Zagerholm <henke () mac se>]

26 jun 2007 kl. 21:42 skrev doug () hcsw org:

> Hi Henrik, great questions!
>
> On Tue, Jun 26, 2007 at 11:19:13AM +0200 or thereabouts, Henrik  
> Zagerholm wrote:
> > I wonder if its possible to set a timeout for DNS resolving?
>
> No, it's not currently possible to change this parameter without  
> recompiling.
> The values for this were tuned for BULK resolution (many thousands  
> of IPs) using
> multiple DNS servers of varying reliability and might not be  
> exactly what
> you are looking for. As (I think) Eddie mentioned though you can  
> change these
> in the hardcoded C file:
>
> static int read_timeouts[][4] = {
>   { 4000, 4000, 5000, -1 }, // 1 server
>   { 2500, 4000,   -1, -1 }, // 2 servers
>   { 2500, 3000,   -1, -1 }, // 3+ servers
> };

Ahh now I see what you mean. Great clarification!
> As you can see, the behaviour depends on the number of DNS servers  
> Nmap is
> configured to use. With 1 server it will try each request that  
> times out
> 3 times with timeuts of 4s, 4s, and 5s respectively. With more  
> servers it
> reduces the timeouts and the number of retries because Nmap will  
> "move"
> the request over to another server if one seems unresponsive. This,  
> especially
> when combined with the CAPACITY levels, also provides a form of  
> load balancing
> among the configured servers.
>
> So, unfortunatley for you, Nmap (like the system resolver but not  
> like the
> dig command line tool) is stuck in a "reliability mode" and you  
> can't change
> this without modifying the source code. If there is sufficient  
> demand (and a
> developer can find some free time) this could probably be made to  
> use the
> max-retries option and maybe a timeout option as well. But, for  
> now, if your
> number of IPs is as small as the sample you pasted, I suggest using  
> the dig
> command line tool in multiple OS processes so you can use its  
> granular timeout
> options. Something like:
>
> foreach ip in ips do
>   if (fork() == 0)
>     system("dig " + ip + "timeout options") |grep out the data you  
> need > my_file
>     # You don't have to use > (redirect) but make sure you use  
> something
>     # that LOCKS (see man 2 flock) the output stream.
>     exit()
>   endif
> endforeach
>
> for length(ips)
>   wait()
> endfor

Mmm I just did a similar thing but used nslookup instead. :)

> The hardcoded minimum timeout you mentioned:
>
>   if (min_timeout > 500) return 500;
>   else return min_timeout;
>
> is just to make sure that we don't stay stuck in nsock for too long so
> we can deal with things like run-time interaction (when you press a  
> key
> during a scan to see the progress) and is unrelated to host timeouts.
>
> > So I get the same result but at a fraction of the time. The script
> > just do 2 things:
> > 1. nmap -sP -n 192.168.1.0/24 (avoiding DNS resolve)
> > 2. Passing the active adresses one by one to nmap again nmap -sL (IP-
> > adress)
> >
> > How can this be?
>
> Hm that is strange. It sounds to me like the records were CACHED  
> and the
> records that didn't resolve were NEGATIVE CACHED so you are  
> receiving the
> requests from your local nameserver which obviously makes the whole  
> process
> faster and more reliable.
I did several consecutiive runs with both methods and the one just  
using one ip address at a time is still faster.

Try for you self and do nmap -sL ip1 ip2 ip3 ip4 ip5 ip6 ip7 ip8

And a script that does

IPs.each |ip| do
        nmap -sL ip
end

I bet you a cold one the last one is faster :)


Cheers,
Henrik
> Best,
>
> Doug
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org


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