DNS für Gameserver richtig einrichten: A, SRV und TXT im Überblick
Die DNS Einstellungen für Ihren Gameserver richtig einrichten: A, SRV und TXT Einträge anlegen, TTL senken und Verbindungsprobleme vermeiden.
Die DNS Einstellungen für Ihren Gameserver richtig einrichten: A, SRV und TXT Einträge anlegen, TTL senken und Verbindungsprobleme vermeiden.
Für einen Gameserver reicht im Minimum ein A‑ oder AAAA‑Record, der Ihre Domain auf die Server‑IP zeigt. Bei Minecraft kommt meist ein SRV‑Record dazu, der den Port vor Spielern verbirgt, während FiveM in der Regel eine Subdomain mit A‑Record oder einen Reverse‑Proxy braucht. Bevor Sie etwas umziehen, senken Sie die TTL und legen Sie zuerst den A‑Record an, denn darauf bauen alle weiteren Einträge auf.
Kurz gesagt:
- Für einen Gameserver reicht ein A‑ oder AAAA‑Record, bei Minecraft kommt meist ein SRV‑Record hinzu, bei FiveM ist oft eine Subdomain mit A‑Record oder Reverse‑Proxy notwendig.
- Ein SRV‑Record braucht einen korrekt auflösbaren Target-Record, sonst funktioniert das Port‑Hiding bei Minecraft nicht, wobei Tippfehler und fehlende Punkte häufige Fehlerquellen sind.
- Vor Migrationen empfiehlt sich, die TTL der DNS‑Records deutlich zu senken, um eine schnellere Aktualisierung der Resolver bei IP‑Änderungen zu gewährleisten.
- Bei FiveM unterstützt das DNS‑Setup kein natives SRV‑Port‑Hiding, stattdessen setzen Betreiber auf Subdomain‑A‑Records oder Proxy‑Lösungen sowie spezielle server.cfg‑Einstellungen.
- Für eine zuverlässige Servererreichbarkeit sollten NS‑Einträge bei Parent‑ und Child‑Zone konsistent gehalten und mindestens zwei unabhängige Name‑Server betrieben werden.
Jeder dieser Record‑Typen erfüllt eine andere Aufgabe, und wer sie verwechselt, produziert genau die Fehler, die später stundenlange Fehlersuche kosten.
Der A‑Record verknüpft einen Hostnamen mit einer IPv4‑Adresse, der AAAA‑Record macht dasselbe für IPv6. Ein Eintrag wie play.beispiel.de. IN A 203.0.113.10 reicht aus, damit Spieler die Domain statt der nackten IP eingeben können. CNAME‑Records verweisen dagegen auf einen anderen Hostnamen, nie auf eine IP, und dürfen nicht auf die Zonen‑Apex (also die reine Domain ohne Subdomain) gesetzt werden, weil das mit anderen Pflichteinträgen der Zone kollidiert.
SRV‑Records sind komplexer aufgebaut und folgen diesem Schema:
_minecraft._tcp, vorangestellt an den Domainnamen.Ein SRV‑Record funktioniert nämlich nur, wenn das Target selbst über einen A‑, AAAA‑ oder CNAME‑Record auflösbar ist. Ohne diesen zusätzlichen Eintrag läuft die Anfrage ins Leere, auch wenn der SRV‑Record selbst syntaktisch korrekt aussieht.
TXT‑Records spielen hier eine andere Rolle: Sie dienen der Verifikation von Domain‑Eigentum oder tragen Sicherheitsinformationen wie TLSA‑Hinweise für DANE. Für das reine Verbinden mit einem Gameserver haben sie keine Funktion, sie sind reine Zusatzinformation für Dienste und Registrare.
Bei Minecraft Java Edition ist der SRV‑Record der Grund, warum Spieler play.beispiel.de statt play.beispiel.de:25566 eintippen können. Das Format lautet exakt _minecraft._tcp.domain.com. IN SRV priority weight port target., und laut Minecraft Wiki braucht dieser Eintrag zwingend einen zusätzlichen A‑Record oder CNAME für das Target, der auf die tatsächliche Server‑IP zeigt.
So gehen Sie Schritt für Schritt vor:
mc.beispiel.de. IN A 203.0.113.10._minecraft._tcp.beispiel.de. IN SRV 0 5 25566 mc.beispiel.de.dig A mc.beispiel.de und dig SRV _minecraft._tcp.beispiel.de, bevor Sie den Server öffentlich bewerben.Die Ausgabe von dig zeigt Ihnen im ANSWER-Bereich, ob der Record überhaupt existiert und welchen Wert er zurückliefert. Fehlt dort eine Zeile, ist entweder der Eintrag noch nicht propagiert oder schlicht falsch gesetzt.
Vor jeder Migration oder IP‑Änderung lohnt es sich, die TTL der betroffenen Records testweise auf etwa 300 Sekunden zu senken, wie es die Praxis rund um Minecraft‑Serverumzüge empfiehlt. So übernehmen die Resolver Ihrer Spieler die neue IP deutlich schneller, statt stundenlang die alte Adresse im Cache zu behalten.
Profi-Tipp: Vergessen Sie nie den abschließenden Punkt hinter dem Target im SRV-Record, sonst hängt Ihr Provider automatisch die eigene Domain an und der Eintrag zeigt ins Leere.
Die häufigsten Fehlerquellen sind fehlende A‑Records für das Target, Tippfehler in der Subdomain oder ein vergessener Punkt am Ende des Hostnamens. Wer diese drei Punkte prüft, löst die meisten SRV‑Probleme ohne weiteres Troubleshooting.
FiveM tickt hier anders als Minecraft. Laut Cfx-Dokumentation unterstützt die Engine kein natives SRV‑basiertes Port‑Hiding, wie Sie es von Minecraft gewohnt sind. Stattdessen setzen die meisten Betreiber auf eine Subdomain mit eigenem A‑Record, die direkt auf den Standardport zeigt, oder auf einen Reverse‑Proxy.
Für die Sichtbarkeit in der Serverliste reicht der DNS‑Eintrag allein ohnehin nicht aus. Entscheidend sind zusätzliche server.cfg‑Einstellungen:
sv_listingHostOverride sorgt dafür, dass die Master‑Liste den richtigen öffentlichen Hostnamen anzeigt statt einer internen Adresse.sv_endpoints definiert, über welche Adressen der Server erreichbar ist.sv_forceIndirectListing und sv_proxyIPRanges werden relevant, sobald ein Proxy zwischengeschaltet ist.Wer Port oder Domain hinter einem Reverse‑Proxy wie Nginx verstecken möchte, leitet üblicherweise Port 443 oder 80 auf den internen FiveM‑Port weiter; für reinen TCP‑ oder UDP‑Verkehr braucht Nginx zusätzlich das Stream‑Modul, wie die Cfx-Dokumentation beschreibt. Ob Ihr Server überhaupt sichtbar ist, lässt sich am info.json‑Endpunkt und an den eingehenden Heartbeats ablesen, siehe die Cfx-Hinweise zu Serverproblemen. Sobald Proxy‑Konfiguration oder Firewall‑Regeln ins Spiel kommen, lohnt sich oft ein kurzer Kontakt zum Hoster‑Support, statt stundenlang an der server.cfg zu basteln.
Ein funktionierender DNS‑Eintrag nützt wenig, wenn die Delegation dahinter wackelt. Die ICANN SSAC empfiehlt, Parent‑ und Child‑Zone konsistent zu halten und für wichtige Zonen mindestens zwei unabhängige Name‑Server zu betreiben.
Inkonsistente Delegation zwischen Parent- und Child-Zone gilt als häufige Ursache für DNS-Ausfälle, wenn NS‑Einträge nur beim eigenen Hoster geändert, aber nicht beim Registrar aktualisiert werden, wie die ICANN SSAC empfiehlt.
Für den Alltag als Gameserver‑Betreiber zählen diese Punkte:
Eine bewährte Wartungscheckliste sieht so aus: TTL senken, Änderung durchführen, Auflösung aktiv überwachen, TTL wieder anheben. Dieser simple Ablauf verhindert die meisten bösen Überraschungen bei Serverumzügen.
Wenn Spieler sich plötzlich nicht mehr verbinden können, hilft Panik nicht, sondern eine feste Reihenfolge an Prüfungen.
dig A domain.de und, bei Minecraft, zusätzlich mit dig SRV _minecraft._tcp.domain.de.nc oder tcptraceroute und kontrollieren Sie Firewall‑ und NAT‑Regeln.Profi-Tipp: Führen Sie dig und nslookup immer von einem Gerät außerhalb Ihres eigenen Netzwerks aus, sonst sehen Sie unter Umständen nur einen lokal zwischengespeicherten, veralteten Eintrag.
DNS funktioniert im Kern als verteiltes Nachschlagesystem: Ihr Resolver fragt zunächst die Root‑Server, dann die zuständigen Server für die Top‑Level‑Domain und schließlich die autoritativen Name‑Server Ihrer eigenen Zone. Für einen Gameserver heißt das konkret: Die Domain, die Sie Ihrer Community geben, muss am Ende bei genau den Servern landen, die Ihre Einträge verwalten, typischerweise die Ihres Hosters oder DNS‑Anbieters.
Eine Zone besteht aus mehreren Record‑Typen, die zusammenspielen. Der SOA‑Record definiert die grundlegenden Parameter der Zone, die NS‑Records benennen die zuständigen Name‑Server, und erst darunter kommen die praktischen Einträge wie A, AAAA, CNAME, SRV und TXT, die Sie für den eigentlichen Spielbetrieb brauchen. Jede Anfrage eines Spiele‑Clients durchläuft diese Kette, bevor die Verbindung überhaupt aufgebaut wird, und jede Verzögerung oder jeder Fehler in dieser Kette wirkt sich direkt auf den Verbindungsaufbau aus.
Wichtig für Gameserver‑Betreiber ist, dass DNS ausschließlich die Namensauflösung übernimmt, also die Zuordnung von Domain zu IP‑Adresse und gegebenenfalls Port. Ob der Server danach erreichbar ist, hängt von ganz anderen Faktoren ab: offene Ports, korrekte Firewall‑Regeln und eine laufende Serverinstanz. DNS kann also einen falsch konfigurierten Server nicht reparieren, es sorgt lediglich dafür, dass Spieler überhaupt die richtige Adresse finden.
Nicht jedes Spiel behandelt DNS gleich, und das liegt an den jeweiligen Netzwerk‑Protokollen der Engines. Minecraft Java Edition unterstützt, wie bereits beschrieben, SRV‑Records nativ, wodurch Sie Domain und Port vollständig von der Spieleingabe trennen können. Die Bedrock Edition dagegen verhält sich anders und verlangt in vielen Fällen die direkte Portangabe, da SRV dort nicht durchgängig unterstützt wird.
Bei klassischen Source‑Engine‑Titeln wie CS2 oder Garry’s Mod spielt DNS eine kleinere Rolle als bei Minecraft. Spieler verbinden sich meist über IP und Port direkt oder über die Steam‑Serverliste, ein eigener SRV‑Mechanismus wie bei Minecraft existiert hier nicht. Ein A‑Record auf eine Subdomain wie gmod.beispiel.de erleichtert zwar das Merken der Adresse, ersetzt aber nicht die Portangabe in der Verbindungszeile.
FiveM nimmt, wie im Abschnitt zuvor beschrieben, eine Zwischenposition ein: kein natives SRV‑Port‑Hiding, dafür aber die Möglichkeit, über Subdomain‑A‑Records und serverseitige Konfiguration wie sv_listingHostOverride eine ähnliche Nutzerfreundlichkeit zu erreichen. Wer mehrere Spiele parallel betreibt, tut gut daran, für jedes Spiel eine eigene, klar benannte Subdomain zu verwenden, etwa mc., fivem. oder gmod. vor der eigentlichen Domain, statt alles über denselben Hostnamen zu mischen.
DNS ist ein beliebtes Ziel für Angriffe, weil eine Störung der Namensauflösung den gesamten Spielbetrieb lahmlegt, selbst wenn der eigentliche Gameserver tadellos läuft. Zwei Angriffsmuster treten in der Praxis am häufigsten auf: direkte Floods gegen die eigenen Name‑Server und sogenannte DNS‑Amplification‑Angriffe, bei denen Angreifer DNS‑Server missbrauchen, um Traffic auf ein fremdes Ziel umzulenken.
Für Gameserver‑Betreiber zählen hier vor allem organisatorische Maßnahmen. Nutzen Sie, wenn möglich, mehrere unabhängige Name‑Server in unterschiedlichen Netzen, damit ein Angriff auf einen Server nicht die gesamte Erreichbarkeit zerstört, eine Empfehlung, die auch die ICANN SSAC für kritische Zonen ausspricht. Verlassen Sie sich außerdem nicht allein auf DNS‑Schutz, sondern achten Sie darauf, dass auch die Infrastruktur dahinter, also der eigentliche Gameserver und seine Netzanbindung, über einen eingebundenen DDoS‑Schutz verfügt.
Ein durchdachtes Setup trennt zudem die öffentlich bekannte Domain von internen Verwaltungsadressen. Wer das Control‑Panel oder SSH‑Zugänge über dieselbe, öffentlich beworbene Domain erreichbar macht wie den Spielserver, vergrößert unnötig die Angriffsfläche. Eine separate, nicht beworbene Subdomain für Administrationszwecke reduziert dieses Risiko spürbar, ohne zusätzlichen Konfigurationsaufwand zu verursachen.
Nicht jeder Gameserver läuft auf einer festen, öffentlichen IP, gerade bei Eigenbetrieb zu Hause oder hinter wechselnden Providern ändert sich die Adresse gelegentlich. Genau für diesen Fall existiert Dynamic DNS: Ein kleiner Client auf dem Server oder Router meldet bei jeder IP‑Änderung automatisch den neuen Wert an den DNS‑Anbieter, sodass der A‑Record ohne manuellen Eingriff aktuell bleibt.
Für Minecraft‑ oder FiveM‑Server, die hinter einer wechselnden Heimleitung betrieben werden, ist eine niedrige TTL hier besonders wichtig, oft deutlich unter den sonst üblichen Werten, damit Spieler nach einem IP‑Wechsel nicht minutenlang eine veraltete Adresse aus dem Cache ihres Resolvers erhalten. Der SRV‑Record selbst muss bei einer IP‑Änderung nicht angepasst werden, solange er weiterhin auf denselben Hostnamen zeigt, nur der dahinterliegende A‑Record ändert sich.
Wer dauerhaft stabilen Betrieb ohne das Risiko wechselnder IPs möchte, kommt um einen gemieteten Server mit fester Adresse kaum herum. Das erspart nicht nur die Dynamic‑DNS‑Konfiguration, sondern auch die kurzen Verbindungsausfälle, die bei jedem IP‑Wechsel entstehen können, selbst mit niedriger TTL.
DNS‑Latenz betrifft ausschließlich den Moment des Verbindungsaufbaus, also die Zeit, bis der Client die IP‑Adresse hinter Ihrer Domain kennt. Danach läuft der eigentliche Spielverkehr direkt zwischen Client und Server, ohne weitere DNS‑Abfragen, solange die Verbindung bestehen bleibt. Eine spürbar hohe DNS‑Auflösungszeit macht sich also vor allem beim ersten Verbindungsversuch oder bei einem Reconnect bemerkbar, nicht während des laufenden Spiels.
Entscheidend für kurze Auflösungszeiten ist in erster Linie eine stabile, gut erreichbare Infrastruktur der eigenen Name‑Server, kombiniert mit einer sinnvollen TTL. Eine zu niedrige TTL im Dauerbetrieb erzwingt unnötig häufige Neuabfragen und erhöht damit die Grundlast auf Ihre DNS‑Infrastruktur, während eine zu hohe TTL im Ernstfall einer Migration für unnötig lange Umstellungszeiten sorgt. Ein Mittelweg, etwa einige Stunden im Normalbetrieb und eine kurzfristige Absenkung vor geplanten Änderungen, deckt die meisten Fälle sauber ab.
Weit wichtiger für das tatsächliche Spielgefühl ist ohnehin die Netzwerklatenz zwischen Spieler und Server während des laufenden Betriebs, nicht die einmalige DNS‑Auflösung. Ein Server mit guter Anbindung und kurzen Wegen zu den Spielern bringt hier spürbar mehr als jede DNS‑Feinjustierung.
Caching sorgt dafür, dass nicht jede einzelne Verbindungsanfrage eine vollständige DNS‑Abfrage auslöst. Resolver auf Client‑Seite, beim Internetanbieter und teils auch im Spiel selbst speichern Antworten für die Dauer der TTL zwischen und sparen sich damit wiederholte Anfragen an Ihre Name‑Server.
Für den Gameserver‑Betrieb bedeutet das: Die TTL, die Sie setzen, bestimmt direkt, wie schnell sich eine Änderung bei den Spielern durchsetzt. Ein Eintrag mit 24 Stunden TTL bleibt im schlimmsten Fall einen ganzen Tag lang bei manchen Resolvern zwischengespeichert, selbst wenn Sie die IP längst geändert haben. Genau deshalb gehört das Senken der TTL vor jeder geplanten Migration zu den wichtigsten Routineschritten, die in den vorherigen Abschnitten bereits als Wartungscheckliste beschrieben wurden.
Ein zu aggressives Caching kann zudem zu scheinbar widersprüchlichen Fehlerberichten in der Community führen: Manche Spieler verbinden sich bereits zur neuen Adresse, während andere noch den alten, gecachten Wert nutzen. Wer das weiß, kann Supportanfragen während einer Migration deutlich gelassener einordnen, statt von einem generellen DNS‑Fehler auszugehen.
Der mit Abstand häufigste Fehler, den wir bei Supportanfragen rund um DNS sehen, ist ein falsch gesetztes SRV‑Target, meist durch einen fehlenden Punkt am Ende des Hostnamens oder eine falsch getippte Subdomain. Beide Fehler sehen auf den ersten Blick harmlos aus, führen aber dazu, dass der komplette Eintrag ins Leere läuft.
Unsere Empfehlung: Testen Sie jede DNS‑Änderung in einem festen Wartungsfenster, mit vorab gesenkter TTL, und prüfen Sie die Auflösung aktiv mit dig, bevor Sie die Domain öffentlich bewerben. Diese kleine Disziplin erspart Ihnen und Ihrer Community die meisten bösen Überraschungen.
— Erik
Ein sauber konfigurierter DNS‑Eintrag nützt wenig, wenn die Server‑Infrastruktur dahinter wackelt. Wir bieten Gameserver für Minecraft, FiveM, Garry’s Mod und weitere Titel sowie VPS‑Lösungen an, die sich auch als Reverse‑Proxy‑Host eignen, jeweils mit DDoS‑Schutz und deutschem Standort.
Wer bei der Einrichtung von A‑ oder SRV‑Einträgen, Port‑Mapping oder DNS‑Delegation unsicher ist, kann sich jederzeit direkt an unseren Support wenden, statt stundenlang selbst zu testen.
Jeder Gameserver braucht mindestens einen A‑ oder AAAA‑Record, der die Domain auf die Server‑IP zeigt. Minecraft profitiert zusätzlich von einem SRV‑Record zum Verbergen des Ports, während FiveM meist mit einer Subdomain und einem einfachen A‑Record auskommt.
Ein SRV‑Record scheitert fast immer an einem fehlenden oder fehlerhaften Target: Laut Minecraft Wiki braucht das Target im SRV‑Record zwingend einen eigenen A‑ oder CNAME‑Eintrag. Häufige Ursachen sind ein fehlender Punkt am Ende des Hostnamens oder ein Tippfehler in der Subdomain.
FiveM unterstützt kein natives SRV‑basiertes Port‑Hiding wie Minecraft, wie die Cfx-Dokumentation beschreibt. Üblich sind stattdessen eine eigene Subdomain mit A‑Record oder ein Reverse‑Proxy in Kombination mit der Einstellung sv_listingHostOverride.
Vor geplanten Migrationen empfiehlt sich eine deutlich gesenkte TTL, etwa im Bereich von wenigen Minuten, damit die Resolver der Spieler die neue IP zügig übernehmen. Nach erfolgreicher Umstellung und einer Beobachtungsphase lässt sich die TTL wieder auf den gewohnten, höheren Wert anheben.
Unsere Minecraft‑Server starten bei 5,57 € pro Monat, FiveM‑Hosting bei 6,14 € pro Monat. Die passende Domain lässt sich bereits ab 0,99 € pro Monat registrieren.