Capture DNS messages at each resolution stage to isolate where failures occur in ACK Pro clusters.
Prerequisites
Before you begin, ensure that you have:
-
An ACK Pro cluster.
-
The cluster kubeconfig file and kubectl connectivity.
Background
dnstap is a log format for DNS messages. CoreDNS includes a built-in dnstap plugin that captures every DNS message. ACK CoreDNS DNSTAP Analyser receives these messages over TCP and aggregates them into per-session diagnostic records.
See dnstap for log format details.
Step 1: Install ACK CoreDNS DNSTAP Analyser
-
Log on to the ACK console. In the left-side navigation pane, click Clusters.
-
On the Clusters page, find the cluster and click its name. In the left-side navigation pane, choose Applications > Helm.
-
On the Helm page, click Deploy. In the Basic Information step, configure the following parameters. Select ack-coredns-dnstap-analyser and click Next.
Parameter Value Application Name ack-coredns-dnstap-analyserNamespace kube-systemSource Marketplace (default) Chart — Use Scenarios All Chart — Supported Architecture amd64 Chart — Search box ack-coredns-dnstap-analyser -
In the Parameters step, configure the Chart Version and click OK.
Step 2: Configure the dnstap plugin in CoreDNS
CoreDNS includes the dnstap plugin. Enable it and point it at ACK CoreDNS DNSTAP Analyser to forward DNS messages automatically.
-
Get the cluster IP address of the DNSTAP Analyser service. Note this address for the next step.
kubectl -n kube-system get svc dnstap-analyserIn this example, the cluster IP address is
172.21.0.10. -
Open the CoreDNS ConfigMap for editing.
kubectl -n kube-system edit cm coredns -o yaml -
Add the
dnstapdirective to the Corefile. Replace172.21.0.10with the cluster IP address from Step 1.Corefile: | .:53 { # ... other plugins ... ready # Add this line. The "full" flag includes the complete wire-format DNS # message in each record, which provides richer diagnostic data. dnstap tcp://172.21.0.10:6000 full kubernetes cluster.local in-addr.arpa ip6.arpa { # ... other settings ... } # ... other plugins ... reload loadbalance } -
Verify that CoreDNS reloaded the configuration.
-
List all CoreDNS Pods.
kubectl -n kube-system get pod | grep corednsExpected output:
coredns-7d56l 1/1 Running 0 30m coredns-s7m2t 1/1 Running 0 30m -
Tail the log of a CoreDNS Pod. Replace
coredns-7d56lwith a Pod name from the previous output.kubectl -n kube-system logs -f --tail=500 coredns-7d56lWait up to one minute. A successful reload produces:
[INFO] Reloading complete
-
Step 3: View the log of ACK CoreDNS DNSTAP Analyser
-
List all ACK CoreDNS DNSTAP Analyser Pods.
kubectl -n kube-system get pod | grep dnstap-analyserExpected output:
dnstap-analyser-bbdf879-g**** 1/1 Running 0 30m -
Stream the log. Replace
dnstap-analyser-bbdf879-g****with the Pod name from the previous output.kubectl -n kube-system logs -f dnstap-analyser-bbdf879-g****
Step 4: Analyze the log
Each log line represents one DNS session — a full request-response cycle between a client, CoreDNS, and the upstream DNS server.
How to read a session entry: Check Status to confirm success or failure. Check BitMap to identify which resolution stage failed. Inspect Messages for raw DNS payloads.
Status field
| Status | Description |
|---|---|
Succeeded |
DNS query completed. Response carries a NXDOMAIN or NOERROR status code. |
Failed |
Resolution failed. Response carries an error status code, or the upstream connection timed out. |
SampleLoss |
CoreDNS or the analyser dropped dnstap messages due to overload. Scale up the overloaded component to improve diagnostic accuracy. |
SampleLossentries mean some DNS sessions were not captured. IfSampleLossentries are frequent, scale up CoreDNS or analyser Pods before continuing.
BitMap field
A bitmask encoding which message types were captured in the session. Use it to identify where in the resolution chain the failure occurred.
| BitMap | Description |
|---|---|
1 |
CoreDNS received a client query but returned no response. |
3 |
Internal domain resolved. The query hit the CoreDNS cache or a Kubernetes DNS record, and the result was returned to the client. |
5 |
Upstream DNS server unreachable. CoreDNS forwarded the query but received no response. |
15 |
External domain resolved. CoreDNS forwarded the query to the upstream server, received a response, and returned it to the client. |
Messages field
The Messages field contains DNS queries and responses in JSON. Parse them against the IANA DNS parameters reference to inspect response codes and record types.
(Optional) Step 5: Uninstall ACK CoreDNS DNSTAP Analyser
After your investigation, remove the analyser to avoid unnecessary costs.
-
Remove the
dnstapdirective from the CoreDNS ConfigMap.-
Open the ConfigMap for editing.
kubectl -n kube-system edit cm coredns -o yaml -
Delete the line containing
dnstap.Corefile: | .:53 { # ... other plugins ... ready # Delete the following line. dnstap tcp://10.10.10.10:6000 full kubernetes cluster.local in-addr.arpa ip6.arpa { # ... other settings ... } # ... other plugins ... reload loadbalance } -
Verify that CoreDNS reloaded the configuration. List all CoreDNS Pods.
kubectl -n kube-system get pod | grep corednsExpected output:
coredns-7d56l 1/1 Running 0 30m coredns-s7m2t 1/1 Running 0 30m -
Tail the log of a CoreDNS Pod. Replace
coredns-7d56lwith a Pod name from the previous output.kubectl -n kube-system logs -f --tail=500 coredns-7d56lWait up to one minute. A successful reload produces:
[INFO] Reloading complete
-
-
Delete the ACK CoreDNS DNSTAP Analyser Helm release.
-
Log on to the ACK console. In the left-side navigation pane, click Clusters.
-
On the Clusters page, find the cluster and click its name. In the left-side navigation pane, choose Applications > Helm.
-
On the Helm page, find ack-coredns-dnstap-analyser and click Delete in the Actions column.
-