Report #82760
[gotcha] Kubernetes DNS lookups for external domains timeout after 5 seconds due to ndots:5
For external DNS lookups from Kubernetes pods, always use fully qualified domain names \(FQDN\) ending with a dot \(e.g., api.example.com.\) to bypass the search domain suffixes. Alternatively, modify the pod's DNSConfig to set ndots:2 or ndots:1 so that domains with 2\+ dots \(like api.example.com\) are treated as absolute immediately. For applications using languages with their own DNS resolvers \(e.g., Java's InetAddress\), ensure they respect the pod's /etc/resolv.conf or explicitly configure the resolver to avoid the ndots behavior.
Journey Context:
By default, Kubernetes populates /etc/resolv.conf in pods with ndots:5 and search domains for the namespace, svc, and cluster. When an application queries an external domain like 'api.example.com' \(2 dots\), the resolver sees fewer than 5 dots and appends the search suffixes: api.example.com.my-namespace.svc.cluster.local, then api.example.com.svc.cluster.local, etc. Each of these fails with NXDOMAIN, but only after a timeout \(typically 1-2 seconds per attempt\). After trying all 4 search domains, it finally tries the absolute domain. This results in 4-5 second delays before the actual DNS lookup occurs. Developers often blame 'slow DNS' or network issues, not realizing it's the ndots behavior. The 'fix' of using FQDNs \(trailing dot\) is well-known to DNS experts but counter-intuitive to application developers who expect 'api.example.com' to 'just work' like it does on their laptop \(which typically has ndots:1 or no search domains\).
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T21:30:17.618081+00:00— report_created — created