With Client 3.1.0 we've changed the way the client performs server address resolution when connecting.
Previous clients attempted to connect to possible TSDNS servers on their own in the process of resolving the given address.
This is going to change and in the future the client will no longer attempt to connect to TSDNS servers unless an SRV record _tsdns._tcp.example.com (where example.com is the first subdomain of the server that a connection is attempted to which is not listed in https://publicsuffix.org/list/public_suffix_list.dat - so example.co.uk or example.com for a.b.c.d.example.co.uk and a.b.c.d.example.com respectively) is present and pointing to a TSDNS server.
That means, that if you're not using SRV records already and are currently relying on TSDNS to resolve names to IP addresses and ports, clients will no longer be able to connect to these servers in the future.
To fix this issue and allow clients to connect to your servers again you'll have to create an SRV record as follows:
_tsdns._tcp.example.com 86400 IN SRV 5 0 41144 example.com example.com 86400 IN A 1.2.3.4
Where 86400 is the TTL and example.com is the domain on which the TSDNS server is running. Please note that this has to be a DNS name which has at least one A or AAAA record.
Alternatively you can remove TSDNS altogether and use _ts3._udp SRV records for every virtual server instead.
It has also come to our attention that a few TSDNS servers out there are returning domain names instead of IP addresses - This was never supported, and will no longer work starting with client 3.1.0. TSDNS results were always intended to be a final step in name resolution and hence need to be IP addresses.
Details and Example
Until Client 3.1.0
In previous versions of the TeamSpeak 3 Client (up to 3.0.19.4 inclusive) when attempting a connection to a server at four.three.two.one.example.com the client did the following:
Since Client 3.0.8:
Resolve _ts3._udp.four.three.two.one.example.com IN SRV Resolve _tsdns._tcp.two.one.example.com IN SRV Resolve _tsdns._tcp.one.example.com IN SRV Resolve _tsdns._tcp.example.com IN SRV
always
Resolve four.three.two.one.example.com IN A Attempt to connect to two.one.example.com:41144 Attempt to connect to one.example.com:41144 Attempt to connect to example.com:41144
The connection attempts to 41144 are TSDNS resolution attempts. The first connection attempt that is accepted and responds is used as a result
Since Client 3.1.0
Starting with the 3.1.0 release of the client, we deprecated the connection attempts to port 41144, but instead rely on SRV records to tell the client on where to find a TSDNS server. If none is specified, future client versions will not attempt to connect to TSDNS servers and won't ask them for an IP address for the address we're attempting to connect to.
So the client will do the following in above scenario:
Resolve _ts3._udp.four.three.two.one.example.com IN SRV Resolve _tsdns.tcp.example.com IN SRV Resolve four.three.two.one.example.com IN AAAA Resolve four.three.two.one.example.com IN A
In order to enable a graceful transition for our hosters and users, the 3.1.0 release of the client will still perform the following connection attempts if the _tsdns._tcp SRV resolve failed or returned no data:
Attempt to connect to one.example.com:41144 Attempt to connect to example.com:41144
However a warning will be raised and printed to the log, informing users that the server they're connecting to is using a deprecated setup and will no longer work with the next client release.
With a future Client release
It behaves like 3.1.0 does with the exception that unless the _tsdns._tcp SRV resolve returns a result, no TSDNS server is contacted and the _ts3._udp SRV, AAAA or A record resolves are used to connect.
Comments
0 comments
Please sign in to leave a comment.