---
title: "Docker in LXC/Proxmox — DNS Configuration for Internal Homelab Domains"
aliases: [docker-lxc-dns, docker-internal-dns, docker-adguard-dns, docker-compose-dns]
tags: [docker, lxc, proxmox, dns, adguard, homelab, networking]
sources:
  - "daily/2026-04-28.md"
created: 2026-04-28
updated: 2026-04-28
---

# Docker in LXC/Proxmox — DNS Configuration for Internal Homelab Domains

Docker containers running inside a Proxmox LXC use the host LXC's DNS configuration, which by default points to the router (e.g., `192.168.1.1`). The router's upstream DNS knows nothing about internal homelab domains (e.g., `*.ai-impress.com`). This means services inside Docker containers cannot resolve other homelab services by their friendly domain names — even though the LXC host itself may resolve them correctly if AdGuard is configured differently at the OS level.

## Key Points

- **Docker containers inherit DNS from the LXC host** — the LXC's `/etc/resolv.conf` (usually pointing at the router's DNS) is passed into containers by default
- **Router DNS does not know internal domains** — AdGuard Home holds the split-horizon DNS records (e.g., `jellyfin.ai-impress.com → 192.168.1.x`); the router forwards to upstream public DNS which has no knowledge of these records
- **Fix:** Add an explicit `dns:` entry in `docker-compose.yml` pointing at AdGuard Home (`192.168.1.225`); this overrides the container's DNS regardless of the host's resolver config
- **Service ping checks (Homarr, Uptime Kuma) fail silently** when internal domain names are used as health check targets — they succeed via IP, fail via hostname, making the root cause non-obvious
- This is distinct from the host LXC's DNS — the LXC itself may resolve fine (if `/etc/resolv.conf` points to AdGuard), but Docker adds its own DNS indirection layer

## Details

### Why Docker Ignores the LXC's AdGuard Config

When Docker starts a container, it writes the container's `/etc/resolv.conf` based on:
1. The `dns:` setting in `docker-compose.yml` (explicit override — highest priority)
2. The Docker daemon's `--dns` flag in `/etc/docker/daemon.json`
3. The host's `/etc/resolv.conf` (fallback — this is what normally propagates)

In a Proxmox LXC, the LXC's `/etc/resolv.conf` typically points to the router (`nameserver 192.168.1.1`) because that's what the router's DHCP assigns. Even if you've manually edited the LXC's `/etc/resolv.conf` to use AdGuard, Docker may not pick it up unless the daemon is configured or the compose file specifies DNS explicitly.

### The Fix: Explicit DNS in docker-compose.yml

```yaml
# docker-compose.yml
services:
  homarr:
    image: ghcr.io/ajnart/homarr:latest
    dns:
      - 192.168.1.225   # AdGuard Home — knows internal domains
      - 1.1.1.1         # Cloudflare — fallback for public DNS
    ports:
      - "7575:7575"
    volumes:
      - ./data:/data
```

The `dns:` array replaces the container's DNS entirely — the order matters (AdGuard first, public fallback second). After adding this and restarting the container, `ping jellyfin.ai-impress.com` works from inside the container.

### Global Fix: Docker Daemon DNS

To apply AdGuard DNS to all containers on an LXC without per-compose changes:

```json
// /etc/docker/daemon.json
{
  "dns": ["192.168.1.225", "1.1.1.1"]
}
```

```bash
systemctl restart docker
```

This makes all Docker containers on that LXC use AdGuard as their DNS server by default. Per-compose `dns:` settings still override this.

### Diagnosing DNS Failures Inside Docker

```bash
# Enter the container
docker exec -it homarr sh

# Check what DNS server the container is using
cat /etc/resolv.conf
# Should show: nameserver 192.168.1.225
# If it shows: nameserver 192.168.1.1 → router DNS → no internal domains

# Test resolution directly
nslookup jellyfin.ai-impress.com 192.168.1.225
# Expected: Address: 192.168.1.x

# Test what the container currently resolves to
nslookup jellyfin.ai-impress.com
# If this fails but the above works → container DNS is wrong
```

### Service Health Check Failures

Many homelab dashboard services (Homarr, Homepage, Uptime Kuma) perform ping/HTTP health checks against configured service URLs. When internal domain names are used (e.g., `http://jellyfin.ai-impress.com`), the check fails if the container can't resolve the domain — but the failure looks like a connectivity problem, not a DNS problem.

Indicators that DNS is the issue:
- Health check fails using the domain name, succeeds using the IP directly
- `nslookup <domain>` fails from inside the container
- `cat /etc/resolv.conf` in the container shows the router IP, not AdGuard

### Static IP for LXC Services

When a service (like Immich in CT105) is using DHCP and gets a different IP after a router change or LXC restart, all DNS rewrites and health checks that reference the old IP break. The solution: assign a static IP in the Proxmox LXC config.

In Proxmox web UI → CT → Network → Edit the network interface:
- Set IP to static (e.g., `192.168.1.71/24`)
- Set gateway to `192.168.1.1`

Or via CLI on the Proxmox host:
```bash
pct set 105 --net0 name=eth0,bridge=vmbr0,ip=192.168.1.71/24,gw=192.168.1.1
```

Static IPs for services used in DNS rewrites and health checks should be considered mandatory — DHCP assignments change silently.

## Related Concepts

- [[wiki/concepts/adguard-dns-rewrites-homelab]] — AdGuard Home wildcard DNS rewrites that Docker containers need to reach
- [[wiki/connections/docker-dns-adguard-split-horizon]] — the cross-cutting connection between Docker networking and AdGuard split-horizon DNS
- [[wiki/concepts/homarr-sqlite-integration-cleanup]] — Homarr context where this DNS issue was discovered
- [[wiki/concepts/lxc-arp-cache-api-failures]] — another LXC networking issue that produces similar "service unreachable" symptoms
- [[wiki/homelab/_index]] — homelab infrastructure context

## Sources

- [[daily/2026-04-28.md]] — Homarr Docker container (CT107 LXC) could not ping `jellyfin.ai-impress.com` — container DNS pointed at router, not AdGuard; fixed by adding `dns: [192.168.1.225, 1.1.1.1]` to `docker-compose.yml`; CT105 (Immich) also given static IP `192.168.1.71` to prevent DHCP-related IP changes
