DC0103: Active DNS
"Domain Name: Active DNS" data component captures queried DNS registry data that highlights current domain-to-IP address resolutions. This data includes both direct queries to DNS servers and records that provide mappings between domain names and associated IP addresses. It serves as a critical resource for tracking active infrastructure and understanding the network footprint of an organization or adversary. Examples:
- DNS Query Example: `nslookup example.com`, `dig example.com A` - PTR Record Example: `dig -x 192.168.1.1` - Tracking Malicious Domains: DNS logs reveal repeated queries to suspicious domains like malicious-site.com. The IPs resolved by these domains may be indicators of compromise (IOCs). - DNS Record Types - A/AAAA Record: Maps domain names to IP addresses (IPv4/IPv6). - CNAME Record: Canonical name records, often used for redirects. - MX Record: Mail exchange records, used to route emails. - TXT Record: Can include security information like SPF or DKIM policies. - SOA Record: Start of authority record for domain management. - NS Record: Lists authoritative name servers for the domain.
This data component can be collected through the following measures:
- System Utilities: Use built-in tools like `nslookup`, `dig`, or host on Linux, macOS, and Windows to perform active DNS queries. - DNS Logging - Windows DNS Server: Enable DNS Analytical Logging to capture DNS queries and responses. - Bind DNS: Enable query logging in the named.conf file. - Cloud Provider DNS Logging - AWS Route 53: Enable query logging through CloudWatch or S3: - Google Cloud DNS: Enable logging for Cloud DNS queries through Google Cloud Logging. - Network Traffic Monitoring: Use tools like Wireshark or Zeek to analyze DNS queries within network traffic. - Security Information and Event Management (SIEM) Integration: Aggregate DNS logs in a SIEM like Splunk to create alerts and monitor patterns. - Public OSINT Tools: Use OSINT platforms like VirusTotal, or PassiveTotal to collect information on domains and their associated IP addresses.
Analyst context for executives and security teams
Active DNS is the evidence of current domain-to-IP resolution activity. For leaders, its value is that it helps show what infrastructure users, systems, and possibly adversary-controlled domains are resolving to right now. This matters because many investigations, block decisions, and exposure reviews depend on knowing whether DNS logs and resolution records are available, timely, and searchable.
Executive priority
Treat Active DNS as a core visibility requirement for incident response, SOC triage, cloud security, and audit evidence. Executives should ask whether DNS query and response data is collected from enterprise DNS, cloud DNS, and network monitoring points, and whether teams can quickly answer: which hosts queried a suspicious domain, what IPs were returned, and whether those resolutions changed over time.
Technical view
SOC and IR teams should validate collection of DNS queries and resolution records, including A/AAAA, CNAME, MX, TXT, SOA, NS, and PTR where relevant. The supplied ATT&CK object does not define tactics, platforms, or detection logic, so detection engineering should focus on data readiness: completeness, timestamp quality, resolver coverage, cloud DNS logging, SIEM ingestion, retention, and correlation with host, network, and threat intelligence context.
Likely telemetry
- DNS server query and response logs
- Windows DNS Analytical Logging where Windows DNS is used
- BIND query logs where BIND is used
- Cloud DNS logs such as AWS Route 53 query logging and Google Cloud DNS logging when those services are in scope
- Network traffic DNS observations from tools such as Zeek or packet analysis
Detection direction
- Validate that DNS logs include both query and response details, not only domain names.
- Confirm coverage across on-premises DNS, cloud-hosted DNS, and monitored network segments; gaps often appear when endpoints use alternate resolvers or cloud services log separately.
- Tune analytics around suspicious or repeated domain queries using local baselines and threat intelligence, while accounting for legitimate CDNs, SaaS platforms, mail infrastructure, and security tooling that can generate noisy DNS activity.
- Ensure analysts can pivot from domain to resolved IPs, from IPs back to domains via PTR or OSINT context, and from DNS events to affected hosts and users.
- Because ATT&CK provides no official detection for this data component, local validation should prove collection quality before relying on alerts.
Mitigation priorities
- Prioritize enabling and centralizing DNS logging for enterprise and cloud DNS services.
- Standardize retention and parsing so responders can reconstruct domain-to-IP resolutions during investigations.
- Correlate DNS telemetry with network, endpoint, identity, and threat intelligence data to support triage and containment decisions.
- Review resolver architecture and logging gaps, especially cloud DNS, unmanaged networks, and systems bypassing expected DNS paths.
- Use Active DNS evidence to support compliance readiness by demonstrating visibility into name resolution activity and investigation workflows.
Analyst notes and limits
This is a data component, not a technique. Its defensive value is indirect but important: many detections and investigations depend on whether active DNS resolution data is available and reliable. The object supplies examples of collection methods and DNS record types but no ATT&CK relationships, tactics, platforms, or official detection guidance.
No relationship context, tactics, platforms, or official detection text were supplied. Any assessment of coverage, maliciousness, business exposure, or control effectiveness requires local DNS architecture, logging configuration, retention, SIEM parsing, and investigation evidence.
Active DNS
"Domain Name: Active DNS" data component captures queried DNS registry data that highlights current domain-to-IP address resolutions. This data includes both direct queries to DNS servers and records that provide mappings between domain names and associated IP addresses. It serves as a critical resource for tracking active infrastructure and understanding the network footprint of an organization or adversary. Examples:
- DNS Query Example: `nslookup example.com`, `dig example.com A` - PTR Record Example: `dig -x 192.168.1.1` - Tracking Malicious Domains: DNS logs reveal repeated queries to suspicious domains like malicious-site.com. The IPs resolved by these domains may be indicators of compromise (IOCs). - DNS Record Types - A/AAAA Record: Maps domain names to IP addresses (IPv4/IPv6). - CNAME Record: Canonical name records, often used for redirects. - MX Record: Mail exchange records, used to route emails. - TXT Record: Can include security information like SPF or DKIM policies. - SOA Record: Start of authority record for domain management. - NS Record: Lists authoritative name servers for the domain.
This data component can be collected through the following measures:
- System Utilities: Use built-in tools like `nslookup`, `dig`, or host on Linux, macOS, and Windows to perform active DNS queries. - DNS Logging - Windows DNS Server: Enable DNS Analytical Logging to capture DNS queries and responses. - Bind DNS: Enable query logging in the named.conf file. - Cloud Provider DNS Logging - AWS Route 53: Enable query logging through CloudWatch or S3: - Google Cloud DNS: Enable logging for Cloud DNS queries through Google Cloud Logging. - Network Traffic Monitoring: Use tools like Wireshark or Zeek to analyze DNS queries within network traffic. - Security Information and Event Management (SIEM) Integration: Aggregate DNS logs in a SIEM like Splunk to create alerts and monitor patterns. - Public OSINT Tools: Use OSINT platforms like VirusTotal, or PassiveTotal to collect information on domains and their associated IP addresses.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | ad1b501b8ed8… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0103Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.