hakrevdns: Batch Reverse DNS Lookups from the Command Line

Why hakrevdns Targets IP-to-Hostname Workflows

hakrevdns solves a narrow but common infrastructure task: converting many IPv4 addresses into DNS hostnames. The README describes the contract simply: the tool receives IP addresses and returns hostnames. Its intended use is reconnaissance of the relationship between an organization and its public addresses. The README specifically suggests finding domains and subdomains belonging to a company from its IP addresses.

This places the project in the asset-discovery stage of security research. An IP list can come from a network range, supplied observations, or another reconnaissance step, but hakrevdns does not generate that list itself. It transforms existing IPv4 input into PTR-based DNS names. That boundary matters because a reverse DNS answer is a DNS fact, not proof that the named host is controlled by the address owner. Shared infrastructure, hosting providers, and delegated mail systems can produce names associated with the same address without representing a dedicated organizational subdomain.

The tool is written in Go and is designed for Unix-style pipelines. Standard output is easy to pass to programs such as `httprobe`, as shown in the README. This makes it more useful as a processing stage than as a graphical investigation application. It does not present historical DNS data, validate returned names against other services, or distinguish authoritative records from resolver observations. Those tasks remain outside the behavior documented for the project.

Inside hakrevdns Concurrent Reverse DNS Processing

Based on the repository layout, the project is compact: `main.go` sits beside the README and MIT license. Its documented data path is line-oriented. IP addresses enter through standard input, `hakrevdns` performs reverse lookups, and results are written as IP address and hostname pairs. The optional `-d` mode removes the IP address and emits domains alone.

Concurrency is controlled with `-t`, which the help output describes as the number of threads and gives a default of 8. Resolver behavior can be changed with `-r` for one resolver IP, `-R` for a file containing one resolver IP per line, and `-U` for a predefined resolver list. The README also states that combining `-r` and `-R` adds the resolver from `-r` to those read from the file.

DNS transport is configurable through `-P`, with documented values `tcp` and `udp`. UDP is the default. Resolver port selection is available through `-p`, whose default is 53. These options expose the central architecture directly: a batch of addresses, a selected resolver set, a transport and port, concurrent processing, and filtered or paired output. They also expose practical operational constraints. A resolver that permits UDP does not necessarily provide the same result over TCP, while a port intended for DNS must match the service listening there.

The README does not document retry counts, timeout controls, input validation behavior, duplicate handling, ordering guarantees, exit statuses, or how unsuccessful PTR lookups are rendered. Those details cannot be assumed from the command examples.

Installing hakrevdns and Running the First Lookup

The README gives one installation path through Go. It assumes a working Go toolchain and installs the latest module version into the environment configured for Go-installed commands.

go install github.com/hakluke/hakrevdns@latest

After installation, verify that the command is available on the executable path. The documented basic interface accepts standard input, so begin with one literal IP address. This example asks for only the domain name.

echo "173.0.84.110" | hakrevdns -d

The README says this form emits a domains-only list suitable for a downstream command. To retain the association between each address and its returned hostname, omit `-d`.

echo "173.0.84.110" | hakrevdns

For a larger set, the README demonstrates piping the output of `prips`, which expands a CIDR range into addresses, into `hakrevdns`. Replace the example range with addresses you are authorized to investigate.

prips 173.0.84.0/24 | hakrevdns

The expected result for the documented address is a line containing `173.0.84.110` and `he.paypal.com.`. DNS data can change, so the README's example should be treated as documented behavior rather than a permanent result.

Choosing Resolver, Protocol, and Output Controls

The default invocation uses the resolver configuration available to the operating environment, eight threads, UDP, and port 53. To force a particular public resolver, pass its address to `-r`. The README uses `1.1.1.1` as its custom-resolver example.

echo "173.0.84.110" | hakrevdns -r 1.1.1.1

The expected line pairs the input address with its reverse DNS hostname. For multiple resolvers, `-R` reads a file containing one resolver IP address per line. Supplying `-r` as well adds that resolver to the file-based set. The documentation does not specify selection order, failover semantics, deduplication, or whether every resolver is used for every address.

Transport can be changed where UDP is blocked or unreliable. The help output accepts only `tcp` or `udp`, and `--port` selects the destination port. These are meaningful infrastructure choices rather than cosmetic flags. An organization may restrict outbound DNS, require TCP, or run an internal resolver on a nonstandard port. An unavailable resolver or inaccessible port can therefore prevent lookups even when the input addresses are valid.

Use `-d` when the next stage needs names rather than address and hostname pairs. This can shorten stored results and simplify piping. It also removes the local mapping to each queried address, so choose paired output when later review needs to identify which input produced which PTR record.

Limits of PTR Data and Undocumented Failure Handling

The main limitation is the nature of reverse DNS itself. A missing PTR record means the tool has no hostname to return for that lookup, but the README does not explain how that case appears in output. A PTR record can also name a hosting provider, CDN endpoint, mail exchanger, or shared application server. Such a result does not, by itself, establish that every hostname in the returned FQDN belongs to the organization that owns the public address.

hakrevdns also operates only on the addresses supplied to it. The repository contents do not include CIDR expansion or address discovery; the `prips` command in the README is an external producer. Similarly, `httprobe` is an external consumer. This separation is useful in shell pipelines, but users must supply and interpret both ends themselves.

The documented flags do not include controls for retries, timeouts, maximum response size, output format, or error classification. The README also does not promise stable ordering despite concurrent processing. That omission matters when comparing large outputs: concurrency can improve batch throughput, but ordering should not be assumed from the examples. Duplicate addresses are not discussed either.

The tool is therefore best treated as a DNS transformation step, not a complete subdomain discovery engine. It can provide PTR names, but the documentation does not claim that it verifies those names, resolves their forward records, filters unrelated hosting domains, or enriches the results with service data.

Manual Resolution Versus hakrevdns Batch Processing

The practical alternative is to perform reverse lookups one address at a time through the DNS workflow already available to the host or network. A manual approach can be useful when a small number of addresses need careful inspection, especially when the operator needs direct control over the exact lookup operation and must correlate each request with external logs.

hakrevdns changes the operational shape of that task. It consumes a stream, runs multiple lookups using a configurable thread count, supports several resolver sources, and writes machine-readable results without requiring a separate loop. Its output can remain as IP and hostname pairs or be reduced to domains for another command. This is a clear difference in approach: isolated per-address investigation versus concurrent batch processing designed for a pipeline.

The trade-off is reduced transparency in the documented interface. There are no README options for showing which resolver answered, forcing serial execution except through thread control, or labeling NXDOMAIN and timeout outcomes. Operators who need that evidence may prefer manual queries or should inspect the source in `main.go`. Operators processing a prepared IP list are more likely to benefit from hakrevdns's standard-input and standard-output model.

hakrevdns Maintenance, Releases, and MIT Upgrade Work

The repository is not archived, and its last push was on 2026-08-05. The README does not state whether that commit represents a release, a documentation change, or a code change. There are no GitHub releases, so the repository does not provide a release history through that mechanism.

Installation uses `@latest`, which directs Go to resolve the latest available module version rather than pinning a release in the documented command. For environments that require reproducible builds, the README does not provide a version-pinning tutorial. Checking the module behavior after an update is therefore part of adopting the documented installation path.

The project is licensed under MIT. That permits use, modification, distribution, and sublicensing subject to the license conditions, but this is not legal advice. For an organization, the operational upgrade cost appears low in repository scope because the repository contains a Go entry point rather than a large multi-service layout. That layout does not eliminate the need to verify Go compatibility, CLI behavior, resolver access, and expected output after upgrades.

The absence of published GitHub releases also means changelogs are not documented in the README. Adopters should not assume formal release notes or a stated support policy.

Editorial conclusion

hakrevdns is appropriate for researchers and administrators who already have IP lists and need pipe-compatible reverse DNS results. It is a poor fit for forward DNS discovery, hostname validation, or environments requiring per-result provenance from multiple resolvers. Before adoption, verify the DNS resolvers and ports permitted in the target network, confirm whether UDP is appropriate, and inspect results for shared hosting PTR records that do not identify the intended organization.

Frequently asked questions

Official sources

1. hakluke/hakrevdns on GitHub
2. Issues
3. License: MIT
4. README