DNS-Layer Threat Detection, Locally Run

Every internet connection on your network starts with a DNS lookup. Before a single byte of payload moves, the device asks "what's the IP address for this name?" — and a resolver answers, or doesn't.

That moment is the highest-leverage point in your network for a security control. If a query for a known-malicious domain is refused at the resolver, no connection ever forms. The malware never reaches its C2. The phishing payload never loads. The data exfiltration never starts. One decision, made in microseconds, prevents an entire downstream attack chain.

This post covers why DNS-layer enforcement is the right control for organizations with serious threat-detection requirements, what the detection stack actually needs to do to be useful, and what changes when your compliance posture rules out cloud-based DNS filters.

DNS is the universal chokepoint

Browser extensions like uBlock Origin are excellent within their scope, but they have a hard ceiling: they only protect what runs inside the browser. Every other process — email clients, IoT firmware, mobile apps, file-sharing tools, system updates, employee-installed software, malware that's already inside — bypasses extensions entirely.

DNS-layer enforcement doesn't care what software is making the connection. Every connection starts with a name lookup. Block the lookup, block the connection. One control covers every device, every application, every user on the network.

This is the same architectural reason DNS filtering was the first detection layer enterprise security teams adopted twenty years ago, before EDR, before network segmentation, before any of the modern tooling. It hasn't gotten less effective. The threats on the other end have just gotten faster.

What modern DNS-layer detection has to do

A list of "known-bad domains, refuse to answer" is a starting point, not a finished product. Real threat detection at this layer needs:

Reputation-based blocking for the bulk of known threats. Curated public threat-intelligence sources cover the long tail of cataloged malicious infrastructure. This catches the boring 80% of threat traffic instantly.

Heuristic detection for what isn't on any list yet. Domain-generation algorithms (DGAs) produce gibberish names like xkfjwpqmvtsldh.biz that have specific entropy and trigram-frequency signatures. Fast-flux infrastructure rotates IPs faster than any feed can catalog. Newly-registered domains (NRDs) are a leading indicator for phishing campaigns. None of these need a feed entry — they have signatures the resolver can compute on its own.

Lexical similarity detection for typosquats and homoglyph attacks. A user clicking a link in a phishing email isn't paying attention to whether the domain is paypa1.com or micros0ft-update.com — the brain auto-corrects in the moment. Confusable-character edit distance with proper substitution costs catches these patterns even when the exact domain has never been seen before.

Semantic similarity detection for what lexical similarity misses. A domain like secure-banking-portal-verify.example doesn't lexically match any specific brand, but its word distribution is semantically clustered around banking and authentication patterns. Modern embedding models can score this similarity against a curated bank of known-malicious indicators without needing to have seen this exact domain before.

Behavioral analysis for what static signals miss entirely. C2 malware that's already on a device makes periodic callouts to its operator — the timing pattern is detectable even when the destination domain looks innocuous. A device making queries to a rare destination at 57-second intervals for eight hours straight has a beacon fingerprint regardless of what the domain is named.

These layers compound. Anything caught by the first cheap signal doesn't need the more expensive ones. Anything that slips past one layer can be caught by the next. The result is a defense that's both fast (cheap layers handle the bulk) and adaptive (expensive layers handle the long tail).

What changes for restricted environments

For most organizations, the question of where the DNS resolver lives is operationally interesting but not legally binding. They can pick the easiest deployment — usually a SaaS DNS filter — and move on.

For organizations operating under HIPAA, GLBA, FFIEC, ITAR/CMMC, FERPA, GDPR, attorney-client privilege, or any number of contractual data-residency obligations, the question becomes binding. DNS queries are operational telemetry that can reveal:

What systems your organization talks to
What software you have installed
What websites employees visit
What internal-only resources exist
What patterns of activity your network shows

For some buyers, keeping that information on their own hardware is a written legal or contractual obligation. For others, it's a matter of preference — they would rather not hand operational telemetry to a third party.

Most commercial DNS filters run detection in their cloud. That's a reasonable engineering choice for many customers, and it's worked well in the market for a long time. For organizations with strict data-sovereignty requirements — or simply a preference to keep their data on their own hardware — that architecture creates a procurement question those customers shouldn't have to absorb.

The alternatives have historically been:

Build it yourself. Open-source DNS filters plus custom blocklists plus write-your-own-detection. Works, but takes a security engineer's full attention indefinitely.
Pay enterprise pricing for an appliance. Handles the use case but at price points that exclude SMBs and even some mid-market organizations.
Accept the gap. Run no DNS-layer detection at all and hope EDR catches what slips through. Inadequate for any serious threat model.

There's a fourth option, which is what we built: a DNS resolver that runs entirely on-premises, with the threat-detection stack and the reference banks shipping embedded in the installer. No SaaS uplink for detection. No commercial threat-feed subscription with its own data-flow contract to negotiate.

What that looks like in practice

The resolver runs as a daemon on a small host inside your network — a single VM, a dedicated appliance, or a colocated workload. Every DNS query from your network goes through it. The threat scoring happens in the local process, in microseconds. The query log lives in a local database under your retention policy. Detection events are explained in plain language: which signal fired, what category, what reference matched.

Reference banks of malicious indicators (curated from public threat-intelligence sources) refresh daily via a delta pull from our cloud. The delta transmission is one-way: we send bank updates, the resolver sends nothing about your queries the other direction.

For the small fraction of queries where the local score lands in an uncertainty band, the resolver can optionally consult our cloud threat-intel service via a 4-byte SHA-256 prefix lookup. This is k-anonymized: we get the prefix, return the matching hash bucket, and have no way to reconstruct which specific domain you asked about. Millions of legitimate domain names share any given 4-byte prefix; reconstruction isn't mathematically possible. This lookup is opt-in and admin-controlled — off by default in the current build.

There's also a periodic license heartbeat that transmits product version, platform, and uptime — nothing about your queries, devices, or detections. We need this for license-state management and product telemetry; it doesn't see your network's traffic.

What we're honest about: the current product is "cloud-light." It requires cloud connectivity for initial license activation. The daily bank delta pull and the license heartbeat are ongoing cloud touches. None of those touches transmit DNS query content or detection events.

What this is and isn't

DNS-layer detection is the highest-leverage early control in your stack. It catches a substantial portion of threats cheaply and stops many attack chains before they can form a connection. It's not a complete security stack — you still want endpoint detection, network segmentation, identity controls, and the rest of the posture. But for the cost of running one more daemon on one more host, you close a category of threat that nothing else closes as cleanly.

For organizations that prefer their DNS-layer detection to live on their own hardware, that's the gap we're working in.