Start with CoreDNS: pod restarts, CPU throttling, error rate, and replica count against query volume. Then check ndots, since the default of 5 makes every external lookup try several search domains first and multiplies query load. Classic culprits are conntrack table exhaustion on nodes, UDP packet loss under load, and single threaded resolvers. Node local DNS caching plus fully qualified names usually settles it.
Why interviewers ask this
DNS problems in Kubernetes are common, poorly understood, and reveal how deep your platform knowledge really goes. The interviewer wants specifics: ndots and search domains, conntrack, CoreDNS scaling and caching. Vague answers about checking DNS show you have read about the problem, while naming the ndots amplification shows you have debugged it.
How to structure your answer
- Quantify the symptom: which pods, which names, what error, what rate.
- Check CoreDNS health, throttling, and replica capacity first.
- Explain ndots and search domain amplification for external lookups.
- Cover node level causes: conntrack limits and UDP loss.
- Give the durable fixes: node local cache, tuned ndots, FQDNs.
Example answer
I would start by measuring rather than guessing: which names fail, internal or external, and is it correlated with load. Then CoreDNS itself, because if those pods are CPU throttled or there are only two of them for a large cluster, everything downstream looks intermittent. The one that surprises people is ndots. The default pod resolv.conf sets ndots to 5, so looking up an external hostname tries it against every search domain before the real one, which turns one query into five and puts a lot of extra pressure on CoreDNS. The fix is either a trailing dot on the name to make it fully qualified, or a custom dnsConfig with ndots set to 2. Node side, I check conntrack table usage, because a full table drops UDP responses silently and looks exactly like flaky DNS. In practice deploying NodeLocal DNSCache fixed this for us permanently since it moves lookups to a local cache over TCP.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- What does NodeLocal DNSCache change about the query path?
- How would you confirm conntrack exhaustion on a node?
- Why might lowering ndots break service discovery for short names?
Related site reliability engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions