Fix Podman DNS Resolution Issues on Debian 13 (Trixie)

Meta Description: Troubleshoot and fix Podman container DNS resolution failures on Debian 13. Learn how to diagnose systemd-resolved conflicts, install missing networking tools, configure aardvark-dns, and restore reliable DNS in your containers.

---

When you run a Podman container on Debian 13 (Trixie) and nslookup google.com fails with a timeout or “server not found” error, the issue is almost never Podman itself—it’s a configuration clash between Debian 13’s default networking stack and Podman’s container network namespace.

This guide walks you through diagnosing the problem and implementing fixes from quick overrides to production-ready configurations.

---

Symptoms of DNS Problems in Containers

Before diving into solutions, confirm that your containers are experiencing DNS issues:

# Test DNS resolution inside a container
podman run --rm alpine nslookup google.com

# Check what the container sees for DNS
podman run --rm alpine cat /etc/resolv.conf

Typical symptoms include:

• DNS timeouts: nslookup or dig commands hang indefinitely
• “Server not found” errors: Immediate failure with no resolver listed
• IP connectivity works, hostname resolution fails: You can ping 8.8.8.8 but not google.com
• Sporadic behavior: DNS works after a host reboot but fails later
• Container-to-container resolution fails: Containers on the same network can’t resolve each other by name

---

Understanding the Root Causes

Debian 13 ships with systemd-resolved enabled by default, which introduces several potential points of failure for container networking. Here are the four main culprits:

1. systemd-resolved Stub Resolver Conflict

Debian 13’s /etc/resolv.conf typically points to 127.0.0.53, a local stub resolver provided by systemd-resolved. This address only works on the host’s loopback interface. Inside a container’s separate network namespace, 127.0.0.53 loops back to the container’s own (empty) loopback—effectively going nowhere.

2. Missing Userspace Networking Tools

Podman’s rootless networking requires either slirp4netns or pasta (from the passt package). Without these, containers fall back to a crippled network mode that cannot forward DNS traffic at all.

3. Missing or Misconfigured aardvark-dns

Container-to-container DNS resolution relies on aardvark-dns and the netavark backend. If aardvark is missing or its process is stale in an old network namespace, internal DNS silently fails.

4. Firewall Interference

Firewall rules (from firewalld, nftables, or ufw) that block traffic to the aardvark-dns listener on port 53 will prevent containers from reaching the DNS resolver, even if the network configuration is correct.

---

Diagnostic Checklist

Run these commands first to identify what’s broken:

# 1. What does the container actually see?
podman run --rm alpine cat /etc/resolv.conf

# 2. Does raw IP work? (isolates DNS from general networking)
podman run --rm alpine ping -c2 8.8.8.8

# 3. Check host's resolv.conf
ls -la /etc/resolv.conf
cat /etc/resolv.conf

# 4. Is systemd-resolved active?
resolvectl status

# 5. Is aardvark-dns installed and running?
which aardvark-dns
ps aux | grep aardvark

# 6. Are networking tools available?
which slirp4netns
which pasta

# 7. Check for firewall interference
sudo nft list ruleset | grep -A5 dport\ 53
sudo firewall-cmd --list-all 2>/dev/null || echo "firewalld not active"

---

Quick Fixes

Fix 1: Per-Container DNS Override (Testing Only)

For immediate testing without configuration changes, specify DNS servers directly:

podman run --dns 8.8.8.8 --dns 1.1.1.1 alpine nslookup google.com

Use case: Ad-hoc debugging and one-off containers
Limitation: Not a persistent solution; doesn’t work for Compose stacks

---

Fix 2: Global DNS Configuration (Recommended)

Set explicit DNS servers for all containers via containers.conf:

# Create user-level config directory
mkdir -p ~/.config/containers

# Add DNS configuration
cat >> ~/.config/containers/containers.conf << 'EOF'
[containers]
dns_servers = ["8.8.8.8", "1.1.1.1"]
EOF

For system-wide configuration:

sudo mkdir -p /etc/containers/containers.conf.d
sudo tee /etc/containers/containers.conf.d/01-dns.conf > /dev/null << 'EOF'
[containers]
dns_servers = ["8.8.8.8", "1.1.1.1"]
EOF

Note: Requires Podman ≥ 4.4.3 (older versions had a bug where host resolvers were still appended).

---

Fix 3: Switch Host resolv.conf to Upstream DNS

Make containers inherit actual upstream DNS servers instead of the stub resolver:

sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

This points /etc/resolv.conf to real upstream servers (typically from DHCP) rather than 127.0.0.53. Containers will then inherit these working resolvers.

Trade-off: This disables local DNS caching in systemd-resolved for the host itself. Only use this if you don’t rely on resolved’s caching features.

---

Fix 4: Configure systemd-resolved to Listen on Podman Bridge

Keep systemd-resolved as a local cache but make it reachable from containers:

# Find your Podman bridge IP (typically 10.88.0.1 for default network)
ip addr show podman0 | grep inet

# Configure resolved to also listen on that IP
sudo mkdir -p /etc/systemd/resolved.conf.d
sudo tee /etc/systemd/resolved.conf.d/podman.conf > /dev/null << 'EOF'
[Resolve]
DNSStubListenerExtra=10.88.0.1
EOF

sudo systemctl restart systemd-resolved

Then configure containers to use the bridge IP:

# In ~/.config/containers/containers.conf
[containers]
dns_servers = ["10.88.0.1"]

Benefit: Maintains DNS caching while providing container access.

---

Installing Missing Components

Fix 5: Install Userspace Networking Tools

If rootless networking is broken entirely (no IP connectivity), install the required packages:

sudo apt update
sudo apt install -y slirp4netns passt aardvark-dns

Verify installation:

which slirp4netns  # should print path
which pasta        # from passt package
which aardvark-dns # from aardvark-dns package
podman info --format '{{.Host.NetworkBackend}}'  # should show "netavark"

---

Firewall Configuration

Fix 6: Allow DNS Traffic Through Firewall

If containers can reach each other by IP but not by name, and aardvark-dns is running, firewall rules may be blocking DNS:

# Check for explicit drop rules on DNS port
sudo nft list ruleset | grep -B2 -A5 dport\ 53

# If firewalld is active, add an allow rule
sudo firewall-cmd --add-port=53/udp --permanent
sudo firewall-cmd --reload

# Or temporarily stop firewalld to test
sudo systemctl stop firewalld

The netavark firewall driver manages its own forwarding rules. A host-level firewall that inserts DROP rules before the FORWARD chain’s ACCEPT rules will break DNS regardless of Podman’s configuration.

---

Advanced: Custom Networks with DNS

Fix 7: Create a Proper Network with DNS Enabled

The default podman network does NOT enable aardvark-dns for container-to-container resolution. You must create a custom network:

# Create a network (DNS is enabled by default)
podman network create myapp-net

# Verify DNS is enabled
podman network inspect myapp-net --format '{{.DNSEnabled}}'
# → true

# Run containers on it
podman run -d --name web --network myapp-net nginx
podman run -d --name app --network myapp-net alpine sleep 3600

# Test container-to-container DNS
podman exec app nslookup web

---

Fix 8: Restart Stale aardvark-dns

If aardvark-dns is running but in the wrong network namespace, force a restart by removing and recreating the network:

podman network rm myapp-net
podman network create myapp-net

Or reconnect a container to re-trigger DNS setup:

podman network disconnect myapp-net web
podman network connect myapp-net web

In extreme cases with stale processes:

sudo pkill -9 aardvark-dns
podman system reset --force  # ⚠️ removes containers, images, volumes

---

Verification

Fix 9: End-to-End Testing

Run these tests to confirm everything works:

# External DNS resolution
podman run --rm --network myapp-net alpine nslookup google.com 2>&1

# Internal DNS (container-to-container)
podman run -d --name c1 --network myapp-net alpine sleep 3600
podman run -d --name c2 --network myapp-net alpine sleep 3600
podman exec c1 nslookup c2

# HTTP connectivity
podman exec c1 wget -qO- http://google.com | head -c 200

---

Decision Tree: Which Fix to Apply?

┌─ Container DNS fails?
│
├─ cat /etc/resolv.conf shows 127.0.0.53
│   → Fix: Switch to upstream resolv.conf (Fix 3)
│     or configure systemd-resolved on bridge (Fix 4)
│     or set explicit DNS in containers.conf (Fix 2)
│
├─ which slirp4netns returns nothing
│   → Fix: Install networking tools (Fix 5)
│
├─ Container-to-container resolution fails
│   → Fix: Create custom network (Fix 7)
│     or restart aardvark-dns (Fix 8)
│
├─ nft list ruleset shows DROP on port 53
│   → Fix: Adjust firewall rules (Fix 6)
│
└─ Nothing above applies
    → Fix: Use --dns override for testing (Fix 1)
      then escalate to Podman issue tracker

---

Production Prevention Checklist

Before deploying containerized applications, verify these items:

• systemd-resolved configuration: Either configure DNSStubListenerExtra or symlink /etc/resolv.conf to upstream DNS
• Required packages installed: slirp4netns, passt, and aardvark-dns
• Custom networks used: Multi-container applications should use custom networks, not the default bridge
• Firewall rules verified: Allow traffic to network gateway on UDP 53
• containers.conf configured: Define dns_servers as a fallback
• Network backend confirmed: podman info | grep NetworkBackend should show netavark

---

Key Commands Reference

Command	Purpose
cat /etc/resolv.conf	Check host DNS configuration
resolvectl status	Check systemd-resolved state
podman info --format '{{.Host.NetworkBackend}}'	Verify netavark is active
podman network inspect <net> --format '{{.DNSEnabled}}'	Check DNS on a network
podman run --rm alpine nslookup google.com	Test DNS resolution in container
podman run --dns 8.8.8.8 alpine ...	Override DNS per-container
which slirp4netns aardvark-dns pasta	Verify networking tools installed
journalctl -u systemd-resolved | tail -20	Check systemd-resolved errors

---

References

• containers.conf(5) — Debian manpage
• Podman Issue #17578 — dns_servers override bug (fixed in 4.4.3)
• Podman Issue #25857 — network —dns vs —disable-dns semantics
• Podman Issue #26917 — firewall blocking internal DNS
• Netavark Issue #1055 — firewall rules interfering with DNS

---

Conclusion

DNS resolution issues in Podman containers on Debian 13 are almost always caused by the systemd-resolved stub resolver conflict, missing networking tools, or misconfigured network backends. By following this guide’s diagnostic approach and applying the appropriate fixes—from quick overrides to production configurations—you can restore reliable DNS functionality in your containerized applications.

Remember that the most robust solution involves a combination of: proper systemd-resolved configuration, installed networking tools (slirp4netns/passt/aardvark-dns), custom networks for multi-container applications, and verified firewall rules. With these in place, your containers should have consistent DNS resolution both externally and between themselves.