Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
lnussbaum opened this issue Jun 20, 2020 · 2 comments
Closed

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

lnussbaum opened this issue Jun 20, 2020 · 2 comments
Labels
Nmap

Comments

@lnussbaum
Copy link

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.
@lnussbaum lnussbaum added the Nmap label Jun 20, 2020
lnussbaum pushed a commit to lnussbaum/nmap that referenced this issue Jun 20, 2020
Make DNS::Factory::ptrToIp case insensitive
e10e958 
Fixes nmap#2068
@lnussbaum lnussbaum mentioned this issue Jun 20, 2020
Closed
@dmiller-nmap
Copy link

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!

@dmiller-nmap dmiller-nmap mentioned this issue Jun 22, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Nmap
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Make DNS::Factory::ptrToIp case insensitive lnussbaum/nmap
3 participants
@lnussbaum @dmiller-nmap and others