DNS TXT/SRV Record

[theWeird]

Situation:
I am running different servers for different jobs of hosting.
One of them is dedicated for the websites. So the A records for domains and subdomain www are pointing to this.
Another Server is for 'special applications' like Jabber or TS³.
At the moment my Clanmembers have to access the TS³ server using a subdomain ts.domain.com.

For Jabber it is possible to redirect client calls to another host than the one defined in A record using a TXT record.
It would be great to have such a redirect by DNS record for TS³, too.

Regards from Germany

[ScP]

Please check out TSDNS which is included in our latest pre-release server...

http://ftp.4players.de/pub/hosted/ts...leases/server/

#############################################
                    TSDNS
#############################################

TS DNS is a system that allows TeamSpeak users to connect to servers that are
running on arbitrary ports without having to specify the port. The "TSDNS name"
is used by the system to determine IP and Port. It can be compared to some
extent to the "Virtual Host" system of Apache in its purpose, though the
technical aspects are very much different.

Motivation
----------
Say you own a server running on the IP 1.2.3.4 and Port 4321. Telling people
you want to join your server to join "1.2.3.4:4321" or (using regular DNS)
"myclanrocks.net:4321" works, but the port there is an extra source of
confusion to inexperienced users. It would be nice if you could just tell
people to join "myclanrocks.net" (as if your TS server were running on the
default port).

How it works
------------
A TSDNS server is a very simple network service that uses TCP/IP to listen on
port 41144 and knows a list of (query,result) pairs. Upon connecting to the
TSDNS server you must submit your query and the TSDNS server will answer you
with the result, if it has this query in his list, or with "404" if no such
query is known to it. The result is supposed to be either an IP (which assumes
a port of 9987) or an IP:Port pair. Instead of a number as port the special
string "$PORT" is also allowed, which results in any port specified on the
client side to be used.

Whenever a TeamSpeak Client tries to connect to a server using a hostname,
it will try to connect to up to three possible TSDNS servers to try and
retrieve a (IP, Port) pair using the hostname as string that the TSDNS server
is queried with.

Illustration:
hostname=voice.teamspeak.com
TSDNS Server asked queried are:
- voice.teamspeak.com (with query = voice.teamspeak.com)
- teamspeak.com       (with query = voice.teamspeak.com)
- com                 (with query = voice.teamspeak.com)

Second Example (with longer hostname)
hostname=i.will.roxx.your.soxs.myclan.com
- soxs.myclan.com     (with query = i.will.roxx.your.soxs.myclan.com)
- myclan.com          (with query = i.will.roxx.your.soxs.myclan.com)
- com                 (with query = i.will.roxx.your.soxs.myclan.com)

Third Example (with short hostname)
hostname=myclanrocks.net
- myclanrocks.net     (with query = myclanrocks.net)
- net                 (with query = myclanrocks.net)

If any of these succeed to retrieve an answer from a TSDNS server the one to
answer first is used to connect. If all of the above TSDNS server queries fail
(usually due to no TSDNS servers running on the (up to) three hosts), the
TeamSpeak Client will fall back to a regular DNS resolve of the hostname.

[theWeird]

I already heard about TSDNS.
But it has to run as service on the web host, hasn't it?
So it breaks a concept of consequent seperating services to different servers and is no option for me.

[ScP]

The TSDNS server does not need to run on the same physical machine as your TeamSpeak 3 Server instance and also not on your webserver. You could set it up on ts.domain.com and create TSDNS names like server1.ts.domain.com, etc.

The TeamSpeak 3 Client will try to resolve a TSDNS name by performing a query on the Top-Level-Domain, Second-Level-Domain and Third-Level-Domain of a specified hostname. Here's an example with three different hosts:

Host A: teamspeak.com
Host B: voiceserver1.teamspeak.com (1.2.3.4)
Host C: voiceserver2.teamspeak.com (5.6.7.8)

Let's assume a client tries to connect to my.ts3server.voiceserver1.teamspeak.com. The client will perform simultaneous TSDNS queries to voice.teamspeak.com AND teamspeak.com. Regardless on which of these two hosts your TSDNS server is running, the client will eventually get a reply and could even connect to voiceserver2.teamspeak.com:1337 when your TSDNS config looks like this:

my.ts3server.voiceserver1.teamspeak.com=5.6.7.8:1337

So you don't really need to run a TSDNS server on teamspeak.com in this example, but of course it would be the easiest solution.

Anyway... Here's some example content from a client log while trying to connect to my server on voice.planetteamspeak.com:

03.05.2011 23:14:04        Info    TSDNS found at "planetteamspeak.com" and queried successfully. Result: 85.25.137.75:9987
03.05.2011 23:14:05        Info    No TSDNS found at "voice.planetteamspeak.com"

As you can see, the TeamSpeak 3 Client tried to query TSDNS servers on both planetteamspeak.com and voice.planetteamspeak.com, but got the reply from planetteamspeak.com first. So you're even getting some kind of reduncance here - depending on your setup.

[chibisuke]

- TSDNS is now added to to the package. We recommend hosters to take a look at this, as addresses like "myclan.hoster.com" are much easier to remember than "hoster.com:46233"

Using SRV DNS Records would have been to easy right?

I mean its much easier to have something like

_teamspeak._udp.mysrv.tshosts.com. 3600 IN SRV 10 0 9987 host1.tshost.com.

In your DNS. and when you rebalacing vhosts to other servers, to update the DNS record instead of heaving to run an additional deamon that causes additional resource usage, on the ts server itself.

(http://tools.ietf.org/html/rfc2782)

I mean that would have even allowed users to bring their own domain and just point it to the TS Server.
So how would I run a ts server under a domain pointing to a different server then the DNS Server? Maybe even without the ability to run any software on the host the Domain points to?

sorry, but this concept is only thought half to an end, the other half got implemented on the fly without thinking about it. Same as quite a few other features in ts3.

[Peter]

Using SRV DNS Records would have been to easy right?

Support for SRV records is a separate item on our TODO list, but it is planned for post 3.0 release. TSDNS is something different (despite some similarities) from SRV records.

[chibisuke]

then there is no point in TSDNS, because all "features" tsdns currently offers according to its documentation can be implemented in normal srv records. Except of course that the connection tries cause additional network traffic, and log warning in the firewall logs of my server.

If that would be one of my company's servers our IDS would already have gone nuts, with hundreds of clients trying to connect on a closed port.

Sorry I really don't get what you wanted to try with that stuff?

btw. where is the point in trying to resolv "com." to find a tsdns server? I mean no TLD will (hopefully) ever resolve to any IP address.

[ScP]

then there is no point in TSDNS, because all "features" tsdns currently offers according to its documentation can be implemented in normal srv records. Except of course that the connection tries cause additional network traffic, and log warning in the firewall logs of my server.

So basically, what you're saying is that there's no point to any instancing or virtual host concept in any application out there (i.e. Apache, MSSQL, etc). Sounds weird to me...



Here's a fact you might not be aware of... Most admins of TeamSpeak 3 Servers do not have access to the advanced configuration of their domains since the DNS servers are maintained by their provider or simply do not know how SRV records work.

With TSDNS we provide an easy to use way for the average joe to use custom domain names to let people connect to a specific TeamSpeak 3 Server. We know that SRV records are a very nice thing and as Peter already stated, this is on the devs TODO list, but first things first...

Anyway... we're getting a lot of positive feedback for the TSDNS service so I cannot agree with your opinion that there's no use to it.

[chibisuke]

For apache and similar stuff the concept is completely different and not compareable.

As you might already know, all virtual hosts of apache (or any other decent webserver) run on the same port, and the server and protocol themself handle the switch to which virtual host the requesst belong. This is a totaly different concept that makes especialy sense in relation to firewall restrictions, proxy ect.

MSSQL (or SQL Server as its called nowadays) as you might know doesn't have any virtual host concent at all, they use a named instance based concept, and a totaly different type of communication (if you using instance names you need to connect via named pipes).

But for teamspeak its a different thing. You NEED to assign a different port to each virtual host, so this method doesn't apply here, and for this case (multiple server running on different port, multiple servers running on different hosts on different ports) SVR records were designed.

So please don't compare apples and oranges.

Not knowing about service records is not an excuse as knowlege on this topic is widely available on the internet (first hit on google is wikipedia I know decribing them in detail, as well as rfc2782 explaining everything even more detailed).

The point is, while you can do some stuff with tsdns its use is rather limited. You're still restricted to domains that have an A record pointing to your TSDNS Server. sure, now you can do domains like myclan.yourprovider.com .... but how would I do myclan.com when myclan.com already points to a webserver where I don't have any possibility of running tsdns?

Also tsdns requires the hoster of the tsdns server (usualy your teamspeak hoster) to configure the server for you.

So even if I'd point a ts.myclan.com to the tsdns server of yourhoster.com it would still require the hoster to change its config for it to work, which lets ppl end up giving out ts.myclan.com:12353 again.
When using srv records no config on the ts-hosters side is required, I'd just point myclan.com IN SRV to the ts server and everything is fine.

And I think there are more ppl out there that would love to use myclan.com and got the ability to modify the dns records of their domain then there are ts hosting providers that don't have the ability to create srv records.

I mean nearly every hoster that offers virtual or dedicated servers offers plesk or similar stuff, that allows one to easily manage your own primary nameserver, and I think I'd have a hard time finding a dedicated server hoster providing domains without the ability to run the primary nameserver myself. Even most normal webhosters already offer advanced DNS config for their hostings.

So while the original idea of having virtual host names is not bad at all, the implementation lacks. And the fact that ppl use the implementation is mostly originated because of the fact that there is no alternative then using it. If you would have implemented srv records first, ppl would use that too.

PS: apache style virtual hosting (all ts servers running on one port and the client transmitting the hostname of the virtual host) would have been a possible considderation too.

[Stefan1200]

@ chibisuke: But what is wrong if in future both (SRV DNS and TSDNS) is possible (maybe TS3 version 3.1 / 3.2). So everyone can use what they like.

[Peter]

Good things about tsdns are:
- easy to administer and understand. Many admins are not in their comfort zone when fiddeling around with DNS records
- easily extendible. Say I own a server on "rocks.com" domain. Writing a simple php script that let's any clan register "myclan.rocks.com" is simple, even with thousands of clans registering.
- free of additional cost. You are not charged anything extra for any TSDNS entries.

[jumuro]

TSDNS be! )))
With SRV-records clear, but TSDNS has its pluses and very comfortable.

tsdns = deployment time, the load host, the settings routing.

"deployment time" ~1.5 minutes
"the load host" ~0.1 CPU ~0.1 MEM
"the settings routing" ~1.5 minutes

[chibisuke]

SRV Record:

deployment time (for hoster) = 0 seconds
load on host = zero

the hoster can just tell his customers to put up a srv record and done... no devlopment work for web panels on the hosters side to allow customers to set their DNS. No support work for users asking to have specific DNS entries added ect.

- easy to administer and understand. Many admins are not in their comfort zone when fiddeling around with DNS records
- easily extendible. Say I own a server on "rocks.com" domain. Writing a simple php script that let's any clan register "myclan.rocks.com" is simple, even with thousands of clans registering.
- free of additional cost. You are not charged anything extra for any TSDNS entries.

- maybe easy to understand, but still not foolprove.
- entensible - maybe.... now if I add a srv record to a zone file or change the tsdns config file does make some difference, because the zone file can be modified REMOTEly (dynamic zone updates) and ON THE FLY. And depending on the nameserver the backend to use is not fixed at all. I can use a mysql database holding my zone, or an LDAP tree. But if you got multiple webservers remotly modifying a tsdns config file gives you some chellenges.
- running my own DNS server. Not changed for running DNS Server, not changed for any records, not changed for anything except the ~3€ per year I pay per domain. (depending on domain).

- tsdns = yet another service running, that can crash. Yet another system that needs to be monitored. Yet another service that might pose a potential remote security risk to the system. Yet another config that needs to be maintained. and not even as flexible as srv records. Should I continue?

- dns server - already running. Nescessary for the domains anyway,so: no addition monitoring needed. No additional security risk created. No additional config file to be maintained (as the zone file has to be maintained anyway) and no additional load on the system.



btw.: when already at it. - where is the point in --update function of tsdns? - SIGHUP? anyone?

[benv666]

+1 for the SRV records.

The first thing I thought when I saw "TSDNS" was "Oh no, they wouldn't ... another security hole waiting to happen". But yes, they would.
I think chibisuke sums it up quite nicely.

[olewales]

Hello.
I registered to the forums only to express my disappointment on how a good idea was ruined by its implementation.
The whole idea behind TSDNS is to make it easier to use teamspeak on ports other than default and the reason for this is running multiple servers on the same ip address, possibly independent and managed by different people. Meanwhile TSDNS server by design has to run on a fixed port and one instance must support all ts3 servers on specific IP. DNS hierarchy doesn't help at all because higher level domain will be usually pointing on www server, which, in many if not most cases will be shared hosting with no possibility to run TSDNS on it. In fact if one person sets up tsdns on shared hosting he could easily manipulate clients into connecting to his own ts3 server.
These problems could be mitigated by using TXT/SRV DNS records. Every domain could point to different port on the same ip address. It would even reduce number of connections to server. All data needed to determine location of voice server would come from dns.
Please think about switching to this simple, elegant and already tested (SIP, XMPP) solution while its still possible.