A query log is a raw record of DNS requests that shows what was queried, where it came from, and how it was resolved. In practice, it provides the detail needed to investigate misconfigurations, unused records, unusual traffic, and incident timelines.
Expanded Definition
A query log is the authoritative telemetry trail for DNS activity: it records the queried name, the source that issued the request, the response returned, and the resolution path that followed. In NHI operations, that makes it more than a network record. It becomes a visibility source for service accounts, workloads, agents, and other non-human entities that depend on DNS to discover endpoints, call internal services, and reach external dependencies.
Usage in the industry is still evolving, because some teams treat query logs as a pure troubleshooting artifact while others elevate them into security evidence for detection, forensics, and policy validation. The distinction matters. A DNS query log can help confirm whether an NHI is contacting expected domains, whether a workload is unexpectedly resolving new infrastructure, or whether a compromised identity is probing for lateral movement paths. That aligns with the broader governance approach described in the Ultimate Guide to NHIs and with the visibility emphasis in NIST Cybersecurity Framework 2.0.
The most common misapplication is treating query logs as proof of authorization, which occurs when teams assume a successful DNS resolution means the requesting NHI was allowed to access the destination.
Examples and Use Cases
Implementing query log analysis rigorously often introduces data volume and retention overhead, requiring organisations to weigh forensic depth against storage, cost, and review complexity.
- Investigating whether a service account started resolving an unfamiliar domain after a deployment change, then correlating the event with workload identity activity.
- Detecting unused DNS records tied to decommissioned NHIs, which helps reduce stale dependencies and cleanup risk.
- Tracing the sequence of lookups during an incident to reconstruct when an agent began contacting a suspicious host and how far the activity spread.
- Spotting unusual query bursts from automation that may indicate misconfigured retries, token misuse, or a compromised workload path.
- Comparing query patterns against expected service behavior using operational guidance from the Ultimate Guide to NHIs alongside DNS and identity controls informed by NIST Cybersecurity Framework 2.0.
These examples show why query logs are especially valuable in environments where agents, APIs, and service accounts change rapidly and where DNS is often the first observable step in a connection chain.
Why It Matters in NHI Security
Query logs matter because they expose the early signs of NHI misuse before the attack reaches credentials, data, or privileged APIs. When service accounts, keys, or agentic workflows are compromised, DNS activity often provides the first durable evidence of reconnaissance, command routing, or exfiltration staging. That is why NHI governance cannot rely only on vault status or IAM policy snapshots. It also needs operational telemetry that shows what identities actually attempted to resolve and reach.
This becomes more urgent when organisations realise how often NHIs are already overexposed. NHI Mgmt Group reports that only 5.7% of organisations have full visibility into their service accounts, which means query logs may be one of the few practical ways to reconstruct NHI behavior at scale. Used well, they support anomaly detection, incident scoping, and post-incident cleanup across identity, network, and workload layers.
Practitioners should pair query logs with identity context, because DNS alone rarely explains intent or privilege. Organisations typically encounter the operational importance of query logs only after an investigation is already underway, at which point the term becomes unavoidable to reconstruct compromise paths and validate containment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Query logs help reveal NHI visibility gaps and unexpected access patterns. |
| NIST CSF 2.0 | DE.AE-3 | Anomalous event detection relies on logs that show unusual query behavior. |
| NIST Zero Trust (SP 800-207) | ID.AM | Zero Trust asset and identity context depends on observable request telemetry. |
Review DNS telemetry to identify unmanaged NHI behavior and unexpected lookup paths.
Related resources from NHI Mgmt Group
- How should security teams govern AI agents that query sensitive data in Snowflake?
- Who is accountable when an AI agent runs a query on behalf of a user?
- How should security teams govern AI assistants that can query workload IAM data?
- How should security teams handle AI agents that need to log into SaaS applications?
