TL;DR: The daemon's DNS cannot resolve the registry. Check the host resolves it (`nslookup registry-1.docker.io`); if the host is fine but docker is not, set explicit DNS servers for the daemon in /etc/docker/daemon.json (`{"dns": ["8.8.8.8", "1.1.1.1"]}`) and restart docker. VPNs and corporate resolvers that do not answer from inside docker's network namespace are the usual cause.

## The error

```text
dial tcp: lookup registry-1.docker.io on CONTAINER_IP:53: no such host
```

## Fix it

1. Test host DNS:
   `nslookup registry-1.docker.io`
   Expected: if this fails too, fix the host network first (cable, VPN, /etc/resolv.conf).
2. If the host resolves fine, give the daemon explicit DNS:
   add to /etc/docker/daemon.json: `{"dns": ["8.8.8.8", "1.1.1.1"]}`
3. Restart and retry:
   `sudo systemctl restart docker && docker pull hello-world`
   Expected: pull works.

## When this applies
- Pulls and builds fail on name resolution while the browser/host works
- Laptops moving between corporate VPN and home networks

## When this does NOT apply
- "no such host" for YOUR private registry (that hostname may genuinely not exist; check spelling and internal DNS)
- Timeouts rather than NXDOMAIN (connectivity, not DNS)

## Versions
All Docker Engine versions.

## Why it happens
Containers and the daemon use the host's /etc/resolv.conf by default. Corporate DNS servers often refuse queries from unexpected subnets, and VPN clients rewrite resolv.conf on connect/disconnect, leaving docker pointing at a dead resolver.

## Edge cases
- systemd-resolved stub at 127.0.0.53 breaks docker's embedded DNS in some setups; the explicit `dns` array bypasses it.
- `--dns` on `docker run` overrides per-container without touching the daemon config.
- Some registries are region-specific; "no such host" can also mean the mirror hostname in daemon.json is wrong.