Privacy notice This website only uses technically necessary cookies. Statistics, marketing and external services are not loaded without JavaScript. Learn more in our Privacy Policy.
Back to the blog
Nexthosting Guide

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.

Oct 6, 2026 4 views
DNS für Gameserver richtig einrichten: A, SRV und TXT im Überblick

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.

Nexthosting
Gameserver mit starker Infrastruktur betreiben
Nexthosting bietet leistungsstarke Gameserver in Deutschland, DDoS-Schutz, schnelle Bereitstellung und persönlichen Support für Ihre Community.
Gameserver entdecken

Inhaltsverzeichnis

A, AAAA, CNAME, SRV und TXT: Funktion, Syntax und Beispiel-Einträge

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:

  • Service und Protokoll: zum Beispiel _minecraft._tcp, vorangestellt an den Domainnamen.
  • Priority und Weight: steuern, welcher von mehreren Zielen bei Lastverteilung bevorzugt wird.
  • Port: der tatsächliche Spielport, den der SRV‑Record vor dem Spieler verbirgt.
  • Target: der Hostname, auf den der SRV‑Record letztlich zeigt, und genau hier liegt die Falle.

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.

Minecraft: SRV korrekt einrichten und mit dig prüfen

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:

  1. Legen Sie zuerst einen A‑Record für die Zieldomain an, etwa mc.beispiel.de. IN A 203.0.113.10.
  2. Erstellen Sie anschließend den SRV‑Record: _minecraft._tcp.beispiel.de. IN SRV 0 5 25566 mc.beispiel.de.
  3. Prüfen Sie beide Einträge mit 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 und andere Engines: warum SRV nicht immer reicht

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.

Betriebsregeln: NS-Konsistenz, Redundanz und TTL-Strategie

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:

  • Halten Sie NS‑Einträge bei Parent und Child synchron und aktualisieren Sie den Registrar zeitnah bei jedem Wechsel.
  • Betreiben Sie, wenn möglich, Name‑Server in unterschiedlichen Netzen oder AS‑Blöcken, damit ein Ausfall nicht gleich die ganze Auflösung lahmlegt.
  • Senken Sie die TTL vor geplanten Migrationen, führen Sie die Änderung durch, beobachten Sie die Stabilität und erhöhen Sie die TTL erst danach wieder.
  • DNSSEC und TLSA‑Einträge erhöhen die Sicherheit, bringen aber zusätzliche Komplexität mit; führen Sie sie nur ein, wenn ein konkreter Bedarf besteht.

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.

Schnelle Fehlerbehebung: Checkliste mit Prüfbefehlen

Wenn Spieler sich plötzlich nicht mehr verbinden können, hilft Panik nicht, sondern eine feste Reihenfolge an Prüfungen.

  1. Prüfen Sie zuerst die DNS‑Auflösung mit dig A domain.de und, bei Minecraft, zusätzlich mit dig SRV _minecraft._tcp.domain.de.
  2. Testen Sie die Porterreichbarkeit mit Werkzeugen wie nc oder tcptraceroute und kontrollieren Sie Firewall‑ und NAT‑Regeln.
  3. Kontrollieren Sie die Serverkonfiguration: bei FiveM die server.cfg, bei Minecraft die server.properties.
  4. Prüfen Sie die Sichtbarkeit in der Master‑Liste, etwa über den info.json‑Endpunkt bei FiveM oder den klassischen Server‑Ping bei Minecraft.
  5. Liegt das Problem an der Delegation selbst, hilft nur der Registrar oder Parent‑NS‑Betreiber weiter, etwa bei einem Glue‑ oder NS‑Mismatch.

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.

Grundlagen zum DNS-Aufbau speziell für Gameserver

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.

Unterschiede in DNS-Konfigurationen zwischen Gametypen

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.

Absicherung der DNS-Server gegen DDoS-Angriffe

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.

Dynamic DNS bei wechselnder IP-Adresse

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 optimieren für eine bessere Spielerfahrung

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.

Best Practices für DNS-Caching bei Spieleverbindungen

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 hours 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.

Typische Fehlerfälle und Vorsichtsmaßnahmen aus der Praxis

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

Wie Nexthosting beim DNS-Setup unterstützen kann

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.

FAQ

Welche DNS-Einträge braucht ein Gameserver mindestens?

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.

Warum funktioniert mein SRV-Record für Minecraft nicht?

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.

Warum verbirgt DNS den Port bei meinem FiveM-Server nicht?

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.

Wie lange sollte die TTL vor einer Serverumstellung sein?

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.

Was kostet ein Gameserver mit passendem DNS-Setup bei Nexthosting?

Unsere Minecraft‑Server starten bei €5.57 per month, FiveM‑Hosting bei €6.14 per month. Die passende Domain lässt sich bereits ab €0.99 per month registrieren.

Quellen