Qualys provides multiple mechanisms for tracking assets in your environment; IP, DNS, NetBIOS, Agent, and EC2. Agent and EC2 tracking are for specific use cases and I won’t be discussing them here. When it comes to selecting the appropriate tracking mechanism for an asset, the choice is mostly driven by whether or not the IP address of a given asset is likely to change, and secondarily if there are requirements to match or merge Qualys data with data from another source, such as a CMDB using DNS names. In Qualys IP tracking is the default mechanism.
It is important to understand that in Qualys, unlike some other products, scanning and reporting are two entirely different things. Scanning by one method has no implication on the ability or requirement to report using that method. Generally it is better in Qualys to scan blocks of address space, defined by the networks a particular scanner or group of scanners can reach, and then potentially report using different methods tailored to fit your audience(s). For example scanning all your internal RFC1918 address space weekly using asset groups that reflect the ranges for all your network segments, and reporting on risk by line of business, and on remediation by platform team. Scanning everything, all the time, ensures that the asset data is as complete and up to date as possible, and that assets (particularly “rogue” or unknown-unknown assets) are not missed.
DNS and NetBIOS tracking are most useful for DHCP networks. Although not a requirement, I recommend using IP tracking for networks where there is little churn, primarily because it eliminates a dependency on an external system. Tools like Qualys are very good at uncovering misconfiguration, performance issues, inaccuracies, and other problems in core services upon which they depend. For DHCP ranges I recommend using DNS rather than NetBIOS as it is more inclusive, and because NetBIOS is becoming less and less common and less supported. NetBIOS is legacy and you only need it if you are using old applications or old versions of Windows that require it or use WINS. All modern DHCP clients, including Windows clients, perform DDNS updates allowing DNS to be accurate and complete without human interaction, whereas many assets may not support NetBIOS. In the modern Windows environment we are typically using Domain Controllers for DNS name resolution, but even if we aren’t, BIND and other DNS servers can be configured to allow secure DDNS updates from DHCP servers. Similarly, modern wireless network controllers can be configured to securely perform DDNS updates for the assets to which they are serving DHCP leases, important for example in tracking assets on BYOD wireless networks.
When scanning by IP address, during discovery Qualys performs a reverse lookup of the IP address. The name that is returned is used as the DNS name for the asset, and reported in QID 6. If the IP is in a DNS tracked range, that name is used (and is required) for tracking purposes. When the scan data is processed following a scan, and if the IP is in a DNS tracked range, either an existing asset is updated or a new asset is created using on that DNS name. If there is no reverse zone entry (PTR record) for the IP address, then for DNS tracked ranges this asset is marked as unresolved and is not scanned. If there are multiple PTR records for a single IP, or multiple IP addresses with a matching name value in the PTR record (unusual, unrecommended, but not impossible configurations - sometimes used when a single mail server supports multiple domains, or when DNS trickery is used for round robin load balancing or geolocation) we will use the first record returned. If this is not consistently the same record, there exists the possibility of Qualys creating multiple records for the same asset or with multiple assets combining scan data with unpredictable results. So be aware of these situations in your environments and develop a scanning/reporting strategy to accommodate them. When scanning a host in a DNS tracked range by IP address, that host must have a reverse zone entry in order to create or update an asset in the Qualys host assets data. If it does not, it will not be scanned and will be marked as unresolved.
Scan by DNS
When scanning by DNS name we necessarily first do a forward zone lookup to resolve the name to an IP address. In this case Qualys uses the forward zone and not the reverse zone as the DNS name reported in QID 6, and for asset creation and updating. In this case a name must be resolvable in order to scan. It is important to note this difference between scan by IP and scan by name for DNS tracked range, because there is nothing in DNS that requires forward and reverse zones to match. Quite apart from admin errors, there may be a design choice preventing forward and reverse zones from matching. For example where a 3rd party owns and manages the network. In this case we often see the forward zone being managed by the customer, and the reverse zone being managed by the provider, and the names not matching. It only presents a problem where scanning and/or reporting is not consistently using the same zone, either forward or reverse.
As a rule I do not recommend scanning by DNS name. Usually when I see a customer scanning by DNS name it is because they really have a requirement for reporting by DNS name. There is no requirement in Qualys for scanning and reporting to use the same mechanism. Generally you should be scanning everything, all the time, and tailoring report scope and target to the constituent audiences.
My recommendation is to obtain DHCP ranges from the network team. These should be easily available from your Active Directory, Cisco, Wireless Controller, or other configurations. Configure these ranges in Assets->Host Assets as DNS tracked, and ensure DNS is accurate and updated timely. Again, DDNS from modern DHCP clients is the way to go. Note, if you are changing a network range that you have been previously scanning from IP tracked to DNS tracked all currently existing assets in the range must have a DNS name associated with them. If they do not, Qualys will throw an error when you try to convert the range.
Some customers have used the results of an asset search to selectively change the tracking mechanism for individual assets and discovered that this does not always work as you might expect. What is happening here is that you are changing the tracking mechanism for the asset entry in the Qualys host data, and for that specific IP address. However it is not telling Qualys to automatically set the tracking mechanism any time we see that particular target system. This is a subtle but important difference. Essentially you are changing the asset entry in the database to DNS tracked (after purging any existing conflicts), and creating a DNS tracked range where the size of the range is a single IP address. In subsequent scans, if that same target system always resolves to an IP that is in an DNS tracked range, then it will behave as expected, by updating the existing asset in the host data and changing the IP address to the one the asset is most recently detected on. If, however, that asset has received a new DHCP lease for an address not previously defined as DNS tracked (i.e. it is still an IP tracked address), a new IP tracked asset will be created and the previous DNS tracked asset will remain untouched from the prior scan. Additionally, if over time multiple systems are detected on that DNS tracked address, the address may accumulate DNS tracked entries associated with it. Because of this I strongly recommend creating DNS tracked ranges directly from the the DHCP server and configuring them in Assets->Host Assets.
When it comes to reporting, you can create an Asset Group with DNS names and use that as the target for a report. It is important to note that these names are not resolved when the report is run, but just used to search the asset database for matching assets. Be aware that it is possible to have multiple assets in the Qualys host data with the same DNS name as long as no more than one of them are DNS tracked. If you need to report on a set of assets from a CMDB where the CMDB tracks assets by name, this is the mechanism I recommend you use. Configure network ranges in Assets->Host Assets to track by IP or DNS as appropriate, scan by IP address blocks, scan frequently, and report based on names if required, updating or recreating reporting asset groups via API.
NetBIOS name, which is used for Windows (SMB) type sharing and messaging, is significantly different from DNS. First, NetBIOS can be used not just for name-to-IP resolution, to identify specific computers, but also for people, services, and groups. Second, NetBIOS doesn’t have the concept of forward and reverse zones like DNS. Finally, NetBIOS has multiple mechanisms for resolving names, including via a WINS server, via broadcasts, and by interrogating a host. Broadcast resolution uses 137/udp and only works on local segments as routers don’t forward broadcasts. Broadcast NetBIOS resolution works in a similar way as ARP does to resolve IP addresses to MAC addresses, except at a higher layer in the OSI stack. This means that cross-network name resolution requests are almost always handled by WINS. Just to muddy the waters, for a time Microsoft allowed IP host names to be used as a substitute for NetBIOS names, however this has been deprecated since Windows 2000. If you decide to use NetBIOS tracking you will need to configure your scanners to point to WINS servers as Qualys uses these for forward resolution of NetBIOS names. Reverse resolution tries to get the name from the target, usually via "NETBIOS name service" or NTLM AV_PAIRs. The NetBIOS service operates over 139/tcp and this port must be included in the scan options when scanning by or tracking by NetBIOS (it is part of the Standard and Full options).