Bug 1390326

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