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, because ignite-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 that systemd-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 and search lines.
( More intricate DNS options don't all translate well to a DHCP configuration. )