| Summary: | nslookup problems | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | teke97 <teke97> |
| Component: | Networking | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | CC: | busybox-cvs |
| Priority: | P5 | ||
| Version: | 1.31.x | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
|
Description
teke97@gmail.com
2020-06-11 14:36:26 UTC
I see this problem in the uclibc version: ``` $ kubectl run -it --rm evanstest-b5 --image=busybox:1.32.0-uclibc -- sh If you don't see a command prompt, try pressing enter. / # nslookup opentelemetry-collector.observability.svc.cluster.local Server: 10.0.0.10 Address: 10.0.0.10:53 *** Can't find opentelemetry-collector.observability.svc.cluster.local: No answer *** Can't find opentelemetry-collector.observability.svc.cluster.local: No answer / # ``` The musl and glibc versions partially work: ``` $ kubectl run -it --rm evanstest-b3 --image=busybox:1.32.0-musl -- sh If you don't see a command prompt, try pressing enter. / # nslookup opentelemetry-collector.observability.svc.cluster.local Server: 10.0.0.10 Address: 10.0.0.10:53 *** Can't find opentelemetry-collector.observability.svc.cluster.local: No answer Name: opentelemetry-collector.observability.svc.cluster.local Address: 10.0.228.84 / # $ kubectl run -it --rm evanstest-b4 --image=busybox:1.32.0-glibc -- sh If you don't see a command prompt, try pressing enter. / # nslookup opentelemetry-collector.observability.svc.cluster.local Server: 10.0.0.10 Address: 10.0.0.10:53 Name: opentelemetry-collector.observability.svc.cluster.local Address: 10.0.228.84 *** Can't find opentelemetry-collector.observability.svc.cluster.local: No answer / # ``` The Kubernetes community has been working around this issue for a couple of years by pinning to busybox:1.28 - what can we do to help fix this issue? It looks like this is a duplicate of https://bugs.busybox.net/show_bug.cgi?id=11161, which was closed, but apparently not resolved. (In reply to evans.tucker from comment #1) > I see this problem in the uclibc version uclibc has a rather primitive support for resolver routines, thus nslookup on uclibc is likely to be buggy: nslookup just overrides default DNS address, then uses standard name resolution in libc to get addresses. Even such trivial thing as setting DNS server address to a IPv6 address does not work. LEDE project contributed a better version of nslookup, it is enabled by setting FEATURE_NSLOOKUP_BIG=y but it requires a libc with a decent resolver support: uses ns_initparse(), ns_msg_count(), ns_parserr() etc. It will not compile on uclibc (did not try uclibc-ng). So. What version of busybox is it? Is FEATURE_NSLOOKUP_BIG=y ? > The musl and glibc versions partially work: > $ kubectl run -it --rm evanstest-b3 --image=busybox:1.32.0-musl -- sh > If you don't see a command prompt, try pressing enter. > / # nslookup opentelemetry-collector.observability.svc.cluster.local > Server: 10.0.0.10 > Address: 10.0.0.10:53 > > *** Can't find opentelemetry-collector.observability.svc.cluster.local: No answer > > Name: opentelemetry-collector.observability.svc.cluster.local > Address: 10.0.228.84 What is the exact problem in the above? It said that AAAA request was replied with no records ("No answer") and A request was successfully answered with an IP address. Aha. I see. We indeed differ from bind. Fixed in git:
commit 49fd1d69babc6945175068e8fe4c85713fe5fcdb (HEAD -> master)
Date: Thu Dec 31 01:39:44 2020 +0100
nslookup: do not print "No answer" for NODATA replies, closes 13006
Only print when there was no answer at all.
|