Re: Q: Does DNS code implement any ping/canary probes?

David Fifield <[email protected]> Sat, 10 Nov 2018 11:17:14 -0700
Newsgroups gmane.comp.security.nmap.devel
Message-ID <[email protected]>
On Sat, Nov 10, 2018 at 02:27:46PM +0100, Jacek Wielemborek wrote:
> I'm comparing nmap_dns.cc to scan_engine.cc and while I'm under the impression
> that Nmap uses a rate limiting scheme (could you confirm?), but I found no code
> for ping/canary probes. I mean an equivalent of ones from scan_engine.cc that
> are regularly sent with a request we already have an answer for, just to find
> out if the network is congested. Is there an equivalent in DNS scanning code?
> If not, would it make sense to add it?

You are right about the rate limiting, nmap_dns.cc has a rate limiting
scheme, but one that is independent of --min-parallelism/--max-retries/--max-rate.

I don't think reverse DNS has any canary probes--but unless I'm
mistaken, it doesn't need them. In a port scan, it's common for almost
all of your probes to be ignored--giving you no performance feedback--so
mix in some canary probes that are known to elicit a reponse, and if you
start dropping the canaries, you know you need to slow down. In
contrast, a DNS server should always return a response to a well-formed
query, even if it's an NXDOMAIN, so there's no reason to re-query an
already known name just for the sake of performance feedback, when you
could get the same feedback by querying a name you haven't tried yet.
But maybe there's something about the context I'm missing.

> Also, why is CAPACITY_MAX hardcoded and not dependent on -Tn?

I think it's just historical reasons; nmap_mass_rdns evolved separately
from ultra_scan.
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/