Almost every piece of malware has to resolve a name before it can talk to its operator, so outbound DNS is one of the cheapest places to catch an infected host. MITRE D3FEND names this detection DNS Traffic Analysis (D3-DNSTA) and defines it as "Analysis of domain name metadata, including name and DNS records, to determine whether the domain is likely to resolve to an undesirable host." It sits under the Detect tactic as a child of Network Traffic Analysis. Its digital artefacts are Outbound Internet DNS Lookup Traffic, which it analyses, and the DNS Lookup records that traffic may contain. This card covers the analytics D3FEND describes, the ATT&CK techniques it relates to D3-DNSTA, where to collect DNS data, how to verify detection and the limits, especially encrypted DNS. Collection and logging basics are in the DNS Logging and Detection Guide; this page stays on the D3FEND technique.
Key takeaways
- It judges the domain, not the content. D3FEND states plainly that the technique "does not check for content hosted at the domain". It decides from the name and the DNS records whether the destination is likely to be bad.
- D3FEND describes three analytics. Detecting algorithm-generated domains, scoring visited domains on traits such as unusual length, dynamic DNS, fast flux and recent registration, and turning domains seen in sandboxed malware into signatures.
- D3FEND relates it to DNS command and control. Through its artefacts, D3FEND links D3-DNSTA to T1071.004 DNS, T1568 Dynamic Resolution and T1040 Network Sniffing.
- Collection point decides visibility. Logging at the internal resolver sees every client but misses hosts that bypass it; logging on the network sees direct queries but not encrypted DNS over HTTPS or TLS.
- A compromised legitimate site passes. D3FEND's considerations note that a watering hole on a compromised server whose DNS is unchanged is not caught, so DNS analysis is one layer, not the whole answer.
D3-DNSTA at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-DNSTA (d3f:DNSTrafficAnalysis) |
| Tactic | Detect |
| Parent technique | Network Traffic Analysis |
| Digital artefacts | Outbound Internet DNS Lookup Traffic (analyzes); DNS Lookup (may contain) |
| Analytics named by D3FEND | Algorithm-generated domain detection; scoring on name length, dynamic DNS, fast flux and domain age; sandbox-derived domain signatures |
| D3FEND references | Patents from Palo Alto Networks (heuristic botnet detection; sinkholing), Rapid7 (domain age registration alert) and Vectra Networks (algorithm-generated domains), and an academic paper on predicting domain generation algorithms with LSTM networks |
| Typical data sources | Internal resolver query logs, network sensor DNS logs, endpoint DNS events, cloud resolver query logs, protective DNS services |
| Effort | Low to collect; medium to score and tune at volume |
| Main limitation | Blind to encrypted DNS that bypasses the monitored resolver and to bad content on good domains |
How it works
D3FEND's description gives three approaches, each backed by a reference.
- Algorithm-generated domains: some malware uses a domain generation algorithm (DGA) to produce many pseudo-random names, only a few of which the operator registers, so blocking a fixed list does not work. Analytics classify names as likely generated. The Vectra patent D3FEND cites also checks the IP addresses returned (how many, who owns them, whether they keep changing), registration details and domain popularity, and alerts above a score. The academic reference applies LSTM neural networks to the same classification.
- Heuristic scoring of visited domains: score each visited domain on traits such as a name longer than common, a dynamic DNS provider, fast-flux behaviour and recent registration, and alert above a threshold. The Rapid7 reference is built on domain registration age: newly registered domains are treated as high risk.
- Sandbox-derived signatures: run collected malware in a virtual environment, record the domains it contacts and turn them into signatures for other hosts. The Palo Alto Networks sinkholing reference then registers or redirects those domains to a sinkhole so infected hosts reveal themselves when they connect.
Practitioners add DNS tunnelling indicators to the same pipeline: unusually long query labels, high counts of unique subdomains under one parent domain, heavy use of TXT or NULL records and steady query rates from a single host. These are indicators to score, not fixed rules.
ATT&CK techniques D3FEND relates to D3-DNSTA
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-DNSTA. The rows below are inferred through shared artefacts (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What DNS analysis can notice |
|---|---|---|---|
| T1071.004 | Application Layer Protocol: DNS | Technique produces Outbound Internet DNS Lookup Traffic | Command and control carried inside queries and responses: long encoded labels, many unique subdomains, TXT-heavy traffic, regular timing |
| T1568 | Dynamic Resolution | Technique produces Outbound Internet DNS Lookup Traffic | Generated names, rapidly changing answers and short TTLs. Its sub-techniques include T1568.001 Fast Flux DNS and T1568.002 Domain Generation Algorithms |
| T1040 | Network Sniffing | Technique may produce DNS Lookup | Lookups made by sniffing tools resolving captured addresses; a weak signal on its own |
Defensive guidance for the two command and control techniques is in MITRE ATT&CK T1071 Application Layer Protocol and MITRE ATT&CK T1568 Dynamic Resolution; for sniffing see MITRE ATT&CK T1040 Network Sniffing. DNS tunnelling used purely as a transport is also close to T1572 Protocol Tunnelling Defensive Guide.
Where to collect DNS data
| Collection point | Key fields | Sees | Misses |
|---|---|---|---|
| AWS Route 53 Resolver query logging | VPC ID, source IP and instance ID, query name, record type, response code, response data, DNS Firewall action; delivered to CloudWatch Logs, S3 or Firehose | Queries from VPCs, inbound and outbound Resolver endpoints | Answers served from the resolver cache are not logged, so repeat queries within the TTL are absent |
| Network sensors (Suricata EVE dns events, Zeek dns.log) | Suricata: rrname, rrtype, rcode, answers with ttl and rdata. Zeek: query, qtype_name, rcode_name, answers, TTLs, with uid to join conn.log | Clear-text DNS crossing the sensor, including hosts that bypass the internal resolver | DNS over HTTPS and DNS over TLS (Zeek's documentation notes these are not captured in dns.log) |
| Protective DNS services | Blocked or redirected queries matching threat intelligence, with alerts | Known-bad domains for every client using the service | Unknown domains and clients configured to use another resolver |
| Windows DNS Server analytic log | Event IDs 257 RESPONSE_SUCCESS, 258 RESPONSE_FAILURE, 260 RECURSE_QUERY_OUT, 261 RECURSE_RESPONSE_IN | Every query the server answers, with client address | Clients that use another resolver. The log is off by default; Microsoft cites about 5% performance impact at 100,000 queries per second and none apparent at 50,000 or below |
| Windows endpoints (Sysmon Event ID 22, DNSEvent) | The process that made the query, the name and the result | Which process asked, on Windows 8.1 and later, cached or not | Applications that resolve over their own DoH client |
Collection points are listed alphabetically. Most organisations need two: one at the resolver or protective DNS layer for coverage of managed clients, and one on the network or endpoint to catch bypass. CISA's Protective DNS Resolver, for example, is mandated for US federal civilian agencies and blocks, redirects or sinkholes queries that match threat intelligence, alerting the agency and CISA. Wider design guidance is in the Protective DNS Guide and the NIST SP 800-81 Rev. 3 Secure DNS Deployment Guide.
Where identity fits
Workloads, containers and CI runners resolve a small, stable set of domains: their APIs, registries and cloud endpoints. That makes DNS profiles per workload identity unusually sharp. A build runner or service that starts resolving newly registered or generated domains is a strong lead, and on cloud resolvers the instance ID in the query log ties the lookup to the workload and its attached role. Keys and tokens stolen from such workloads are often used next, so pair a DNS alert with a check of the workload's credentials; see D3-CCSA Credential Compromise Scope Analysis.
Implementation steps
- Force DNS through known resolvers. Block outbound port 53 from clients except from the approved resolvers, and decide a policy for DNS over HTTPS and DNS over TLS (use managed endpoints that point to your resolver, or block known public DoH endpoints). Encrypted DNS options are covered in the Encrypted DNS Enterprise Guide.
- Turn on query logging. Enable resolver query logging (for Windows DNS Server, the analytic log; for cloud resolvers, the provider's query logging) and send it to the SIEM. Add Sysmon Event ID 22 or EDR DNS telemetry on endpoints to attribute queries to processes.
- Enrich each domain. Add registration age, popularity rank, dynamic DNS provider flag and threat intelligence matches. Reputation lookups are their own technique, covered in D3-DNRA Domain Name Reputation Analysis.
- Score. Combine generated-name likelihood, domain age, flux indicators and tunnelling indicators into a score per host and domain. Start with alert-only mode.
- Tune with an allowlist of patterns, not hosts. Content delivery networks, telemetry services and anti-malware products produce long, random-looking labels. Allowlist the parent domains after checking them, never whole hosts.
- Act on high scores. Route confirmed indicators to the protective DNS layer for blocking or sinkholing, and isolate hosts with strong command and control indicators.
- Roll back cleanly. Keep blocks and rules versioned; when a block breaks a business service, remove that entry only and record why.
How to verify it works
- Synthetic generated-name test: from an approved test host, resolve a short list of random-looking names under a test domain you control and confirm the analytic scores and alerts.
- New domain test: resolve a domain you registered recently for testing and confirm the age enrichment works.
- Bypass test: attempt a query directly to an external resolver from a client and confirm it is blocked or, at least, logged by the network sensor.
- Attribution test: confirm a test query appears in the endpoint log with the process name, and in the resolver log with the right client.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Share of client DNS traffic passing through logged resolvers | Close to 100% | Unlogged DNS is invisible to the technique |
| Direct outbound port 53 attempts from clients | Near zero, each investigated | Shows the bypass control is holding |
| Synthetic generated-name and new domain tests detected | 100% | End-to-end proof |
| DNS alerts closed as benign per week after tuning | Falling | Precision of scoring and allowlists |
| Time from high-score alert to block or isolation | Hours, not days | Command channels are active while you wait |
Limits, bypasses and failure patterns
- Encrypted DNS: DNS over HTTPS and DNS over TLS to an outside resolver hide queries from network sensors and skip the internal resolver.
- Good domains, bad content: D3FEND notes that a compromised server whose DNS is unchanged, for example in a watering hole attack, is not caught. Cloud storage, collaboration and code hosting domains used for command and control look normal in DNS.
- Volume: D3FEND's considerations state that DNS produces a large amount of traffic that can be resource-intensive to analyse in real time. Score in batches where real time is not affordable, and keep raw logs for hunting.
- Cache gaps: resolver logs that skip cached answers, as Route 53 Resolver query logging does, under-count repeated lookups, so beacon timing from resolver logs alone is unreliable.
- Noisy allowlists: allowlisting whole hosts (often the security tools themselves) creates a blind spot an attacker on that host can use.
- Dangling records on your own domains: outbound analysis does not cover takeover of your own subdomains; that is covered in the Subdomain Takeover and Dangling DNS Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Monitoring outbound communications for indicators of attack |
| NIST SP 800-53 Rev 5 | SC-7 Boundary Protection | Forcing DNS through managed interfaces and resolvers |
| NIST SP 800-53 Rev 5 | SC-20, SC-21, SC-22 | Secure name and address resolution services and their architecture |
| NIST SP 800-81 Rev. 3 | Secure Domain Name System (DNS) Deployment Guide (final, March 2026) | NIST guidelines to secure the DNS protocol and infrastructure and mitigate misuse or misconfiguration |
| NIST CSF 2.0 | DE.CM-01, DE.AE-02 | Network monitoring and analysis of adverse events |
| MITRE D3FEND | Network Traffic Analysis, D3-DNSTA | Parent and technique |
Related countermeasures
- Domain Name Reputation Analysis (D3-DNRA): scores a domain on known reputation rather than traffic. See D3-DNRA Domain Name Reputation Analysis.
- Homoglyph Detection (D3-HD): catches look-alike names. See D3-HD Homoglyph Detection.
- IP Reputation Analysis (D3-IPRA): checks the addresses the DNS answer returns. See D3-IPRA IP Reputation Analysis.
- Protocol Metadata Anomaly Detection (D3-PMAD): wider protocol field anomalies, including DNS. See D3-PMAD.
Practitioner checklist
- Block client DNS to anything but approved resolvers and set a policy for DoH and DoT.
- Enable resolver query logging and send it to the SIEM.
- Collect process-level DNS events on endpoints (Sysmon Event ID 22 or EDR).
- Run a network sensor DNS log to catch resolver bypass.
- Enrich domains with age, popularity, dynamic DNS and threat intelligence.
- Score generated names, flux and tunnelling indicators per host, starting in alert-only mode.
- Allowlist checked parent domains, never whole hosts.
- Feed confirmed indicators to protective DNS for blocking or sinkholing.
- Test with synthetic generated names, a new domain and a bypass attempt on a schedule.
Standards and references
- MITRE D3FEND: DNS Traffic Analysis (D3-DNSTA)
- NIST: SP 800-81 Rev. 3 Secure Domain Name System (DNS) Deployment Guide
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-4, SC-20 to SC-22)
- CISA: Protective Domain Name System (DNS) Resolver
- Microsoft Learn: DNS logging and diagnostics
- Microsoft Learn: Sysmon
- AWS: Route 53 Resolver query logging
- Zeek: dns.log documentation
Related NHI Mgmt Group resources: DNS Logging and Detection Guide · Protective DNS Guide · DNS Security Guide · MITRE D3FEND Guide