This repository has been archived by the owner on Dec 7, 2023. It is now read-only.
DHCPv4 DNS incorrect on host /w systemd-resolved using --runtime=containerd #437
Labels
area/networking
Issues related to networking
area/runtime
Issues related to container runtimes
kind/bug
Categorizes issue or PR as related to a bug.
priority/important-soon
Must be staffed and worked on either currently, or very soon, ideally in time for the next release.
Milestone
Currently, the containerd runtime indiscriminately mounts
/etc/resolv.conf
into the container.On an Ubuntu host using
systemd-resolved
, this will break because/etc/resolv.conf
points to the NS proxy systemd-resolved running @127.0.0.53
/::ffff:127.0.0.53
.It's important that we mount a working
/etc/resolv.conf
into the runtime container's mount namespace, becauseignite-spawn
will use it to configure DHCP and the nameservers will end up as the vm's primary DNS servers.Docker implements some nice logic that detects
["127.0.0.53"]
and uses a file thatsystemd-resolved
maintains @/run/systemd/resolve/resolv.conf
.Docker also post-processes any resolvconf it loads from disk.
This is to filter loopback addresses since they won't work well in a fresh network namespace.
If no nameservers are left they append Google's public NS as a fallback.
The results of this post-processing are always written to a new file per-container.
This behavior is well documented here https://docs.docker.com/v17.09/engine/userguide/networking/default_network/configure-dns/.
We should consider implementing a subset of this heuristic for our containerd runtime.
It makes sense at the moment to support
nameserver
andsearch
lines.( More intricate DNS options don't all translate well to a DHCP configuration. )
The text was updated successfully, but these errors were encountered: