Vor ein paar Jahren hat Teamspeak die Software TSDNS ins Lebengerufen. War damals recht praktisch falls man als User einen Teamspeak-Server abweichend vom Standardport hatte, ihn via Subdomain auch ohne Portangabe erreichbar machen zu wollen aber beim Provider nur A-Records setzen zu dürfen.
Nun hat sich mit 3.1 eine Neuigkeit ergeben die TSDNS ad absurdum führt und nur einen wirklich kleinen Nutzen bringt.
Ausgangsposition
Ausgangsposition ist ein Teamspeak-Server mit der IP 192.0.2.2 auf Port 9990. Der soll nun so eingerichtet werden dass er via ts.example.com erreichbar sein soll. Auch soll die Portangabe im Client nicht nötig sein.
Grundlegende Funktion von TSDNS
Teamspeak selbst unterstützt SRV-Nameserver-Einträge. Nun gibt/gab es zu der Zeit einige Hoster die keine SRV-Einträge können. Als Workaround entstand dann TSDNS. Das läuft als Serverdienst und vermittelt dem Client die richtige Adresse. Als Beispiel:
- Verbunden werden soll zu ts.example.com
- Der Client prüft ob ein A-Record existiert und verbindet sich zum TSDNS-Server auf Port 41144
- Wenn das klappt übermittelt der Client dem Server den ursprünglichen Namen „ts.example.com“
- Der schaut nun ob in seiner Liste „ts.example.com“ exisitert und liefert ggf. dann die IP und Port dazu.
- Der Client nimmt diese Werte nun und verbindet sich direkt mit dem Server
Damit ist eine Verbindung auch ohne SRV-Record möglich.
Dämliche Änderung mit 3.1
Mit TS 3.1 hat nun Teamspeak beschlossen dass TSDNS-Server nur noch gesucht werden wenn für die entsprechende (Sub)Domain auch einen SRV-Eintrag für den TSDNS-Server hat. Im Klartext: Wenn nur A-Records auf den Server zeigen wird keine Verbindung mehr zustande kommen können.
Wenn ihr also keine SRV-Records setzen könnt, dann habt ihr – salopp gesagt – Pech gehabt. Entweder den A-Record direkt auf die Server-IP zeigen lassen und den Port mit angeben oder schauen dass man irgendwo einen Standardport bekommt.
Wozu noch überhaupt TSDNS?
Ich habe lange überlegen müssen wozu man überhaupt noch TSDNS nutzen soll, wenn es auch ein SRV-Record direkt auf den Server tut.
Im Wesentlichen ist mir da nur ein Punkt eingefallen:
Man kann die Server umziehen wie es einem passt und der Kunde muss die SRV-Einstellungen nicht ändern. Das erkauft man sich allerdings mit einem zentralen Server der – wenn er ausfällt – alle Namensauflösungen verhindert. Ein zusätzlicher Faktor also der die Verbindung verhindern kann.
Sinnvoller wäre also ein direkter SRV-Record auf den direkten Teamspeak-Server. Die DENIC fordert für .de-Domains mindestens 2 DNS-Server. Und selbst falls die ausfallen: Die Chancen stehen gut dass die Daten noch im Cache beim Provider liegen.
IMHO ist es durchaus zumutbar bei einem Serverwechsel die IP und den Port im Record zu ändern. Das sollte ja auch nicht alle Monate passieren. Im Idealfall natürlich gar nicht.
Besser: Direkt den SRV-Record auf den TS-Server zeigen lassen
Besser also direkt einen SRV-Record für den Teamspeak-Server setzen. Das hat neben dem fehlenden Risiko namens TSDNS nebenbei auch noch den tollen Beigeschmack von DNS-Caching z.B.
Um den SRV-Eintrag RFC-konform anzulegen geht man man wie folgt vor (als Beispiel mal lima-city (Ref-Link), weil ich den Artikel wohl öfter dort verlinken werde):
- A-Record für die Subdomain anlegen die man nutzen will mit der IP als Wert. [Screenshot]
- SRV-Record mit dem Namen „_ts3._udp.example.com“ („example.com“ ersetzt wird natürlich durch die gewünschte (Sub)Domain ersetzt)
Der Inhalt ist „GEWICHT PORT ZIEL“. Gewicht kann in der Regel 0 bleiben. Port ist im Beispiel 9990 und das Ziel die oben angelegte Subdomain. Hier also „0 9990 ts.example.com“. [Screenshot] - Das wars. Wenn jetzt
