see the following github issue for details. https://github.com/docker-library/busybox/issues/48 This started with version 1.29
I haven't dug into the code yet, but in testing it would appear that the new DNS code in "nslookup" for the 1.29 release doesn't support DNS search domains ("search" entry in /etc/resolv.conf) at all, which Kubernetes makes pretty heavy use of.
(For context, my previous comment was based on testing a build of 1.29.1 built against all three of uClibc via buildroot, musl via Alpine, and glibc via Debian.) Looking in the code, it appears my hunch was correct; I think "parse_resolvconf" is the culprit? (https://git.busybox.net/busybox/tree/networking/nslookup.c?h=1_29_1#n664) That doesn't appear to do anything with "search" values (except ignore them), which is a regression from the previous libc-based behavior. Was ignoring these intentional in this new implementation, or simply an oversight? (should someone work on / is someone working on a patch?)
No, it's not intentional. I'm actually surprised there were users of "old" nslookup, it had severe problems working (and even compiling on some libc). Your options: (1) switch to old version (disable FEATURE_NSLOOKUP_BIG) (2) send a patch to improve the new version (3) wait for someone to do (2)
I'm seeing nslookup fail intermittently. If I specify -type=a then it succeeds reliably. In my case it appears to be related to nslookup issuing A and AAAA queries concurrently; in this case there is no AAAA record - I have not tried a scenario where there is an AAAA record. From the DNS side the two queries are using the same ID and as best I can determine the failure happens if the AAAA response returns first. Hopefully that's helpful additional data.
(In reply to ghicken from comment #4) > I'm seeing nslookup fail intermittently. If I specify -type=a then it succeeds reliably. > In my case it appears to be related to nslookup issuing A and AAAA queries concurrently; in this case there is no AAAA record - I have not tried a scenario where there is an AAAA record. > From the DNS side the two queries are using the same ID and as best I can determine the failure happens if the AAAA response returns first. Can you provide the error message and ideally, tcpdump of the resolution attempt?
Hopefully fixed in git.