DNS is Still the Most Underrated Sensor in Your Environment

The Industry Narrative: DNS as Intrusion Detection

DNS logging is routinely framed as the cost-free sentinel of network security — a "passive" data source that, unlike endpoint detection and response (EDR), network IDS/IPS, and SIEM forwarders, requires minimal agent deployment, no kernel instrumentation, and near-zero performance penalty. The narrative runs: enable query logging on your recursive resolver, forward logs to your SIEM, build YARA rules or Sigma detection logic around known malicious domains, and you have achieved visibility into command-and-control callbacks, data exfiltration destinations, malware staging servers, and lateral reconnaissance. Security publications from SANS ISC, Dark Reading, and SecurityWeek have championed DNS as an asymmetrically powerful early-warning system — Krebs on Security itself has documented case after case where organisations detected intrusions through DNS query anomalies after the breach was already months old.

The technical foundation is sound. DNS operates at layer 3-4 of the OSI model, beneath application-layer encryption. A compromised host cannot hide its DNS queries (without proxying through encrypted DNS-over-HTTPS or DNS-over-TLS, which introduces its own visibility and performance tradeoffs). A domain controller, workstation, or server exfiltrating data to attacker infrastructure must eventually resolve an IP. DNS is also cheap: most enterprises already run BIND, Windows Server DNS, or cloud DNS services (AWS Route 53, Cloudflare, Google Public DNS) with query logging available at marginal operational cost. The industry has accordingly invested in DNS-centric detection frameworks — Snort, Suricata, and open-source Zeek have DNS parsers; commercial SIEM platforms (Splunk, Elastic, CrowdStrike, Microsoft Sentinel) ingest DNS logs and correlate them against threat intelligence feeds (DNSDB, Farsight Security, open-source blocklists). NIST Cybersecurity Framework (CSF) guidance (Identify.AM-3, Detect.DE-4) acknowledges DNS monitoring as a component of asset discovery and anomaly detection.

The real-world validation has been striking. The Change Healthcare ransomware incident (February 2024) — one of the costliest healthcare breaches in US history — was preceded by reconnaissance activity that included DNS queries for internal infrastructure. The Optus breach (September 2022) involved attackers performing DNS enumeration of customer databases. The Synnovis NHS ransomware attack (June 2024), which crippled pathology services across UK hospitals for weeks, relied on lateral movement preceded by DNS reconnaissance. In each case, post-breach forensic analysis recovered DNS query logs that, had they been properly correlated against threat intelligence and internal baselines, would have accelerated detection and containment. The UK's Financial Conduct Authority (FCA) and the Information Commissioner's Office (ICO), in their post-incident guidance and enforcement actions under GDPR and the Network and Information Systems Regulations 2018 (NIS 2018), have explicitly cited absence of DNS monitoring as a control gap.

Yet DNS detection, as it is practised today, exists within an architecture that has reached its operational ceiling. The detection itself is sound; the ecosystem that surrounds it is not.

The Architectural Failure: Detection Cannot Compensate for Absence

The standard DNS detection stack assumes a reactive posture: intrusion has occurred, the host is now beaconing or exfiltrating, and detection logic — domain reputation scoring, anomaly profiling, Snort/Sigma rules, MITRE ATT&CK enrichment — identifies the malicious communication after the fact. This is post-breach detection, and it is fundamentally constrained by the speed of alert triage. Even with modern SOAR orchestration, alert-to-human-analyst time remains in the minutes-to-hours range. By that point, in a Change Healthcare scenario, the attacker has already had network access for weeks; in a Synnovis scenario, months. The detection worked — but too late.

More critically, DNS monitoring as currently deployed offers no structural resistance to compromise. It is a sensor, nothing more. It records what happened; it does not prevent the host from attempting the query in the first place. An infected endpoint can resolve attacker-controlled domains across multiple naming schemes: legitimate typosquats, algorithmically generated domains (DGAs), newly registered infrastructure rotating on fast-flux networks. Organisations respond by deploying DNS sinkholing, threat intelligence feed integration, and DNS firewalling (via Cisco Umbrella, Cloudflare Gateway, Zscaler, or on-premises appliances). But each of these is a control placed between the client and the resolver — a choke point that assumes the host itself is trustworthy. The moment the endpoint has been compromised, this assumption collapses.

Worse, DNS logs themselves become an attack surface. A sophisticated adversary with code execution on the DNS infrastructure (a resolver, forwarder, or recursive server) can suppress query logs, poison cache entries, or redirect legitimate queries. The Snowflake tenant compromise cascade (November 2023–February 2024) — which affected dozens of high-profile organisations including Ticketmaster, Santander, and LendingClub — involved attackers who, once inside tenant environments, had access to logging and telemetry systems. DNS logs, stored on centralised SIEM platforms or cloud logging services, are themselves breach targets. A 2024 analysis by security researchers at Troy Hunt's Have I Been Pwned documented cases where organisations discovered their DNS logs had been accessed by attackers months after exfiltration — because DNS log integrity had not been cryptographically protected.

The fundamental problem is architectural: organisations have built the ability to see DNS queries, but not the ability to trust the query environment itself, nor to prevent the query from occurring. Detection is treated as a substitute for prevention, and because no substitute exists for actually securing the host, DNS monitoring has become a confidence signal masking deeper structural fragility.

The PULSE Reading: Zero-Knowledge Substrate and Continuous Drift

The PULSE doctrine proposes an inversion: do not collect DNS queries and analyse them downstream. Instead, engineer the DNS substrate itself such that:

1. A compromised host cannot resolve attacker-controlled infrastructure — because the recursive resolver and all forwarding layers operate under a zero-knowledge commitment. The host itself does not hold the cryptographic material to redirect queries; the resolver cannot be tricked into lying to the client; threat intelligence is encrypted and verified at query time, not imported as a bulk feed.

1. Query metadata is cryptographically bound to time, source, and resolution result — making post-hoc DNS log manipulation detectable without reliance on centralised logging infrastructure. HMAC-SHA256 query signing, using ephemeral per-host keys distributed via secure enclave or attestation protocol, ensures that no query can be unlogged or falsified without breaking cryptographic verification.

1. The recursive resolver and authoritative nameserver are logically separated by an adaptive threat-intelligence decision layer — one that continuously shifts its filtering posture based on real-time telemetry, not static blocklists. This is not Snort or Suricata rules; it is domain-specific primitives embedded in the DNS protocol stack itself.

1. Lateral movement reconnaissance is blocked at the DNS layer — because internal domain queries from external (or anomalous) sources are verified against a cryptographically signed authority ledger, updated in real-time, that the host cannot bypass. A compromised endpoint attempting to enumerate internal hostnames (a standard reconnaissance technique, documented in the Synnovis incident) triggers architectural denial, not detection.

This is not DNS filtering as traditionally understood. It is DNS as a post-breach resistance mechanism — not because it prevents initial compromise, but because it renders the most common post-compromise actions (command-and-control, data exfiltration, lateral reconnaissance via DNS) structurally impossible without active disruption of the DNS substrate itself. An attacker would need to compromise the resolver infrastructure or poison the threat-intelligence layer — substantially harder than compromising an endpoint.

Architectural Principles for DNS-as-Resistance

Concretely, the implementation follows these principles:

Zero-Knowledge Query Verification: Recursive resolvers enforce a zero-knowledge proof that a queried domain is either (a) in the organisation's authorised internal namespace, verified cryptographically against a Merkle tree signed by the domain's DNSSEC KSK (Key Signing Key), or (b) permitted by a real-time threat-intelligence oracle, also cryptographically signed and rotated every 10 minutes. The host does not hold the key material; only the resolver does. A Trojan running on the endpoint cannot forge a resolution to attacker infrastructure because the resolver's decision logic is not accessible to user-space code.

Encrypted Authority Ledger: Internal DNS authority is stored not in cleartext zone files but in an encrypted, append-only ledger. Each host receives a subset of this ledger appropriate to its network context (its VLAN, service role, zero-trust network access policy). When an endpoint queries for an internal hostname it has no authority to resolve, the resolver returns NXDOMAIN (not an error that triggers a secondary attacker-controlled resolver), and the event is cryptographically logged. Lateral reconnaissance via DNS becomes visible structurally, not through anomaly detection.

Continuous Adversarial Drift: Threat-intelligence filtering rules are not deployed once per quarter; they rotate every 10 minutes, based on continuous ingestion of telemetry from the organisation's endpoints, network sensors, and historical threat feeds. The resolver's posture adapts: if a domain has appeared in a suspicious DNS query pattern (high query volume from a single host, recursive queries to newly registered domains, queries to known DGA infrastructure), the resolver's threat-intelligence layer adjusts its scoring and begins challenging future queries to that domain with DNS-over-TLS validation or rate-limiting. The attacker observes the change and must constantly adjust their infrastructure — a continuous cost borne entirely by the adversary.

Control-Plane / Data-Plane Separation: DNS query resolution (the data plane) is logically isolated from threat-intelligence decision-making and policy updates (the control plane). A compromise of the threat-intelligence management system does not automatically poison all DNS lookups — it triggers a cryptographic proof-of-work or rate-limit that forces an out-of-band human review before changes propagate. This is not EDR orchestration; it is architectural separation, embedded in the DNS substrate.

Practical Implications and Regulator Recognition

The UK's Prudential Regulation Authority (PRA), under APRA CPS 234 (Advanced Operational Resilience), has begun explicitly requiring organisations to "design operational resilience into core service components, not detect failures after they occur." The European Union's Digital Operational Resilience Act (DORA), effective January 2025, imposes near-identical language on financial institutions: "Resilient infrastructure and processes must be designed from the outset, not retrofitted through detection and response." The US Securities and Exchange Commission's 4-day breach disclosure rule (effective February 2024) has already begun pressuring organisations to compress alert-to-disclosure timelines — a constraint that makes post-breach detection increasingly untenable as a primary control.

DNS-as-resistance aligns with this regulatory shift because it does not attempt to detect intrusions faster; it prevents the attacker from using DNS to coordinate the intrusion in the first place. An organisation operating under the architectural principles outlined above can truthfully state to its regulator: "We cannot prevent initial endpoint compromise, but we have made it structurally impossible for an attacker to use DNS to exfiltrate data, callback to command-and-control, or reconnoitre our internal infrastructure — without active disruption of our DNS infrastructure itself, which we monitor with cryptographic assurance." This is a claim no legacy detection architecture can make.

The Obsolescence of Legacy Sensors

The industry will continue to improve EDR, SIEM, and SOAR platforms. Vendored YARA rules will become more sophisticated. Alert correlation will accelerate. But none of these innovations address the core architectural failure: that detection is not prevention, and post-breach visibility does not equal post-breach resistance. DNS monitoring as practised today is a sensor that records what happened; the PULSE reading is to make DNS itself part of the architecture that prevents the attacker's goals from being achievable in the first place.

This is not a call to abandon DNS monitoring. It is a call to stop using DNS monitoring as a substitute for structural security. DNS is the most underrated sensor in your environment precisely because we have asked too much of it — we have asked it to be a detection system when it should be a resistance layer. The organisations that will survive the next generation of intrusions are those that have engineered DNS not as a source of alerts, but as a mechanism of architectural denial.

---

Qualified operators seeking a detailed technical briefing on zero-knowledge DNS substrates, cryptographic query binding, and continuous adversarial drift implementation should request an engagement under Mutual NDA.