Diagnose in-cluster DNS resolution failures and isolate root causes.
NewMaintained
Automatic
◆DevOps & SRE pack
Last verified 8/3/2026
What it changes
Passed 6 of 22 test cases with the skill, and 17 of 22 without it.
Without skill75%
With skill25%
Checks it passed that the model alone missed
Run kubectl -n kube-system logs -l k8s-app=kube-dns --tail=200
Execute nslookup or dig repeatedly from pods in different namespaces and confirm 100% successful response codes.
2 fixed17 passed either way0 still failing3 broke
Pass-rate lift
-50 pp
Tokens
-26%
Agent turns
0%
Response time
-48%
Model gemini-3.6-flashMeasured 8/3/2026v119 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 2
Prompt
An SRE needs to inspect recent logs from the cluster DNS service to check for lookup errors and timeouts. What kubectl command using label selectors should be run against the system namespace?
What was checked, without and with the skill
Checked
Without skill
With skill
Run kubectl -n kube-system logs -l k8s-app=kube-dns --tail=200
Missed
Passed
case-07 · gemini-3.6-flash · 8/3/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md46 linessingle file
When to use
Use when pods cannot resolve service names (e.g., *.svc.cluster.local) or external DNS intermittently fails.
Preconditions
You can run commands in a diagnostic pod or an affected pod.
You can access CoreDNS/kube-dns logs.
Procedure
Confirm whether the issue is cluster-wide or namespace/workload-specific.
Validate resolver configuration inside the pod (/etc/resolv.conf) and search domains.
Query the same name from multiple pods/nodes to identify locality.
Check CoreDNS health, restarts, and error logs.
Check network policies and CNI health that might block DNS to the DNS service.
Decision points
Only one namespace affected: network policy or custom DNS config.
Only one node affected: node-level networking issues.
CoreDNS errors/timeouts: capacity, upstream recursion, or misconfiguration.
NXDOMAIN for a service: confirm the service/endpoints exist.
Verification
Repeated DNS queries succeed from multiple pods.
CoreDNS error logs stop increasing.
Rollback / undo
Revert CoreDNS config changes.
Revert network policy changes if they widen access unexpectedly.
Escalation
Platform/network team for CNI or node-level packet loss.
Service owner if the service/endpoints are missing due to deploy issues.
Session-weight hygiene. Use when sessions run long, when an agent gets slower or starts forgetting mid-session, when deciding between /clear, /compact, or a fresh session, or when every message feels heavier than the work in it. Calls the moment a session has blown the weight limit: cut it right and start the next one light.