It is a little bit more complicated. I remembered it copied the resolv.conf to the docker data root for the new container and mounted that copy, except when it was the stub resolver, because it always mounts something that should work in a container.
Testing that now, I see that when I have systemd and I use the stub resolver, it mounts /run/systemd/resolve/resolv.conf and I see this in the logs:
Apr 09 18:53:52 docker-vm-noble dockerd[3887]: time="2025-04-09T18:53:52.799236585+02:00" level=info msg="detected 127.0.0.53 nameserver, assuming systemd-resolved, so using resolv.conf: /run/systemd/resolve/resolv.conf"
If I unlink the symbolic link that points to the stub resolver and use a static resolv conf containing servers pointing to a loopback interface, it generates this one for the containers:
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.
nameserver 8.8.8.8
nameserver 8.8.4.4
search .
options edns0 trust-ad
# Based on host file: '/etc/resolv.conf' (legacy)
# Used default nameservers.
# Overrides: []
And logs this:
Apr 09 19:17:58 docker-vm-noble dockerd[4784]: time="2025-04-09T19:17:58.319918805+02:00" level=info msg="No non-localhost DNS nameservers are left in resolv.conf. Using default external servers"
If I use the static resolv conf but with a non-loopback (non-localhost) IP, it uses the value from the static resolv. conf, but not the original content, only the IP with new comments
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.
nameserver 192.168.100.1
search .
options edns0 trust-ad
# Based on host file: '/etc/resolv.conf' (legacy)
# Overrides: []
So if “No non-localhost” was logged, it looks like it used Google’s DNS servers which could be slower indeed.
But the resolv conf shared by @abhishekpatwari started with this:.
Which should not have had the the “non-localhost” log entry unless something else was broken on the system and Docker read another file, or the Docker daemon was not restarted after the resolv.conf was changed since it seems Docker reads the file when the daemon starts, not when the container is created (tested it now).