Introduction

If nslookup in a recent BusyBox image cannot resolve a service IP, the first thing to remember is that BusyBox nslookup is a small diagnostic tool, not a full-featured resolver implementation. In Kubernetes and other service-discovery environments, that difference matters: short names, search domains, record types, and resolver behavior may not match what your application or libc resolver does.

Start by checking the actual DNS context inside the container

Do not assume the problem is BusyBox before checking the pod's resolver configuration.

cat /etc/resolv.conf
cat /etc/hosts

In Kubernetes, a healthy pod often has:

• cluster DNS server IP in nameserver
• one or more search domains such as default.svc.cluster.local
• an options ndots: setting that affects how names are queried

If those values are wrong, nslookup is only revealing a broader DNS configuration problem.

Prefer the fully qualified service name when testing

BusyBox nslookup may behave differently from normal application resolution for short service names. When debugging, use the full cluster service name first.

nslookup my-service.default.svc.cluster.local

If that works but nslookup my-service does not, the likely issue is search-domain or resolver behavior rather than a missing service.

That distinction matters because application code using libc name resolution may still work even when BusyBox nslookup gives confusing results.

BusyBox nslookup is not the same as dig or getent

Minimal images trade features for size. BusyBox utilities are intentionally small, and their DNS tooling is much less expressive than dig, host, or getent.

So if you are using BusyBox only as a quick debug pod, treat its output as a clue, not absolute truth. For deeper debugging, use a DNS-focused image or install fuller tools.

In Kubernetes, a common pattern is to use a pod with better DNS utilities for verification instead of relying only on BusyBox.

Verify that the service actually exists and has endpoints

A DNS name can resolve correctly while the service still does not behave as expected, and the inverse can also happen in debugging confusion. Check the control-plane objects directly.

kubectl get svc my-service -n default
kubectl get endpoints my-service -n default

If the service or endpoints are missing, no amount of nslookup tweaking will fix the result.

Compare BusyBox with another diagnostic image

If BusyBox is suspicious, compare it with a more complete image.

kubectl run dns-test --rm -it --image=busybox:latest --restart=Never -- sh

Then, in another session, try a DNS utility image or a distro image with getent or dig. If the full-featured tools resolve the service while BusyBox does not, you have likely narrowed the issue to the tool choice or its limited behavior.

Use the right question for the right tool

If the question is "does Kubernetes DNS contain this service record," a fully qualified query with a capable DNS tool is the best test. If the question is "will my application resolve the short name the same way," then BusyBox nslookup may not be representative enough.

That is why many DNS debugging sessions go wrong: the chosen diagnostic tool is not actually exercising the same resolution path as the real application.

Common Pitfalls

• Assuming BusyBox nslookup behaves exactly like the application's resolver.
• Testing only a short service name and never trying the fully qualified cluster DNS name.
• Ignoring /etc/resolv.conf and debugging the wrong layer.
• Forgetting to verify that the Kubernetes Service and Endpoints objects actually exist.
• Treating a minimal BusyBox image as if it were a complete DNS debugging environment.

Summary

• BusyBox nslookup is a minimal tool and may not reflect full resolver behavior.
• Always inspect the pod's DNS configuration before blaming the image.
• Test the fully qualified service name first.
• Verify the Kubernetes Service and Endpoints objects directly.
• When debugging serious DNS issues, compare BusyBox results with a richer DNS toolset.