Vexta's DNS Resolver Pool for Reliable Recon

Vexta's DNS resolver pool keeps a validated, latency-ranked list of public DNS resolvers on hand so that subdomain enumeration and other DNS-heavy recon don't depend on a single resolver that might be slow, rate-limited, or simply dead. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and this pool runs in-process rather than shelling out to external tooling, which keeps DNS lookups consistent across every recon step in a scan.

Where does the resolver list come from?

Vexta builds its candidate list from a fixed order of sources. It first tries public-dns.info's published nameserver list, then falls back to the trickest/resolvers list if that's unavailable, and if both of those fail it falls back to a 10-IP seed list covering Cloudflare, Google, Quad9, OpenDNS and AdGuard. That layered fallback means the pool has a usable set of candidate resolvers to start from even if one of the upstream lists is down or unreachable when a scan kicks off.

Candidates don't get used just because they're on a list, though. Vexta validates each one with a real DNS query against cloudflare.com and an 800 millisecond ceiling on the response. Anything that doesn't answer correctly and quickly enough doesn't make the cut.

How does Vexta decide which resolvers to keep using?

After validation, Vexta persists the top 50 active resolvers ranked by latency, and keeps that set available locally so a resolver pool survives a restart rather than rebuilding itself from scratch on every run. On top of the initial validation, Vexta keeps a running stat per resolver IP: an active or inactive counter, plus a use count and a bad count that track how that resolver has actually performed across real lookups, not just the one-time validation check. A resolver that starts answering slowly or incorrectly over time will show that in its bad count, separate from whatever its initial validation looked like.

That combination, initial validation plus ongoing stat tracking, is what keeps the pool honest over a long engagement. A resolver that was fast and reliable when the pool was first built can degrade later, get rate-limited, or start returning bad answers, and the stat tracking is what would surface that instead of Vexta continuing to trust a resolver based only on how it looked on day one.

Where the resolver pool actually gets used

The pool isn't a side feature bolted onto one recon step. It backs every part of a scan that needs DNS: subdomain enumeration, asset enrichment, subdomain takeover verification, and zone-transfer style techniques like AXFR and NSEC walking. All of those paths go through the same pool-backed resolver rather than each maintaining its own DNS logic, so a resolver that's degraded for one recon step is degraded, and avoided, for all of them at once.

One detail worth knowing if you're running Vexta on a long recon job: resolver selection happens live, inside the lookup path itself, rather than being fixed once at the start of a scan. That means if the pool refreshes or a resolver's standing changes partway through a long-running job, later lookups in that same scan benefit from the updated pool rather than being stuck with whatever was current when the scan started.

Why this matters for subdomain enumeration specifically

Subdomain enumeration is one of the most DNS-lookup-heavy things a recon tool does, often issuing thousands of queries against a wordlist or permutation set for a single target. A resolver that's slow, rate-limiting you, or occasionally dropping queries doesn't usually fail loudly; it just quietly returns fewer subdomains than actually exist, and there's no obvious signal that anything went wrong. A validated, latency-ranked, continuously-tracked pool of 50 resolvers spreads that load and reduces the odds that a single flaky resolver is the reason a subdomain enumeration pass came back thinner than it should have.

There's also a dedicated view for the pool itself, showing each batch of resolvers with active, used and bad counts, a per-resolver detail view, and buttons to use or delete individual entries, plus a refresh action to pull a fresh batch on demand. That gives you visibility into exactly which resolvers are backing your recon at any point, rather than treating DNS as an invisible layer underneath the scan.

A detail worth knowing before a large recon job

Because resolver selection happens inside the lookup path itself rather than being decided once up front, a long-running scan against a large target automatically benefits from any pool refresh that happens while it's still working. That's a small design choice with a real effect: on a scan that runs for hours against a target with a large subdomain surface, you're not locked into whatever resolver standing looked like at minute one. If a resolver degrades an hour into the job, subsequent lookups route around it without anyone restarting the scan.

For a hunter comparing recon tooling, the honest way to think about a resolver pool is as insurance against a specific, easy-to-miss failure mode: DNS lookups that fail quietly instead of loudly. A crashed scan is obvious. A subdomain enumeration pass that silently came back 20% short because one resolver in the rotation was rate-limiting responses is not, and it's the kind of gap that only shows up much later, when a subdomain someone else found turns up in a report and you're left wondering why your own pass missed it.

Key takeaways