DNS activity is the observable use of the Domain Name System to query, resolve, or respond to host and service names. It covers lookups, caching, zone transfers, and related traffic patterns between clients, resolvers, and authoritative servers, which security teams inspect for misrouting, tunnelling, or command-and-control behaviour.
What DNS activity tells you
DNS activity is one of the clearest ways to see how systems discover and reach services. Because every lookup reveals a naming decision, it can expose whether traffic is following expected paths, being redirected, or contacting unfamiliar infrastructure.
For defenders, DNS is useful because it sits close to the start of many communications. A single query can show the intended destination name, the resolver path, the response returned, and whether a client is repeatedly asking for the same name or generating unusual patterns.
Common DNS activity patterns
Normal DNS activity includes recursive lookups, cached answers, authoritative responses, and occasional zone transfers between trusted DNS servers. These patterns are routine, but the details matter: query rate, query type, response code, time-to-live behaviour, and the mix of internal versus external names all help establish what is ordinary for an environment.
Security teams also look for activity that departs from common business use. Repeated lookups for random-looking subdomains, unusual TXT queries, or abrupt resolver changes can signal tunnelling, beaconing, or attempts to hide command-and-control traffic inside a protocol that many networks allow by default.
Why DNS activity is security-relevant
DNS is often trusted as a utility layer, which makes it attractive for abuse. If an attacker can influence resolution, they can redirect users to rogue infrastructure, stall services by degrading name resolution, or conceal outbound communications in queries that blend into normal traffic.
That is why DNS activity is examined alongside host, network, and proxy telemetry. The value is not just in seeing that a lookup occurred, but in understanding whether the lookup supports legitimate service discovery, suspicious redirection, or a larger compromise path.
When DNS is misconfigured or insufficiently observed, organisations can miss early signs of exploitation. The same visibility gap can also hide dependency failures, because applications may appear broken long before the root cause is traced back to resolution issues.
How defenders use DNS activity in investigation
Investigators usually start with asset inventory and name ownership, then compare observed DNS activity with expected application behaviour. That comparison helps separate routine service resolution from traffic that originates on unexpected hosts, targets unfamiliar domains, or changes patterns after a system or user compromise.
Resolvers, authoritative logs, firewall records, and endpoint telemetry are most useful when correlated. A single DNS event may look harmless in isolation, but a sequence of queries, retries, failed resolutions, and subsequent connections can reveal staging, persistence, or data exfiltration attempts.
For baseline reference, defenders often rely on authoritative naming and registry sources such as IANA to understand protocol parameters and naming infrastructure, and they may compare findings against broader control guidance such as NIST Cybersecurity Framework 2.0 when building detection and response practices around network visibility.
Risk and Threat Considerations
DNS activity can become a security signal because DNS is both widely trusted and widely exposed. Attackers may abuse that trust to redirect traffic, hide command-and-control communications, or make malicious infrastructure look like ordinary resolution activity.
Failure mechanism: Weak logging, blind spots in resolver telemetry, or permissive DNS egress controls can let malicious lookups and responses blend into routine traffic, while misrouting or tunnelling remains undetected.
Impact: The result can include session theft, service redirection, data exfiltration, or delayed incident detection, especially when DNS is the first visible stage of a broader compromise chain.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Security Continuous Monitoring | DNS activity is monitored as part of network and service telemetry for anomalies and compromise signals. |
| DE.AE-02 — Detected Events are Analyzed | Suspicious DNS patterns require analysis to distinguish routine lookups from tunnelling or C2. | |
| Recommendation — Monitor DNS telemetry for unusual resolution patterns and feed anomalies into detection workflows. Analyze suspicious DNS events to separate benign resolution from attack activity. | ||
| MITRE ATT&CK | T1071.004 — Application Layer Protocol: DNS | DNS activity is a known channel for command-and-control and covert communication. |
| Recommendation — Map suspicious DNS patterns to T1071.004 and hunt for command-and-control behaviour. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | DNS activity is a core network telemetry source for detecting anomalies and malicious traffic. |
| Recommendation — Collect and review DNS logs to identify abnormal resolution and malicious traffic patterns. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | DNS visibility depends on generating and retaining logs for resolver and server activity. |
| Recommendation — Generate DNS audit records that preserve query, response, and resolver activity for investigation. | ||
Practitioner Guidance
Why practitioners should care: DNS is a high-value control point because it sits between user intent and network reachability. If you can interpret DNS activity well, you gain early visibility into misconfiguration, abuse, and compromise.
What to watch for: Focus on sudden changes in query volume, unusual record types, repeated failures, rare destinations, and DNS responses that do not match the application or host that generated them. Those patterns often matter more than any single lookup.
Practitioner takeaway: Treat DNS as a behavioural data source, not just plumbing, and compare it against a stable baseline for each application, resolver, and network segment.
Related resources from NHI Mgmt Group
- How should security teams detect fast flux activity in DNS traffic before it supports a broader intrusion?
- Why do encrypted DNS and TLS still leave some internet activity exposed to ISPs?
- Why does suspicious EC2 DNS activity create risk for cloud environments?
- What does unusual DNS query activity usually indicate?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org