Ask any DNS resolver where a domain points, and it will answer for now. It has no memory. It can’t tell you which IP address the domain used last spring, or what other domains shared the same server six months ago. If you’re a security analyst chasing an attacker, or a risk team trying to map a vendor’s real footprint, that blind spot is the whole problem.
Passive DNS closes it. Instead of asking the live system where something points today, passive DNS keeps a record of every answer the global domain name system has already handed out. It turns DNS into something you can rewind.
What Passive DNS Is
Passive DNS, often shortened to pDNS, is a technique for logging DNS responses as they occur and storing them so you can query them later. Security researcher Florian Weimer introduced it in 2004 as a way to fight malware. The idea was to reconstruct a partial, queryable view of the global DNS network from the answers resolvers were already seeing, and the core of it hasn’t changed since. Recursive DNS resolvers handle a constant stream of DNS queries and the responses from authoritative servers. Passive DNS captures those answers, strips out anything that could identify the user who asked, and replicates the rest into a central store.
What you end up with is historical DNS: a searchable store of data that the live system throws away. A normal DNS query gives you a single live answer. A passive DNS query gives you every resolution observed for a name or an IP address, with timestamps for when each was first and last seen. You can ask where a domain pointed two years ago. You can ask what it points to now. You can ask both in the same breath.
That time dimension is what makes pDNS useful for security work rather than ordinary lookups. Attackers move infrastructure constantly. Vendors spin up and retire assets without telling anyone. A live query misses all of that movement. A historical record captures it.
How Passive DNS Data Gets Collected
Collection happens just above the recursive resolver, not at your device. A sensor sits between recursive resolvers and the authoritative DNS server that holds each answer, and it logs the responses flowing back. These are the cache-fill answers: the records a resolver fetches from an authoritative source when it doesn’t already hold them. Collecting passive DNS this way means the sensor watches DNS activity at the network level, logging responses as ordinary network traffic without touching the content of anyone’s session. It never sees which person or machine triggered the lookup, only the answer itself.
The best-known passive DNS dataset is Farsight Security’s DNSDB, which has logged more than 100 billion DNS records since 2010 and is now part of DomainTools. Open-source and community-run options exist too, including CIRCL (Computer Incident Response Center Luxembourg)’s passive DNS service, and the security community has standardized a common output format so results from different providers line up. No single sensor network sees everything. Coverage depends on where the sensors sit and how much DNS traffic passes through them.
At SecurityScorecard, passive DNS is one of many inputs. We pair it with our own scanning data and sinkhole infrastructure, which handles more than 2 billion requests a day, so the historical resolution picture rests on data collected directly rather than borrowed wholesale from a third-party source. The records collected this way feed the same attribution engine that powers our security ratings.
The Record Types Analysts Pivot On
A passive DNS database isn’t limited to domain-to-IP mappings. It stores answers across record types, and each record type carries a different slice of DNS information. An A record ties a domain name to an IPv4 address, and an AAAA record to IPv6. A CNAME record points one name at another, which is how you trace aliases and the cloud services a domain leans on. NS records reveal name servers, MX records reveal mail handling, and the SOA record names the administrative contact and primary authoritative name server for a DNS zone. The data captures full hostnames, so you can see an operation from the top-level domain down to individual subdomains.
Pivoting is where the technique earns its keep. Say you start with a single malicious IP address. You query passive DNS for every domain that has resolved to it, then take those domain names and look up every other IP they have touched. Then you check the SOA and NS records to see which of them share administrative fingerprints. Within a few hops, one indicator becomes a map of related domains and IPs. Working a single domain, you can surface dozens of connected hosts that the attacker assumed were separate.
Running a Passive DNS Lookup
A passive DNS lookup looks a lot like a normal one from the outside. You hand a passive DNS service a domain or IP, and it hands back what it has seen. The difference is in the response data. Where a live query returns one current answer, a passive DNS query returns a list of historical resolutions, each row carrying an rrname (the name that was queried), the rdata (what it resolved to), and a first-seen and last-seen timestamp. Most services expose this through an API, so you can wire passive DNS lookups straight into your own tooling rather than checking by hand.
That searchable, current, and historical view is what turns a single lead into a thread you can pull. Query a domain, and you get every IP it has used. Query a server’s IP address, and you get every hostname that has pointed at it. Query a name server, and you get the zones it has answered for. DomainTools runs DNSDB this way, and open-source services like CIRCL expose the same shape of data through their own APIs.
Tracking Threat Infrastructure
Adversaries reuse things. The same server hosts two campaigns, the same name server backs a cluster of phishing domains, and the same registration pattern repeats across throwaway domains. Passive DNS exposes that reuse by retaining connection records even after a threat actor tears down the live infrastructure. For threat hunting, that memory is the point: you take one known-bad indicator and pull on it until the rest of the attacker’s infrastructure comes loose. That makes it one of the more dependable open source intelligence techniques for studying an adversary from the outside.
How Analysts Pivot Through Attacker Infrastructure
The moves are mechanical. Start with a command-and-control domain, pull historical DNS data to find the IP addresses associated with it, then pivot to every other hostname those IPs have served. Throwaway phishing domains, botnets, and malware staging hosts tend to cluster once you can see their history. Analysts running incident response use the same trick in reverse, taking an IP from a log and asking passive DNS which malicious domains have lived there and what they supported. Feed the answers into a firewall or blocklist, and you cut the resolution off at the source. Many threat intelligence feeds are built on exactly this kind of correlation.
Our STRIKE threat intelligence team works this way. When they investigated the LapDogs operation, a botnet of compromised devices used to relay attacker traffic, passive DNS replication records were part of how they tied hardcoded command-and-control domains back to the IP addresses hosting them and confirmed which hosts belonged to the same intrusion set.
They ran the same correlation against the MOVEit exploitation campaign, matching published indicators to the IP addresses reaching out to victim servers in our own traffic data. We fuse that historical resolution data with our Internet Intelligence data layer, so a domain pulled from passive DNS can be matched against what is actually running on the IP today. History tells you where the infrastructure has been. Internet Intelligence tells you what is live on it now.
Tracking Vendor Infrastructure
The same capability that maps an attacker’s footprint maps a vendor’s. You likely have a rough idea of which domains a vendor owns and almost no idea about the rest: the subsidiaries, the forgotten subdomains, and the orphaned hostnames bolted on through a CNAME to a cloud provider nobody documented.
That last category is the kind of stray record that leads to a subdomain takeover. Passive DNS is part of how we find it. By tracing historical resolutions back to the companies that own them, we map the domains and IP addresses a vendor actually controls and attribute those internet-facing assets to the right organization across the 4.1 billion IP addresses and domains we scan continuously, backed by the same 99.9% data accuracy behind our proprietary threat intelligence.
That attribution is the foundation of third-party risk management, not a side feature. You can’t assess a vendor’s security posture without first seeing their full footprint.
Our TITAN AI platform turns that attributed footprint into continuous monitoring, surfacing vendor risks you didn’t know existed as the underlying infrastructure changes, rather than at the next scheduled review. For teams that want threat intelligence wired straight into that view, TITAN Secure connects the same historical and live signals to the vendors you depend on.
Where Passive DNS Falls Short
Passive DNS is powerful, but treating it as ground truth still gets analysts into trouble. The data only reflects the resolutions a sensor actually observed. A domain that resolved only through resolvers no sensor was watching simply won’t appear, so an empty result never proves something didn’t happen. The data can lag, and timestamps tell you when a resolution was observed, not the exact moment infrastructure changed hands.
It can’t tell you intent, either. Two domains sharing an IP address might be one actor’s tightly run campaign, or two unrelated tenants on the same shared host. Pivoting surfaces connections. Judgment decides which ones mean anything. Passive DNS is a lead generator and corroborator, and it works best when you read its output alongside scan data, threat feeds, and context rather than in place of them.
Passive DNS gives you a memory that the live domain name system was never built to keep. It turns scattered resolutions into traceable infrastructure, whether you’re following an attacker across the servers they’ve burned through or mapping the true footprint of a vendor you’re about to trust. We build that historical view into how we attribute, monitor, and score security risk across the supply chain. To see how SecurityScorecard’sTITAN AI puts it to work in your environment, request a demo.
