Some limitations of the built-in DNS service

[jandubois]

I spent some time testing various DNS scenarios while looking into rancher-sandbox/rancher-desktop#1181 and noticed the following issues:

• on systemd instances mDNS lookup would not work. The request never goes to our own server, but is presumptively handled directly by systemd-resolved. Since it can only broadcast on the slirp interface, it can't find any devices on the host network.

• *.local names that are provided by DNS and have no corresponding mDNS response are reported too late, so get a DNS timeout. It looks like our DNS server is waiting for the mDNS query to time out before returning the DNS name (or from /etc/hosts).

While looking for a workaround, I tried (on Alpine, to avoid systemd) various entries in /etc/hosts. Specifying a .local name as an alias works, and both names can be resolved in the guest:

1.2.3.4 foo.internal foo.local

If the .local name is the canonical name, then neither name returns a result before an error occurs:

1.2.3.4 foo.local foo.internal

On the host system, the .local names from /etc/hosts are resolved without any delay, so why is this different?

[jandubois]

Assigning low priority because using .local with unicast DNS is discouraged.

Providing mDNS lookup to systemd-based instances may be regular priority though.

[jandubois]

cc/ @dee-kryvenko

[jandubois]

Furthermore, it looks like with systemd-resolved, the host resolver is still configured as a backup even when useHostResolver is false.

[christhomas]

I'm also facing some issues with dns right now because I have a dnsmasq container I'm trying to run and I'm wondering if there is ever a scenario where you'd want a VM to use it's own private dns resolver opposed to your machines dns setup. Wouldn't that mean there are two dns resolvers, one on my machine and one inside the VM? Is there a scenario where my machine would not have dns configured and access to the internet but the VM would?