DNS Record: Data Point Intelligence Guide

DNS records are an organisation's architecture diagram, published voluntarily and updated in real time. Most defenders never read their own.

Understanding the DNS Record as an intelligence artifact

A DNS record is a typed entry in a zone that binds a name to data: A and AAAA to addresses, CNAME to another name, MX to mail exchangers, NS to authoritative servers, TXT to arbitrary strings, SOA to zone administration parameters, and PTR to reverse mappings. Each record carries a time to live governing caching. Collectively a zone represents deliberate configuration decisions, and because DNS must be publicly resolvable to function, those decisions are readable by anyone who asks the right server the right question.

The analytically dense record types are TXT and CNAME. TXT holds SPF policies, DKIM public keys, DMARC policy with reporting addresses, and dozens of vendor domain-verification tokens that enumerate an organisation's SaaS estate. CNAME chains expose third-party dependencies and email or CDN providers. SOA serial numbers and low TTLs reveal change cadence and failover design, and NS records expose the DNS operator.

Why it matters

DNS records let you reconstruct hosting, mail, security posture and vendor relationships without touching a single production system. For defence, SPF, DKIM and DMARC records determine whether a domain can be spoofed and whether the organisation would ever find out. For investigation, TXT verification tokens map an organisation's cloud footprint, MX records reveal mail providers to serve legal process on, and TTL and serial changes provide timing evidence for when infrastructure moved.

What analysts actually look for

These are the concrete, observable signals that carry weight in this area of work:

• SPF record presence, mechanism count and whether it ends in a hard fail, soft fail or dangerously permissive all clause.
• DMARC policy value of none, quarantine or reject, plus rua and ruf reporting addresses that identify the monitoring vendor.
• DKIM selectors discoverable by name, revealing which mail platforms sign for the domain and which are stale leftovers.
• Vendor verification TXT tokens enumerating SaaS platforms the organisation uses, from cloud tenants to helpdesk and analytics services.
• MX host naming that identifies the mail provider, on-premises gateway, or security filtering layer in front of the mailbox platform.
• NS records showing the DNS operator, whether the zone uses multiple providers, and whether records are self-hosted.
• TTL values, where very low values on A records indicate deliberate fast rotation or failover, common in both CDNs and fast flux.
• SOA serial changes across observations, providing a coarse timeline of when the zone was last modified.
• CNAME targets to third parties, which both map dependencies and identify takeover risk when the target no longer exists.

Where the data comes from

Authoritative and openly available collection points. Always confirm licensing and terms before operational or commercial use:

• dig and Unbound or a controlled resolver — Authoritative live queries per record type, including direct queries to the zone nameservers to bypass cache.
• SecurityTrails or Farsight DNSDB — Historic record values and change timelines, showing when hosting, mail or nameservers moved.
• DNSDumpster — Consolidated free view of common record types with discovered hosts and hosting relationships.
• MXToolbox — Practical mail posture checks for SPF, DKIM, DMARC, blacklists and MX reachability.
• dmarcian or Postmark DMARC tooling — Policy parsing, alignment explanation and validation of published SPF and DMARC syntax.
• crt.sh — Certificate names that corroborate hostnames found in DNS and reveal records not otherwise published.
• Cloudflare or Google DNS over HTTPS endpoints — Quick programmatic resolution from a neutral resolver for comparison against authoritative answers.
• DNSViz — DNSSEC chain validation and delegation analysis, exposing broken or absent signing.

A working method

A repeatable sequence beats ad-hoc searching. This is a practical starting workflow:

1. Query authoritatively — Resolve NS first, then query those servers directly for each record type so cached and filtered answers do not distort the picture.
2. Enumerate the full type set — Collect A, AAAA, MX, NS, TXT, SOA, CAA and CNAME, and probe common DKIM selector names rather than assuming none exist.
3. Assess mail posture — Parse SPF for mechanism count and failure mode, read DMARC policy and reporting addresses, and identify signing platforms from selectors.
4. Map third-party dependencies — Extract vendor verification tokens and CNAME targets to build an inventory of SaaS and hosting providers the organisation relies on.
5. Compare against history — Pull passive DNS timelines to identify when records changed, correlating moves with incidents, takedowns or campaign relaunches.
6. Check delegation health — Validate DNSSEC where present, look for lame delegation, and identify dangling CNAMEs that permit takeover.
7. Monitor for change — Baseline the zone and alert on new records, TTL reductions or nameserver changes, which frequently precede infrastructure movement.

How this connects across the intelligence taxonomy

Intelligence work does not respect neat boundaries. The mission domain you are working, the disciplines you practise, and the data points you pivot on are one connected system. These are the direct relationships for this entry — every link is also a tag, so you can follow any thread across the whole library.

Pivots to these data points

• Domain Name — Human-readable address that maps to IP infrastructure via DNS.
• IP Address — Internet Protocol address identifying a device or server on a network.
• URL — Uniform Resource Locator pointing to a web resource.
• ASN — Autonomous System Number identifying a network operator on the internet.
• Subdomain — A host under a parent domain — often reveals staging, admin, and forgotten infrastructure.
• IP Range / CIDR — A block of IP addresses expressed in CIDR notation — the unit of network ownership and allocation.

Inside the platform: where DNS Record lives

The Quantus platform is 204 pages behind a 147-item sidebar organised into six working groups: Command (24 items), Dashboards (15), Threat Theaters (14), Intelligence Domains (15), Investigate (34), and Administration (45). This entry is not a page in isolation — it is a thread running through several of them.

The modules that matter most here:

• datapoint.php?dp=dp_dns_record — Data point hub
• search.php — Advanced search, filter and pivot
• correlate.php — Correlation graph
• cases.php — Case management

Each dashboard is local-first: it renders from the platform’s own database rather than depending on a live third-party call, so it still works when an upstream API is unreachable or rate-limited. Heavy aggregates are cached with a hard query time cap and degrade to the last good value instead of hanging the page.

Automation, playbooks and AI skills

Analysis that only happens when someone remembers to run it is not a capability. The platform ships a 30-step automation pipeline (cron.php) that collects, ingests, resolves, enriches, correlates and scores on a schedule — 25 seeders, 11 resolvers and 7 enrichment runners, all idempotent and cursor-based so a run can be interrupted and resumed without duplicating or losing work.

AI skills that apply

The 16 one-click operations in ai-skills.php are deterministic jobs, not free-text generation. The ones that matter here:

• Enrichment Runner
• Enrichment → Local
• Correlate Infrastructure
• DNS Audit
• Summarise (Copilot)
• Generate Report

Alerting closes the loop: rules in alerts.php fire on new indicators matching a saved query, so a first sighting in this area raises a notification rather than waiting to be noticed at the next review.

Feeds, data sources and the API

The collection layer runs a feed registry of free, machine-readable sources — bulk blocklists and trackers (Maltrail, IPsum, FireHOL, the full abuse.ch corpora, phishing databases, Emerging Threats, Spamhaus, DigitalSide, ThreatView), authoritative government feeds (CISA KEV, OFAC, UN and EU sanctions lists), and reference datasets (RIR allocations, ip-to-ASN and geolocation tables, MITRE ATT&CK, EPSS). collect.php pulls them server-side on a schedule; feeds.php and source-catalog.php show what is registered, what it covers and when it last ran.

Anything the platform holds is reachable programmatically. The REST API in api.php exposes 11 endpoints — status, stats, search, lookup, recent, export, bulk_check, top_threats, by_category, categories, check — and export.php streams 18 formats in bounded chunks, so a million-row export neither exhausts memory nor times out:

STIX 2.1, MISP, OpenIOC 1.1, CEF (ArcSight), LEEF 2.0 (QRadar), Zeek/Bro intel, Snort/Suricata rules, Palo Alto EDL, BIND RPZ, hosts blackhole, iptables, CSV, JSON, NDJSON/JSONL, XML.

That covers the CTI standards (STIX 2.1, MISP, OpenIOC), SIEM ingestion (CEF, LEEF, Zeek), detection engines (Snort/Suricata), and direct enforcement (Palo Alto EDL, BIND RPZ, hosts, iptables) — so intelligence developed here can be actioned in the tools you already run, without a manual reformatting step. A TAXII 2.1 server and a MISP/RSS feed are also served for pull-based sharing.

Use cases

Three ways this entry earns its keep in day-to-day work:

1. Triage under time pressure. An artifact or report lands and you need a defensible read in minutes, not days. Query authoritatively is the first move; the platform pre-computes the enrichment so the analyst spends the time on judgement rather than lookups.
2. Building the picture. A single indicator is rarely the story. Assess mail posture turns one artifact into a network — shared infrastructure, repeated selectors, the same operator behind different names — via the correlation graph and the cross-entity link engine.
3. Producing something actionable. Analysis that ends in a document nobody can use is wasted. Monitor for change feeds the case file, the detection rule, the block list or the referral — with sourcing attached so the recipient can verify it.

Case management (cases.php), watchlists, saved searches and scheduled reports mean the work persists between sessions and survives an analyst leaving the team.

How each sector uses DNS Record

The same entry is worked very differently depending on who you are, what authority you hold, and what you are ultimately producing. A military analyst is supporting a commander’s decision; a journalist is meeting a publication standard; an NGO caseworker is protecting a person. The underlying artifacts are shared — the constraints, outputs and thresholds are not.

🎖 Military and defence

Zone configuration is a readable description of an organisation's architecture, dependencies and mail security posture, obtained without touching a production system. For defence that supports cyber terrain mapping, supply chain and contractor assurance, and force protection through detecting domains configured to spoof unit or programme identities. Mail authentication records determine whether an adversary can impersonate a headquarters to a supplier, which is a direct operational risk. Constraints are modest for passive resolution but real for zone transfer attempts against third parties, which are interactions rather than observations, and for records that expose programme names or contractor relationships requiring handling before circulation.

🕵 National intelligence

Zone data answers structural questions cheaply: which cloud tenants an organisation holds, which security vendors it uses, which mail platform serves it, and when its infrastructure moved. Vendor verification tokens in text records effectively enumerate an entity's software estate, which supports capability and dependency assessment. Because it is unclassified and reproducible, it fuses well with classified reporting and can be released to partners. Handling considerations arise where reporting addresses and administrative contacts name individuals. Record resolver identity, query time and record lifetime with every observation, since answers are volatile and a finding without provenance cannot be defended later.

👮 Law enforcement

For law enforcement mail exchange records identify which provider holds a suspect's mail and therefore where to serve preservation and production orders, which is often the single most valuable output. Historic passive records establish when infrastructure moved, corroborating timelines around an incident or a takedown evasion. Capture answers with resolver identity, query time and record lifetime, because a screenshot without provenance carries little weight. Avoid zone transfer attempts against third party servers, which can be treated as unauthorised access attempts. Text record verification tokens also identify cloud tenants holding evidence, directing further process.

🔍 Private investigation and corporate security

Corporate security uses zone analysis for mail security assurance, vendor discovery, merger due diligence and detecting configuration that would permit brand impersonation. Establishing whether a client domain publishes an enforcing mail policy is one of the highest value, lowest cost checks available. Against third parties, a private actor may resolve public records freely but should not attempt zone transfers, probe internal resolvers or use discovered administrative addresses for pretext contact. Deliverables should distinguish confirmed posture on client owned domains from passive observations about counterparties, and should quantify impersonation risk rather than listing raw records.

📰 Journalism and OSINT media

Zone records are among the most verifiable artifacts in technology reporting because any reader with a resolver can reproduce them. They evidence vendor relationships, cloud tenancy and mail providers, and dated passive records evidence when a subject moved infrastructure. Verification requires stating the resolver used and the query time, and acknowledging that split horizon configuration means the public view may differ from the internal one. Do not publish administrative or reporting mailboxes that identify individuals, and give organisations a right of reply, particularly where you are reporting that their configuration permits spoofing of their own brand.

🌍 NGO, humanitarian and human rights

Civil society organisations use zone analysis defensively, since mail impersonation of a human rights organisation is a common attack on its partners and beneficiaries. Publishing an enforcing mail policy is a concrete protection measure for the people who receive the organisation's mail. Analytically, zone records also help document the vendor infrastructure behind surveillance companies and disinformation operations, entirely passively and without risk to anyone in country. Do no harm applies to publishing records that expose a partner organisation's hosting or mail arrangements, which can reveal where it operates and who supports it.

🎓 University and research

Zone data supports research on mail authentication adoption, cloud concentration, dependency risk and takeover exposure, all at internet scale from public sources. Method must state the resolver, vantage point, query cadence and how negative answers were distinguished from failures, because misclassified failures dominate error in large studies. Ethics review is normally light since the data is infrastructural, but administrative contacts are personal data and should be excluded or aggregated. Reproducibility is strong here: publish the resolver configuration, the query list and the parsing code, and cite passive datasets by snapshot date since coverage varies over time.

Playbook: working DNS Record end to end

A repeatable sequence, from the moment the requirement lands to the moment a product is delivered and the case is closed out. Each phase states what you are trying to establish, not merely what to click — the point is a defensible chain of reasoning, not a checklist.

Phase 1 — Scope the zone and the question

Decide which domains are in scope and what the analysis must establish: mail spoofability, vendor inventory, infrastructure timeline, or takeover exposure. Each drives a different record set and a different depth. A good output is a scoped domain list with the analytical purpose recorded. Stop when the purpose is defined, because full zone enumeration without a question produces a record dump nobody acts on.

Phase 2 — Resolve the delegation first

Query the parent for the delegation, then retrieve the nameserver set the zone itself publishes and compare the two. Mismatches indicate lame delegation, migration in progress or a stale parent record. A good output is the authoritative nameserver set with the delegation state noted. Stop when you know which servers are authoritative, because everything after this depends on asking the right ones.

Phase 3 — Query authoritatively and through a neutral resolver

Ask the authoritative servers directly for each record type and repeat through an independent public resolver, recording both answers with record lifetimes and query times. Divergence reveals caching, filtering, geographic answers or split horizon configuration and is a finding rather than an error. A good output is a paired answer set with resolver identity attached. Stop when both views are captured verbatim.

Phase 4 — Enumerate the full type set

Collect address, mail exchange, nameserver, text, start of authority, certification authority authorisation, canonical name and service records, and probe common signing selector names rather than assuming none exist. A good output is a complete record inventory with lifetimes. Stop when every standard type has been queried and absent types are recorded as absent rather than omitted.

Phase 5 — Parse mail authentication posture

Read the sender policy for mechanism count, lookup limits and whether it ends in hard fail, soft fail or a permissive catch all, then read the domain policy record for enforcement level and reporting addresses, and identify signing platforms from selector names. A good output is a spoofability verdict with the specific record text supporting it. Stop when you can state whether an external party could send mail that passes authentication as this domain.

Phase 6 — Inventory third party dependencies

Extract vendor verification tokens from text records and canonical name targets pointing at external platforms, then build an inventory of the cloud tenants, security vendors, marketing platforms and support tools the organisation relies on. A good output is a dependency list with the record that evidences each. Stop when each token is attributed to a vendor or explicitly marked unknown.

Phase 7 — Check for stale and dangling configuration

Identify verification tokens for services no longer in use, canonical names pointing at deprovisioned resources, and signing selectors for retired mail platforms. Dangling canonical names are a takeover condition; stale tokens are an inventory and hygiene finding. A good output is a cleanup list ranked by exploitability. Stop at detection rather than claiming any dangling resource.

Phase 8 — Reconstruct the change timeline

Pull passive historic records to see when address, mail, nameserver and text values changed, and align those changes against incidents, takedowns or corporate events. Start of authority serial progression gives a coarse modification cadence. A good output is a dated change table with the evidence source per entry. Stop when the timeline covers the period of interest with gaps acknowledged.

Phase 9 — Validate signing and delegation health

Where the zone is signed, validate the chain of trust from the parent and check for expired signatures, algorithm mismatches and broken delegation. Absent signing is common and is a posture observation rather than a fault. A good output is a validation state with the specific failure where one exists. Stop when the chain validates or the break is identified precisely enough to fix.

Phase 10 — Assess the certification authority policy

Read certification authority authorisation records to see which issuers the domain permits, and compare against certificates actually issued in transparency logs. A permissive or absent policy combined with unexpected issuers is worth investigating. A good output is an issuance policy statement with any inconsistencies noted. Stop when policy and observed issuance are reconciled or the discrepancy is documented.

Phase 11 — Baseline and monitor for change

Store the full record set as a dated baseline and alert on new records, nameserver changes, lifetime reductions, mail policy weakening and new verification tokens, all of which frequently precede infrastructure movement or indicate unmanaged change. A good output is a diffing monitor with alert routes to an owner. Stop when alerts reach someone who can act on them.

Phase 12 — Report and remediate

For owned domains, drive enforcement of mail policy, removal of stale tokens and dangling names, and correction of overly long sender policies. For third party analysis, report posture and dependencies with the records that evidence them. A good output is a remediation tracker or a documented research record with preserved raw answers. Stop when each finding has an owner or an explicit acceptance.

The platform ships this as a step-checked workflow in playbooks.php, so progress is recorded against a case rather than held in someone’s head.

Source register: what to collect from, and how

Sources are listed with their access model so you can plan around cost and licensing before you build a dependency on them. Open means no account required; registration means a free account or API key; licensed means paid or institutional access. Always confirm current terms — licensing changes, and a source that was free for research may not be free for commercial or evidential use.

Source	Access	What it gives you	How it is used here
IETF DNS specifications	Open	The normative RFC series defining record types, zone structure, caching semantics and the meaning of record lifetimes.	Authoritative basis for interpreting record semantics rather than relying on tool output conventions.
IANA DNS parameters registry	Open	Authoritative registry of record types, response codes, option codes and other protocol parameters with their defining specifications.	Confirms the meaning and current status of unusual record types encountered during enumeration.
SecurityTrails	Registration	Historic record values and change timelines across record types for large numbers of domains, with reverse lookup capability.	Reconstructs when hosting, mail or nameservers changed, which anchors incident and evasion timelines.
DNSDumpster	Open	Free consolidated view of common record types with discovered hosts and hosting relationships presented in a single report.	Fast first pass posture and hosting map before committing to detailed authoritative queries.
MXToolbox	Registration	Practical diagnostics for mail exchange reachability, sender policy syntax, signing selectors, policy records and blocklist status.	Rapid mail posture assessment with syntax validation that catches lookup limit and mechanism count problems.
DNSViz	Open	Visual analysis of delegation and signing chains showing validation state, algorithm use and specific chain of trust failures.	Diagnoses signing and delegation problems precisely enough to hand to an operator for correction.
dmarcian and open policy tooling	Registration	Parsing, validation and explanation of domain policy records, alignment behaviour and aggregate report interpretation.	Converts a raw policy record into a defensible statement about whether the domain can be spoofed.
Cloudflare and Google public resolvers with DNS over HTTPS	Open	Neutral recursive resolvers offering programmatic query interfaces returning structured answers with validation status.	Independent second view for comparison against authoritative answers to detect filtering and geographic responses.
crt.sh	Open	Certificate transparency search returning every publicly logged certificate for a domain with issuer and subject alternative names.	Corroborates hostnames found in records and tests whether observed issuance matches the domain's issuance policy.
Farsight and commercial passive DNS providers	Licensed	Large scale passive collection of resolution observations with first and last seen timestamps per record value.	Provides dated historic evidence of record values when authoritative history is unavailable.
OpenINTEL measurement platform	Open	Long running academic project performing daily active measurement of large portions of the domain name space with published datasets.	Research grade longitudinal record data with documented methodology, suitable for citation and reproducibility.
M3AAWG and messaging best practice documentation	Open	Industry guidance on mail authentication deployment, policy progression and reporting practice from major mail operators.	Benchmarks for what a defensible mail posture looks like and how to progress policy without breaking delivery.
Public Suffix List	Open	Boundary between registrable domains and delegated subdomains, needed to apply policy and alignment rules correctly.	Determines the organisational domain for alignment evaluation and prevents mis scoped policy inheritance conclusions.
NCSC mail security guidance	Open	National guidance on configuring mail authentication and anti spoofing controls for organisations of varying size.	Authoritative reference for the remediation recommendations produced from a mail posture assessment.
Internet Systems Consortium documentation	Open	Reference material for widely deployed name server software covering zone file syntax, transfer controls and logging.	Explains server side behaviour such as transfer restriction and response policy that shapes what an external observer sees.

Prefer sources that publish a methodology and a revision history. A dataset that changes silently is a liability in any product that has to survive challenge.

Tooling

Tools commonly used against DNS Record. None of these replace judgement, and each carries its own failure modes — know what a tool infers versus what it observes.

• dig — Precise, scriptable querying of any record type against any resolver with full flag control. Limitation: shows the current answer only, with no history.
• dnsx — High throughput resolution of large name and record type lists for enumeration pipelines. Limitation: aggressive querying can be treated as abuse by resolvers.
• DNSViz — Visualises delegation and signing chains and pinpoints validation failures. Limitation: focused on signing correctness rather than content or posture analysis.
• checkdmarc and policy parsers — Parse and validate sender, signing and policy records including lookup limits and syntax errors. Limitation: syntax validity does not tell you whether delivery will actually break.
• zdns — Fast bulk active resolution designed for internet scale measurement with structured output. Limitation: requires careful rate control and a documented scan origin.
• Passive DNS query clients — Retrieve historic record values with first and last seen dates across providers. Limitation: coverage varies, so absence reflects sensor placement rather than fact.
• Unbound or a controlled recursive resolver — Gives a clean, instrumented resolution path with validation and full logging under your control. Limitation: your own resolver becomes an attributable vantage point.
• Mail policy reporting platforms — Ingest aggregate reports to show which senders are using a domain and whether they authenticate. Limitation: reports lag by a day and omit non participating receivers.
• MISP with domain and record attributes — Stores record observations with timestamps for correlation across cases. Limitation: record values change fast, so stale attributes mislead unless expiry is enforced.

AI skills and automation in detail

These are deterministic jobs with defined inputs and outputs, not open-ended prompting. Each is idempotent and cursor-based: interrupt one and it resumes where it stopped rather than duplicating work or losing progress.

• Enrichment Runner — Walks the indicator set through a chosen provider in time-boxed, cursor-based batches that resume rather than restart.
• Enrichment → Local — Materialises enrichment into the local store so dashboards render from your own database instead of a live third-party call.
• Correlate Infrastructure — Builds the cross-entity link graph: shared hosting, reused certificates, overlapping registrants, repeated selectors.
• DNS Audit — Bulk-resolves A/AAAA/MX/NS/TXT/CNAME/SOA records and stores them as observations, building passive DNS from your own collection.
• Summarise (Copilot) — Produces a narrative summary beside the underlying records. It explains; it never creates indicators or assigns attribution.
• Generate Report — Assembles a sourced product from the current case or query, with provenance attached to each element.

A note on the boundary: the only skill that involves a language model is Summarise (Copilot), and it writes prose about records that already exist. Nothing else on this list involves generation of any kind. No indicator, relationship or attribution in the platform originates from a model. See the full skill list.

Tradecraft notes

The distinctions that separate a competent analyst from a fast one:

• Ask the authoritative servers directly and record which resolver gave each answer. Cached and filtered responses from a recursive resolver routinely describe a state the zone abandoned hours earlier, and that difference has decided disputes.
• A published policy record is not enforcement. A monitoring only policy protects nobody while looking identical to protection in a compliance checklist, so always report the enforcement level rather than the presence of the record.
• Text records are an inventory of everything the organisation ever bought. Stale verification tokens persist for years after a service is abandoned, so treat the list as a superset requiring confirmation rather than a current estate.
• Very short record lifetimes are ambiguous. They indicate deliberate fast rotation, which is equally characteristic of content delivery networks, failover designs and fast flux hosting, so read them alongside the hosting classification.
• Split horizon means the public view is one view. Anything you conclude about internal architecture from external resolution is a hypothesis about the external face, not a description of the network.
• Probe for signing selectors by name rather than concluding none exist. Selectors are not enumerable from the zone, so absence in your results usually reflects an unimaginative guess list rather than an unsigned domain.
• Sender policy lookup limits break silently. A policy that exceeds the permitted number of lookups fails evaluation entirely at some receivers, so count the mechanisms rather than trusting that a long chain works.
• Do not attempt zone transfers against third parties. It is an interaction rather than an observation, it is logged, and in several jurisdictions an unauthorised transfer request has been treated as an access attempt.

Measuring whether it is working

Capability claims should be falsifiable. These are the measures that show whether work on DNS Record is producing anything, and they are worth baselining before you change process or tooling.

• Percentage of owned domains, including parked and legacy ones, publishing an enforcing anti spoofing policy rather than a monitoring only policy.
• Number of domains where sender policy exceeds the permitted lookup count, tracked to zero since these fail evaluation silently.
• Count of stale verification tokens and dangling canonical names in owned zones, with mean time to removal.
• Median time from an unauthorised or unplanned record change to detection by zone diffing, measured against change management records.
• Proportion of mail sent from owned domains that authenticates correctly, derived from aggregate policy reports rather than from configuration alone.
• Share of zone findings preserved with resolver identity, query time and record lifetime, sampled from case records.
• Reduction over time in third party dependencies discovered in zones that were not present in the vendor register, measuring shadow procurement.

Beware of measuring volume alone. Indicator counts and report counts rise easily and say little; time-to-attribution, proportion of findings that survive review, and how often a product changed a decision say a great deal.

Common pitfalls

• Resolvers return cached data, so an answer may reflect a state that the authoritative zone abandoned hours or days earlier.
• Split-horizon DNS serves different answers internally and externally, meaning public observation captures only one view of the architecture.
• Passive DNS coverage is uneven, so an absent historic record indicates missing sensor visibility rather than proof the record never existed.
• SPF and DMARC presence does not mean enforcement, since a policy of none monitors without protecting and is frequently mistaken for security.
• TXT records accumulate stale tokens for years, so an enumerated vendor may be a service the organisation abandoned long ago.
• Wildcard and CDN-generated records can create the appearance of vast infrastructure that does not correspond to distinct systems.

Legal and ethical considerations

DNS data is published for public resolution and is generally lawful to query and retain, but DMARC reporting addresses, SOA contacts and TXT records sometimes contain individual mailboxes that constitute personal data. Avoid zone transfer attempts against third parties, since AXFR requests to unauthorised zones can be treated as unauthorised access attempts in some jurisdictions. Preserve raw query responses with resolver identity, query time and record TTL, because DNS is volatile and a screenshot without provenance has little evidential weight.

Data integrity: no fabrication, no drift, no hallucination

Intelligence that cannot be traced back to a source is not intelligence, it is assertion. Everything in this entry — and everything in the platform behind it — is built on a small number of non-negotiable rules.

Provenance on every record

Every indicator carries the source that supplied it, a first-seen and last-seen timestamp, and a sighting count. Where several feeds report the same artifact, each contribution is recorded separately rather than collapsed, so you can see whether a finding rests on one source or twelve. Source attribution travels with the data into every export, so a recipient can audit a claim without asking you for the working.

Nothing is invented to fill a gap

If the platform has no data for DNS Record, it says so. Empty is displayed as empty — never padded with plausible-looking placeholder values, sample records or illustrative examples that a reader might mistake for observations. A dashboard with no rows is a true statement about collection coverage, and it is treated as a gap to close, not a blemish to hide.

Scoring is deterministic and reproducible

Threat scores, reputation grades and risk tiers are computed from stated inputs with fixed weights, not estimated. The same inputs always produce the same output, and the formula is visible rather than a black box. Aggregates are cached with an explicit time-to-live so a figure on screen is never silently stale — and when a heavy query exceeds its time budget the platform serves the last known-good value and labels it, rather than inventing a fresh number or hanging.

Where AI is used, and where it is not

Language models summarise and explain. They do not create indicators, assign attribution or manufacture relationships. No IP address, wallet, hash or identity in the platform originates from a model — every one is ingested from a named feed, resolved from a reference dataset, or entered by an analyst with a source recorded. Copilot output is presented as narrative alongside the underlying records, never in place of them, so a reader can always check the summary against the evidence.

Guarding against drift

Enrichment is additive and timestamped rather than overwriting. Reference data — sanctions lists, allocations, taxonomies — is re-synchronised from the authority on a schedule instead of being edited in place, so local copies cannot quietly diverge from the source of truth. Attribution is recorded with a confidence level and the reporting it rests on, and inferred relationships are labelled as inferred. When a source retracts or corrects, the correction propagates rather than leaving a stale assertion behind.

What this means for you

You can put a finding from this platform in front of a regulator, a court, a board or a partner agency and show where each element came from. That is the standard the tooling is built to — because in this work, being confidently wrong is more damaging than being usefully uncertain.

By the numbers

The taxonomy this entry belongs to is not a marketing list — it is the actual structure of the platform: 52 mission domains, 52 intelligence disciplines and 65 data points, each with a live dashboard behind it. Supporting that: 18 indicator types, 14 playbooks, 16 AI skills, 18 export formats and a 30-step automated pipeline.

This particular entry connects directly to 6 closely related entries — every one of them a tag you can follow, and a dashboard you can open.

Questions analysts actually ask

Why do the authoritative servers and my resolver disagree?

Several legitimate causes. Caching means a recursive resolver serves the previous value until the record lifetime expires, which can be hours or days. Geographic and load balanced answers vary by the resolver's location. Filtering resolvers may substitute or withhold answers for reputation reasons. Split horizon configuration serves different data to internal and external queries. None of these is an error, but all of them mean you must record which resolver produced each answer and prefer direct authoritative queries when the answer matters evidentially.

How do I tell whether a domain can be spoofed?

Read the sender policy and the domain policy together. A domain is protected only when the policy record specifies quarantine or reject with full coverage and the sender policy ends in a hard fail with the mechanism count inside the permitted lookup limit. A monitoring only policy provides visibility and no protection. Also check subdomain policy, since a domain may enforce on itself and permit anything beneath it. Finally, confirm alignment: passing authentication for a different domain does not protect the visible sender address.

What can verification tokens tell me?

They enumerate the platforms an organisation has connected, because most business services prove domain ownership by asking for a token in a text record. That produces a partial inventory of cloud tenants, security vendors, marketing and support tools without any privileged access. Two caveats matter. Tokens accumulate and are almost never removed, so many reflect abandoned services. And they prove that a domain was verified with a platform, not that the service is in current use or holds current data. Corroborate before relying on them.

Is querying a third party's records lawful?

Ordinary resolution is how the system is designed to work and is generally unproblematic: you are asking a public server the question it exists to answer. Two activities sit differently. Zone transfer requests to servers you are not authorised to transfer from are interactions that have been treated as unauthorised access attempts in some jurisdictions. High volume enumeration against a target's authoritative servers can constitute abuse and may breach terms or trigger defensive measures. Keep third party work to normal resolution and passive sources unless authorised.

How do I detect a dangling canonical name?

Resolve each canonical name target and check whether it still exists at the provider. Providers return characteristic responses when a name points at a resource that has been released, and those signatures are documented per platform. Record the target, the response and the timestamp; that is sufficient evidence for a remediation ticket. Do not claim the released resource to prove the point, since that is asserting control over a name you do not own. On your own estate, remove the record rather than re creating the resource.

What does a very short record lifetime indicate?

Deliberate control over rotation, which has both benign and malicious explanations. Content delivery networks, global load balancers and failover designs all use short lifetimes to move traffic quickly. So does fast flux hosting, where an operator rotates addresses continuously to survive takedown. The lifetime alone does not discriminate. Read it alongside how many distinct addresses appear in passive history over a short window, whether those addresses sit in residential or compromised space, and whether the name has a plausible content delivery relationship.

How much history can I actually recover?

It depends entirely on passive sensor coverage for that domain, which varies enormously. Well trafficked domains have dense history across multiple providers; obscure ones may have almost nothing, and absence of a record in passive data is evidence about sensor placement rather than about the zone. Start of authority serial numbers give a coarse indication of modification frequency but not of what changed. For evidential work, capture current state contemporaneously rather than expecting to reconstruct it later, because the volatility here is genuinely high.

Standards, frameworks and further reading

Work that references a recognised framework is easier to defend, easier to hand over, and easier for a partner to consume:

• RFC 1034 and RFC 1035, defining the domain name system, zone structure, record types and caching semantics.
• RFC 7208, RFC 6376 and RFC 7489, defining sender policy, message signing and domain based message authentication reporting and conformance.
• RFC 4033 to 4035, defining the security extensions that provide origin authentication and integrity for zone data.
• RFC 6844 and RFC 8659, defining certification authority authorisation records that constrain which issuers may certify a domain.
• RFC 5936 and operator practice on zone transfer restriction, governing when a transfer request is authorised.
• M3AAWG messaging best practice documents, setting industry expectations for mail authentication deployment and policy progression.
• ISO/IEC 27001 Annex A supplier and configuration controls, requiring inventory of third party dependencies evidenced in zone configuration.
• National cyber security guidance on anti spoofing controls, which sets baseline mail configuration expectations for public bodies and suppliers.

References

Primary sources and authoritative references for this entry. Publishers revise and retire material, so treat the retrieval date as part of the citation and re-check before relying on any of it in a formal product.

1. Domain Names Concepts and Facilities — IETF. The foundational specifications defining zone structure, record types and resolution behaviour.
2. DNS Parameters registry — IANA. Authoritative registry of record types, response codes and protocol parameters.
3. DNSViz — Sandia National Laboratories and community. Analysis tool visualising delegation and signing chains and their validation state.
4. OpenINTEL — University of Twente and partners. Longitudinal active measurement platform publishing daily domain name system datasets for research.
5. M3AAWG best practice documents — M3AAWG. Industry guidance on mail authentication and anti abuse configuration from major operators.
6. Mail security guidance — NCSC. National guidance on configuring anti spoofing and mail authentication controls.
7. crt.sh certificate search — Sectigo. Certificate transparency search used to reconcile issuance against authorisation policy.
8. Public Suffix List — Mozilla Foundation. Boundary definition needed for correct policy alignment and organisational domain determination.
9. BIND and name server documentation — Internet Systems Consortium. Reference documentation for widely deployed authoritative and recursive name server software.
10. MXToolbox diagnostics — MXToolbox. Practical mail configuration and reachability diagnostics used for posture assessment.

Link integrity: every reference above was verified with a live request when this page was generated. Where a publisher had moved or withdrawn a document, the link was repointed at a preserved copy in the Internet Archive and marked as archived. Anything with no reachable copy anywhere had its link removed rather than left to rot — the source is still credited, it simply cannot be linked.

Put it into practice

The Quantus Intel threat intelligence platform operationalises this entry: captures and diffs full zone posture over time, alerting on record, nameserver and mail policy changes. Explore the platform, or browse the rest of the library by following any tag above.