Skip to main content
DNS Tap is an open source protocol that streams DNS query and response logs to a TCP endpoint. Enable DNS Tap from the Resolve Satellite to observe DNS resolution activity across your cluster in real time, without injecting anything into your application code.

How ResolveAI Uses DNS Tap

The Resolve Satellite uses DNS Tap to understand runtime relationships between services in your infrastructure. Each time one pod resolves another (ex. serviceA queries checkout.service.cluster.local), the Satellite logs that DNS request. These query logs help Resolve:
  • Build a live dependency graph of your architecture
  • Surface upstream/downstream relationships during investigations
  • Detect when a service goes down and others are affected
This visibility is critical if you don’t have full APM or tracing coverage.
DNS Tap allows the Resolve Satellite to capture service-to-service DNS queries and build a runtime dependency map.

Prerequisites

Install the Resolve Satellite before setting up DNS Tap.

1. Get Cluster IP

Copy the cluster IP of the Resolve Satellite.
kubectl

2. Configure CoreDNS

Add this line to the CoreDNS ConfigMap Corefile to forward logs.
ConfigMap
For example, your ConfigMap will look something like this:
coredns config file example

Frequently Asked Questions

DNS Tap is an open source logging / monitoring technology that enables DNS servers to efficiently forward DNS logs to a TCP socket. The logs contain all DNS queries and responses made by the DNS server, as well as the requester’s IP and port. This DNS information can be used to determine which source IPs are requesting IPs for which other servers. Additional information on DNS Tap can be found at https://dnstap.info/.
No, the Satellite receives data via a non-intrusive push model from the DNS layer. It does not introduce any observable latency or load on your DNS servers or Kubernetes workloads.For deeper implementation specifics and performance characteristics, we recommend watching this video overview.
The dependency map reflects real traffic-driven service relationships (not just declared ones). It includes:
  • Calling services and target services, identified via DNS requests.
  • Overlays with other metadata (e.g., from Kubernetes infrastructure data, tracing, etc.) to provide root cause context during investigations.
Example: If serviceA makes a DNS request to checkout.service.cluster.local, and that resolves to a pod in the checkout service, ResolveAI will register a dependency between the two—enriching investigations when serviceA fails.