Forum

Results 1 to 14 of 14
  1. #1
    Join Date
    August 2016
    Posts
    9

    TS name resolving issue

    Hey guys,

    I just found a bug in TeamSpeak 3.1.0.1 (Server 3.0.13.6)
    There is an issue resolving names. But first, let me explain the setup:

    888.888.888.888:9987 = Real TeamSpeak Server IP
    444.444.444.444:9987 = Another TeamSpeak server (they are also hosting a TSDNS on that IP, not assosiated with us)

    The domains DNS records are
    A @ 444.444.444.444 -> Website running here
    A ts 888.888.888.888 -> ts.domain.com


    Now whats happening:

    Code:
    2/7/2017 18:56:08	ClientUI	Info	Connect to server: ts.domain
    2/7/2017 18:56:08	ClientUI	Info	Trying to resolve ts.domain.com
    2/7/2017 18:56:08	TSDNS	Info	SRV DNS resolve unsuccessful, "_ts3._udp.ts.domain.com" Domain name not found	
    2/7/2017 18:56:08	TSDNS	Info	A/AAAA DNS resolve successful, "ts.domain.com" =(h: [IPv6] p:0), (h: 888.888.888.888 p:0)	
    2/7/2017 18:56:08	TSDNS	Info	A/AAAA DNS resolve for possible TSDNS successful, "ts.domain.com" =(h: [IPv6] p:0), (h: 888.888.888.888 p:0)	
    2/7/2017 18:56:08	TSDNS	Info	TSDNS found at [IPv6]:41144 and queried successfully. Result: (h: [IPv6] p:9987), (h: 888.888.888.888 p:9987)	
    2/7/2017 18:56:08	TSDNS	Info	A/AAAA DNS resolve for possible TSDNS successful, "domain.com" =(h: 444.444.444.444 p:0)	
    2/7/2017 18:56:08	TSDNS	Info	TSDNS found at 444.444.444.444:41144 and queried successfully. Result: (h: 444.444.444.444 p:9987)	
    2/7/2017 18:56:08	TSDNS	Info	SRV DNS resolve unsuccessful, "_tsdns._tcp.domain.com" DNS server returned answer with no data	
    2/7/2017 18:56:08	ClientUI	Info	Lookup finished: ip=444.444.444.444 port=9987 query=ts.domain.com wasTSDNS=1 error=0	
    2/7/2017 18:56:08	ClientUI	Info	Resolve successful: 444.444.444.444:9987	
    2/7/2017 18:56:08	ClientUI	Info	Blacklist check ok	
    2/7/2017 18:56:08	ClientUI	Info	Initiating connection: 444.444.444.444:9987	
    2/7/2017 18:56:08	TSDNS	Info	A/AAAA DNS resolve successful, "blacklist.teamspeak.com" =(h: 46.105.112.65 p:0)
    So for whatever reason it is connection to 444.444.444.444 instead of the correct domain. ts.domain.com definitely resolves to the correct 888.888.888.888 (as you can also see up there)


    Is this a known bug or is anyone else experiencing this?

  2. #2
    Join Date
    August 2016
    Posts
    9
    Update: I have just set up an SRV record for ts.domain.com - and it works as a workaround.

    It is still a bug that TS correctly resolves ts.domain.com with our TSDNS service, but then querys the @.domain.com IP for another TSDNS service and then uses this IP. It just makes no sense.

  3. #3
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,319
    BTW, for some reasons, some IPs and host names were replaced by other IPs like 444.444.444.444 and hostnames like ts.domain. I fixed that for you:
    Code:
    2/7/2017 18:56:08    ClientUI    Info    Connect to server: ts.allianceplus.life
    2/7/2017 18:56:08    ClientUI    Info    Trying to resolve ts.allianceplus.life
    2/7/2017 18:56:08    TSDNS    Info    SRV DNS resolve unsuccessful, "_ts3._udp.ts.allianceplus.life" Domain name not found    
    2/7/2017 18:56:08    TSDNS    Info    A/AAAA DNS resolve successful, "ts.allianceplus.life" =(h: 2001:4ba0:ffa4:3d1:: p:0), (h: 78.31.67.61 p:0)    
    2/7/2017 18:56:08    TSDNS    Info    A/AAAA DNS resolve for possible TSDNS successful, "ts.allianceplus.life" =(h: 2001:4ba0:ffa4:3d1:: p:0), (h: 78.31.67.61 p:0)    
    2/7/2017 18:56:08    TSDNS    Info    TSDNS found at 2001:4ba0:ffa4:3d1:::41144 and queried successfully. Result: (h: 2001:4ba0:ffa4:3d1:: p:9987), (h: 78.31.67.61 p:9987)    
    2/7/2017 18:56:08    TSDNS    Info    A/AAAA DNS resolve for possible TSDNS successful, "allianceplus.life" =(h: 89.163.219.241 p:0)    
    2/7/2017 18:56:08    TSDNS    Info    TSDNS found at 89.163.219.241:41144 and queried successfully. Result: (h: 89.163.140.25 p:9987)    
    2/7/2017 18:56:08    TSDNS    Info    SRV DNS resolve unsuccessful, "_tsdns._tcp.allianceplus.life" DNS server returned answer with no data    
    2/7/2017 18:56:08    ClientUI    Info    Lookup finished: ip=89.163.140.25 port=9987 query=ts.allianceplus.life wasTSDNS=1 error=0
    However, the rest of the post is hard to understand because there are two different IPs that both became 444.444.444.444 in your post for some reason: 89.163.140.25, 89.163.219.241.

    TSDNS has priority over A, so that's how it's supposed to work. Why is this in bug reports? Adding an SRV record is indeed the fix, as SRV has priority over TSDNS.

  4. #4
    Join Date
    August 2016
    Posts
    9
    Well, I didn't want to publish the IP's and domain names, however you got them

    All IP's have been replaced correctly in the post above.

    This is in fact a client bug!

  5. #5
    Join Date
    September 2012
    Posts
    6,060
    Not a bug.
    The client needs to know which TSDNS to query, which you can tell it by using SRV records. If you don't tell it and there aren't any TS3 SRV records then the client will have to guess TSDNS servers and ask them all.
    When sending PMs please make sure to include a reference link to the thread in question in the body of your message.

  6. #6
    Join Date
    August 2016
    Posts
    9
    Quote Originally Posted by Chris View Post
    Not a bug.
    The client needs to know which TSDNS to query, which you can tell it by using SRV records. If you don't tell it and there aren't any TS3 SRV records then the client will have to guess TSDNS servers and ask them all.
    But why would it keep asking if it has a TSDNS server on the correct server with the correct IP?
    It get's the correct answer and then just uses a completely different subdomain (which is really stupid) and takes that result?
    That is literally stupid. In my eyes it is a bug or not very smart to do.

  7. #7
    Join Date
    September 2012
    Posts
    6,060
    how is the client supposed to know which is "the right one"?

    the client contacts them at the same time, without waiting for a response, in order to minimize time spent waiting. If it would first try to connect to the TSDNS at sub.domain.tld and then wait for that when there is no TSDNS running there before trying the TSDNS at domain.tld it would waste time.

    In any case there shouldn't be more than one TSDNS per domain anyway. Not to mention that TSDNS is superfluous and deprecated without SRV records on the root domain telling the client which TSDNS to contact.

    See also https://support.teamspeakusa.com/ind...ticle/View/332
    When sending PMs please make sure to include a reference link to the thread in question in the body of your message.

  8. #8
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,319
    Correcting myself, this IS indeed a bug. Look at this chart:
    Name:  dns-allianceplus.png
Views: 223
Size:  33.5 KB

    OP has the TSDNS server at ts.allianceplus.life under his control which gives the correct result. If there was no SRV TS3 record, the answer from that TSDNS server should be used, which is identical to SRV TS3. The TS client however connects to the result from the TSDNS server at allianceplus.life. There is no official statement concerning the order in which 3.1-b3 queries the two TSDNS servers, but given that subdomains had priority over top-level domains in previous versions, this is a bug.

    Quote Originally Posted by Chris View Post
    That FAQ is only for client versions up to 3.0.19.4 and some unreleased version. The information provided on that page does not apply to any current release between 3.1-b3 and 3.1.1-b1.

  9. #9
    Join Date
    August 2016
    Posts
    9
    Quote Originally Posted by Chris View Post
    how is the client supposed to know which is "the right one"?

    the client contacts them at the same time, without waiting for a response, in order to minimize time spent waiting. If it would first try to connect to the TSDNS at sub.domain.tld and then wait for that when there is no TSDNS running there before trying the TSDNS at domain.tld it would waste time.

    In any case there shouldn't be more than one TSDNS per domain anyway. Not to mention that TSDNS is superfluous and deprecated without SRV records on the root domain telling the client which TSDNS to contact.

    See also https://support.teamspeakusa.com/ind...ticle/View/332
    I get that and I have added the SRV record now, however:

    If the TSDNS on the subdomain gives an IP for the server and the TSDNS on the main domain doesn't have that domain, WHY ON EARTH would it connect to the wrong one?

  10. #10
    Join Date
    September 2012
    Posts
    6,060
    I cannot see any error using current beta version (3.1.1-b2). Client uses SRV result as expected.
    The order in which TSDNS replies are used is "domain.tld" then "sub.domain.tld"

    Quote Originally Posted by cat24max View Post
    If the TSDNS on the subdomain gives an IP for the server and the TSDNS on the main domain doesn't have that domain, WHY ON EARTH would it connect to the wrong one?
    Why are there two TSDNS servers in the first place, and more importantly why on earth would the Top level one reply to queries about servers which it is not responsible for?
    When sending PMs please make sure to include a reference link to the thread in question in the body of your message.

  11. #11
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,319
    Quote Originally Posted by Chris View Post
    The order in which TSDNS replies are used is "domain.tld" then "sub.domain.tld"
    Yeah, I saw that. But why? That is contrary to the previous plain TSDNS behaviour (mimicing which is the only reason TSDNS was re-added in 3.1-b3!), as well as previous and current SRV TSDNS behavior which both favor subdomains. Those make sense, unlike the current plain TSDNS behaviour, because...

    Quote Originally Posted by Chris View Post
    Why are there two TSDNS servers in the first place, and more importantly why on earth would the Top level one reply to queries about servers which it is not responsible for?
    ...there is a TSDNS server running on his web host. He has no control over that server, except for putting his website there.

    So because this new order for plain TSDNS does not make any sense, I call this a bug, though it might not be what the OP was thinking about.

  12. #12
    Join Date
    August 2016
    Posts
    9
    Quote Originally Posted by Chris View Post
    Client uses SRV result as expected.
    The order in which TSDNS replies are used is "domain.tld" then "sub.domain.tld"
    Yea, but why? If I enter sub.domain.tld I want to join on sub.domain.tld and not domain.tld

  13. #13
    Join Date
    September 2012
    Posts
    6,060
    TSDNS with SRV RR is only supported on the main domain. The client won't even look at _tsdns._tcp.sub.domain.tld because there isn't much of a use case for different TSDNS servers on the same domain. As a side effect, legacy discovery of TSDNS servers gives priority to the domain as well.
    When sending PMs please make sure to include a reference link to the thread in question in the body of your message.

  14. #14
    Join Date
    June 2011
    Location
    Germany
    Posts
    4,319
    So this is intentional? I find it strange, but well...

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. SRV does not seem to be resolving
    By hibird1 in forum Linux / FreeBSD
    Replies: 3
    Last Post: June 18th, 2016, 01:57 PM
  2. Trouble resolving host name
    By police5861 in forum Windows
    Replies: 0
    Last Post: April 27th, 2016, 12:23 AM
  3. Resolving, but not connecting.
    By Wisbits in forum Windows
    Replies: 2
    Last Post: October 9th, 2014, 02:47 PM
  4. Country resolving for clients
    By znypan in forum Linux / FreeBSD
    Replies: 2
    Last Post: August 11th, 2010, 11:09 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •