Assets Discovery Scan to Windows Devices using PowerShell can Result in Incorrect Network Interface Details

Issue Summary

When using Assets Discovery to Scan Windows Devices using PowerShell, the tool uses nslookup to collect host and ip information where it then adds the values to the <NetworkInterfaceInfo> section of the scan results.

For example: Here is a successful nslookup command

% nslookup windows.atlassian.com
Server:  dns.atlassian.com
Address: 10.125.56.53#53

Non-authoritative answer:
Name: windows.atlassian.com
Address: 114.172.142.12

Where the "Server/Address" block is the DNS server used to query, and the "Name/Address" block is the actual response details. The "Name/Address" is what Discovery is trying to target with this workflow.

Bug:

If the nslookup command returns a non-existent host error, and the DNS server hostname includes NAME in the entry, then Assets Discovery will use the DNS server information from the "server/address" block and add that to the Scan Results.

As a result, inaccurate network interfaces can be found in the Assets Object Schema

Replication Steps:

• Setup Assets Discovery to scan two IP addresses where one IP ties to a valid Windows Host and the other is a non-existent host, using powershell. Both hosts should be on a network which uses a DNS server that has a hostname that contains "name" in the entry.
• Run the scan using Discovery.exe

Expected Results

Discovery finds one host with one valid network interface because the Windows host was valid, and the other IP address pointed to a non-existent entry

Valid:

%  nslookup windows.atlassian.com
Server: dns.mydomainname.com
Address 1.2.3.4

Non-authoritative answer: 
Name: windows.atlassian.com 
Address: 114.172.142.12

Invalid:

% nslookup windows.atlassian.com
Server: dns.mydomainname.com
Address 1.2.3.4 

** server can't find <non-existent host ip address>.in-addr.arpa: NXDOMAIN

And therefore the <NetworkInterfaceInfo> section of the scan results only contains a single entry

Actual Results

Two IPs are Associated with the network interface scan results detail because the DNS server hostname has "NAME" in the entry and In the object schema you see multiple IP addresses associated to the Network Interface Attribute

Workaround

Currently there is no known workaround for this behavior. A workaround will be added here when available