Passive DNS Explained: A Practical Guide for Threat Hunters

by

If you’ve ever needed to know where a domain pointed six months ago, or which other domains share infrastructure with an IP you’re investigating, you’ve hit the same wall every analyst eventually runs into: DNS only tells you what’s true right now. Ask a resolver about a domain today and you get today’s answer — yesterday’s is already gone, unless something was logging it as it happened.

That’s the gap passive DNS closes. I’ve written before about building an ELK stack for pfSense logs and getting Suricata alerts into Kibana — passive DNS is a natural next layer on top of that setup, and once it’s running, it’s hard to imagine going back to investigating without it.

What Is Passive DNS?

Passive DNS (often shortened to pDNS) is the practice of logging DNS answers as they cross the network, then storing them in a searchable database so you can look up what a domain resolved to at any point in the past — not just right now.

The idea goes back to 2004, when security researcher Florian Weimer built the first passive DNS replication system and presented it at the FIRST conference in 2005. The pitch was simple: recursive resolvers already see every DNS answer that goes out. Log those answers instead of throwing them away, and you get a historical map of DNS activity almost for free.

It’s called “passive” because nothing is actively queried — no zone transfers, no scanning. You’re listening to traffic that’s already happening and keeping a record of it.

Why Does Passive DNS Matter for Threat Hunting and Incident Response?

Passive DNS earns its keep the moment an investigation needs history instead of a snapshot. A few of the situations where it matters most:

  • Tracking C2 infrastructure — malware operators rotate domains constantly. Passive DNS lets you see every IP a suspicious domain has ever pointed to, and every other domain that has shared that IP — often how you find the rest of an actor’s infrastructure.
  • Investigating phishing — a phishing domain that’s already been taken down still has a resolution history. Passive DNS can confirm it existed, when it was active, and what it pointed to.
  • Spotting DGA activity — malware that generates pseudo-random domains to reach its command-and-control server produces a flood of NXDOMAIN (non-existent domain) responses. A spike in those is one of the more reliable early signs of a domain-generation-algorithm infection.
  • Attack surface discovery — passive DNS records can surface subdomains and hosts that active enumeration would miss entirely, including ones that were only briefly active.

How Does Passive DNS Actually Work?

At a basic level, a passive DNS setup has three parts:

  1. A sensor — placed somewhere it can see DNS traffic (usually mirrored or tapped from a resolver or network segment), logging every DNS answer it observes.
  2. A collector/database — the logged answers get normalized and stored, keyed by domain name and record type, with a first-seen and last-seen timestamp for each.
  3. A query interface — something that lets you ask “what has this domain resolved to?” or “what domains have resolved to this IP?” and get an answer from history, not just the present.

That’s the whole concept. The complexity is mostly in scale — the larger providers are logging billions of DNS answers a day.

Passive DNS vs. Active DNS: What’s the Difference?

Worth being precise about this, since the two get confused. Active DNS techniques query the DNS system directly, right now — zone walking, brute-force subdomain enumeration, scanning tools. Passive DNS never queries anything; it only observes and records answers that were already produced by real traffic.

That difference matters for two reasons: passive DNS doesn’t tip anyone off that you’re looking, since nothing is being actively queried, and it can show you infrastructure that no longer exists — something active techniques simply can’t do.

Setting Up Your Own Passive DNS Collector

If you want to try this on your own network instead of relying only on third-party lookups, the tool most practitioners reach for is passivedns, by Edward Bjarte Fjellskål (aka gamelinux). It’s a lightweight network sniffer, originally released back in 2013, purpose-built to log DNS server replies for exactly this use case. It’s old by software standards, but it’s still the reference tool people point to when they want to stand up their own passive DNS feed, and it still builds and runs fine on current Linux distros.

Install it (Debian/Ubuntu):

sudo apt install git build-essential libldns-dev libpcap-dev automake autoconf
git clone https://github.com/gamelinux/passivedns.git
cd passivedns
autoreconf --install
./configure
make
sudo make install

Run it against a live interface:

sudo passivedns -i eth0 -l /var/log/passivedns.log

That alone gets you a running log of every DNS answer passivedns sees on that interface. A few options worth knowing before you go further:

  • ./configure --enable-json turns on JSON logging instead of the default pipe-delimited format — worth doing if you’re planning to ship this into Logstash or Filebeat, since JSON drops into an ELK pipeline with a lot less parsing work than pfSense’s syslog output ever needed.
  • Adding -L /var/log/passivedns-nx.log alongside -l splits NXDOMAIN answers into their own file — the detail to watch if you’re hunting DGA activity rather than just building a lookup archive.
  • The tools/pdns2db.pl script that ships with the repo will load your log file straight into MySQL, if you’d rather query it with SQL than grep through flat files.

If you’re already running Suricata and ELK from the setup in my earlier posts, this slots in as another data source feeding the same stack — same pattern as the pfSense logs, just a different sensor.

Passive DNS Services Worth Knowing

Running your own collector only shows you your own traffic. For domains you’ve never seen locally, you’ll want one of the larger third-party datasets:

  • CIRCL Passive DNS — access on request for security researchers and CERTs, run by Luxembourg’s CERT. A solid starting point if you’re not ready to pay for anything yet.
  • VirusTotal — passive DNS lookups built in as a secondary feature alongside its malware analysis tools, free to use at a basic level.
  • SecurityTrails — one of the most commonly integrated passive DNS sources in open-source recon tooling, with a usable API.
  • Farsight DNSDB — now part of DomainTools following Farsight’s 2021 acquisition, and still the dataset with the longest continuous sensor history; the one enterprise threat intel teams tend to pay for.
  • Microsoft Defender Threat Intelligence — the successor to RiskIQ’s PassiveTotal after Microsoft’s acquisition of RiskIQ; if your org is already in the Microsoft security ecosystem, this is where that data lives now.

None of these replace running your own sensor. They’re complementary — your own passive DNS setup tells you about your traffic, these tell you about everyone else’s.

Common Questions

Is passive DNS logging a privacy concern? Passive DNS systems are generally designed to minimize privacy exposure — they log server answers rather than communication content, and the common output formats used across the industry were built with that in mind. That said, DNS logging can still be subject to local privacy regulations, so it’s worth checking your own jurisdiction and org policy before standing up a collector that captures more than your own network’s traffic.

Do I need special hardware to run my own collector? No. passivedns runs comfortably on a spare VM or alongside an existing Security Onion or ELK box, as long as it can see a mirrored copy of DNS traffic — a SPAN port or tap is enough.

How is this different from just checking my firewall’s DNS logs? Firewall or resolver logs usually cover only your own network and often get rotated out quickly. A dedicated passive DNS setup is built to retain history indefinitely and is indexed specifically for “what did this resolve to, and when” — which a firewall log was never designed for.

Wrapping Up

Passive DNS is one of those things that feels optional until the first time you actually need it mid-investigation, and then it’s suddenly indispensable. Once a domain’s resolution history is in front of you, half the “who else is behind this” questions in an investigation start answering themselves. Start small — a single passivedns sensor and a log file is enough to get a feel for it before committing to a full pipeline.

References

Leave a Comment