---
title: Network observability DNS resolution analysis
---

# Network observability DNS resolution analysis {#network-observability-dns-resolution-analysis_{context}}

Learn how DNS resolution analysis uses eBPF-based decoding to identify service discovery issues and follow the steps to enable DNS tracking in the FlowCollector resource to enrich network flow records with domain names.

## Strategic benefits of DNS resolution analysis {#network-observability-dns-resolution-analysis-strategic-benefits_network-observability-dns-decoding}

Use DNS resolution analysis to differentiate between network transport failures and service discovery issues by enriching eBPF flow records with domain names and status codes.

Standard flow logs only show that traffic occurred on port 53. DNS resolution analysis allows you to complete the following tasks:

- Reduced Mean time to identify (Mtti): Distinguish immediately between a network routing failure and a DNS resolution failure, such as an `NXDOMAIN` error.
- Measure internal service latency: Track the time it takes for CoreDNS to respond to specific internal lookups (e.g., `my-service.namespace.svc.cluster.local`).
- Audit external dependencies: Audit which external APIs or third-party domains your workloads are communicating with without requiring sidecars or manual packet captures.
- Improved security posture: Detect potential data exfiltration or Command and Control (C2) activity by auditing the Fully Qualified Domain Names (FQDNs) queried by internal workloads.

### DNS flow enrichment {#dns-flow-enrichment_network-observability-dns-decoding}

When this feature is active, the eBPF agent enriches the flow records. This metadata allows you to group and filter traffic by the intent of the connection (the domain) rather than just the source IP.

Enhanced DNS decoding allows the eBPF agent to inspect UDP and TCP DNS traffic on port 53 along with the query names for the DNS request.

## Configure DNS domain tracking for network observability {#network-observability-dns-resolution-analysis-configure_network-observability-dns-decoding}

Enable DNS tracking in the Network Observability Operator to monitor DNS query names, response codes, and latency for network flows within the cluster.

**Prerequisites**

- The Network Observability Operator is installed.
- You have `cluster-admin` privileges.
- You are familiar with the `FlowCollector` custom resource.

**Procedure**

1. Edit the `FlowCollector` resource by running the following command:

   ```terminal
   $ oc edit flowcollector cluster
   ```
2. Configure the eBPF agent to enable the DNS tracking feature:

   ```yaml
   apiVersion: flows.netobserv.io/v1alpha1
   kind: FlowCollector
   metadata:
     name: cluster
   spec:
     agent:
       type: eBPF
       ebpf:
         features:
           - DNSTracking
   ```

   where:

   `spec.agent.type.ebpf.features`
   :   Specifies the list of features to enable for the eBPF agent. To enable DNS tracking, add `DNSTracking` to this list.
3. Save and exit the editor.

**Verification**

1. In the OpenShift Container Platform web console, navigate to **Observe** → **Network Traffic**.
2. In the **Traffic Flows** view, click the **Manage columns** icon.
3. Ensure that the **DNS Query Name**, **DNS Response Code**, and **DNS Latency** columns are selected.
4. Filter the results by setting **Port** to `53`.
5. Confirm that the flow table columns are populated with domain names and DNS metadata.

## DNS flow enrichment and analysis reference {#network-observability-dns-resolution-analysis-reference_network-observability-dns-decoding}

Identify metadata added to network flows, leverage DNS data for network optimization, and understand the performance and storage impacts on the cluster.

The following table describes the metadata fields added to network flows when DNS tracking is enabled.

> [!NOTE]
> Query names might be missing or truncated because of compression pointers or cache limitations.

**DNS flow metadata**

| Field | Description | Example |
| --- | --- | --- |
| `dns_query_name` | The Fully Qualified Domain Name (FQDN) being queried. | `example.com` |
| `dns_response_code` | The status code returned by the DNS server. | `NoError`, `NXDomain` |
| `dns_id` | The transaction ID used to match queries with responses. | `45213` |

### Leverage DNS data for network optimization {#leverage-dns-data-optimization_network-observability-dns-decoding}

Use the captured DNS metadata for the following operational outcomes:

- Audit external dependencies: Ensure workloads are not reaching out to unauthorized external APIs or high-risk domains.
- Performance tuning: Monitor `DNS Latency` to identify if `CoreDNS` pods require additional scaling or if upstream DNS providers are lagging.

### Identify misconfiguration errors {#identify-misconfiguration-errors_network-observability-dns-decoding}

A high frequency of `NXDOMAIN` responses typically indicates service discovery errors in application code or stale environment variables.

`NXDOMAIN` errors can be frequent in Kubernetes because of DNS searches on services and pods. While these results do not necessarily indicate a misconfiguration or broken URL, they can negatively impact performance.

When `NXDOMAIN` errors are returned despite an apparently valid Service or Pod host name, such as `my-svc.my-namespace.svc`, the resolver is likely configured to query DNS for different suffixes. You can optimize this by adding a trailing dot to fully qualified domain names to tell the resolver that the name is unambiguous.

For example, instead of `https://my-svc.my-namespace.svc`, use `https://my-svc.my-namespace.svc.cluster.local.` with a trailing dot.

### Loki storage considerations {#loki-storage-considerations_network-observability-dns-decoding}

DNS tracking increases the number of labels and the amount of metadata per flow. Ensure that the Loki storage is sized to accommodate the increased log volume.

**Additional resources**
{._additional-resources}

- [Network flows format reference](/openshift-docs-markdown/observability/network_observability/json-flows-format-reference#network-observability-flows-format_json_reference)
- [Network Observability Operator runbooks](https://github.com/openshift/runbooks/tree/master/alerts/network-observability-operator)