Eine Domain mit dem Server verbinden (DNS-Grundlagen)

Bisher erreichst du deinen Server nur über seine IP-Adresse. Für echte Dienste brauchst du eine Domain – nicht nur der Optik wegen: Ohne eine öffentlich auflösende Domain kann Traefik später kein TLS-Zertifikat von Let’s Encrypt holen. Dieses Tutorial verbindet deine Domain mit dem Server und erklärt die drei Begriffe, an denen Einsteiger hängenbleiben: A-Record, TTL und Propagation.

Was bauen wir?

Am Ende zeigt deine Domain (DEINE_DOMAIN) per A-Record (IPv4) und – falls dein Server IPv6 hat – AAAA-Record auf deine Server-IP, inklusive www. Du kannst das mit dig selbst überprüfen und verstehst, warum eine Änderung nicht immer sofort sichtbar ist. Optional richtest du zusätzlich Reverse DNS (PTR) ein – wichtig, sobald dein Server E-Mails verschickt. Damit ist die Grundlage für alle öffentlich erreichbaren Dienste gelegt.

Voraussetzungen

• Ein eingerichteter Server mit bekannter öffentlicher IP-Adresse
• Eine registrierte Domain (bei netcup, einem anderen Registrar oder inklusive im Hosting-Paket)
• Zugang zur DNS-Verwaltung deiner Domain (bei netcup: das Kundenkonto CCP)

Schritt für Schritt

Schritt 1: Die Server-IP herausfinden

Verbinde dich per SSH und lass dir die öffentlichen IP-Adressen anzeigen:

ip -4 addr show scope global
ip -6 addr show scope global

Die IPv4-Adresse steht hinter inet (z. B. 203.0.113.10), eine eventuelle IPv6-Adresse hinter inet6 (beginnt nicht mit fe80::, das wäre nur link-local). Läuft schon Docker auf dem Server, tauchen zusätzlich private Adressen aus 172.16.0.0/12 an docker0/br-… auf – Container-Netze, die nicht ins DNS gehören. Du brauchst die von eth0. Alternativ findest du beide auch im netcup Server Control Panel (SCP) in der Server-Übersicht.

Schritt 2: A- und AAAA-Record anlegen

Öffne die DNS-Verwaltung deiner Domain. Dort trägst du Ressource-Records ein – die Zuordnung von Namen zu Adressen. Lege an:

• @ steht für die Domain selbst (DEINE_DOMAIN), www für die Unterdomain www.DEINE_DOMAIN.
• A verweist auf eine IPv4-, AAAA auf eine IPv6-Adresse. Der Name „AAAA" kommt daher, dass eine IPv6- viermal so lang ist wie eine IPv4-Adresse.
• Für einzelne Dienste kannst du später gezielt Subdomains anlegen (z. B. cloud, git) – nach demselben Muster.

Schritt 3: TTL und Propagation verstehen

Jeder Record hat eine TTL (Time To Live) in Sekunden – z. B. 3600 (eine Stunde). Sie sagt Resolvern weltweit, wie lange sie die Antwort zwischenspeichern dürfen, bevor sie erneut nachfragen.

Daraus folgt die berüchtigte Propagation: Änderst du einen Record, sehen manche Resolver den neuen Wert sofort, andere erst nach Ablauf der alten TTL. „DNS propagiert" heißt nichts anderes, als dass diese Caches nach und nach ablaufen. Rechne im Alltag mit Minuten bis zu einer Stunde, gelegentlich länger.

Schritt 4: Mit dig überprüfen

Warte ein paar Minuten und prüfe dann von deinem eigenen Rechner aus, worauf die Domain zeigt. dig ist das Standardwerkzeug dafür; auf Debian und Ubuntu steckt es im Paket bind9-dnsutils:

sudo apt install bind9-dnsutils

Dann frag den A-Record ab:

dig +noall +answer DEINE_DOMAIN A

So sieht eine korrekte Antwort aus (Beispiel für die reale Domain dieser Seite):

serverkueche.de.	3600	IN	A	152.53.246.100

Die Zahl 3600 ist die verbleibende TTL – sie zählt herunter, solange die Antwort im Cache liegt –, dahinter steht die Ziel-IP. Für IPv6 fragst du analog den AAAA-Record ab:

dig +short DEINE_DOMAIN AAAA

2a0a:4cc0:c0:939c::1

+short liefert nur die nackten Werte, auch für IPv4:

dig +short DEINE_DOMAIN

152.53.246.100

Erscheint deine korrekte Server-IP, ist die Domain verbunden. Prüfe auch www:

dig +short www.DEINE_DOMAIN

Mit einem eigenen A-Record für www (Schritt 2) kommt genau eine Zeile mit derselben IP wie beim Apex zurück. Zeigt www dagegen per CNAME auf die Hauptdomain – auch verbreitet und völlig in Ordnung –, gibt dig +short erst das CNAME-Ziel und dann dessen IP aus, so wie bei dieser Seite:

serverkueche.de.
152.53.246.100

Entscheidend ist in beiden Fällen die letzte Zeile: Dort muss die IP deines Servers stehen.

Schritt 5: Reverse DNS (PTR) setzen – optional, aber empfohlen

Der A-Record beantwortet die Frage „Welche IP gehört zu diesem Namen?". Reverse DNS – der PTR-Record – beantwortet die Gegenrichtung: „Welcher Name gehört zu dieser IP?". Für eine reine Website brauchst du das nicht. Sobald dein Server aber E-Mails verschickt – und sei es nur Benachrichtigungen von Nextcloud, Gitea & Co. –, ist es praktisch Pflicht: Die Mailserver der Gegenseite lehnen Post von IPs ohne passenden PTR ab oder werten sie als Spam. Der PTR ist dabei nur der erste von vier DNS-Bausteinen – SPF, DKIM und DMARC kommen dazu, sobald du wirklich Mails verschickst; die behandelt das Tutorial E-Mail-Zustellbarkeit.

Der entscheidende Unterschied zu den bisherigen Records: Den PTR trägst du nicht bei deinem DNS-Anbieter ein, sondern dort, wo die IP-Adresse verwaltet wird – also bei deinem VPS-Anbieter. Bei netcup findest du das im Servercontrolpanel (SCP) im Tab Netzwerk – dort gibt es je Adresse (IPv4 und IPv6) ein Feld Reverse-DNS. Trage dort einen Hostnamen ein, der per A-Record auf denselben Server zeigt – entweder direkt DEINE_DOMAIN oder einen eigenen Namen wie server.DEINE_DOMAIN (im Screenshot als Beispiel) – und klicke auf Speichern.

Hast du IPv6, setze den PTR für beide Adressen – IPv4 und IPv6. Der IPv6-PTR wird gern vergessen, und genau darüber stolpern manche Mailserver dann doch.

Prüfen kannst du das Ergebnis mit dig und der Option -x (Reverse Lookup) – für IPv6 analog mit DEINE_SERVER_IPV6:

dig +short -x DEINE_SERVER_IPV4

Zurückkommen sollte genau der Hostname, den du gerade eingetragen hast – mit abschließendem Punkt:

server.DEINE_DOMAIN.

Kommt nichts oder noch der Standard-Name des Anbieters zurück (bei netcup etwas wie v220….bestsrv.de), ist der PTR noch nicht (richtig) gesetzt – oder die Änderung braucht wie bei jedem DNS-Eintrag noch etwas Zeit.

Wenn es nicht funktioniert

Wartung & Backups

• DNS ist wartungsarm. Einmal korrekt gesetzt, ändert sich am A/AAAA-Record selten etwas. Ausnahme: ein Server-Umzug – dann greift der TTL-Trick aus Schritt 3.
• Dokumentiere deine Records. Halte irgendwo fest, welche Namen (@, www, cloud, …) auf welche IP zeigen. Bei mehreren Diensten verliert man sonst den Überblick.
• Kein klassisches Backup nötig, aber ein Screenshot bzw. Export deiner DNS-Zone schadet nicht, falls du den Anbieter wechselst.
• Reverse DNS bei einem IP-Wechsel mitziehen. Bekommt der Server eine neue IP (Umzug, neues Produkt), musst du den PTR beim VPS-Anbieter neu setzen – er hängt an der IP, nicht an der Domain.

Deine Domain zeigt jetzt auf den Server – damit ist die letzte Voraussetzung erfüllt, um Dienste mit dem Reverse Proxy Traefik öffentlich mit automatischem HTTPS bereitzustellen.