nmap "Failed to resolve" hostname error during authorized pentest scope scan
Fixes nmap's Failed to resolve error for hostnames in an authorized pentest scope: verifying DNS, pointing nmap at the engagement's authoritative nameserver with --dns-servers, and falling back to scanning the resolved IP. Use when the scan dies before any packet is sent. Not for scan failures after resolution succeeds.
TL;DR
"Failed to resolve" means nmap could not turn the hostname into an IP address, so the scan never started. During an authorized engagement this is almost always a DNS gap: the name lives in the client's internal zone and your box is asking the wrong nameserver. Point nmap at the authoritative nameserver from the scope document with --dns-servers, or resolve the name another way and scan the IP.
Failed to resolve "web01.corp.internal".Use this when
- nmap exits before scanning anything and prints Failed to resolve.
- The hostname came from the authorized scope sheet for the engagement.
- Other scans against IPs in the same engagement work fine.
Not for this skill when
- DNS resolves but the scan itself fails. That is a different failure.
- You are testing name resolution for defense, not running a scope scan.
Steps
- Prove the gap is DNS, not nmap:
dig +short web01.corp.internal. If dig also fails, the resolver is the problem, not nmap. Verify: dig returns nothing or SERVFAIL while the scope sheet lists the name. - Check which nameserver your box uses:
cat /etc/resolv.conf. During engagements the client usually supplies an authoritative nameserver for the target zone. Verify: you have the IP of the nameserver that should answer for this zone. - Re-run nmap pointed at it:
nmap --dns-servers 192.0.2.53 -sS web01.corp.internal. Verify: the Failed to resolve line disappears and the scan starts. - If it still fails, the record may not exist as you spelled it. Check for CNAME chains and typos against the scope sheet, comparing character by character. Verify: you know the exact correct name before the next scan attempt.
- As a fallback, resolve the name once and scan the IP directly, documenting the substitution in your notes so the report maps findings to the right asset. Verify: the scan completes against the resolved address.
Compatibility: nmap 7.x, Linux, macOS, Windows. The --dns-servers flag exists in all current builds.
Variant phrasings
nmap could not resolve hostname
Same fix path, common phrasing.
nmap DNS resolution failed during scan
Symptom-level search.
Failed to resolve given hostname or IP
The alternate wording some nmap versions print.
Why it happens
nmap resolves every target name to an IP before sending a single packet. If the name only exists in the client's internal DNS and your box queries a public resolver, or the VPN tunnel drops DNS traffic, resolution fails and nmap quits on that target. Split-DNS environments during engagements are the usual cause.
Edge cases / pitfalls
- VPN clients often fail to push the engagement DNS. Check resolv.conf after connecting, not before.
- NetworkManager and systemd-resolved can overwrite /etc/resolv.conf. Pin the nameserver for the engagement network.
- Some scope sheets list short names that only resolve through the client's search domains. Append the full domain before scanning.
- Scan only the names in your written authorization. A resolving name outside scope is still outside scope.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_H6wOc6wpR1pRTAfQNyLVPw