Rješenje za Podman DNS probleme na Debianu 13 (Trixie)

Meta opis: Ispravi probleme s DNS rješavanjem u Podman kontejnerima na Debianu 13. Nauči dijagnosticirati konflikte systemd-resolved-a, instalirati nedostajuće mrežne alate, konfigurirati aardvark-dns i vratiti pouzdano DNS rješavanje u svojim kontejnerima.

---

Kada pokrećeš Podman kontejner na Debianu 13 (Trixie) i nslookup google.com ne uspijeva s timeoutom ili “server not found” greškom, problem je gotovo nikad u samom Podmanu — to je sukob konfiguracije između Debian 13-ove zadane mrežne stacke i Podmanovog kontejnerskog mrežnog imena prostora.

Ovaj vodič te vodi kroz dijagnostiku problema i implementaciju rješenja od brzih override-a do proizvodno spremnih konfiguracija.

---

Simptomi DNS problema u kontejnerima

Prije nego što skočiš na rješenja, potvrdi da tvoj kontejner ima DNS probleme:

# Testiraj DNS rješavanje unutar kontejnera
podman run --rm alpine nslookup google.com

# Provjeri što kontejner vidi za DNS
podman run --rm alpine cat /etc/resolv.conf

Tipični simptomi uključuju:

• DNS timeoutovi: nslookup ili dig naredbe vise u beskonačnost
• “Server not found” greške: Odmahni neuspjeh bez navedenog resolvera
• IP povezanost radi, hostname rješavanje ne uspijeva: Možeš pingati 8.8.8.8 ali ne i google.com
• Povremeno ponašanje: DNS radi nakon host reboot-a ali kasnije prestane
• Kontejner-kontejner rješavanje ne uspijeva: Kontejneri na istoj mreži ne mogu se međusobno riješiti po imenu

---

Razumijevanje uzroka problema

Debian 13 dolazi s systemd-resolvedom uključenim iz zadane konfiguracije, što uvodi nekoliko potencijalnih točaka neuspjeha za kontejnersko mrežiranje. Evo četiri glavna krivca:

1. systemd-resolved Stub Resolver Sukob

Debian 13-ov /etc/resolv.conf obično pokazuje na 127.0.0.53, lokalni stub resolver koji pruža systemd-resolved. Ta adresa radi samo na host-ovom loopback sučelju. Unutar kontejnerovog zasebnog mrežnog imenskog prostora, 127.0.0.53 se vraća u kontejnerov vlastiti (prazan) loopback — učinkovito nigdje.

2. Nedostajući korisnički mrežni alati

Podmanovo rootless mrežiranje zahtijeva ili slirp4netns ili pasta (iz passt paketa). Bez ovih, kontejneri padaju na onemogućenu mrežnu modu koja uopće ne može preusmjeriti DNS promet.

3. Nedostajući ili pogrešno konfiguriran aardvark-dns

Kontejner-kontejner DNS rješavanje ovisi o aardvark-dns i netavark backendu. Ako je aardvark nedostupan ili njegov proces zastario u starom mrežnom imenskom prostoru, interni DNS tiho neuspjeva.

4. Zaštitni zidni interferencija

Zaštitni zidne pravila (iz firewalld-a, nftables-a ili ufw-a) koja blokiraju promet prema aardvark-dns slušaču na portu 53 spriječiti će kontejnere da dođu do DNS resolvera, čak i ako je mrežna konfiguracija ispravna.

---

Dijagnostički popis za provjeru

Pokreni ove naredbe prvo kako bi identificirao što je pokvareno:

# 1. Što kontejner zapravo vidi?
podman run --rm alpine cat /etc/resolv.conf

# 2. Radi li sirova IP adresa? (izolira DNS od općeg mrežiranja)
podman run --rm alpine ping -c2 8.8.8.8

# 3. Provjeri host-ov resolv.conf
ls -la /etc/resolv.conf
cat /etc/resolv.conf

# 4. Je li systemd-resolved aktivan?
resolvectl status

# 5. Instaliran i pokrenut li je aardvark-dns?
which aardvark-dns
ps aux | grep aardvark

# 6. Dostupni li su mrežni alati?
which slirp4netns
which pasta

# 7. Provjeri za zaštite zidnu interferenciju
sudo nft list ruleset | grep -A5 dport\ 53
sudo firewall-cmd --list-all 2>/dev/null || echo "firewalld nije aktivan"

---

Brza rješenja

Rješenje 1: DNS override po kontejneru (samo za testiranje)

Za trenutno testiranje bez promjena konfiguracije, specifikuj DNS servere izravno:

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

Primjena: Ad-hoc debugiranje i jednokratni kontejneri
Ograničenje: Nije trajno rješenje; ne radi za Compose stackove

---

Rješenje 2: Globalna DNS konfiguracija (preporučeno)

Postavi eksplicitne DNS servere za sve kontejnere putem containers.conf:

# Stvori korisničku konfiguracijsku mapu
mkdir -p ~/.config/containers

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

Za sustavsku konfiguraciju:

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

Napomena: Zahtijeva Podman ≥ 4.4.3 (starije verzije imale su bug gdje su host resolveri ipak dodani).

---

Rješenje 3: Promijeni host-ov resolv.conf na upstream DNS

Neka kontejneri naslijede stvarne upstream DNS servere umjesto stub resolvera:

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

Ovo pokazuje /etc/resolv.conf na stvarne upstream servere (obično iz DHCP-a) umjesto 127.0.0.53. Kontejneri će onda naslijediti ove radne resolvere.

Kompromis: Ovo onemogućuje lokalno DNS keširanje u systemd-resolvedu za sam host. Koristi ovo samo ako ne ovisiš o resolved-ovim keširajućim značajkama.

---

Rješenje 4: Konfiguriraj systemd-resolved da sluša na Podman Bridge

Zadrži systemd-resolved kao lokalni cache, ali ga učini dostupnim iz kontejnera:

# Pronađi svoj Podman bridge IP (obično 10.88.0.1 za default mrežu)
ip addr show podman0 | grep inet

# Konfiguriraj resolved da također sluša na tu IP adresu
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

Zatim konfiguriraj kontejnere da koriste bridge IP:

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

Prednost: Zadržava DNS keširanje dok pruža pristup kontejnerima.

---

Instaliranje nedostajućih komponenti

Rješenje 5: Instaliraj korisničke mrežne alate

Ako je rootless mrežiranje potpuno pokvareno (nema IP povezanosti), instaliraj zahtijevane pakete:

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

Provjeri instalaciju:

which slirp4netns  # treba ispisati putanju
which pasta        # iz passt paketa
which aardvark-dns # iz aardvark-dns paketa
podman info --format '{{.Host.NetworkBackend}}'  # treba pokazati "netavark"

---

Konfiguracija zaštite zida

Rješenje 6: Dozvoli DNS promet kroz zaštitni zid

Ako kontejneri mogu doseći jedan drugog po IP-u ali ne i po imenu, i aardvark-dns je pokrenut, zaštite zidna pravila možda blokiraju DNS:

# Provjeri za eksplicitne DROP pravila na DNS portu
sudo nft list ruleset | grep -B2 -A5 dport\ 53

# Ako je firewalld aktivan, dodaj allow pravilo
sudo firewall-cmd --add-port=53/udp --permanent
sudo firewall-cmd --reload

# Ili privremeno zaustavi firewalld da testiraš
sudo systemctl stop firewalld

Netavark zaštite zidni upravlja svojim vlastitim pravilima preusmjeravanja. Vlasnička zaštita zidna koja umetne DROP pravila prije FORWARD lanca-ovog ACCEPT pravila slomit će DNS bez obzira na Podmanovu konfiguraciju.

---

Napredno: Custom mreže s DNSom

Rješenje 7: Stvori pravilnu mrežu s omogućenim DNSom

Default podman mreža NE omogućuje aardvark-dns za kontejner-kontejner rješavanje. Moraš stvoriti custom mrežu:

# Stvori mrežu (DNS je uključen iz zadane konfiguracije)
podman network create myapp-net

# Provjeri je li DNS omogućen
podman network inspect myapp-net --format '{{.DNSEnabled}}'
# → true

# Pokreni kontejnere na njoj
podman run -d --name web --network myapp-net nginx
podman run -d --name app --network myapp-net alpine sleep 3600

# Testiraj kontejner-kontejner DNS
podman exec app nslookup web

---

Rješenje 8: Ponovno pokreni zastarijeli aardvark-dns

Ako je aardvark-dns pokrenut ali u pogrešnom mrežnom imenskom prostoru, prisili ponovno pokretanje brisanjem i ponovnim stvaranjem mreže:

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

Ili ponovno poveži kontejner da ponovno aktivira DNS postavljanje:

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

U ekstremnim slučajevima s zastarjelim procesima:

sudo pkill -9 aardvark-dns
podman system reset --force  # ⚠️ uklanja kontejnere, slike, volumene

---

Provjera

Rješenje 9: End-to-End testiranje

Pokreni ove testove kako bi potvrdio da sve radi:

# Eksterni DNS rješavanje
podman run --rm --network myapp-net alpine nslookup google.com 2>&1

# Interni DNS (kontejner-kontejner)
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 povezanost
podman exec c1 wget -qO- http://google.com | head -c 200

---

Decision Tree: Koje rješenje primijeniti?

┌─ Kontejner DNS ne uspijeva?
│
├─ cat /etc/resolv.conf pokazuje 127.0.0.53
│   → Rješenje: Promijeni na upstream resolv.conf (Rješenje 3)
│     ili konfiguriraj systemd-resolved na bridge (Rješenje 4)
│     ili postavi eksplicitni DNS u containers.conf (Rješenje 2)
│
├─ which slirp4netns ne vraća ništa
│   → Rješenje: Instaliraj mrežne alate (Rješenje 5)
│
├─ Kontejner-kontejner rješavanje ne uspijeva
│   → Rješenje: Stvori custom mrežu (Rješenje 7)
│     ili ponovno pokreni aardvark-dns (Rješenje 8)
│
├─ nft list ruleset pokazuje DROP na portu 53
│   → Rješenje: Podesi zaštite zidna pravila (Rješenje 6)
│
└─ Ništa od iznad ne vrijedi
    → Rješenje: Koristi --dns override za testiranje (Rješenje 1)
      zatim eskaliraj Podman bug trackeru

---

Prodajna spretna popis za sprječavanje

Prije deploy-a kontejneriziranih aplikacija, provjeri ove stavke:

• systemd-resolved konfiguracija: Ili konfiguriraj DNSStubListenerExtra ili symlink /etc/resolv.conf na upstream DNS
• Zahtijevani paketi instalirani: slirp4netns, passt i aardvark-dns
• Custom mreže korištene: Multi-kontejner aplikacije trebaju koristiti custom mreže, ne default bridge
• Zaštitne zidna pravila provjerena: Dozvoli promet prema mrežnom gatewayu na UDP 53
• containers.conf konfiguriran: Definiraj dns_servers kao fallback
• Mrežni backend potvrđen: podman info | grep NetworkBackend treba pokazati netavark

---

Ključne naredbe za referencu

Naredba	Namjena
cat /etc/resolv.conf	Provjeri host-ov DNS konfiguraciju
resolvectl status	Provjeri systemd-resolved stanje
podman info --format '{{.Host.NetworkBackend}}'	Potvrdi je li netavark aktivan
podman network inspect <net> --format '{{.DNSEnabled}}'	Provjeri DNS na mreži
podman run --rm alpine nslookup google.com	Testiraj DNS rješavanje u kontejneru
podman run --dns 8.8.8.8 alpine ...	Override DNS po kontejneru
which slirp4netns aardvark-dns pasta	Potvrdi instalirane mrežne alate
journalctl -u systemd-resolved | tail -20	Provjeri systemd-resolved greške

---

Reference

• containers.conf(5) — Debian manpage
• Podman Issue #17578 — dns_servers override bug (fixiran u 4.4.3)
• Podman Issue #25857 — network —dns vs —disable-dns semantičke
• Podman Issue #26917 — zaštite zid blokiraju interni DNS
• Netavark Issue #1055 — zaštite zidna pravila interferiraju s DNSom

---

Zaključak

DNS rješavanje problemi u Podman kontejnerima na Debianu 13 gotovo su uvijek uzrokovani systemd-resolved stub resolver sukobom, nedostajućim mrežnim alatima ili pogrešno konfiguriranim mrežnim backendovima. Slijedeći ovaj vodič-ov dijagnostički pristup i primjenjujući odgovarajuća rješenja—from brzih override-a do proizvodnih konfiguracija—možeš vratiti pouzdano DNS funkcionalnost u svojim kontejneriziranim aplikacijama.

Zapamti da je najrobustnije rješenje kombinacija: pravilne systemd-resolved konfiguracije, instaliranih mrežnih alata (slirp4netns/passt/aardvark-dns), custom mreža za multi-kontejner aplikacije i provjerenih zaštite zidnih pravila. S ovim na mjestu, tvoj kontejneri trebaju imati konzistentno DNS rješavanje kako eksterno tako i međusobno.