hakrevdns: Why Reverse DNS Lookups Still Matter in 2024
Hook
While most security tools race to map domains to IPs, hakrevdns does the opposite—and that’s exactly why bug bounty hunters love it. Going backward through DNS reveals infrastructure that forward enumeration completely misses.
Context
Traditional asset discovery follows a predictable path: start with a domain, enumerate subdomains, resolve those to IPs. But this approach has a blind spot. Companies often have internal services, staging environments, and legacy infrastructure sitting on IP ranges that aren’t linked from their main domains. These systems have reverse DNS (PTR) records pointing back to hostnames, but you’ll never find them through forward enumeration.
Before tools like hakrevdns, security researchers either wrote custom scripts or chained together standard Unix utilities like dig and xargs. The problem? DNS lookups are slow—typically 20-100ms each. When you’re checking thousands or millions of IPs in a cloud provider’s range, single-threaded approaches become impractical. You needed something that could fire off hundreds of concurrent queries while remaining simple enough to pipe into existing reconnaissance workflows. hakrevdns emerged from this gap: a single-purpose tool that does reverse DNS lookups fast, outputs clean results, and gets out of your way.
Technical Insight
hakrevdns is architecturally minimal, which is precisely its strength. The entire tool clocks in at a few hundred lines of Go, leveraging the language’s goroutines to parallelize DNS queries without the complexity of thread pools or callback hell. When you pipe IP addresses into hakrevdns, it spawns worker goroutines (default: 8) that pull from an input channel, perform lookups, and push results to an output channel.
Here’s a typical reconnaissance workflow combining hakrevdns with other tools:
# Generate IP range for a target's ASN
prips 104.16.0.0/12 | \
# Perform reverse DNS lookups with 50 concurrent workers
hakrevdns -t 50 | \
# Extract just the hostnames
awk '{print $2}' | \
# Filter for target's domain
grep 'targetcompany\.com$' | \
# Probe for live HTTP services
httprobe | \
# Take screenshots
aquatoneThis pipeline demonstrates hakrevdns’s Unix philosophy design. It doesn’t try to do IP range generation, HTTP probing, or filtering—it just does reverse DNS, fast. The -t flag controls concurrency, letting you tune based on your DNS resolver’s capacity and rate limits.
Under the hood, hakrevdns uses Go’s net.LookupAddr() function, which queries PTR records through the system’s configured resolver by default. But security researchers often need more control. You can specify a custom resolver to route queries through a specific DNS server:
# Use Google's DNS
cat ips.txt | hakrevdns -r 8.8.8.8
# Or use a list of resolvers to distribute load
cat ips.txt | hakrevdns -R resolvers.txtWhen you pass a resolver file with -R, hakrevdns round-robins through the list. This is critical for large-scale scans where a single resolver would rate-limit you. By spreading queries across multiple DNS servers—often a mix of public resolvers and organization-specific ones—you can sustain higher throughput without triggering defensive measures.
The concurrency model is straightforward but effective. Each worker goroutine operates independently:
// Simplified version of the core lookup logic
for ip := range inputChannel {
names, err := net.LookupAddr(ip)
if err != nil {
continue // Silently skip failures
}
for _, name := range names {
outputChannel <- fmt.Sprintf("%s\t%s", ip, name)
}
}This design choice—silently skipping errors—is controversial but pragmatic. During reconnaissance, you expect most IPs won’t have PTR records. Logging every failure would flood your output with noise. The tool optimizes for the happy path: finding the needles in the haystack.
One subtle but important feature: hakrevdns preserves the order of results relative to input. While lookups happen concurrently, the output mechanism ensures that results appear in a predictable sequence, making it easier to correlate findings with input ranges when reviewing results manually or processing them with position-dependent tools.
Gotcha
The biggest limitation is the silent failure mode. If your DNS resolver is down, rate-limiting you, or unreachable, hakrevdns will simply produce no output for those IPs. You won’t get an error message, a count of failures, or any indication that something went wrong. During a scan of 100,000 IPs, you might think you’re getting comprehensive results when actually 30% of queries are timing out. The only way to detect this is to manually verify a sample or compare expected versus actual output counts.
Rate limiting is another pain point. While you can tune concurrency with -t, there’s no built-in backoff or retry logic. If you set threads too high, DNS resolvers will start dropping queries, and hakrevdns won’t retry them. You have to experimentally determine safe concurrency levels for your resolvers, and those limits can change based on network conditions or provider policies. Tools like massdns and dnsx have sophisticated rate limiting mechanisms that automatically throttle when they detect packet loss—hakrevdns expects you to handle this externally.
The lack of structured output formats also becomes limiting when integrating with modern security platforms. Everything outputs as tab-separated ‘IP hostname’ pairs. If you need JSON for ingestion into a SIEM, database, or security orchestration platform, you’re writing post-processing scripts. For quick command-line workflows, this is fine. For automated pipelines that feed into centralized infrastructure, it creates friction.
Verdict
Use hakrevdns if you’re conducting security reconnaissance on IP ranges, performing asset discovery for bug bounties, or mapping network infrastructure where speed matters more than exhaustive error reporting. It excels when piped with other Unix tools in ad-hoc investigation workflows, and the minimal dependency footprint (just compile and run) makes it perfect for quickly spinning up on cloud instances during engagements. Skip it if you need production-grade reliability with retry logic and rate limiting, require structured output formats like JSON for automated ingestion, or want detailed logging to audit what succeeded versus failed. In those cases, reach for dnsx or massdns instead. For everything else, hakrevdns does exactly what it promises: reverse DNS lookups, fast and simple.
