Bevor wir im nächsten Beitrag mit Tailscale VPN den Admin-Zugang absichern und danach mit Komodo die Docker-Verwaltung einrichten, klären wir optional eine Kleinigkeit: Ist Port 53 auf deinem System frei für zukünftige DNS-Dienste – und falls nicht, wie machst du ihn frei?

Dieser kurze Artikel schafft die Voraussetzungen für alle späteren DNS-Services – egal ob du AdGuard Home, Pi-hole oder einen anderen DNS-Server einsetzen möchtest. Bei vielen VPS-Images ist Port 53 bereits frei und du bist in zwei Minuten fertig. Nur falls dein System systemd-resolved als lokalen Resolver betreibt, gibt es etwas zu tun.

Brauchst du diesen Artikel?

Überspringe diesen Artikel, wenn:

  • Du keinen eigenen DNS-Dienst betreiben willst
  • Du weder AdGuard Home noch Pi-hole einsetzen möchtest

Folge diesem Artikel, wenn:

  • Du später DNS-basiertes Blocking oder Filterung willst (z. B. AdGuard Home)
  • Du generell mit eigenen DNS-Services arbeiten möchtest

Du kannst diesen Artikel auch später nachholen – z. B. direkt vor der Installation eines DNS-Dienstes. Ohne diesen Schritt läuft dein VPS ganz normal weiter.

Am Ende hast du

  • Geklärt, ob Port 53 auf deinem System überhaupt belegt ist
  • Falls belegt: Port 53 (TCP + UDP) nicht mehr lokal durch systemd-resolved blockiert
  • DNS-Auflösung funktioniert wie gewohnt
  • Keine Docker-Kompatibilitätsprobleme

Voraussetzungen

  • Debian 13 (Server steht aus Artikel 02)
  • SSH-Zugang als Benutzer mit sudo-Rechten

1. Warum Port 53 überhaupt?

Port 53 ist der Standardport für DNS. Jeder lokale DNS-Server benötigt ihn, zum Beispiel:

  • AdGuard Home
  • Pi-hole
  • Unbound
  • CoreDNS

Auf manchen Systemen läuft bereits ein lokaler DNS-Resolver namens systemd-resolved, der Port 53 (genauer: 127.0.0.53:53) belegt. Ist das der Fall, starten die oben genannten Dienste nicht und melden Fehler wie:

Error: listen udp :53: bind: address already in use

Die gute Nachricht: Viele VPS-Images – darunter das in dieser Serie verwendete Netcup-Image – liefern Debian ohne aktiven systemd-resolved aus. Dann ist Port 53 von Haus aus frei und du musst nichts tun. Deshalb prüfen wir zuerst, ob du überhaupt betroffen bist.

2. Bist du überhaupt betroffen?

Ein einziger Befehl entscheidet:

sudo ss -tulpn | grep :53

Keine Ausgabe → Port 53 ist frei. Du bist fertig – springe direkt zu Abschnitt 4. Es gibt nichts zu konfigurieren.

Ausgabe mit 127.0.0.53:53 → systemd-resolved belegt den Port. Beispiel:

udp   UNCONN  0   0   127.0.0.53:53   0.0.0.0:*   users:(("systemd-resolve",pid=545,fd=12))
tcp   LISTEN  0   4096 127.0.0.53:53  0.0.0.0:*   users:(("systemd-resolve",pid=545,fd=13))

In diesem Fall mach mit Abschnitt 3 weiter.

Gegencheck (optional): Wer sichergehen will, ob systemd-resolved läuft:

systemctl status systemd-resolved
  • Unit systemd-resolved.service could not be found. oder inactive (dead) → Dienst nicht aktiv, Port 53 frei, nichts zu tun.
  • active (running) → Dienst läuft, weiter mit Abschnitt 3.

Hinweis: Auf dem Netcup-Image dieser Serie ist systemd-resolved nicht installiert. /etc/resolv.conf ist dort eine statische Datei mit den Provider-Nameservern, kein Symlink auf einen Stub-Resolver. Du wirst also vermutlich „keine Ausgabe" sehen und kannst diesen Artikel überspringen. Andere Provider oder eine manuelle Debian-Installation aktivieren systemd-resolved jedoch häufig – für diese Fälle ist Abschnitt 3 da.

3. Stub-Listener deaktivieren (nur falls systemd-resolved aktiv ist)

Diesen Abschnitt brauchst du nur, wenn Abschnitt 2 ergeben hat, dass systemd-resolved auf 127.0.0.53:53 lauscht. War Port 53 bereits frei, überspringe ihn.

Wir deaktivieren nicht systemd-resolved selbst, sondern nur den Stub-Listener auf 127.0.0.53:53. Der Dienst läuft weiter und behält wichtige Funktionen wie VPN-Integration oder Split-DNS.

Schritt 1: Aktuellen Zustand verstehen

cat /etc/resolv.conf

Typische Ausgabe bei aktivem Stub-Resolver:

# This is /run/systemd/resolve/stub-resolv.conf managed by systemd-resolved
nameserver 127.0.0.53
options edns0 trust-ad

Die Adresse 127.0.0.53 und der Header managed by systemd-resolved zeigen, dass der Stub-Listener arbeitet.

Schritt 2: Konfiguration anpassen

sudo nano /etc/systemd/resolved.conf

Die Zeile mit DNSStubListener anpassen:

#DNSStubListener=yes
DNSStubListener=no

Speichern mit Ctrl+X, dann Y, dann Enter.

Schritt 3: /etc/resolv.conf korrekt verlinken

systemd-resolved stellt zwei Varianten bereit:

  • stub-resolv.conf → zeigt auf 127.0.0.53 (Stub)
  • resolv.conf → zeigt auf die echten Upstream-DNS-Server

Nach dem Deaktivieren des Stub-Listeners darf /etc/resolv.conf nicht mehr auf den Stub zeigen.

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

Dieser Schritt ist wichtig: Ohne ihn würde /etc/resolv.conf weiter auf 127.0.0.53 zeigen, obwohl dort kein Stub-Listener mehr läuft. DNS-Auflösung würde dann fehlschlagen.

Schritt 4: Dienst neu starten

sudo systemctl restart systemd-resolved

Schritt 5: Erfolg prüfen

Port 53 ist nicht mehr lokal belegt:

sudo ss -tulpn | grep :53

→ Keine Ausgabe bedeutet: Port ist frei.

/etc/resolv.conf zeigt echte Resolver:

cat /etc/resolv.conf

Du solltest jetzt echte Nameserver-IPs sehen (z. B. 8.8.8.8, 1.1.1.1 oder Provider-DNS), nicht mehr 127.0.0.53.

DNS-Auflösung funktioniert weiterhin:

nslookup google.com

→ IP-Adressen werden zurückgegeben.

Hinweis zur Firewall: Port 53 ist jetzt lokal frei, aber UFW bleibt unverändert. Es wird nichts nach außen geöffnet.

4. Häufige Fragen

Warum KEIN chattr +i /etc/resolv.conf?

Manche Anleitungen empfehlen, /etc/resolv.conf zu „sperren" mit:

sudo chattr +i /etc/resolv.conf  # ← NICHT in dieser Serie!

Das verhindert, dass Docker seine eigene DNS-Konfiguration schreiben kann.

Typische Fehlermeldung, wenn die Datei gesperrt ist:

operation not permitted

Der Symlink auf /run/systemd/resolve/resolv.conf ist dynamisch, aber korrekt – und Docker bleibt kompatibel.

Muss ich jetzt UFW für Port 53 öffnen?

Nein.

Port 53 ist jetzt nur nicht mehr lokal belegt. Die Firewall bleibt unverändert. Erst wenn später ein DNS-Dienst läuft (z. B. AdGuard Home), wird gezielt eine passende UFW-Regel gesetzt – falls der DNS-Server von außen erreichbar sein soll.

Bei mir war Port 53 von Anfang an frei – ist das ein Problem?

Nein, im Gegenteil. Viele VPS-Images liefern Debian ohne aktiven systemd-resolved aus. Dann ist Port 53 sofort nutzbar und du musst nichts vorbereiten. Du kannst direkt mit der Installation eines DNS-Dienstes loslegen, wenn es so weit ist.

5. Fazit und Ausblick

Nach diesem kurzen Check weißt du, dass Port 53:

  • entweder von Haus aus frei ist (bei vielen VPS-Images, inkl. dem dieser Serie)
  • oder durch das Deaktivieren des Stub-Listeners frei gemacht wurde
  • bereit für zukünftige DNS-Services ist (z. B. AdGuard Home)
  • ohne Eingriff in Docker oder Firewall

Im nächsten Artikel richten wir Tailscale VPN ein – deinen sicheren Admin-Zugang ohne offene Ports. Die DNS-Vorbereitung bleibt davon unberührt und wird erst wieder relevant, wenn später ein eigener DNS-Dienst (Artikel 18+, z. B. AdGuard Home) ins Spiel kommt.

👉 Nächster Artikel: 05. Tailscale VPN einrichten