Forum


Notice to all users

We are migrating towards a new forum system located at community.teamspeak.com, as such this forum will become read-only on January 29, 2020

Page 2 of 2 FirstFirst 12
Results 16 to 30 of 30
  1. #16
    Join Date
    April 2011
    Location
    Germany
    Posts
    1,266
    I can only recommend the suggestion of PotaBlava, use different labels...

    If the A record can't be modified and is xxx.domain.com use xxy.domain.com as SRV record, so when the client resolve xxy the xxx will not interfere. The best way in my opinion is to use a SRV record name which is unique.

  2. #17
    Join Date
    December 2004
    Location
    RF
    Posts
    3,008
    That's "the workaround", not "the best way". But I agree, right now there's no way to make it work right.

  3. #18
    Join Date
    January 2010
    Location
    El Prat de Llobregat (Barcelona, Spain)
    Posts
    2,698
    Quote Originally Posted by ANR Daemon View Post
    That's "the workaround", not "the best way".
    Having a parameter, something like "waiting time before decide the final ip", could be a better solution?

    I think that now this "waiting time" is hardcoded in the client: it sends the addresses, it waits for answers and then it decides which one to use. Maybe if the waiting time were adjustable, maybe as a general value (in Settings --> Options), maybe in each bookmark entry, each user, according with his internet connection status could adjust this value for resolving the correct final address.

  4. #19
    Join Date
    December 2004
    Location
    RF
    Posts
    3,008
    DNS timeout is always hardcoded, and it's not the problem.
    The real problem is that the recommended "2 seconds" timeout is a thing of past.
    With global move towards IPv6 and DNS signing, answer times are increasing, and not always fit into 2 seconds.
    (Why IPv6? Because IPv6 answers require more data to be sent and often cause connection to fall to TCP, which takes some time.)

  5. #20
    Join Date
    May 2012
    Location
    The 3rd dimension
    Posts
    956
    Quote Originally Posted by Barungar View Post
    I can only recommend the suggestion of PotaBlava, use different labels...

    If the A record can't be modified and is xxx.domain.com use xxy.domain.com as SRV record, so when the client resolve xxy the xxx will not interfere. The best way in my opinion is to use a SRV record name which is unique.
    That might work (assuming that technique works) if I didn't have a wildcard record so that anything.mydomain.tld goes to an IP I use when I am testing things. I cannot remove that because it would be too time consuming to have to keep logging into my DNS provider to keep adding records for different purposes.

    EDIT:
    Okay, I am going out on a limb here. I got a new domain and have made sure I do not add records to my SRV record and broadcasted the new address to everyone in my server. Hopefully this issue should not happen again on my server (if you are right). That still does not change the fact the TS client is doing things it should not do. It should always connect in order of it's records resolving. Yet it does not every time as you have seen from the logs.
    Last edited by Morthawt; August 15th, 2014 at 06:31 PM.

  6. #21
    Join Date
    December 2004
    Location
    RF
    Posts
    3,008
    Generally speaking, wildcard DNS names is a bad idea.

  7. #22
    Join Date
    May 2012
    Location
    The 3rd dimension
    Posts
    956
    It saves me a lot of time with the things I do. I hope this gets resolved. For now, if people use my new domain's record it "should" prevent it happening.

  8. #23
    Join Date
    December 2004
    Location
    RF
    Posts
    3,008
    That's why I said "generally speaking". I know what it means to be a website developer
    But normally I don't cross such things on the same domain. I have a separate domain that is exclusively used for demonstration purposes.

  9. #24
    Join Date
    May 2012
    Location
    The 3rd dimension
    Posts
    956
    I think you would agree that since the records are all there and given the order that records are "supposed" to resolve, the SRV record should take prescience even in the presence of other DNS records existing.

  10. #25
    Join Date
    December 2004
    Location
    RF
    Posts
    3,008
    I agree 100%

  11. #26
    Join Date
    January 2010
    Location
    El Prat de Llobregat (Barcelona, Spain)
    Posts
    2,698
    Quote Originally Posted by Morthawt View Post
    I think you would agree that since the records are all there and given the order that records are "supposed" to resolve, the SRV record should take prescience even in the presence of other DNS records existing.
    The client already does but the issue is when the SRV resolution arrives "late", that is your case:
    Code:
    13/08/2014 06:12:43	ClientUI	Info	Connect to server: subdomain.domain.tld	13/08/2014 06:12:43	ClientUI	Info	Trying to resolve subdomain.domain.tld	
    13/08/2014 06:12:45	TSDNS	Info	DNS resolve successful, "subdomain.domain.tld"=192.31.186.	
    13/08/2014 06:12:45	ClientUI	Info	Lookup finished: 192.31.186.0 9987 subdomain.domain.tld 0 0	
    13/08/2014 06:12:45	ClientUI	Info	Resolve successful: 192.31.186.0:9987	
    13/08/2014 06:12:45	ClientUI	Info	Initiating connection: 192.31.186.0:9987 subdomain.domain.tld	
    13/08/2014 06:12:45	ClientUI	Info	Connect status: Connecting	
    
    13/08/2014 06:12:45	TSDNS	Info	SRV DNS resolve successful, "_ts3._udp.subdomain.domain.tld"=>"subdomain.domain.tld:9988" = 123.123.123.123:9988

  12. #27
    Join Date
    December 2004
    Location
    RF
    Posts
    3,008
    That's TSDNS, not SRV.

  13. #28
    Join Date
    May 2012
    Location
    The 3rd dimension
    Posts
    956
    Quote Originally Posted by ANR Daemon View Post
    That's TSDNS, not SRV.
    It seems the TSDNS system in the client does the resolving of all SRV records since it TSDNS was there before single server SRV support.

  14. #29
    Join Date
    January 2010
    Location
    El Prat de Llobregat (Barcelona, Spain)
    Posts
    2,698
    Quote Originally Posted by ANR Daemon View Post
    That's TSDNS, not SRV.
    Well, maybe the log denomination is not clear. There, TSDNS, I think, is not the TSDNS server or service, it is the TS Client DNS resolver (I imagine),
    so it gets the resolution of the DNS (a CNAME or A Record),
    13/08/2014 06:12:45 TSDNS Info DNS resolve successful, "subdomain.domain.tld"=192.31.186.

    waits the "hardcoded" time and then decides the final IP between the collected answers and connects:
    13/08/2014 06:12:45 ClientUI Info Initiating connection: 192.31.186.0:9987 subdomain.domain.tld

    and then arrives the resolution of the SRV Record
    13/08/2014 06:12:45 TSDNS Info SRV DNS resolve successful, "_ts3._udp.subdomain.domain.tld"=>"subdomain.domai n.tld:9988" = 123.123.123.123:9988

    but it's too late.

    That's why I have suggested to have this "waiting time for TSDNS answers" as a parameter. Maybe, just waiting 3 seconds before to decide the final IP the SRV Record would entered in the selection.

    Sometimes the SRV records arrive in time and sometimes not. And maybe the TS client is "waiting" the same time that when only exist the DNS and now there are DNS, SRV Record and TSDNS server and maybe the client should wait a little bit more before to decide the final IP.

  15. #30
    Join Date
    May 2012
    Location
    The 3rd dimension
    Posts
    956
    Well anything that would resolve it should be done. People who operate a website at domain.tld may want users to easily connect to their teamspeak 3 server by connecting to domain.tld also. But if this issue continues there will remain disconnection issues and some people who are never able to connect.

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. Issues connecting on pc
    By Livvyy in forum Windows
    Replies: 3
    Last Post: August 28th, 2013, 07:46 AM
  2. Connecting issues
    By sprell in forum Client Support
    Replies: 1
    Last Post: August 15th, 2011, 02:11 PM
  3. Connecting Issues
    By kcstrikers19 in forum General Questions
    Replies: 0
    Last Post: July 29th, 2011, 11:26 PM
  4. [Resolved] Connecting Issues
    By slydog316 in forum General Questions
    Replies: 5
    Last Post: February 7th, 2011, 05:13 PM

Posting Permissions

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