mass_rdns fails to resolve if the name in reply is in upper #2

[witold-swierzy]

Fix described here : #2068 (comment) works fine for nmap 7.98 x86 - linux (Ubuntu 26.04)
details:
nmap --version
Nmap version 7.98 ( https://nmap.org/ )
Platform: x86_64-pc-linux-gnu
Compiled with: liblua-5.4.8 openssl-3.5.5 libssh2-1.11.1 libz-1.3.1 libpcre2-10.46 libpcap-1.10.6 nmap-libdnet-1.18.0 ipv6
Compiled without:
Available nsock engines: epoll poll select
it also works for Oracle Linux 9, nmap 7.92
details:
nmap --version
Nmap version 7.92 ( https://nmap.org )
Platform: x86_64-redhat-linux-gnu
Compiled with: nmap-liblua-5.3.5 openssl-3.5.5 libz-1.2.11 libpcre-8.44 libpcap-1.10.0 nmap-libdnet-1.12 ipv6
Compiled without: libssh2
Available nsock engines: epoll poll select

but IT DOES NOT WORK for nmap 7.99 on MacOS Tahoe 26.5.2
details:
nmap --version
Nmap version 7.99 ( https://nmap.org/ )
Platform: arm-apple-darwin25.3.0
Compiled with: nmap-liblua-5.4.8 openssl-3.6.3 libssh2-1.11.1 libz-1.2.12 libpcre2-10.47 nmap-libpcap-1.10.6 nmap-libdnet-1.18.0 ipv6
Compiled without:
Available nsock engines: kqueue poll select

I am not able to check if this issue is platform/OS-specific or version specific

[toor11]

I looked into whether the case-handling path changed between the versions you tested, and I
don't think the difference you're seeing is in the decoding.

DNS::Factory::ptrToIp() — the function that maps a PTR name back to an address, and the
one the #2068 fix landed in — is byte-identical in 7.98, 7.99, and current master. I
extracted it from the 7.98 and 7.99 release tarballs and from master and diffed all three;
there is no difference. (It also moved file in June 2026, from nmap_dns.cc to
libnetutil/massdns.cc, but that commit didn't change the function body either.)

Its case-insensitivity comes from strcasestr() for the suffix plus explicit A-F/a-f
handling for IPv6 nibbles. Running that exact function body against uppercase input:

156.32.33.45.in-addr.arpa   -> 45.33.32.156
156.32.33.45.IN-ADDR.ARPA   -> 45.33.32.156
156.32.33.45.In-Addr.Arpa   -> 45.33.32.156
...8.b.d.0.1.0.0.2.ip6.arpa -> 2001:db8::1
...8.B.D.0.1.0.0.2.IP6.ARPA -> 2001:db8::1

So uppercase .IN-ADDR.ARPA still decodes correctly on current code.

One thing that may help re-frame the search: 7.99 is newer than 7.98 (7.99 released
2026-03-26, 7.98 released 2025-08-21), so the working/failing pair is
older-works / newer-fails rather than a platform split. Diffing nmap_dns.cc across that
window, the only reverse-DNS behavioural change is the GH#3280 fix, which reworked how
requests are paced onto the wire (server_send() / write_busy) — not how replies are
matched or decoded.

That makes request pacing, or a difference in what the two resolvers actually return, more
likely candidates than case handling. Could you attach the mass_dns: lines from

nmap -dd --dns-servers <your-dns-server> -sL <target-ip>

on both the working Linux host and the failing macOS host? Those trace lines show whether
the reply is arriving and being rejected, or not arriving at all, which would separate the
two possibilities. If it's useful I'm happy to dig further once those are up.