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. 46.38.243.234), eine eventuelle IPv6-Adresse hinter inet6 (beginnt nicht mit fe80::, das wäre nur link-local). 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:

dig +noall +answer DEINE_DOMAIN A

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

serverkueche.de.	600	IN	A	46.38.243.234

Die Zahl 600 ist die verbleibende TTL, dahinter steht die Ziel-IP. Für IPv6 analog mit AAAA. Wenn du es nur ganz kurz willst:

dig +short DEINE_DOMAIN

46.38.243.234

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

dig +short www.DEINE_DOMAIN

Auch hier sollte dieselbe Server-IP wie beim Apex als reine Zeile zurückkommen:

46.38.243.234

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 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):

dig +short -x DEINE_SERVER_IP

Zurückkommen sollte dein Hostname mit abschließendem Punkt:

serverkueche.de.

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

Wenn es nicht funktioniert

Symptom: dig liefert keine oder eine falsche (alte) IP.

Ursache & Lösung: Meist noch Propagation. Frage gezielt einen öffentlichen Resolver, der deinen lokalen Cache umgeht: dig +short DEINE_DOMAIN @1.1.1.1. Zeigt der schon den richtigen Wert, ist nur dein lokaler/Provider-Cache noch nicht abgelaufen – abwarten.

Symptom: Die Domain zeigt zwar, aber die falsche IP – z. B. eine Parking-Seite des Registrars.

Ursache & Lösung: Oft existiert noch ein alter A-Record oder eine Weiterleitung/Parking-Einstellung. Entferne widersprüchliche Einträge; pro Name und Typ sollte genau ein Wert stehen (bewusste Ausnahmen ausgenommen).

Symptom: IPv4 klappt, IPv6 (AAAA) führt zu Timeouts.

Ursache & Lösung: Du hast einen AAAA-Record eingetragen, obwohl der Server keine funktionierende IPv6-Adresse hat. Browser bevorzugen dann IPv6 und laufen in einen Timeout. Lösung: AAAA-Record entfernen, bis der Server wirklich IPv6 kann.

Symptom: In manchen Oberflächen wird der Wert mit angehängtem Punkt gespeichert (DEINE_DOMAIN.) und du bist unsicher.

Ursache & Lösung: Der abschließende Punkt (Root der DNS-Hierarchie) ist normal und korrekt – viele DNS-Verwaltungen ergänzen ihn automatisch. Kein Grund zur Sorge.

Symptom: Vom Server verschickte E-Mails landen im Spam oder werden abgelehnt (im Mail-Log steht z. B. does not resolve to address oder no PTR record).

Ursache & Lösung: Der Reverse-DNS-Eintrag (PTR) fehlt oder passt nicht zum Absender-Hostnamen. Setze den PTR wie in Schritt 5 beschrieben beim VPS-Anbieter und achte darauf, dass er auf denselben Namen zeigt, der auch per A-/AAAA-Record auflöst.

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 öffentlich mit automatischem HTTPS bereitzustellen – der nächste Schritt ist der zentrale Baustein der Serverküche: der Reverse Proxy mit Traefik.