How does Docker decide which upstream DNS servers a container uses, and what would you change if every container must query a corporate internal DNS server instead?

## Where the upstream list comes from Containers do not inherit the host's resolver by magic. When the daemon starts a container it builds a DNS configuration in this order of precedence: 1. **Per-container flags** - `--dns`, `--dns-search`, `--dns-option` (Compose: `dns`, `dns_search`). 2. **Daemon configuration** - `dns`, `dns-search`, `dns-opts` in `/etc/docker/daemon.json` (or the equivalent `dockerd` flags). 3. **The host's `/etc/resolv.conf`**, filtered. On the **default bridge** the resulting nameservers are written directly into the container's `/etc/resolv.conf`. On a **user-defined network** the container instead sees `nameserver 127.0.0.11`, and the resolved list becomes the embedded resolver's **forwarders**. Either way the same source list is used. ## The loopback filter, and why it bites Loopback nameservers are stripped from the inherited list. The reason is structural: `127.0.0.53` on a systemd-resolved host, or `127.0.0.1` for a local dnsmasq, refers to the *host's* loopback. A container has its own loopback, so copying that entry would point it at nothing. If every entry is loopback - the normal case on modern Ubuntu - the filter empties the list and Docker falls back to well-known public resolvers, logging a warning. Symptoms: public names resolve, but `git.corp.internal` does not, and split-horizon DNS answers with the wrong (external) address. The correct fixes, in order of durability: - Put the **real** corporate resolvers in `daemon.json` under `"dns"`. - Or point the daemon at the upstream servers systemd-resolved itself is using (`resolvectl status` shows them per link). - Avoid the tempting hack of bind-mounting the host's `/etc/resolv.conf`; you re-import the loopback entry that cannot work. ## Search domains and ndots `search` appends suffixes to short names; `options ndots:N` says "a name with fewer than N dots gets the search list tried first". Docker propagates the host's search list unless you override it. Two failure shapes appear repeatedly: - A long inherited search list plus a high `ndots` means every lookup of a short name issues several queries that must fail (often waiting for timeouts) before the unqualified name is tried. This shows up as slow startup rather than as an error. - Conversely, an application that relies on a short intranet name breaks when the search list is *not* propagated, and needs `--dns-search corp.example.com`. On a user-defined network Docker typically sets `options ndots:0`, so container names are tried as-is first - part of why container-name resolution stays fast even with search domains present. ## Verifying Inspect what the container actually got (`cat /etc/resolv.conf` inside it), then query both an internal and an external name with `getent hosts` to separate forwarding problems from record problems. Check the daemon's effective configuration and its logs for the fallback warning. Remember that changing `daemon.json` requires a daemon restart and only affects **newly created** containers - existing ones keep the configuration they were built with, which is why "we fixed DNS but the container still misbehaves" usually just means it was never recreated. ## Related knobs `--add-host name:ip` injects a static `/etc/hosts` entry, useful for pinning one hostname without touching DNS. Containers on the **host** network use the host's resolv.conf as-is, so none of the filtering or embedded-resolver behaviour applies to them - a detail worth stating explicitly when someone reports that DNS behaves differently for one container.