Detection and Logging

DNS Logs

DNS logs are high value because most connections begin with name resolution. They help you identify suspicious domains, domain generation behavior, and signs of DNS tunneling or misconfiguration.

Learning objectives

What you should be able to do after reading.
  • Understand what a DNS query and response represent in an investigation
  • Use baselines to spot rare domains, unusual query types, and abnormal failure rates
  • Recognize indicators of tunneling and domain generation without relying on exact signatures

At a glance

Fast mental model before you dive in.
🧠
High value fields
  • Client identity (host, IP, subnet)
  • Query details (qname, qtype)
  • Response details (rcode, answers)
  • Timing (timestamp, response time)
Strong early signals
  • Newly seen domains queried by critical hosts
  • Many NXDOMAIN responses from one client
  • High volume unique subdomains under one domain
  • Unusual query types such as frequent TXT
Safe response
  • Confirm with endpoint and proxy logs before blocking broadly
  • Prefer resolver level controls for consistent enforcement
  • Use allow lists for business critical domains
  • Document changes so you can roll back quickly

What to collect

  • Client identifier, queried name, query type, response code, and the returned answers
  • Resolver actions such as allow, block, redirect, or sinkhole, including the policy reason when available
  • Latency and failure rates so you can detect outages, abuse, and resolver misconfiguration

Common suspicious patterns

Pattern What you see Why it matters Typical response
High NXDOMAIN Many lookups that return non existent domains from one host Often DGA activity, typos, or blocked malware retry loops Inspect top queried names, check the endpoint, and block known bad domains
Long labels Very long or high entropy subdomains with steady volume Can indicate data being encoded into DNS queries (tunneling) Review the domain and query structure, block if malicious, and investigate the host
Rare TLDs New or uncommon TLDs and domains suddenly become frequent Often used in phishing and commodity malware infrastructure Enrich and validate, then block or sinkhole and monitor impacted hosts

Signals to watch for

Patterns worth investigating further.
📡
  • A sudden spike in NXDOMAIN or SERVFAIL responses
  • Domains with high entropy labels that appear machine generated
  • One endpoint generating far more DNS queries than comparable systems

DEEP DIVE

DNS basics that matter in investigations

DNS is often the first observable step before a connection. If a host resolves a domain, it is a strong hint that it may try to connect to the returned address soon after.

Capture key fields consistently: client, resolver, qname, qtype, rcode, answers, and response time.

Preserve both the query and the response when possible, because answers can change over time and caches can mask what happened later.

Baselines beat guesswork

A baseline can be a rolling list of common domains per subnet and per application. When you know what normal looks like, rare domains and rare query types stand out quickly.

Baselines should be contextual. A developer workstation, a server, and a kiosk have different normal. Compare like with like.

Track first seen for domains in your environment. It is a simple but powerful enrichment field during investigations.

Tunneling and abuse signals

DNS tunneling and abuse often show odd query shapes and odd volumes. Very long subdomains, high entropy labels, frequent TXT queries, and many unique subdomains under one domain are common warning signs.

Repeated NXDOMAIN responses can indicate domain generation behavior, typos, or a misconfigured application. Use context to decide which.

Correlate suspicious DNS with outbound connections to the resolved IPs, and with process activity on the host that made the queries.

Enrichment and blocking safely

Enrichment makes DNS logs far more useful. Map domains to category, reputation, and ownership when you can. Even basic enrichment like first seen and who queried helps.

Blocking should be careful and reversible. Prefer resolver level controls so you can log the decision and apply policy consistently.

Use allow lists for critical business domains, and document changes so you can roll back quickly if you break something.

Resolver view versus authoritative view

Where you log DNS matters. Resolver logs show what your clients asked. Authoritative logs show what the world asked your domains. They answer different questions.

For detection and logging inside an organization, resolver logs are usually the most valuable because they tie activity back to internal clients.

Modern DNS features that affect visibility

Encrypted DNS options can reduce visibility at traditional network sensors. If clients use DNS over HTTPS directly to external resolvers, your internal resolver logs may not see the queries.

A practical approach is to enforce approved resolvers and monitor for direct outbound traffic to known public resolver services.

Starter hunts

• Newly seen domains queried by critical hosts

• Many NXDOMAIN responses from one client

• Unusual qtype usage such as frequent TXT for one domain

• High volume unique subdomains under one parent

• Domains with very long labels compared to baseline