I have several Docker networks where containers discover one another through Docker's built-in DNS, such as Caddy proxying to `flatnotes:8080` or Nextcloud connecting to Redis by container name. This works reliably with the default runc runtime, but breaks when I switch to Kata Containers or gVisor.
Changing `--dns` in `docker run` or using `dns:` in Compose does not solve the problem because those options only change upstream DNS servers for external lookups. Container names still resolve through Docker's `127.0.0.11` entry, and that mechanism appears to depend on networking behavior that alternate runtimes do not provide.
Is there a practical way to keep Docker-style service-name discovery while using Kata or another non-runc runtime? I'm looking for a middle ground between sharing the host kernel with runc and adopting a much larger orchestration stack.
3 Answers
Docker’s embedded resolver is not really a normal DNS server running inside each container. Docker’s networking layer redirects traffic sent to `127.0.0.11:53` using host-kernel networking and then forwards it to Docker’s internal resolver. That works naturally with runc because the container shares the host kernel and network namespaces, but a Kata container has its own guest kernel, so the host-side rules are not visible in the same way. gVisor has a similar compatibility problem because its networking and netfilter behavior is different.
The usual workaround is to run an actual DNS service on the container network, such as CoreDNS or dnsmasq, and configure the containers to use its real network IP. That avoids relying on Docker’s special loopback resolver. Another option is using a networking stack with a userspace DNS implementation, such as Podman with Netavark and Aardvark DNS, or using Kubernetes with CoreDNS when that level of infrastructure is justified.
There is also a responsibility boundary here: Docker’s embedded DNS was designed around Docker’s own networking model and the default runtime. Alternate runtime providers need to support the assumptions Docker’s networking layer makes, or users need to replace the runtime-specific convenience features with generic services. It would certainly be useful if Docker exposed a runtime-independent resolver, but changing this could affect several networking drivers and existing deployments.
The `--dns` and Compose `dns:` settings only select upstream resolvers for names outside the Docker network. They do not replace Docker’s service-discovery mechanism, which is why they do not make names like `flatnotes` or `nextcloud-aio-redis` resolve.
For a Docker-based setup, you could run CoreDNS with a Docker-aware plugin, give it a stable address on the bridge network, and configure the other containers to query it. Before setting that up, test whether the alternate-runtime containers can communicate by IP. If IP connectivity fails, the Kata or gVisor network integration needs fixing first; DNS cannot work until the underlying network path works.
That makes sense for inter-container names, but ordinary upstream DNS configuration does not fix this by itself. The important part is having a real DNS process that knows the container names and is reachable over the network, rather than merely changing the external nameserver.