AEONHOST / WISSEN

DNS-TTL bei einem Gameserver-Umzug berücksichtigen

Wenn sich die IP-Adresse eines Gameservers ändert, können manche Spieler noch die alte Adresse aus einem DNS-Cache erhalten. Die TTL beschreibt die maximale Cachezeit eines Resource Records in Sekunden. Ein niedrigerer TTL-Wert löscht keine bereits gespeicherten Antworten; Resolver können den alten Wert noch bis zum Ablauf der zuvor erhaltenen TTL zurückgeben. (RFC 1035, RFC 2181, Amazon Route 53: Änderungen wirken nicht sofort)

Aktualisiert am 07.10.2026

Wenn sich die IP-Adresse eines Gameservers ändert, können manche Spieler noch die alte Adresse aus einem DNS-Cache erhalten. Die TTL beschreibt die maximale Cachezeit eines Resource Records in Sekunden. Ein niedrigerer TTL-Wert löscht keine bereits gespeicherten Antworten; Resolver können den alten Wert noch bis zum Ablauf der zuvor erhaltenen TTL zurückgeben. (RFC 1035, RFC 2181, Amazon Route 53: Änderungen wirken nicht sofort)

Dieser Ablauf behandelt die A- und AAAA-Einträge einer bestehenden DNS-Zone. Er kopiert keine Welten, Plugins oder Konfigurationen und beschreibt keinen Wechsel der autoritativen Nameserver. Plane die Datenübertragung separat; der Minecraft-Hosterwechsel-Guide behandelt diesen Teil. Wenn dein Spiel zusätzlich einen SRV-Eintrag verwendet, prüfe auch dessen Ziel und Port; für Minecraft Java steht die genaue Zuordnung im SRV-Guide.

Vor dem Zeitfenster den alten Zustand erfassen

Notiere, welche DNS-Zone für den Spielnamen autoritativ ist und wo du ihre Einträge änderst. Erfasse für diesen Namen mindestens den A-Wert, einen vorhandenen AAAA-Wert und den TTL jedes betroffenen Eintrags. Bei Minecraft Java gehören auch _minecraft._tcp-SRV-Eintrag, Zielhost und Port dazu. Zeigt das SRV-Ziel auf den umziehenden Server, erfasse zusätzlich dessen A- oder AAAA-Adresse und TTL in der Zone, die für diesen Zielnamen autoritativ ist. Einträge in einer Zone, die für den jeweiligen Namen nicht autoritativ ist, ändern die Antworten für Spieler nicht.

Mit dig kannst du die Antwort deines aktuell konfigurierten DNS-Resolvers samt TTL anzeigen. Die zweite Spalte der Antwort ist der TTL in Sekunden, den dieser Resolver noch ausliefert. Ein Abfrageergebnis aus einem Cache ist nicht zwingend der unveränderte TTL-Wert in deiner Anbieteroberfläche. (BIND 9: dig)

dig +noall +answer play.example.com A
dig +noall +answer play.example.com AAAA
dig +noall +answer _minecraft._tcp.play.example.com SRV

Ein Antwortbeispiel mit reservierten Dokumentationswerten:

play.example.com. 3600 IN A     192.0.2.40
play.example.com. 3600 IN AAAA  2001:db8::40
_minecraft._tcp.play.example.com. 3600 IN SRV 0 0 25570 node.example.net.

example.com und example.net sowie die Adressbereiche 192.0.2.0/24 und 2001:db8::/32 sind für Dokumentation reserviert. Ersetze sie für deine Abfragen durch deinen eigenen Namen. (IANA: Special-Use Domain Names, IANA: Example Domains, IANA: IPv4-Adressraum, IANA: IPv6-Sonderbereiche)

TTL vor der Adressänderung senken

Wenn der Anbieter es zulässt, senke den TTL der betroffenen Einträge vor dem geplanten Umstellungsfenster. Prüfe an allen zuständigen autoritativen Nameservern, dass der niedrigere Wert veröffentlicht ist; erst dann beginnt die Wartezeit. Beispiel: Steht der alte TTL auf 3600 Sekunden und du setzt ihn auf 300, warte ab dieser Veröffentlichung mindestens die vollen 3600 Sekunden, bevor du die Adresse änderst. So können Resolver, die unmittelbar vor der Änderung die alte Antwort erhalten haben, deren ursprüngliche Cachezeit auslaufen lassen. Die Zahlen sind ein Rechenbeispiel; unterstützte Werte und sinnvolle Regelwerte hängen von deinem DNS-Anbieter ab.

Wenn du den TTL erst im Moment der Adressänderung senkst, wird ein bereits gecachter Datensatz dadurch nicht kürzer. Amazon dokumentiert diesen Effekt ausdrücklich für Route 53. Die TTL-Werte von A, AAAA und SRV können getrennt voneinander laufen; prüfe jeden Eintrag, den Spieler für die Verbindung benötigen. (Amazon Route 53: Änderungen wirken nicht sofort)

Adresse im Wartungsfenster umstellen

Bereite den neuen Endpunkt vor und prüfe ihn direkt, bevor du die öffentliche Adresse änderst. Im Wartungsfenster aktualisierst du die betroffenen Einträge in ihren autoritativen Zonen: A für IPv4, AAAA für IPv6 und gegebenenfalls SRV für Zielhost oder Spielport. Bei Minecraft Java liefert die A- oder AAAA-Adresse des SRV-Zielhosts den Endpunkt; ändere diese Adresse, wenn der Zielhost auf den neuen Server zeigen soll. Passe den SRV-Eintrag an, wenn Zielhost oder Spielport wechseln (RFC 2782). Lass keine veraltete AAAA-Adresse stehen, wenn der neue Server darüber nicht erreichbar ist. Ein SRV-Eintrag, der noch auf den alten Zielhost oder Port zeigt, bleibt ebenfalls ein alter Verbindungspfad.

DNS kann alte und neue Antworten während einer Übergangszeit nebeneinander liefern, weil unterschiedliche Resolver ihre Caches zu unterschiedlichen Zeitpunkten gefüllt haben. Plane mit einem Wartungsfenster, nicht mit einer minutengenauen Umschaltung. Falls der alte Endpunkt noch verfügbar bleibt, halte ihn in einem Zustand, der keine zweite frei bespielbare Welt erzeugt. Zwei Instanzen mit getrennten Schreibständen erschweren einen sicheren Rückweg.

Eine Änderung an A, AAAA oder SRV in derselben Zone ist kein Wechsel der Nameserver. Falls du zusätzlich die autoritativen Nameserver wechselst, plane Delegation und eine allfällige DNSSEC-Konfiguration separat nach der Anleitung deines DNS-Anbieters. Eine Änderung der A-Record-TTL steuert nicht die Cachezeit der Nameserver-Delegation. (Amazon Route 53: Änderungen wirken nicht sofort)

Neue Antworten und TTL prüfen

Frage die betroffenen Namen erneut ab und vergleiche Typ und Ziel mit deinem Änderungsplan:

dig +noall +answer play.example.com A
dig +noall +answer play.example.com AAAA
dig +noall +answer _minecraft._tcp.play.example.com SRV

Bei erfolgreicher Veröffentlichung zeigen die Antworten die neuen Adressen beziehungsweise den neuen SRV-Zielhost und Port. Prüfe zusätzlich über die autoritativen Nameserver, die dein DNS-Anbieter für die Zone nennt. Wiederhole die Abfrage später aus einem zweiten Netz oder mit einem anderen Resolver, wenn Spieler weiterhin die alte Adresse erhalten. Eine DNS-Antwort bestätigt nicht, dass der neue Spielserver läuft oder der Port erreichbar ist; teste den Beitritt mit einem echten Spielclient.

Wenn ein SRV-Name zuvor nicht existierte, kann ein Resolver auch eine negative Antwort zwischenspeichern. Bei NXDOMAIN oder einer Antwort ohne passenden Eintrag kann die negative Cachezeit aus dem SOA-Datensatz stammen. Darum kann ein eben angelegter SRV-Eintrag für manche Abfragen noch fehlen, obwohl der autoritative Datensatz inzwischen vorhanden ist. Prüfe dann auch den SOA-Abschnitt der Antwort; das ist eine andere Cachezeit als der TTL eines vorhandenen A- oder SRV-Eintrags. Mit BIND dig kannst du diesen Abschnitt gezielt ausgeben: (RFC 2308, BIND 9: dig)

dig +noall +authority _minecraft._tcp.play.example.com SRV

Nach dem Wechsel

Wenn die neuen Antworten stabil sind und der Verbindungsweg mit einem Client geprüft wurde, setze die betroffenen TTL-Werte auf den für deinen Betrieb vorgesehenen Wert zurück. Bewahre die vorherigen DNS-Werte als Rollback-Notiz auf. Ändere den TTL nicht mit dem Ziel, alte Antworten sofort zu löschen. Wenn der neue Name korrekt aufgelöst wird, eine Verbindung aber abgelehnt wird oder abläuft, prüfe Serverstatus, Spielport und Netzwerkpfad in der Anleitung zu Connection refused und Timeout.

Quellen