> ## Content Index > Fetch the complete content index at: https://blog.cube-m.de/llms.txt > Use this file to discover other available public pages before exploring further. # 04. DNS-Vorbereitung: Port 53 für einen späteren lokalen DNS-Server freihalten (optional) - URL: https://blog.cube-m.de/04-dns-vorbereitung-port-53-fur-einen-spateren-lokalen-dns-server-freihalten-optional/ - Published: 2026-02-11T07:26:25.000Z - Updated: 2026-06-01T11:56:27.000Z - Description: Port 53 muss für AdGuard Home oder Pi-hole frei sein. Bei vielen VPS-Images ist er das schon – ein kurzer Check klärt das in Sekunden. Falls nicht: systemd-resolved sauber umstellen statt abschalten. - Author: Martin - Tags: VPS, Basis, Debian, systemd-resolved, dns-vorbereitung, self-hosting, Server, #Import 2026-09-06 19:52 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-Diens**t 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: ```bash sudo ss -tulpn | grep :53 ``` **Keine Ausgabe** → Port 53 ist frei. Du bist fertig – springe direkt zu [Abschnitt 4](#4-fazit-und-ausblick). 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: ```bash 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 ```bash 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 ```bash 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. ```bash 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 ```bash sudo systemctl restart systemd-resolved ``` ### Schritt 5: Erfolg prüfen Port 53 ist nicht mehr lokal belegt: ```bash sudo ss -tulpn | grep :53 ``` → Keine Ausgabe bedeutet: Port ist frei. `/etc/resolv.conf` zeigt echte Resolver: ```bash 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: ```bash 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: ```bash 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](#)