Live DNS only tells you what a name resolves to right now, while most investigations need to know what it resolved to last month, which other names shared that address, and which records your own organisation forgot to delete. Passive DNS fills that gap by recording DNS answers as resolvers see them and keeping a timeline of first and last sightings. This guide explains how passive DNS data is collected, how to read it, how threat intelligence and incident teams pivot on it, how to use it against your own estate to find forgotten records, and where the data misleads. It is written for threat intelligence analysts, SOC and incident responders, and the DNS and attack surface teams who own the zones.
Key takeaways
- Passive DNS is a history of observed answers, not a copy of zones. A record appears only if some sensor saw a resolver fetch it, so absence of data never proves a record did not exist.
- Five fields carry most of the meaning. The common output format makes rrname, rrtype, rdata, time_first and time_last mandatory; count and bailiwick add confidence when a source supplies them.
- Pivots are only as good as the infrastructure is unique. An IP on a CDN, shared host or parking service links thousands of unrelated domains; pivot on dedicated addresses, name servers and rare record values.
- Your own history is an attack surface map. Old CNAMEs to deleted cloud resources, retired hosts and stale MX records show up in passive DNS long after your team forgot them, and attackers query the same data.
- Treat the data as sensitive. The draft standard's own privacy and security sections say names can leak information and access should be restricted, so handle exports like any other intelligence product.
What passive DNS is and how the data is collected
The technique was first described by Florian Weimer in 2005. Sensors sit between recursive resolvers and the authoritative servers they query, and log the cache-fill answers coming back from the authoritative side. Because the capture happens upstream of the resolver, the record set holds no client IP address or port, which is the main privacy design choice: you learn that a name resolved to an address, not who asked. Aggregators combine many such sensors, often run by ISPs, universities and security partners, and some also import zone files and run their own active lookups to enrich the data.
The result is a database keyed by name and by value, storing for each unique name, type and answer when it was first and last seen. DNSDB documents its sources as the Security Information Exchange sensor network, zone files from ICANN's Centralized Zone Data Service and zone file access programmes, and active enrichment. CIRCL runs a service for vetted partners that also takes records from malware analysis.
The common output format
The Internet-Draft "Passive DNS - Common Output Format" (draft-dulaunoy-dnsop-passive-dns-cof) defines field names so that results from several providers can be merged. As checked on 11 November 2026 the latest version is -13, an Independent Submission marked Informational and shown as expired on the IETF Datatracker, with no IETF endorsement. Providers still use its field names widely, CIRCL among them, but treat it as a convention rather than a standard.
| Field | Requirement in the draft | Meaning | How to use it |
|---|---|---|---|
| rrname | MUST | The name that was queried | Left-hand side lookups, wildcard searches for all names under a domain |
| rrtype | MUST | Record type as text (A, AAAA, CNAME, NS, MX, TXT) or a number | Filter early: NS and MX history answer different questions from A records |
| rdata | MUST | The answer data, a string or an array for multiple records | Right-hand side lookups: every name that pointed at an IP, name server or CNAME target |
| time_first / time_last | MUST | First and last time the tuple was seen, UTC epoch seconds | Build the timeline; bound the window of an incident |
| count | SHOULD | How many times this exact answer set was seen | Low counts suggest little real traffic or very short use |
| bailiwick | SHOULD | Best estimate of the zone apex where the data was authoritative | Spot answers served from an unexpected parent zone |
| sensor_id, origin | MAY | Which sensor or source observed the record | Judge independence of two sightings |
| zone_time_first / zone_time_last | MAY | First and last seen via zone file import rather than sensors | Separate "published in a zone" from "actually resolved by someone" |
DNS history sources compared
"DNS history" is used loosely for several different data sets. Knowing which one a tool is showing avoids wrong conclusions.
| Source | What it records | Strengths | Blind spots |
|---|---|---|---|
| Sensor-based passive DNS | Answers observed by resolvers that feed sensors | Shows what was really resolved, with first and last seen | Names nobody resolved through a sensored resolver; internal zones; coverage varies by region and provider |
| Zone file imports (for example ICANN CZDS) | Delegations (NS and glue) in participating top-level domains | Complete list of registered names in those TLDs and their name servers | Only the delegation, not the hosts inside the zone; many country-code TLDs do not share zones |
| Active resolution or scanning | Answers fetched by the provider's own lookups | Fills gaps for names known from other sources | Reflects the provider's vantage point; can be biased by geo-DNS |
| Your own resolver and DNS logs | Every query your clients made, with client identity | Who inside your network resolved what; ties to endpoints | Only your users; retention limits; see the DNS Logging and Detection Guide |
| Certificate transparency logs | Names on publicly trusted certificates | Reveals hostnames before they ever resolve; see the Certificate Transparency Guide | No resolution data; wildcard certificates hide host names |
| Registration data (WHOIS, RDAP) history | Registrar, dates, name servers, contacts where not redacted | Registration and expiry dates; registrar changes | Heavy redaction of contacts; says nothing about hosts |
Pivoting on attacker infrastructure
MITRE ATT&CK lists passive DNS as an adversary reconnaissance source in T1596.001 DNS/Passive DNS under T1596 Search Open Technical Databases. Defenders use the same data in the other direction, starting from one indicator and expanding to the infrastructure behind it.
- Start from a confirmed indicator. A phishing domain from a reported email, a command-and-control name from an endpoint alert, or an IP from a firewall block.
- Build the timeline of the seed. Run an rrset lookup on the name for A, AAAA, CNAME, NS and MX. Note when each answer was first and last seen. A domain whose first A record appears hours before the campaign and whose last sighting is days later fits a short-lived attack domain.
- Pivot on the right-hand side. Run rdata lookups on each IP and name server. Keep only results inside the same time window, using time fencing (DNSDB, for example, offers time_first_after, time_first_before, time_last_after and time_last_before, in epoch seconds or negative relative seconds).
- Test uniqueness before trusting a link. If an IP returns thousands of names, it is a CDN, a shared host or a parking service, and the link is meaningless. If it returns a dozen names registered in the same week with similar patterns, it is probably dedicated infrastructure.
- Corroborate with other data sets. Check registration dates, certificate transparency entries and hosting autonomous system. Two independent signals turn a hunch into an indicator worth blocking.
- Act and share. Block or sinkhole the confirmed set, search your own DNS and proxy logs for any of the names in the window, and share indicators with partners.
Patterns worth recognising
| Pattern in the history | Likely meaning | ATT&CK reference |
|---|---|---|
| One name, tens or hundreds of A records per day, very low TTLs | Fast flux hosting | T1568.001 Fast Flux DNS |
| Name servers for the domain change frequently as well | Double flux | T1568.001 |
| Many algorithmic-looking names with one or two sightings each | Domain generation algorithm traffic | T1568.002 Domain Generation Algorithms |
| Freshly registered names on the same dedicated IP or name server pair | Infrastructure staged for a campaign | T1583.001 Domains |
| A legitimate domain whose NS records briefly pointed to unfamiliar servers | Possible DNS hijack through registrar or DNS provider compromise | T1584.002 DNS Server |
The joint advisory on fast flux from NSA, CISA, FBI and the Australian, Canadian and New Zealand cyber agencies (AA25-093A, April 2025) describes single flux, where one domain rotates through many IPs, and double flux, where the name servers rotate too. It notes that fast flux domains may cycle through tens or hundreds of IPs a day and change addresses every 3 to 5 minutes, and recommends detection on low TTLs, high IP diversity and inconsistent geolocation. It also warns defenders not to assume a Protective DNS provider blocks fast flux without checking. If you find a hijack pattern on your own domains, move to the DNS Hijack Playbook.
Finding forgotten records in your own estate
Passive DNS is one of the few sources that shows names your organisation published but no longer tracks. Asset inventories list what teams remember; passive DNS lists what the internet resolved.
- Enumerate every name under each registered domain: a wildcard rrset search returns hostnames from old campaigns, acquisitions, test environments and vendor integrations. Compare the list with your current zone exports and your asset inventory.
- Look for CNAMEs to cloud and SaaS platforms: any record pointing to a platform hostname (storage, app hosting, CDN, API gateways) whose target you no longer own is a takeover candidate. Microsoft's guidance on dangling DNS names Azure App Service, Blob Storage, Front Door, CDN, Traffic Manager, API Management, container instances and public IP DNS labels as affected types, and its Get-DanglingDnsRecords tool checks CNAMEs against resources in your tenants. See the Subdomain Takeover and Dangling DNS Guide.
- Check MX and SPF history: MX records pointing at retired mail gateways, or TXT records that still include a former email service, can let someone else receive or send mail for your domain.
- Review NS history: delegations to DNS providers you have left can be dangerous if the provider lets another customer claim the zone.
- Find the reverse: rdata lookups on your own public IP ranges show third-party names pointing at your addresses. Rdata lookups on IPs you have released back to a cloud provider show what now lives there.
Feed the findings into your attack surface process rather than fixing them one by one. See the Attack Surface Management Guide.
Where identity fits
Forgotten hostnames often carry identity consequences. A dangling subdomain that an attacker claims can receive OAuth redirects, session cookies scoped to the parent domain, and API calls from integrations still configured with the old hostname. Microsoft's guidance warns that credentials or tokens sent to a dangling subdomain may have leaked and should be investigated. When passive DNS shows a retired name that was an OAuth redirect URI, webhook endpoint or SSO entity ID, remove it from application registrations, rotate any client secrets or webhook signing keys that were bound to it, and check for API keys in code that still reference it. The API keys and service accounts behind passive DNS subscriptions themselves are non-human identities: store them in a secrets manager, scope them per team and watch their query volume. See the Threat Intelligence for Identity and NHI Guide.
Limits of the data
| Limitation | Effect | How to compensate |
|---|---|---|
| Coverage depends on sensors | Names resolved only inside networks without sensors never appear; internal and split-horizon names are absent | Combine providers; add your own resolver logs and zone exports |
| first seen is not creation time | A record may have existed long before anyone queried it through a sensor | Use zone_time_first or registration dates where available |
| last seen is not deletion time | A record may still exist but no one has queried it recently | Confirm with a live lookup before you report it as gone |
| Shared infrastructure | CDN, cloud load balancer and parking IPs produce false links | Pivot on dedicated IPs, NS pairs and rare TXT values; check the hosting network |
| Geo-DNS and load balancing | Different sensors see different answers for the same name at the same time | Do not treat two answers as a change; look at sensor or origin fields |
| Poisoned or junk answers | Sensors may record spoofed answers or answers from misbehaving resolvers | Check bailiwick; weight answers with very low counts lightly |
| Query limits and result caps | Large result sets are truncated (CIRCL documents a maxset error requiring pagination; CIRCL does not support CIDR queries) | Paginate, time fence, and filter by rrtype |
| Licensing and access | Commercial providers restrict use and redistribution; CIRCL limits access to vetted partners | Read the licence before sharing raw exports in reports |
One more trap is active enrichment. CIRCL's version 2 service runs an active query resolver by default, which can be switched off with a request header. An active lookup touches the target's authoritative servers, so a sensitive investigation can tip off an operator who watches their name server logs. Know which providers query live on your behalf.
Choosing and operating a passive DNS capability
- Small organisations: use the passive DNS views built into a threat intelligence platform, a Protective DNS service or an attack surface tool you already pay for. Run the forgotten-records review quarterly on your own domains.
- Mid-sized teams with a SOC: add API access to one commercial provider so enrichment runs automatically on alerts, and write time-fenced queries into your playbooks.
- Large organisations, ISPs and CERTs: consider running sensors on your own recursive resolvers and contributing to a sharing community, which gives coverage of your region and reciprocal access. That requires a privacy assessment: the draft's privacy section notes that names such as one containing a family name can reveal who uses a resolver, and it points operators to GDPR obligations.
Rolling it out
- List your registered domains and export current zones from every DNS provider.
- Run wildcard history searches for each domain and diff the results against the zone exports. Triage CNAMEs to cloud services first, then MX, NS and TXT.
- Pilot automatic enrichment on one alert type (phishing domains reported by users), measure analyst time saved, then extend it.
- Write pivot rules into your threat intelligence procedures: required corroboration, maximum result size before a pivot is discarded, and how confidence is recorded.
- Add "remove DNS records" to decommissioning checklists, so the history review becomes a check on the process rather than the process itself. Roll back an automated block by keeping blocklists versioned and reviewed.
Detection and measurement
- Dangling records found and closed: count of hostnames in history that point to resources you no longer own, and median days to remove them.
- Unknown hostnames rate: share of names in passive DNS history for your domains that are not in the asset inventory; it should fall each quarter.
- Enrichment coverage: percentage of domain and IP indicators in alerts enriched with passive DNS automatically.
- Pivot yield: confirmed malicious indicators per pivot, and the share later found to be false links from shared hosting.
- Hijack watch: alerts on any change of NS or MX records for your top domains seen in passive DNS or zone monitoring.
Framework mapping
| Framework | Reference | How passive DNS supports it |
|---|---|---|
| NIST CSF 2.0 | ID.AM-03, ID.RA-02, DE.CM-01 | Maps external data flows and hostnames; threat intelligence from sharing sources; network monitoring |
| NIST SP 800-53 Rev. 5 | CM-8, SI-4, RA-5, IR-4 | Component inventory of public names; monitoring; finding exposed hosts; scoping incidents |
| CIS Controls v8.1 | Control 1 (inventory of enterprise assets), Control 9 (email and web browser protections), Control 13 (network monitoring and defence) | Discovering forgotten hosts; DNS filtering; network detection |
| ISO/IEC 27001:2022 Annex A | 5.7 Threat intelligence, 5.9 Inventory of information and other associated assets, 8.16 Monitoring activities | Intelligence production; asset discovery; monitoring |
| MITRE ATT&CK | T1596.001, T1590.002, T1568.001, T1568.002, T1583.001, T1584.002 | Adversary use of the data and the infrastructure patterns it exposes |
| MITRE D3FEND | D3-DNSTA DNS Traffic Analysis, D3-DNRA Domain Name Reputation Analysis | Defensive techniques that consume passive DNS |
Common failure patterns
- Pivoting on a CDN address: an analyst links an attack to hundreds of unrelated domains because they shared a cloud front-end IP, and the resulting blocklist breaks legitimate sites.
- Reading last seen as deleted: a team reports a record removed because no sensor saw it recently, while it still resolves and points to a deleted cloud resource.
- Only checking A records: NS and MX history, where hijacks and mail interception show up, is never queried.
- History review without a decommissioning fix: the same dangling CNAMEs reappear every quarter because nobody added DNS cleanup to the retirement checklist.
- Tipping off the target: a provider's active resolution or the analyst's own lookups hit an attacker-controlled name server during a covert investigation.
Practitioner checklist
- Know which history sources each of your tools uses (sensor, zone file, active, CT, registration) and their coverage limits.
- Run wildcard history searches on every registered domain at least quarterly and diff against zone exports.
- Prioritise CNAMEs to cloud and SaaS platforms, then MX, NS and TXT history.
- Add DNS record removal to every decommissioning checklist and verify it with history searches.
- Time fence every pivot to the incident window and discard pivots through shared infrastructure.
- Require corroboration from a second data set before blocking or publishing a link.
- Store passive DNS API keys in a secrets manager, scope them per team and monitor usage.
- Remove retired hostnames from OAuth redirect URIs, webhooks and SSO configuration, and rotate secrets bound to them.
Standards and references
- IETF Datatracker: Passive DNS - Common Output Format (draft-dulaunoy-dnsop-passive-dns-cof-13)
- MITRE ATT&CK: T1596.001 Search Open Technical Databases: DNS/Passive DNS
- ASD's ACSC, NSA, CISA, FBI and partners: Fast Flux: A National Security Threat
- Microsoft Learn: Prevent dangling DNS entries and avoid subdomain takeover
- CIRCL: Passive DNS
- DomainTools: DNSDB API time fencing parameters
- Microsoft Learn: Threat intelligence data sets
Related NHI Mgmt Group resources: DNS Logging and Detection Guide · Subdomain Takeover and Dangling DNS Guide · Threat Intelligence Guide · Attack Surface Management Guide · DNS Security Guide