1

My objective here is to get nmap to resolve IPs to hostnames without the --system-dns flag or the --dns-servers option.

When I issue the following nmap command without the --system-dns flag or --dns-servers option, 192.168.0.16 is resolved to hostname server1.example.com. 192.168.0.17 is not resolved to a hostname. I understand this is occurring because according to https://nmap.org/book/host-discovery-dns.html, "Nmap uses a custom stub resolver", meaning that nmap has it's own DNS resolver, and not our local DNS servers. Interesting.

[root@client1]# nmap -sn 192.168.0.0/24 -vvv

Initiating Parallel DNS resolution of 256 hosts. at 11:22
Completed Parallel DNS resolution of 256 hosts. at 11:22, 0.02s elapsed
DNS resolution of 18 IPs took 0.02s. Mode: Async [#: 2, OK: 5, NX: 13, DR: 0, SF: 0, TR: 18, CN: 0]

Nmap scan report for server1.example.com (192.168.0.16)
Host is up (0.00063s latency).
Nmap scan report for 192.168.0.17
Host is up (0.00059s latency).

This issue does not occur when the --system-dns flag is being used.

[root@client1]# nmap -sn 192.168.0.0/24 --system-dns

Nmap scan report for server1.example.com (192.168.0.16)
Host is up (0.00029s latency).
Nmap scan report for server2.example.com (192.168.0.17)
Host is up (0.00026s latency).

This issue does not occur when the --dns-servers option is used to declare that our primary DNS server (192.168.0.6) should be used.

[root@client1]# nmap -sn 192.168.0.0/24 --dns-servers 192.168.0.6

Nmap scan report for server1.example.com (192.168.0.16)
Host is up (0.00039s latency).
Nmap scan report for server2.example.com (192.168.0.17)
Host is up (0.00036s latency).

nslookup shows that both IPs can be resolved to their appropriate hostnames.

[root@client1]#  nslookup 192.168.0.16
16.0.168.192.in-addr.arpa       name = server1.example.com.

[root@client1]# nslookup 192.168.0.17
17.0.168.192.in-addr.arpa       name = server2.example.com.

We are using CentOs 7 as our Operating System. /etc/resolv.conf contains the following, meaning that 192.168.0.6 is our primary DNS server.

[root@client1]# cat /etc/resolv.conf

nameserver 192.168.0.6
nameserver 8.8.8.8

192.168.0.6 (our primary DNS server) is using version 9 of Bind as the DNS service.

[root@dns1]# named -v
BIND 9.9.4-RedHat-9.9.4-51.el7 (Extended Support Version)

Here is the relevant snippet of /var/named/forward.example.com.

[root@dns1]# cat /var/named/forward.example.com

$ORIGIN example.com.
$TTL 1D
@       IN      SOA     ns1.example.com. hostmaster.example.com. (
                                        2016032200 ; serial
                                        1D         ; refresh
                                        1H         ; retry
                                        1W         ; expire
                                        3H         ; minimum
)

;name used for the nameserver
        IN      NS      ns1.example.com.

;ip address of the nameserver
ns1     IN      A       192.168.0.6

;hostname to ip address resolutions
server1         IN      A       192.168.0.16
server2         IN      A       192.168.0.17

Here is a snippet of /var/named/reverse.example.com.

[root@client1]# cat /var/named/reverse.example.com

$TTL 1D
@       IN      SOA     ns1.example.com. root.example.com. (
                                        0 ; serial
                                        1D ; refresh
                                        1H ; retry
                                        1W ; expire
                                        3H ; minimum
)

0.168.192.in-addr.arpa. IN      NS      ns1.example.com.

@       IN      NS      ns1.example.com.
ns1     IN      A       192.168.0.6
16      IN      PTR     server1.example.com.
17      IN      PTR     server2.example.com.
4
  • Why aren't you just using --system-dns? – Michael Hampton Sep 1 '20 at 12:42
  • @MichaelHampton Maybe because the nmap team claims : "By default, Nmap resolves IP addresses by sending queries directly to the name servers configured on your host and then listening for responses. Many requests (often dozens) are performed in parallel to improve performance. Specify the --system-dns option to use your system resolver instead (one IP at a time via the getnameinfo call). This is slow and rarely useful unless you find a bug in the Nmap parallel resolver (please let us know if you do)." – HermanB Sep 1 '20 at 15:04
  • 1
    @MichaelHampton The reason for not using --system-dns or --dns-servers is because the ultimate goal here is to use the Ansible nmap inventory plugin (which is probably beyond the scope of this question) and the Ansible nmap inventory plugin does not support the --system-dns or --dns-server options. – JeremyCanfield Sep 1 '20 at 17:33
  • Well, that's a good reason, and it looks like @HermanB came up with the answer while I was in the hospital. Enjoy :) – Michael Hampton Sep 1 '20 at 18:43
5

The root of your problem is your /etc/resolv.conf and how nmap parses that.

    # /etc/resolv.conf

    nameserver 192.168.0.6
    nameserver 8.8.8.8

Only the first of your nameserver entries is qualified to answer queries for your local domain and network.

The second nameserver is public resolver that won't be able to respond to reverse DNS queries for private IP-ranges.

Unlike the system resolver, which by default uses the first nameserver entry in /etc/resolv.conf and only uses the next one(s) when the first nameserver doesn't resond, Nmap uses all nameservers entries found in /etc/resolv.conf in parallel (with the implied assumption that they are all equivalent).

Since in your case the different nameservers are not equivalent, only some of the reverse DNS queries succeed and you see some IP-addresses get resolved to hostnames (when your first name server was queried) and others not (when your second name server was used).

Remove or comment out the second nameserver and nmap -sn 192.168.0.0/24 -vvv should get the same results as nmap -sn 192.168.0.0/24 -vvv --system-dns and nmap -sn 192.168.0.0/24 -vvv --dns-servers 192.168.0.6

1
  • Awesome, commented out nameserver 8.8.8.8 in /etc/resolv.conf resolved this issue. Wonderful solution! – JeremyCanfield Sep 1 '20 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.