Ask a resolver what example.com points to and it tells you the answer right now. Ask it what the domain pointed to last Tuesday, or in 2019, or during the three days a stranger owned it, and it has nothing for you. DNS doesn’t remember. It’s a lookup system, not a ledger — every answer overwrites the last, and the moment a record changes, the old value is gone as if it never existed.
That amnesia is a problem if you’re trying to catch someone. An attacker stands up a domain, points it at a server, runs a campaign, and tears it down over a weekend. By Monday the DNS record is blank and the trail is cold. The one system that watched the whole thing happen kept no notes.
Passive DNS is the fix, and it’s one of the stranger inventions in security: a way to give the internet’s most forgetful system a permanent memory, built by quietly writing down every answer it ever gives — while carefully never recording who asked the question.
What it actually is
The idea came from Florian Weimer, who described Passive DNS Replication at the FIRST conference in 2005. The mechanism is almost embarrassingly simple. You put a sensor near a busy recursive resolver — the kind an ISP or a university runs, serving millions of queries. Every time that resolver has to go out and fetch an answer from an authoritative server, the sensor sees the response go by and writes it down: this name, this type, resolved to this value, at this time.
You don’t store every observation. That would be an ocean. Instead you deduplicate into tuples: the name, the record type, the answer, a first-seen timestamp, a last-seen timestamp, and a count. evil.example first resolved to 203.0.113.7 on June 3rd, was last seen doing so on June 6th, observed 1,400 times. One row. Multiply that across enough sensors on enough big resolvers and you’ve reconstructed a partial, opportunistic, but astonishingly useful history of what the entire DNS was doing — going back years.
Weimer’s own word for it was opportunistic, and it’s the honest one. Passive DNS never sees the whole internet. It sees what its sensors happened to catch. A domain nobody ever queried through a monitored resolver simply isn’t in the database. But the resolvers that get watched are the big ones, and between them they see most of what matters.
The part that makes it not creepy
Here’s the design decision that separates passive DNS from a wiretap, and it’s the part most people miss.
A DNS query has two halves. There’s the stub-to-resolver side — your laptop asking your ISP’s resolver “where’s my-embarrassing-search.example?” — and there’s the resolver-to-authoritative side, where the resolver, on a cache miss, goes and fetches that answer from the domain’s real nameserver. The first half is deeply personal: it’s a log of what you looked up. The second half is not: it’s the resolver, stripped of any individual identity, asking the internet a question on behalf of thousands of people at once.
Passive DNS sensors sit on the second half. They capture the cache-fill traffic — resolver to authoritative — and they deliberately throw away the source IP, source port, and everything else that could tie an observation to a person. There’s even a hardened engineering reason beyond privacy: authoritative servers sometimes hand back different answers depending on who’s asking (that’s what EDNS Client Subnet does), and to build a clean, canonical map you specifically want the resolver’s view, not any one user’s. The result is a database that knows evil.example resolved to 203.0.113.7 last June, and has no idea whatsoever that you were one of the people who visited it.
So the “surveillance database” in the title surveils infrastructure, not people. It’s watching the machines, not the users. That distinction is the whole reason the technique is allowed to exist at the scale it does.
Why defenders can’t live without it
The power shows up the instant you have a single lead and need the rest of the iceberg.
Regular DNS pivots one way and only in the present. You have a domain, you get its current IP. That’s it. Passive DNS pivots both ways, across time:
- Domain to every IP it ever used. Not just where a domain points now, but the whole rotation — the fifteen IPs an attacker cycled through, including the one they only used for six hours before it got flagged.
- IP to every domain ever hosted on it. This is the one that has no equivalent anywhere else. A reverse DNS (PTR) lookup gives you one name for an IP, and only if the operator bothered to set it. Passive DNS gives you the historical set — every domain that ever resolved to that address. Point it at a suspicious server and out falls the attacker’s entire stable of sibling domains, the ones sharing the same box.
- When, exactly. The first-seen and last-seen stamps turn a static map into a timeline. You can prove a domain pointed at a bulletproof host during exactly the window of an incident, then moved on.
This is what incident response runs on. You start with one indicator — a single malicious IP pulled from a firewall log — and passive DNS blooms it into the adversary’s whole footprint: the domains they parked there, the other addresses those domains touched, the shape and lifetime of the operation. One rock, and the ground moves.
There’s a standard for querying it, too, which tells you how seriously the field takes it. The Common Output Format — an Internet-Draft from Alexandre Dulaunoy (CIRCL), Aaron Kaplan (CERT.at), Paul Vixie, and Henry Stern (Farsight) — defines one JSON shape for passive DNS answers so a single client can query Farsight’s DNSDB, CIRCL, VirusTotal, and half a dozen other providers and merge the results. Cross-checking one observation against several independent sensor networks is the whole game; no single source sees everything, and agreement between them is what turns a data point into evidence.
The recon lesson underneath
Strip away the incident-response framing and passive DNS is a statement about how reconnaissance actually works, and it’s the opposite of the movie version.
The loud way to map a target is to touch it: scan its ports, brute its subdomains, query its nameservers directly. Every one of those leaves a footprint in its logs, and a competent defender will see you coming. Passive DNS is the other doctrine entirely. You never send the target a single packet. You read what the internet already wrote down about it — the answers its own domains handed out to everyone else, recorded by sensors it doesn’t know exist and can’t reach. The target cannot detect the lookup because the lookup doesn’t touch the target. It touches a database of the past.
That’s the same instinct behind Certificate Transparency: the most durable intelligence about a system is the exhaust it already emitted into public, append-only records it doesn’t control. Certificates, DNS answers, routing announcements — a domain can’t operate without broadcasting these, and once broadcast, someone was writing them down. The best observation is the kind the observed party can’t switch off, because it already happened.
The catch nobody advertises
Which is exactly where it gets uncomfortable. Passive DNS has no delete key. Once your domain resolves to an address — even by accident, even for the five minutes before you notice the typo and fix it — that resolution can be caught by a sensor, deduplicated into a row, and preserved indefinitely. There is no “right to be forgotten” in a passive DNS database. You cannot un-observe a fact the internet already handed out.
For defenders chasing attackers who want to disappear, that permanence is the entire point. But the same permanence applies to the internal hostname you exposed for an afternoon, the staging domain that briefly pointed at a real production IP, the acquisition you hadn’t announced yet whose new subdomains started resolving a week early. None of it named a person. All of it is still in there, first-seen and last-seen, waiting for anyone who thinks to pivot on the right address.
DNS forgets on purpose; it was built to. Passive DNS is the quiet decision, made by defenders a decade ago and never really debated in public, that the internet should remember anyway.