Red Hat Bugzilla – Bug 1390326
nmap is not able to resolve hostname.
Last modified: 2018-04-10 04:37:10 EDT
There is the same issue on nmap-6.40-7.el7. Tested on the same scenario as was described in original bug 1284866. # nmap -O -T5 192.168.23.84 Starting Nmap 6.40 ( http://nmap.org ) at 2016-10-31 12:58 EDT Nmap scan report for 192.168.23.84 Host is up (0.000011s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 2049/tcp open nfs Device type: general purpose Running: Linux 3.X OS CPE: cpe:/o:linux:linux_kernel:3 OS details: Linux 3.7 - 3.9 Network Distance: 0 hops # nmap -O -T5 192.168.23.84 --system-dns Starting Nmap 6.40 ( http://nmap.org ) at 2016-10-31 12:58 EDT Nmap scan report for www.example.com (192.168.23.84) Host is up (0.0000090s latency). Not shown: 997 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 2049/tcp open nfs Device type: general purpose Running: Linux 3.X OS CPE: cpe:/o:linux:linux_kernel:3 OS details: Linux 3.7 - 3.9 Network Distance: 0 hops
Where is the name record for 192.168.23.84 defined? Is it in /etc/hosts? Nmap's internal resolver parses /etc/hosts and searches it first, falling back to its parallel reverse-DNS resolver if an entry does not exist. It's possible that there's a bug in /etc/hosts parser, though it's very old and robust. We made changes to it in Nmap 6.49BETA6 to support IPv6, but those changes are not in 6.40. Another possibility is a bug in the reverse-DNS resolver. We made big changes to this in Nmap 7.00 and again in 7.30 to handle more edge cases like truncated answers and other oddities. The final possibility is that the system resolver is using some other method unknown to Nmap to resolve this name. NIS+, LDAP, or other directory services could be providing the name, and Nmap is unable (in this particular scan phase) to use those services.
Hi Daniel, the record for 192.168.23.84 is defined in named reverse zone. # cat /etc/named.conf ... zone "23.168.192.in-addr.arpa" IN { type master; file "/var/named/tmp.lOpim5IhLe"; }; # cat /var/named/tmp.lOpim5IhLe $TTL 2d ; 172800 seconds $ORIGIN 23.168.192.IN-ADDR.ARPA. @ IN SOA ns1.example.com. hostmaster.example.com. ( 2003080800 ; serial number 3h ; refresh 15m ; update retry 3w ; expiry 3h ; nx = nxdomain ttl ) IN NS ns1.example.com. IN NS ns2.example.com. IN NS cdnxxxx0.ccsrm.in. IN NS cdnxxxx1.ccsrm.in. IN NS rdndlxx0.ccsrm.in. IN NS rdnhrxx0.ccsrm.in. IN NS rdnkaxx0.ccsrm.in. IN NS rdncaxx0.ccsrm.in. IN NS rdnmbxx0.ccsrm.in. IN NS rdnrjxx0.ccsrm.in. IN NS rdntnxx0.ccsrm.in. IN NS rdnmhxx0.ccsrm.in. IN NS rdngjxx0.ccsrm.in. IN NS rdnapxx0.ccsrm.in. IN NS rdnkrxx0.ccsrm.in. IN NS rdnpbxx0.ccsrm.in. IN NS rdnuwxx0.ccsrm.in. IN NS rdnuexx0.ccsrm.in. IN NS rdnmpxx0.ccsrm.in. IN NS rdncdxx0.ccsrm.in. IN NS rdnhpxx0.ccsrm.in. IN NS rdnbhxx0.ccsrm.in. IN NS rdnosxx0.ccsrm.in. IN NS rdnasxx0.ccsrm.in. IN NS rdnnexx0.ccsrm.in. IN NS rdnjkxx0.ccsrm.in. 84 IN PTR www.example.com. 2 IN PTR joe.example.com. 17 IN PTR bill.example.com. 10 IN PTR hrwbdlxx1.ccsrm.in. 11 IN PTR hrwbdlxx2.ccsrm.in. 12 IN PTR hrdbdlxx1.ccsrm.in. 13 IN PTR hrdbdlxx2.ccsrm.in. 31 IN PTR hrsmdlxx1.ccsrm.in. 32 IN PTR hrsmdlxx2.ccsrm.in. # host 192.168.23.84 ;; Truncated, retrying in TCP mode. 84.23.168.192.in-addr.arpa domain name pointer www.example.com. # nmap -O -T5 192.168.23.84 | grep 'www.example.com' # nmap -O -T5 --system-dns 192.168.23.84 | grep 'www.example.com' Nmap scan report for www.example.com (192.168.23.84) The issue is the same as was reported in bug 1284866 for rhel-6. The issue is that nmap can't handle dns response higher that 512B, because it uses only udp. When I switch from internal resolver to system resolver (--system-dns), it works. It was fixed in rhel-6.
(In reply to Daniel Miller from comment #1) > Another possibility is a bug in the reverse-DNS resolver. We made big > changes to this in Nmap 7.00 and again in 7.30 to handle more edge cases > like truncated answers and other oddities. Thanks Daniel. We had downstream version of [1] for truncated answers in RHEL6 but it's missed in RHEL7. [1] https://github.com/nmap/nmap/commit/0c1d68d6de6b43c0aff8d58fed36cb5025472ecb
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0661