The DNS blind spot hiding in your agentic pipelines
DNS lookup latency is invisible to standard OpenTelemetry instrumentation. eBPF-based tracing closes the gap, and it matters more as agents fan out calls across MCP servers.
DNS resolution happens before a connection is established which means slow or failing lookups don't show up in your traces. The span starts after DNS lookup completes or times out.
That gap is invisible to standard OpenTelemetry instrumentation, and in a microservice or agentic architecture, it's one of the most frustrating latency sources to diagnose because nothing in your dashboard points to it.
At KubeCon + CloudNativeCon Europe 2026, I presented alongside Nikola Grcevski, Principal Software Engineer at Grafana Labs, on how eBPF-based instrumentation, specifically the OpenTelemetry eBPF Instrumentation project has been extended to surface DNS tracing and metrics directly from the kernel. No code changes, no sidecar proxies. The kernel sees the lookup; eBPF captures it.
Why this matters more now: agentic pipelines fan out. A single agent step may call four or five MCP servers in sequence or parallel. Each call starts with a DNS lookup. If any of those lookups are slow — stale TTL, misconfigured resolver, transient NXDOMAIN — you'll see latency on the agent response and no obvious cause in your traces. As MCP adoption scales, this blind spot scales with it.
Watch the talk for the full technical walkthrough, including how DNS spans are correlated back to the originating service and surfaced through standard OTel pipelines.
