TL;DR: Suspicious DNS activity is only the starting signal, according to Infoblox's analysis of network observability. Teams need correlated traffic, routing and asset context to understand blast radius and decide fast.
Editorial analysis by NHI Mgmt Group, based on content published by Infoblox: “See Everything. Know What to Do Next. Why Infoblox + Kentik Changes the Game”.
Key questions
Q: Why do fragmented telemetry sources slow down incident response?
A: Because no single source tells the full story.
Q: How does DNS intelligence help identify risky network activity?
A: DNS intelligence helps identify risky network activity by exposing query patterns, domain reputation, and unusual resolution behaviour, such as beaconing to newly registered domains or connections to known malicious infrastructure.
Q: How do network teams trace blast radius after a suspicious DNS lookup?
A: They correlate DNS resolution events with flow, routing and asset data to see which systems were actually reached after the lookup.
Practitioner guidance
- Correlate DNS queries with downstream flow logs Join resolution events to observed traffic so analysts can see which hosts, services and destinations were actually touched after a suspicious lookup.
- Build a single asset-to-traffic map Maintain an environment view that ties network identity, routing paths and destination risk to the systems that generated the traffic.
- Normalize telemetry before AI ingestion Feed AI assistants from governed DNS, flow, path and asset data rather than letting them query disconnected point systems.
Bottom line: The core problem is not lack of telemetry, but lack of correlation across DNS, flow and asset context.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Blast-radius visibility is now a control requirement, not a reporting luxury. When teams can see a suspicious DNS lookup but not the subsequent connections, they are still working with partial truth. That slows verification, weakens containment confidence and forces analysts to reconstruct movement from multiple tools. The operational priority is no longer just detecting an event, but proving its reach across the environment.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
A question worth separating out:
Q: What should teams prioritise when building network observability for security?
A: Teams should prioritise high-fidelity telemetry from DNS, endpoint, network flow, authentication, and cloud control plane sources, with centralised time synchronisation and normalised log formats. Good observability also needs coverage of east-west traffic, asset context, and retention long enough for baseline building and incident investigation. Without those controls, analysts miss low-and-slow abuse and cannot reconstruct attack paths.
👉 Read our full editorial: Network observability needs DNS context to expose full blast radius