mass_rdns fails to resolve if the name in reply is in upper case

[lnussbaum]

Some DNS servers might not respect the case of the name sent in the query when sending the reply. At least this is the case of bind 9.10, as shown below. This breaks (reverse) DNS resolution.

After flushing the DNS server's cache (rndc flush):

# host -t ptr 8.193.93.128.IN-ADDR.ARPA 172.16.111.118
Using domain server:
Name: 172.16.111.118
Address: 172.16.111.118#53
Aliases: 

8.193.93.128.in-addr.arpa domain name pointer prod-gitlab.inria.fr.

But if I ask again immediately, I get the answer from cache, which is cached in upper case:

# host -t ptr 8.193.93.128.IN-ADDR.ARPA 172.16.111.118
Using domain server:
Name: 172.16.111.118
Address: 172.16.111.118#53
Aliases: 

8.193.93.128.IN-ADDR.ARPA domain name pointer prod-gitlab.inria.fr.

... even if asked in lowercase:

# host -t ptr 8.193.93.128.in-addr.arpa 172.16.111.118
Using domain server:
Name: 172.16.111.118
Address: 172.16.111.118#53
Aliases: 

8.193.93.128.IN-ADDR.ARPA domain name pointer prod-gitlab.inria.fr.

This breaks DNS::Factory::ptrToIp, because it uses std::string::find to match 'in-addr.arpa': https://github.com/nmap/nmap/blob/master/nmap_dns.cc#L1438

As a result, DNS resolution times out and fails:

# nmap -dd -sL 128.93.193.8 -dns-server 172.16.111.118

Starting Nmap 7.40 ( https://nmap.org ) at 2020-06-20 20:42 CEST
Fetchfile found /usr/bin/../share/nmap/nmap.xsl
The max # of sockets we are using is: 0
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
mass_rdns: Using DNS server 172.16.111.118
NSOCK INFO [0.0010s] nsock_iod_new2(): nsock_iod_new (IOD #1)
NSOCK INFO [0.0010s] nsock_connect_udp(): UDP connection requested to 172.16.111.118:53 (IOD #1) EID 8
NSOCK INFO [0.0010s] nsock_read(): Read request from IOD #1 [172.16.111.118:53] (timeout: -1ms) EID 18
Initiating Parallel DNS resolution of 1 host. at 20:42
NSOCK INFO [0.0010s] nsock_write(): Write request for 43 bytes to IOD #1 EID 27 [172.16.111.118:53]
NSOCK INFO [0.0010s] nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 8 [172.16.111.118:53]
NSOCK INFO [0.0010s] nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 27 [172.16.111.118:53]
NSOCK INFO [0.0310s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 18 [172.16.111.118:53] (295 bytes)
NSOCK INFO [0.0310s] nsock_read(): Read request from IOD #1 [172.16.111.118:53] (timeout: -1ms) EID 34
NSOCK INFO [4.0010s] nsock_write(): Write request for 43 bytes to IOD #1 EID 43 [172.16.111.118:53]
NSOCK INFO [4.0010s] nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 43 [172.16.111.118:53]
NSOCK INFO [4.0310s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 34 [172.16.111.118:53] (295 bytes)
NSOCK INFO [4.0310s] nsock_read(): Read request from IOD #1 [172.16.111.118:53] (timeout: -1ms) EID 50
NSOCK INFO [8.0010s] nsock_write(): Write request for 43 bytes to IOD #1 EID 59 [172.16.111.118:53]
NSOCK INFO [8.0010s] nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 59 [172.16.111.118:53]
NSOCK INFO [8.0310s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 50 [172.16.111.118:53] (295 bytes)
NSOCK INFO [8.0320s] nsock_read(): Read request from IOD #1 [172.16.111.118:53] (timeout: -1ms) EID 66
mass_rdns: 13.00s 0/1 [#: 1, OK: 0, NX: 0, DR: 0, SF: 0, TR: 3]
Completed Parallel DNS resolution of 1 host. at 20:42, 13.00s elapsed
NSOCK INFO [13.0010s] nsock_iod_delete(): nsock_iod_delete (IOD #1)
NSOCK INFO [13.0010s] nevent_delete(): nevent_delete on event #66 (type READ)
DNS resolution of 1 IPs took 13.00s. Mode: Async [#: 1, OK: 0, NX: 0, DR: 1, SF: 0, TR: 3, CN: 0]
Nmap scan report for 128.93.193.8
No data files read.
Nmap done: 1 IP address (0 hosts up) scanned in 13.00 seconds

This is a regression introduced in commit e090e09. The current master is still affected. I'll submit a PR in a minute.

[dmiller-nmap]

Thanks a bunch for finding this bug! I appreciate the patch, too. I'm going to end up committing a different fix that avoids a bunch of the STL string copy/append operations in the original; there's nothing wrong with your patch, I just saw an opportunity to improve the performance of the original. You'll get a changelog credit for the fix, too, since you found exactly where the problem was; that's 90% of the work right there!