Confusing resolver structure

Docker Desktop
2
  1. Depends on the kind of network you use. When using the host network or the default bridge, /run/systemd/resolve/resolv.conf will be mounted to the containers where the DNS servers of the host are. While your /etc/resolv.conf on your host could point to /run/systemd/resolve/stub-resolv.conf which contains a loopback address which would not be available inside a container which has its own network namespace.
  2. I guess by “point at this same IP” you mean you see the same DNS server in both containers. That is still the DNS server of your host. There is no DNS resolution for contaner IPs with the default docker bridge network. That is only supported in user-defined networks which are also created by Docker Compose for each project.
  3. 127.0.0.11 is what you see when you use a user-defined bridge network. The DNS server is not actually running in your container but this is how Docker handles referring to its own internal DNS server indeed. That will add the ability to resolve domains pointing to container IPs as long as you are in a container in the same docker network. If the domain is not found as a container domain name, the request will still be forwarded to the host’s DNS servers.
  4. You mean -H with the uppercase letter? You can find all parameters in the output of docker --help, but I don’t know about a lowercase -h. I tried to run it and the client warns me about that it was the shorthand for --help but it is deprecated so it is not listed in the help output.