mailing list archives
Re: Finding v6 hosts by efficiently mapping ip6.arpa
From: Patrik Karlsson <patrik () cqure net>
Date: Thu, 5 Apr 2012 17:02:35 +0200
On Thu, Apr 5, 2012 at 4:42 AM, Daniel Miller <bonsaiviking () gmail com>wrote:
In regards to scanning the 2a01:238:42a8:e700::/48, I just did, got 4
in less than 2 seconds.
This might have to do with different DNS servers treating incomplete
names differently. That's why I suggested a "check" function to see
how it handles a known-good PTR record being truncated. If it doesn't
treat it differently than a nonexistent record, then there's no point
in completing the search.
The way I understand it, it's how the autoritative DNS servers handle the
queries, not the local recursive ones.
This would imply that we should get the same answers as we were scanning
the same zone.
As far as I can tell the authoritative servers in this case both return 4
records in just a few (2-4) seconds.
I guess there is a risk of missing records in case the scan is using a
local recursive DNS server and can't get usable answers from one of the
authoritative servers, but that shouldn't be the case here.
The way the script works it adds a nibble to the prefix and requests a PTR
record iterating over 0-f. In the case it gets a NOERROR, and only then, it
adds the truncated record to the "queue". In the next "round" it goes over
the queue and does the 0-f iteration for all records in the queue. The
queue is cleared between rounds and if there are no records in the queue it
aborts. So using a known record and truncating it does not make sense (at
least to me) to test support, and again, if no records are found in one
round, the script will abort.
The worst thing that could happen is that the resolver returns NOERROR for
every truncated record, at this point, the scan will go on for a long time.
In order to determine this I guess one could supply an ipv6 address in the
range known not to have a ptr record and truncated only the last nibble,
which would work as long as there is no other entry in that range.
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/