## 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.

```text
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
1. 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.
2. 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.
3. 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.
4. 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.
5. 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