Amazon Route 53 Resolver Query Logs are DNS query records generated by the Route 53 Resolver for traffic handled inside a VPC. They show which domain names were queried, the source of the query, and whether it was answered or failed, which supports DNS monitoring and investigation.
What Route 53 Resolver Query Logs Tell You
Route 53 Resolver Query Logs give you visibility into DNS lookups made inside a VPC, including the queried domain, the source of the query, and whether resolution succeeded or failed. That makes them useful for understanding normal name-resolution patterns, tracing unexpected destinations, and building a record of DNS activity for investigations.
Why DNS Query Logging Matters
DNS is often one of the few control points that sits close to application and workload behaviour, so query logs can reveal activity that other telemetry misses. They help show which internal hosts, workloads, or services are attempting to resolve specific names, and they can expose whether a lookup failed because of misconfiguration, filtering, or external dependency issues.
Because the log records are tied to resolution events rather than packet payloads, they are better suited to answer “what names were requested, by whom, and with what result” than to reconstruct full traffic content. That distinction matters when you are separating routing problems, suspicious name lookups, and application failures from one another.
Used well, DNS logs become a practical source for DNS logging and detection, especially when you want to understand what should be collected and how query records support investigation and detection workflows.
What These Logs Can Reveal About Exposure
Resolver query logs can show unexpected domains, repeated failed lookups, or traffic patterns that suggest misuse of DNS as a transport or signalling channel. They can also highlight blind spots, for example when a workload appears active but resolves only a narrow set of names, or when a change in query behaviour coincides with an incident.
Those records are especially helpful when paired with VPC-level visibility. Amazon VPC security controls the surrounding network boundary, while resolver logs show the naming activity happening inside that boundary, which can help separate access-path issues from application-level faults.
Query logs are also relevant to exfiltration and command-and-control analysis because DNS is frequently used as an alternative protocol when direct outbound paths are limited. When domain lookups themselves are the signal, DNS telemetry can help spot patterns consistent with beaconing, tunnelling, or other low-bandwidth communication paths; that is why techniques such as exfiltration over alternative protocol remain an important analytical lens.
How to Use the Logs in Investigation
In an investigation, the most useful questions are usually simple: which domain was queried, from which source, at what time, and did the lookup succeed. That combination lets analysts correlate the query with host activity, application errors, or security events, then decide whether the lookup was expected, suspicious, or just noisy.
When a query pattern looks abnormal, the next step is usually to compare it with other DNS telemetry and with network controls, because logs alone rarely prove intent. A strong investigative workflow pairs resolver records with detection logic for DNS tunnelling, DGA, and other abuse patterns, rather than treating the query log as a standalone verdict.
For broader cloud visibility and guardrails, it is also useful to understand how DNS-related controls fit into the surrounding VPC design, as described in the Amazon VPC Security Guide.
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, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Network Monitoring | DNS query logs support continuous monitoring of network communications. |
| DE.AE-02 — Anomalous Events are Detected | Resolver logs help identify unusual domain lookups and failed queries. | |
| Recommendation — Collect and review DNS query telemetry to detect anomalous resolution patterns. Use DNS logs to detect abnormal query patterns and investigate them promptly. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | DNS resolver logs are security-relevant event records that must be captured. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Resolver logs are most useful when routinely reviewed for suspicious activity. | |
| Recommendation — Define which DNS events are logged so investigations have sufficient evidence. Analyze DNS audit records for unexpected names, sources, and failures. | ||
| CIS Controls v8 | 8 — Audit Log Management | DNS query logs are audit data used for detection and incident response. |
| Recommendation — Centralize and review DNS logs as part of your audit log management program. | ||
| MITRE ATT&CK | T1071.004 — Application Layer Protocol: DNS | DNS logs help detect adversary use of DNS for command and control or data transfer. |
| T1048 — Exfiltration Over Alternative Protocol | DNS can be used as an alternate channel for exfiltration and covert communication. | |
| Recommendation — Map suspicious DNS activity to T1071.004 and hunt for abuse patterns. Correlate DNS logs with outbound filtering to spot alternative-protocol exfiltration. | ||
Practitioner Guidance
What to watch for: Keep query logs wherever DNS behaviour is a meaningful part of your monitoring and incident response story, especially in environments where workloads reach external services or where DNS may be abused for stealthy communication. The practical value comes from correlating the source of the query with the name requested and the resolution outcome, not from collecting logs in isolation.
Governance implication: Treat resolver logs as operational evidence with a clear retention and access policy, because they can quickly become important for incident scoping, service troubleshooting, and proving whether a suspicious lookup was actually executed. If your environment depends on DNS for security visibility, make sure the log pipeline itself is monitored and protected.
Related resources from NHI Mgmt Group
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 November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org