---
title: "Automated, Simplified DNS Troubleshooting for Kubernetes: Only in Calico Enterprise"
source: "https://www.tigera.io/blog/automated-simplified-dns-troubleshooting-for-kubernetes-only-in-calico-enterprise/"
---

[Company Blog](https://www.tigera.io/category/company-blog/)

# Automated, Simplified DNS Troubleshooting for Kubernetes: Only in Calico Enterprise

By [John Armstrong](https://www.tigera.io/blog/author/john-armstrong/) on Dec 16, 2020 • 5 min read

The Domain Name System (DNS) is a naming system for computers, services, or other resources connected to the Internet or a private network. DNS translates domain names to the numerical IP addresses needed for locating and identifying computer services and devices. For decades It’s been an essential component of the Internet. It’s an essential part of Kubernetes as well, and is used to determine how workloads connect to [Kubernetes](http://kubernetes.io/) services as well as resources outside the cluster.

DNS also happens to be a common source of outages and issues in Kubernetes clusters. When applications are not working as expected, the root cause is often DNS-related. However, debugging and troubleshooting DNS issues in Kubernetes environments is not a trivial task given the limited amount of information Kubernetes provides for DNS queries.

Lacking the necessary visibility into the cluster to correlate a DNS query or reply with a specific workload, for example, you are left in the dark. Without Kubernetes context, you are unable to capture even the most fundamental information needed for troubleshooting, such as the type of DNS query (or reply) or the source of the query.

![DNS dashboard showing lack of Kubernetes context: queries, latency, and response codes by service are visible, but lack](https://www.tigera.io/app/uploads/2020/12/DNS-dashboard.png)

*Figure: The DNS Dashboard from Tigera helps Kubernetes teams more quickly confirm or eliminate DNS as the root cause for microservice and application connectivity issues, and eliminates a lot of manual, time-consuming introspection that would typically be required. No other vendor offers this automated capability.*

#### **Introducing DNS Dashboard for Kubernetes**

So how can you gain enough visibility into what is going on in DNS to quickly pin-point and efficiently troubleshoot issues? To solve this problem, our engineering team at Tigera has created the DNS Dashboard based on the DNS log data available in [Calico Enterprise](https://www.tigera.io/tigera-products/calico-commercial-editions/). It’s included in Calico Enterprise, is purpose-built for Kubernetes and provides an interactive GUI that enables you to:

- View the total number of DNS queries and replies

- Classify queries and replies by [record type](http://en.wikipedia.org/wiki/List_of_DNS_record_types), for example CNAME, A, AAAA, MX, SRV, etc.

- Determine the source of a query and whether it is from a workload or service

- Filter on troubleshooting scenarios

- Automatically log all DNS queries and replies

The DNS Dashboard helps Kubernetes teams more quickly confirm or eliminate DNS as the root cause for microservice and application connectivity issues, and eliminates a lot of manual, time-consuming introspection that would typically be required. No other vendor offers this automated capability.

#### **Classify and View DNS Codes by Service**

With the DNS Dashboard, you can view DNS codes by service. For example, if there is a Kubernetes service failure you can determine which service was queried, and can then further explore that service. Classifying queries and replies by service greatly simplifies the troubleshooting process and speeds problem resolution, immediately answering many of the questions that arise when troubleshooting connectivity issues:

- Which DNS servers are in use?

- Who is making the queries?

- What types of queries are being made?

- What replies are they receiving? Are there errors?

- How many queries of a particular service are being made?

- What is the minimum, maximum and average latency?

- How much data was transmitted/received by a service or pod?

#### **All DNS Activity is Automatically Logged**

As a CNI, Calico Enterprise is in the unique position of being able to monitor traffic flows to look for DNS queries and replies, and is able to generate a special set of DNS log data for all Kubernetes activity. This capability is not offered in Kubernetes by default.

External queries to domains outside the purview of Kubernetes are also logged by the DNS Dashboard. So if your pod is talking to the Internet or some other resource outside the cluster, you’ll know what domains it’s using and how many queries it’s making. Within the cluster there is a lot of noise, with services talking to other services. The DNS Dashboard cuts through the clutter and displays the Top 10 domains that are external to your cluster.

#### **Security and Compliance Considerations**

Application developers and DevOps aren’t the only teams that can benefit from the rich set of data that’s provided by DNS Dashboard and Calico Enterprise. Since all query data is logged, Security teams can apply Global Alerts in Calico Enterprise to define alerts that are automatically triggered based on certain criteria using the logged data. Security teams can answer the following questions:

- What DNS servers are being queried?

- How much data is being transferred and received by each pod?

- How many queries are being received?

Abnormal DNS behavior like an unusually high number of queries may indicate unauthorized data exfiltration via DNS and a flaw in your network policy such as a misconfiguration. NXDOMAINS in external requests, especially over TXT or CNAME requests, may suggest a DGA, infiltration or exfiltration attempt by an attacker. External queries to unknown domains may also represent suspicious behavior.

In any of these use cases, the automation that drives the Calico Enterprise DNS Dashboard can quickly confirm or eliminate DNS as the root cause of the issue, thus speeding troubleshooting and problem resolution in Kubernetes environments.

————————————————————————————-

[**Free Online Training**](https://www.tigera.io/events/)

Access Live and On-Demand Kubernetes Training

[**Calico Enterprise – Try Now**](https://www.calicocloud.io/)

Kubernetes Networking, Security and Observability in Hybrid and Multi-Clouds

[Products](https://www.tigera.io/tags/products/)

## Related posts

[![Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/app/uploads/2026/09/Meet-Mylo-An-AI-native-way-to-work-with-Calico.png)](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/)

[Technical Blog](https://www.tigera.io/category/technical-blog/)

#### [Meet Mylo: An AI-native way to work with Calico](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/)

By [Phil DiCorpo](https://www.tigera.io/blog/author/phil-dicorpo/)
on Sep 3, 2026

A library of Calico tools and skills — delivered through the Calico MCP Server What if your hardest network question took ten minutes instead of ten days? Anyone who has operated Kubernetes networking at scale...

[Read more](https://www.tigera.io/blog/meet-mylo-an-ai-native-way-to-work-with-calico/)

[![The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/app/uploads/2026/08/The-Safest-Place-to-Run-an-AI-Agent-Is-On-a-Cluster-That-Doesnt-Trust-It.png)](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

#### [The Safest Place to Run an AI Agent Is On a Cluster That Doesn’t Trust It](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/)
on Aug 27, 2026

Every organization running AI agents has already made a hosting decision. Most made it by accident. The sales team switched on the agent built into their CRM. Engineering is piloting a coding agent in a...

[Read more](https://www.tigera.io/blog/the-safest-place-to-run-an-ai-agent-is-on-a-cluster-that-doesnt-trust-it/)

[![AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/app/uploads/2026/08/AI-Red-Team-Agents-Automate-Attacks-on-your-AI-Agents.-Runtime-Policies-Automate-their-Defense.png)](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

#### [AI Red Team Agents Automate Attacks on your AI Agents. Runtime Policies Automate their Defense.](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

By [Alister Baroi](https://www.tigera.io/blog/author/alister-baroi/)
on Aug 24, 2026

The AI red teaming market grew up fast this year. OpenAI bought Promptfoo, Cisco and Microsoft shipped automated attack suites, and a seed-stage startup publicly compromised 50 of 55 live customer service bots. These platforms...

[Read more](https://www.tigera.io/blog/ai-red-team-agents-automate-attacks-on-your-ai-agents-runtime-policies-automate-their-defense/)

<!-- plugin=object-cache-pro client=phpredis metric#hits=3177 metric#misses=49 metric#hit-ratio=98.5 metric#bytes=1538716 metric#prefetches=0 metric#store-reads=178 metric#store-writes=31 metric#store-hits=154 metric#store-misses=38 metric#sql-queries=45 metric#ms-total=589.19 metric#ms-cache=39.60 metric#ms-cache-avg=0.1904 metric#ms-cache-ratio=6.7 sample#redis-hits=12175391 sample#redis-misses=4853156 sample#redis-hit-ratio=71.5 sample#redis-ops-per-sec=74 sample#redis-evicted-keys=0 sample#redis-used-memory=71915152 sample#redis-used-memory-rss=89550848 sample#redis-memory-fragmentation-ratio=1.2 sample#redis-connected-clients=1 sample#redis-tracking-clients=0 sample#redis-rejected-connections=0 sample#redis-keys=1886 -->
