docker-alpine: Apparent DNS failure in Docker image alpine:3.8, nslookup: can't resolve '(null)'

Seeing odd DNS behavior in Docker image alpine:3.8. I’m baffled that nslookup complains yet finds the IP address. In comparison, ping works perfectly. See below. This little test runs a docker container to resolve the name of the host VM. If I can get that working the next test will be to have the docker container resolve the name of other running containers.

Traced this back from behavior in an OpenJDK image, in which Java cannot resolve host names. I’d really prefer to use an Alpine version of a Java/JRE image, it’s half the size of a non-Alpine (debian) Java/JRE image, but this network glitch is kind of a killer.

So far I’ve run this test under a plain Ubuntu VM running docker 17.05.0-ce and under Kubernetes running docker version 18.09.1. Same behavior in both. I know there are many external variables that might affect this so it might not be an Alpine issue at all, altho issue #255 sure seems to be related.

Would someone possibly take a minute to explain please? Thanks in advance.

me@host-dev1-vm01-core:~$ docker run alpine:3.8 nslookup host-dev1-vm01-core

nslookup: can't resolve '(null)': Name does not resolve
Name:      host-dev1-vm01-core
Address 1: 10.1.0.6
me@host-dev1-vm01-core:~$ docker run alpine:3.8 ping host-dev1-vm01-core
PING host-dev1-vm01-core (10.1.0.6): 56 data bytes
64 bytes from 10.1.0.6: seq=0 ttl=64 time=0.061 ms
64 bytes from 10.1.0.6: seq=1 ttl=64 time=0.133 ms
^C
--- host-dev1-vm01-core ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.061/0.097/0.133 ms

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 31
Comments: 20

Links to this issue

docker - Does Alpine have known DNS issue within Kubernetes? - Stack Overflow

Commits related to this issue

(maint) On container startup, lookup Postgres DNS - There appear to be many reported issues against Alpine DNS. This is an attempt to work around the ones we're experiencing. - In local testing... — committed to Iristyle/puppetdb by Iristyle 5 years ago
(maint) On container startup, lookup Postgres DNS - There appear to be many reported issues against Alpine DNS. This is an attempt to work around the ones we're experiencing. - In local testing... — committed to Iristyle/puppetdb by Iristyle 5 years ago
main/busybox: enable FEATURE_NSLOOKUP_BIG The small nslookup does not work with musl, so lets enable the musl compatible variant. ref: https://github.com/gliderlabs/docker-alpine/issues/476 — committed to alpinelinux/aports by ncopa 4 years ago
main/busybox: enable FEATURE_NSLOOKUP_BIG The small nslookup does not work with musl, so lets enable the musl compatible variant. ref: https://github.com/gliderlabs/docker-alpine/issues/476 (cherry ... — committed to alpinelinux/aports by ncopa 4 years ago
Remove healthchecks This is a bit of an arse, but I have spotted since switching to alpine as the base image the healthchecks no longer work. If I `docker exec` onto the instance I can replicate the ... — committed to Cruikshanks/simple-rails-docker by Cruikshanks 4 years ago
(maint) On container startup, lookup Postgres DNS - There appear to be many reported issues against Alpine DNS. This is an attempt to work around the ones we're experiencing. - In local testing... — committed to voxpupuli/container-puppetdb by Iristyle 5 years ago
(maint) On container startup, lookup Postgres DNS - There appear to be many reported issues against Alpine DNS. This is an attempt to work around the ones we're experiencing. - In local testing... — committed to voxpupuli/container-puppetdb by Iristyle 5 years ago

Most upvoted comments

The BusyBox nslookup, which Alpine uses, does two lookups, one for the DNS server and one for the name you asked for. This can be seen here.

In your example nslookup did resolve the name host-dev1-vm01-core to the address 10.1.0.6.

The line can't resolve '(null)' says that, at that point, it didn’t know what its DNS server was. Looking at the code that might initialize it, we see why. Sorry, I ran out of time chasing down the reason for that. Hope this is of some help.

bboreham on Jan 24, 2019

fixed with config below with k8s deploy

spec:
  template:
    metadata:
      labels:
        app: activityreservation
    spec:
      dnsConfig:
        options:
          - name: ndots
            value: "1"

refer to https://github.com/WeihanLi/ActivityReservation/blob/d3e4de902af70ad1c85618db8a481f7fbfe1a964/k8s/reservation-deployment.yaml for details

WeihanLi on Jan 15, 2020

I have the same problem with alpine:3.10

Same for me…

sashok2k on Aug 25, 2019

Having the same issue with Alpine 3.9 (not Kubernetes case). Is there any workaround for this?

Antiarchitect on Jul 29, 2019

The BusyBox nslookup, which Alpine uses, does two lookups, one for the DNS server and one for the name you asked for. This can be seen here.

This was very useful. There are apparently a different nslookup implementation available in busybox which can be enabled with CONFIG_FEATURE_NSLOOKUP_BIG and the comments there says that it is compatible with musl. I wil enable that and see if i can backport it to alpine:3.11 at least.

BTW, the official docker image has moved to https://github.com/alpinelinux/docker-alpine. Since this was a config option in upstream alpine, it would have been good if it was reported upstream to https://gitlab.alpinelinux.org/alpine/aports

ncopa on Jan 15, 2020

I have the same problem with alpine:3.10

vedmant on Aug 22, 2019

@xbmono if you are complaining about “can’t resolve ‘(null)’” please read my explanation at https://github.com/gliderlabs/docker-alpine/issues/476#issuecomment-457124840. It is nothing to worry about. If something else, I suggest you open a new issue.

bboreham on Jun 20, 2019