Without knowing all records and the domain name it’s more like guessing than knowing.
But I’m trying to explain how to setup records correctly.
First of all creating SRV records for the filetransfer/query service isn’t needed nor supported as far as I know and doesn’t make sense.
I also wonder why would you use a lower priority on the filetransfer port?
The priority is mostly used for similar (multiple) services which are used as backup services for example.
The service with the lowest priority value always has the highest priority.
If you would have 2 TeamSpeak servers running, one as backup server, it would make sense to use the priority.
But these record are wrong anyway…
Keep in mind all records matter.
The base record
All of your SRV records will use your domain name as target.
By definition this target record requires to be a valid A(AAA) record.
example.com. IN A 12.34.56.78
Any requests pointing to example.com will be resolved with 12.34.56.78.
As long as all the required ports are opened up, clients can now connect to your TeamSpeak using example.com as long as your TeamSpeak server is using the default port 9987.
Using a different port for your TeamSpeak server will end up with a connection failure.
The reason for this is only your IP address is known and be resolved but not the port - if it’s not the default port.
Service Resource Records
Let’s take a look at the SRV record(s) using _ts3 as service type.
_ts3._udp.example.com. IN SRV 0 5 9987 example.com.
This defined record will bascially tell your TeamSpeak client the port for the UDP connection is 9987 and the target is example.com. After resolving example.com the client finished the lookup and connects to 12.34.56.78:9987.
Regarding to what I’ve said above about the default TeamSpeak server port this record wouldn’t make much sense and will slighty increase your connection time.
Conclusion:
If you don’t necessary need SRV records and have 1 TeamSpeak server running only use A(AAA) records instead for a faster connection to the server without the need to resolve multiple records.
example.com. IN A 12.34.56.78
ts.example.com. IN A 12.34.56.78
ts3.example.com. IN A 12.34.56.78
If you somehow need to change the target IP address sometimes without willing to change all records always (which might also has a bad impact for clients using a longer TTL for the records) than using SRV records makes sense.
example.com. IN A 12.34.56.78
_ts3._udp.example.com. IN SRV 0 5 9987 example.com.
_ts3._udp.ts.example.com. IN SRV 0 5 9987 example.com.
_ts3._udp.ts3.example.com. IN SRV 0 5 9987 example.com.
As you can see all 3 SRV records have the target example.com.
Clients can connect to the TeamSpeak server using the domain names example.com, ts.example.com and ts3.example.com.
The hostnames for the SRV records example.com, ts.example.com and ts3.example.com don’t require an A(AAA) with the hostname. Just the target has to be a valid A(AAA) record - per definition.
Adding or removing SRV should be self explanatory…
Let’s assume you have a dynamic IP address which changes over time.
It’s only needed to edit your existing A(AAA) record since it is the target of all records.
Even after editing the record clients may not be able to connect to the server.
The reason for this is DNS resource caching.
To get rid of this issue you have to set a low value for time to live (TTL).
The value defines how long records being stored in the DNS cache.
PS.: If you wan’t to use the TCP based _tsdns service for your SRV records, take look at the documention, please. Doing so, please remember the list of required/optional ports to open the port 41144 TCP on your server.
)
