Every organization has more subdomains than the DNS zone file on record suggests. Marketing spins up a campaign host, a contractor provisions a staging environment, an engineer points a CNAME at a cloud bucket for a two-week test. Years later, none of that is in the change log, but the DNS record is often still there. Passive DNS is the tool that surfaces it, and it does so without ever sending a single query to the target’s own name servers.
What passive DNS is and why it never touches the target
Passive DNS is built from replication, not resolution. Sensors sit at large recursive resolvers, ISP infrastructure, or public authoritative servers and record every query and response that passes through: the queried name, the record type, the returned value, and two timestamps, first_seen and last_seen. That data accumulates into a historical database that anyone with API access can query later. Farsight DNSDB, Microsoft Defender External Attack Surface Management, SecurityTrails, VirusTotal’s passive DNS graph, and the CIRCL.lu open dataset all work this way.
Compare that to active enumeration: a dictionary brute force against the target’s authoritative name server, a zone transfer attempt (dig axfr), or a certificate transparency scrape followed by live DNS lookups. Active methods generate traffic the target can log, rate-limit, or alert on. A passive DNS query hits a third party’s archive instead. You get an answer built from traffic that already happened, sometimes years ago, with zero packets sent toward the organization being mapped. That’s the core trade-off: passive DNS is quiet and historical, active enumeration is current and noisy.
The practical implication for reconnaissance planning is straightforward: run passive DNS first, unconditionally, before any active step. It costs nothing in exposure and it frequently returns names that no wordlist would have guessed, because it reflects what was actually deployed rather than what a naming convention predicts.
Historical records: names that still resolve after the service is gone
The value passive DNS adds over a live zone dump is the first_seen field going back further than anyone’s institutional memory. A record created for a 2019 product launch, promo.example.com, might have a first_seen from that year and a last_seen from three years later, meaning it kept resolving long after the campaign ended. If the authoritative zone still lists it today, you have a live but forgotten asset. If it no longer resolves at all, the passive record still tells you it existed, which matters for understanding how the organization’s external footprint evolved and where the naming habits are.
The sharper risk shows up when the record is a CNAME that still exists in the current zone but points at a third-party resource that no longer belongs to anyone: an S3 bucket that was deleted, a Heroku app that expired, a GitHub Pages site that was taken down. This is the classic dangling DNS setup for subdomain takeover. Passive DNS is what lets you find these efficiently, because you can filter for CNAME records with an old first_seen and a target pattern matching known cloud endpoints (*.s3.amazonaws.com, *.herokuapp.com, *.github.io, *.azurewebsites.net), then confirm live status with a direct request:
dig CNAME old-app.example.comto confirm the record still resolves and to whomcurl -sI https://old-app.example.comand check for provider-specific error signatures, such as an S3 “NoSuchBucket” XML body or GitHub’s “There isn’t a GitHub Pages site here”
A subdomain that answers with one of those signatures is a taken-over-waiting-to-happen: anyone who registers the same bucket name or app name on the provider inherits the DNS record for free.
Building the inventory: what first_seen and last_seen actually tell you
A raw passive DNS export is a list of names, not an inventory. Turning it into one means deciding, per record, whether it represents something currently in production, something dormant but real, or something to retire. The two timestamps do most of that work if you set explicit thresholds instead of eyeballing dates:
- last_seen inside the past 30 days: treat as active, schedule for standard scanning and ownership tagging
- last_seen between 30 and 180 days: review tier; confirm it still resolves live and check whether it’s reachable from the internet before deciding to keep or retire
- last_seen older than 180 days with no live resolution: decommission candidate; verify the DNS record itself can be removed and check whether any certificate still references the name
- first_seen predating your organization’s own asset inventory system: flag as legacy; it likely predates the current ownership model and needs manual attribution
Normalization matters as much as thresholds. Passive DNS exports are full of case variations, trailing dots, and duplicate entries for the same name across record types. Fold everything to lowercase, strip trailing dots, and deduplicate on the (name, first_seen) pair before you count anything, or the same host will show up as three separate inventory lines. Platforms that automate this phase, such as SITEY, pull the first_seen and last_seen fields directly into the asset inventory record and apply the age thresholds automatically, rather than asking an analyst to paste timestamps into a spreadsheet by hand.
False positives that inflate the list
Shared hosting and CDN edges
Reverse-pivoting from an IP address to “everything that resolved to it” is the single fastest way to pollute a subdomain inventory. A shared cPanel or GoDaddy hosting IP can serve several thousand unrelated domains from several thousand unrelated customers. A Cloudflare or Akamai anycast edge IP will show the same pattern at even larger scale. If your passive DNS workflow pivots on IP, filter out any address whose reverse pivot returns more than a few dozen distinct apex domains, that’s the signature of shared or CDN infrastructure, not a signal of ownership. Confirm real ownership with an HTTP request that sends the candidate hostname in the Host header and checks whether the response actually serves that organization’s content, rather than a shared default page.
Stale records from former integrations
Subdomains created for a specific partner or client integration, such as partner-abc.example.com pointing at a vendor’s API gateway, often outlive the business relationship by years. They’re real DNS records with a legitimate first_seen, but they no longer map to an active business need. These aren’t technically false positives, the record is genuine, but counting them as current attack surface without checking whether the integration still exists overstates what’s actually in use and wastes triage time on infrastructure nobody is maintaining.
Wildcard catches
A wildcard DNS record (*.example.com) answers for literally any label, including ones nobody ever configured. If a domain has a wildcard, passive DNS will contain an unbounded list of names, many of them random strings left over from other tools’ subdomain-guessing probes that happened to hit the wildcard and get logged by whatever pDNS sensor observed the query. The tell is simple: pick three or four low-probability random strings and resolve them directly. If they all return the same IP as your “discovered” subdomains, the zone is wildcarded and passive DNS enumeration on that zone is not producing a real inventory, it’s echoing internet background noise.
Validating a finding before it earns an inventory line item
A name showing up in a passive DNS export is a lead, not a fact. Before it gets written into the asset inventory as a tracked, scanned asset, it should clear a short checklist:
| Check | Method | Pass condition |
|---|---|---|
| Live resolution | Direct A/AAAA/CNAME lookup against a public resolver | Record currently resolves, not just historically |
| Certificate correlation | Check TLS certificate SANs served on the resolved IP | The subdomain name appears in a certificate SAN issued to the organization |
| HTTP fingerprint | Request with the candidate hostname in the Host header | Response content or headers match organization-owned infrastructure, not a shared default |
| Source corroboration | Query a second independent passive DNS source | Record appears in at least two providers, reducing single-source sensor artifacts |
| Ownership attribution | WHOIS, internal CMDB, or team self-report | A named team or system owner can be assigned |
Only a record that clears live resolution plus at least one of the other four checks should move into active tracking under attack surface management. Platforms built around this workflow re-verify each candidate against these criteria on a recurring schedule rather than accepting a one-time export as ground truth, since a subdomain’s status can flip from dormant to actively serving traffic (or the reverse) between scans.
What passive sources never cover: internal DNS and split-horizon
Passive DNS databases are built entirely from traffic that crossed public infrastructure. Anything resolved exclusively inside a corporate network, an Active Directory-integrated zone such as corp.local, an internal BIND view, a private Consul or Kubernetes service-discovery namespace, never reaches a public resolver and therefore never reaches a public pDNS sensor. No amount of querying third-party passive DNS providers will surface those names.
Split-horizon DNS makes this gap sharper. In a split-horizon setup, the same name resolves to different answers depending on where the query originates: app.example.com might return a private RFC 1918 address to internal resolvers and a public address to everyone else. Passive DNS sensors watching public traffic will only ever record the public answer. The internal answer, and the internal-only hosts that share the split-horizon zone but never get an external record at all, stay completely invisible to this technique.
Closing that gap requires different instrumentation entirely: DHCP lease exports, authenticated zone transfers against internal DNS servers, or endpoint and network agents that observe internal resolution directly, which is the domain covered under network reachability mapping rather than passive DNS. Treat passive DNS as the correct first pass for anything internet-facing, and budget for a separate internal discovery pass before calling a subdomain inventory complete. A report that only lists what public passive sources returned will systematically undercount internal-only assets, and that gap tends to be largest in exactly the organizations that rely most heavily on internal service meshes and private zones.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.