What's in a Name: DNS as a Detection Goldmine
I’m Brian Olson, a cybersecurity professional with deep experience in DFIR and network forensics—currently working in Big Tech. My mission? To share hard-won lessons not just with fellow experts, but with anyone learning and growing in security—especially those in smaller companies without the resources or teams a massive enterprise has. I started blogging to break down real-world strategies, honest tool reviews, and battle-tested workflows in plain language. Whether you’re an underdog SOC analyst or a curious IT pro tackling security for the first time, my goal is to make the practical side of cybersecurity a little less overwhelming—and a lot more actionable. Expect guides that cut through the noise, resources that are actually useful at the keyboard, and stories that prove you don’t need a giant budget to make a real impact. You’ll also find my takes on personal finance, real estate, and anything that helps us level up—in and out of work. Let’s connect. We’re all in this together!
I love DNS. I know that's a weird thing to say, but I've been doing DFIR and detection engineering for close to two decades, and no single protocol has given me more signal per dollar invested than DNS. It's everywhere, it's readable, and most adversaries can't avoid it. Malware needs to phone home. Phishing needs a domain. Data exfiltration needs a channel. And almost all of it touches DNS at some point.
This post is adapted from a talk I've given at several security conferences. The goal isn't to make you a DNS expert — it's to convince you that if you're not building detections around DNS today, you're leaving some of the easiest wins in security on the table.
Why DNS Detections Matter
DNS is a pointer system. It translates friendly names to IP addresses, and nearly every piece of software on your network uses it — including malware. That's what makes it so useful from a detection standpoint: it gives you context that raw IP addresses never will.
Consider a netflow log that shows a host connecting to 1.2.3.4 over TCP/443 and transferring 1.2 MB. Is that suspicious? You have no idea. Now enrich that with DNS and you know the host resolved evil.org to 1.2.3.4 right before that connection. Completely different picture.
DNS touches three of the most critical phases of an attack: initial access (phishing domains, typosquatting), command and control (C2 beaconing, DNS tunneling), and data exfiltration (encoded data stuffed into subdomains or TXT records). If you can see DNS, you can see a lot of the kill chain.
Step Zero: Get the Data
None of this works if you can't see DNS traffic. Before you build a single detection, you need to control the signal.
Force internal resolver use. Block port 53 at your perimeter for everything except your internal DNS servers. If clients can reach external resolvers directly, you're blind. Disable DNS-over-HTTPS (DoH) where possible — it's a privacy feature that also happens to be a visibility killer for defenders.
Don't outsource your DNS. If you hand your DNS resolution to a third party and don't have access to the query logs, you've traded away one of the most valuable data sources in security. The exception is if your provider gives you full access to the data and control over policy — some do, most don't.
Log everything — and consider duplicating. DNS server logs, network captures at the perimeter, passive DNS collection — the more vantage points, the better. Ideally, I want duplicate data sets: logs from the DNS servers and from network taps. If one source drops packets or has a gap, the other catches it. 100% coverage matters here because a single missed resolution could be the one that tells you an endpoint just talked to C2.
Zeek deserves a special mention. It's very near and dear to my heart — it logs DNS alongside dozens of other protocols, so you can pivot from a suspicious DNS query straight into the associated HTTP, TLS, or file transfer session. Even if traffic is encrypted, you often get the domain from the TLS handshake. That cross-protocol visibility is something standalone DNS logging can't give you.
For the home lab crowd: ControlD is what I use for upstream DNS with filtering and analytics built in. Pi-hole is another popular option if you want to run your own resolver on a Raspberry Pi. Either way, implementation is straightforward — update your DHCP options or default gateway DNS settings and you're capturing.
Control the Pointer
Once you own DNS resolution, you can do more than observe — you can redirect. Sinkholing is one of the most underrated defensive capabilities available:
Sinkhole known malicious domains. Feed threat intelligence into your resolver and point known-bad domains at a controlled IP. The endpoint still tries to connect, but it reaches your sinkhole instead of the adversary's infrastructure. You get the alert; they get nothing.
Redirect for policy enforcement. Internal wiki pages, malware sandbox submissions, automatic isolation workflows — DNS gives you a control point that's fast and easy to update. Changing where a domain points takes seconds. Changing firewall rules across a fleet takes considerably longer.
Detections That Actually Work
Here's where it gets practical. These are the DNS-based detections I've found most valuable, roughly ordered from easiest to implement to most complex.
Newly Registered Domains
This is the single easiest high-value DNS detection you can build. A domain that was registered in the last two weeks and is now being queried by hosts in your network is suspicious about 99% of the time. Legitimate services don't spin up brand-new domains and immediately start receiving traffic from enterprise networks.
The catch: it can be surprisingly noisy. Advertisers seem to register and burn through domains at an absurd rate, presumably to stay ahead of blocklists. You'll need some tuning, but the signal-to-noise ratio is still excellent. I'd recommend blocking newly registered domains outright if your environment can tolerate it.
Newly Observed Domains
Different from newly registered, and in some ways more resilient as a detection. This is about when a domain was first seen in your network, not when it was created. A domain registered three years ago but never queried by any host in your environment until today is interesting — especially if it was registered, sat dormant, and then reactivated. Attackers buy expired domains or let infrastructure age specifically to evade newly-registered-domain detections. ICANN requires that creation dates be retained even after expiration, but once a domain changes hands, the age becomes misleading. Newly observed catches what newly registered misses.
Build first-seen and last-seen timestamps into your DNS data. "Never observed in this network before" is a surprisingly powerful filter in most networks.
DNS Permutations and Typosquatting
Attackers register domains that look like yours: yourcompany.co instead of yourcompany.com, yourc0mpany.com with a zero, yourconpany.com with a swapped letter. Dnstwist is an open-source tool that generates these permutations automatically — homoglyphs, character swaps, TLD variations, the works.
Levenshtein distance takes this further: calculate the edit distance between queried domains and your critical assets. A distance of 1 or 2 from your primary domain is a strong phishing indicator. This is how you catch the domains that are close enough to fool a human but different enough to evade exact-match blocklists.
Baseline Anomalies
This is harder to set up but incredibly valuable once it's running. Build a baseline of normal DNS activity in your environment — what domains are queried, how often, by which hosts — and then look for deviations.
There are public domain popularity lists you can use for initial noise reduction. Beyond that, build your own list from your own data. What matters is knowing what's normal for your environment, not the internet at large.
What to look for: day-over-day or week-over-week trending, spikes in query volume, unusually large byte transfers, periodic connection patterns that suggest beaconing, and anomalous record types (a sudden spike in TXT queries from a workstation is rarely innocent).
DNS Tunneling
This is the adversary embedding C2 communications or exfiltrated data directly inside DNS queries and responses. The data gets encoded into subdomain names or stuffed into TXT records. It's clever, and it works because most environments don't inspect DNS payload content.
Detection techniques: high query volume to a single domain, large byte transfers over DNS (which should normally be tiny), unusual record types, an abnormal number of subdomains under a single parent domain, and high entropy in the subdomain strings (base64-encoded data looks nothing like normal hostnames).
DNS Hijacking
A man-in-the-middle technique where the attacker intercepts DNS requests and spoofs a response with their own (malicious) answers. Detection is trickier here — you're looking for anomalous DNS responses, particularly duplicate Transaction IDs (XIDs). If you're running Zeek, check weird.log for DNS-related anomalies.
The TLS Angle
DNS isn't the only place domain names show up. TLS certificates leak domain information in two key places: the Server Name Indication (SNI) field in the Client Hello, and the Subject Alternative Name (SAN) field in the server's certificate.
This matters because as encrypted DNS (DoT, DoH) continues to roll out, traditional DNS visibility gets harder. TLS metadata becomes a complementary signal source — not a replacement, but an important supplement for environments where full DNS visibility isn't achievable. At least until TLS 1.3 with Encrypted Client Hello (ECH) goes mainstream, at which point we lose domain visibility in the handshake entirely. That's the last reliable place we could see where traffic was headed without decrypting it.
Challenges (Because Nothing Is Free)
DNS-based detection isn't without friction:
Performance. DNS admins will push back on logging — and they're not wrong. Full query logging on a busy resolver has a real performance cost. The workaround: tap the network instead of burdening the DNS servers themselves. Let Zeek or passivedns sensors capture the traffic off a port mirror or tap. You get the data without the performance argument.
Encrypted DNS is eating visibility. DNS-over-HTTPS, DNS-over-TLS, and TLS 1.3 with ECH are all designed to improve privacy, and they do — but they also reduce what defenders can see. I'll be honest: this one makes me nervous. Between browsers defaulting to DoH and CDN providers pushing encrypted everything, I think DNS visibility as we know it is slowly going away. Control what you can (your internal resolvers), supplement with TLS metadata where you can't, and accept that this is a moving target.
SIEM cost. If you're feeding DNS into a commercial SIEM, the volume can get expensive fast. High-volume DNS ingestion into something like Splunk will hit your license hard. Think about whether you need every query in your SIEM or whether you can do initial processing and filtering closer to the source, only forwarding the interesting stuff.
False positives. Newly registered domain detections will fire on ad-tech. Baseline anomalies will fire on software updates. Permutation checks will fire on legitimate domains that happen to look similar to yours. Tuning is ongoing work, not a one-time setup.
The Bottom Line
DNS gives you a window into almost everything happening on your network, and most of the detections I've described here range from trivial to moderate to implement. You don't need a massive security budget or a dedicated detection engineering team to start. You need DNS logs and curiosity.
As John Strand puts it: "Know normal, find evil." DNS is one of the best places to start knowing what normal looks like.
This post is adapted from a talk I've given at several security conferences — you can watch the full Zeek webinar version on YouTube. If you want to go deeper on network forensics and detection, I'm teaching FOR572 at SANS Security West in San Diego this May. Find me on LinkedIn or reach out at brian@hurrikane.net.
