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

Results 1 to 11 of 11
  1. #1
    Join Date
    December 2009
    Location
    Germany
    Posts
    105

    Problems with SRV records

    Hello,

    I have created some SRV records for my different TeamSpeak 3 servers.

    Some users have problems because DNS resolution sometimes doesn't work correctly.

    See following client logs please. (I have changed ip adress and domain name to prevent abuse.)


    In this case the client has joined the wrong TeamSpeak 3 server on default port 9987 because the client hasn't used the SRV record:
    Code:
    24.04.2013 20:10:35    ClientUI    Info    Connect to server: subdomain.domain.net 
    24.04.2013 20:10:35    ClientUI    Info    Trying to resolve subdomain.domain.net    
    24.04.2013 20:10:35        Info    DNS resolve successful, "subdomain.domain.net"=1.2.3.4 
    24.04.2013 20:10:35    ClientUI    Info    Lookup finished: 1.2.3.4 9987 subdomain.domain.net 0 0    
    24.04.2013 20:10:35    ClientUI    Info    Resolve successful: 1.2.3.4:9987 
    24.04.2013 20:10:35    ClientUI    Info    Blacklist check ok    
    24.04.2013 20:10:35    ClientUI    Info    Initiating connection: 1.2.3.4:9987 subdomain.domain.net 
    24.04.2013 20:10:35        Info    DNS resolve successful, "blacklist.teamspeak.com"=176.9.148.78    
    24.04.2013 20:10:36    ClientUI    Info    Connect status: Connecting    
    24.04.2013 20:10:36    ClientUI    Info    Connect status: Connected
    See following client log after the user has realized that he is on the wrong TeamSpeak 3 server and has tried again:
    Code:
    24.04.2013 20:10:48    ClientUI    Info    Connect to server: subdomain.domain.net    
    24.04.2013 20:10:48    ClientUI    Info    Trying to resolve subdomain.domain.net    
    24.04.2013 20:10:48        Info    DNS resolve successful, "subdomain.domain.net"=1.2.3.4    
    24.04.2013 20:10:48        Info    SRV DNS resolve successful, "_ts3._udp.subdomain.domain.net"=>"1.2.3.4.domain.net:10000" = 1.2.3.4:10000    
    24.04.2013 20:10:48    ClientUI    Info    Lookup finished: 1.2.3.4 10000 subdomain.domain.net 0 0    
    24.04.2013 20:10:48    ClientUI    Info    Resolve successful: 1.2.3.4:10000    
    24.04.2013 20:10:48    ClientUI    Info    Blacklist check ok    
    24.04.2013 20:10:48    ClientUI    Info    Initiating connection: 1.2.3.4:10000 subdomain.domain.net    
    24.04.2013 20:10:48        Info    DNS resolve successful, "blacklist.teamspeak.com"=176.9.148.78    
    24.04.2013 20:10:48    ClientUI    Info    Connect status: Connecting    
    24.04.2013 20:10:48    ClientUI    Info    Connect status: Connected
    This problem doesn't occur always but we have it very often and different users have this problem.

    Can you tell me why TeamSpeak 3 client doesn't use SRV record on first try? Sometimes it works without problems and sometimes a user has to reconnect 10 times or more before the TeamSpeak 3 client connects to the right TeamSpeak 3 server.

    Don't tell me that I should use tsdns please. I know that I can use tsdns instead of SRV records. However, the TeamSpeak 3 client has to do a lookup on a dns server. Therefore I see no reason for using a second dns server (tsdns server) after the first one.

    Any help you can give me in this matter is greatly appreciated.

    Best regards,
    Ronald

  2. #2
    Join Date
    September 2012
    Posts
    6,079
    If the client doesn't receive an answer from the DNS SRV resolve in time, it will connect using the data received so far. If there is no response for the DNS SRV resolve or the TSDNS request, the client will mark the server as not running either of them and connect right away when it resolved the IP address of the domain name. This is so clients don't have to wait until the DNS / tsdns requests time out before a connection is attempted.
    It appears either the client is having issues, or there is a problem with your DNS servers not answering to the requests in time. As such the client would mark the domain as not running TSDNS nor having SRV records and connect instantly. The client will however still attempt to resolve the SRV record / contact the tsdns server and if a response for either is received will remove the note and wait for SRV / tsdns answers again the next time before attempting to connect.

  3. #3
    Join Date
    December 2009
    Location
    Germany
    Posts
    105
    How does the client get the ip address if the DNS server is not answering?

  4. #4
    Join Date
    September 2012
    Posts
    6,079
    The A record is usually known by many DNS servers, whereas depending on how you set it up the SRV record might not be getting cached by other DNS servers.

  5. #5
    Join Date
    December 2009
    Location
    Germany
    Posts
    105
    Hello Chris,

    thank your for your explanation, but I have two reasons to disprove it.

    First reason: If the DNS server doesn't know the record entry than it is very implausible that it knows the entry ten seconds later. Furthermore, some users have the problem every day. My DNS records have a TTL of one day. I haven't changed the DNS records during the last week, so I think if a DNS server already knows a record, it shouldn't forget it and every DNS server should know all my entries now.

    Second reason: I have tested to connect to a subdomain which doesn't exist. I haven't created a DNS record for subdomain2.domain.net, albeit you see a SRV request for the subdomain in client log. This means you see requests for the SRV record in client log even if they fail. If you have a look at my first post you will see that there isn't a SRV request in the client log.
    Code:
    26.04.13 12:48    ClientUI    Info    Connect to server: subdomain2.domain.net    
    26.04.13 12:48    ClientUI    Info    Trying to resolve subdomain2.domain.net    
    26.04.13 12:48        Info    DNS resolve successful, "subdomain2.domain.net"=1.2.3.4    
    26.04.13 12:48        Info    SRV DNS resolve unsuccessful for "_ts3._udp.subdomain2.domain.net"    
    26.04.13 12:48    ClientUI    Info    Lookup finished: 1.2.3.4 9987 subdomain2.domain.net 0 0    
    26.04.13 12:48    ClientUI    Info    Resolve successful: 1.2.3.4:9987    
    26.04.13 12:48    ClientUI    Info    Blacklist check ok    
    26.04.13 12:48    ClientUI    Info    Initiating connection: 1.2.3.4:9987 subdomain2.domain.net    
    26.04.13 12:48        Info    DNS resolve successful, "blacklist.teamspeak.com"=176.9.148.78    
    26.04.13 12:48    ClientUI    Info    Connect status: Connecting    
    26.04.13 12:48    ClientUI    Info    Connect status: Connected
    I think the client sometimes (or by some users very often) doesn't request the SRV entry, but I can't tell you why or how to reproduce it.

  6. #6
    Join Date
    September 2012
    Posts
    6,079
    That line in the log only appears if the server did respond, but there was no Answer section detailing the SRV record. So the server did answer basically saying "I heard you, but what you asked for is not here", if there is no reply whatsoever nothing is being logged.
    SRV resolve is attempted on every connection, the only difference is that when the client attempted a connection before and either got no result or a result that there is no SRV record then a connection is attempted as soon as the ip is resolved, as opposed to waiting a couple seconds for the SRV Record to be resolved / TSDNS to answer before attempting a connection.

  7. #7
    Join Date
    December 2009
    Location
    Germany
    Posts
    105
    Thank you again for your detailed explanation. I think I have got it.
    A log line will be created after the DNS server has answered, regardless if the answer was positive or negative.

    That explains why clients connect to wrong port on first try and to correct port on second try. If the DNS server hasn't cached the SRV entry then it takes to long to get it and the client has already been connected to the default port. On the second try the DNS server has already cached it and anything will work as expected.
    If the DNS server doesn't cache the SRV entry than it must ask again and again for it. If the answer is received quickly than the client connects to the correct port otherwise to wrong port.

    If I got your right then anything is comprehensible. My question is, is it meaningful? It's impossible to use SRV records with the current implementation I can't rely that anything will work. Maybe it works and maybe not. Some users don't have problems and others can't use the subdomain.

    This means for me, I have to use TSDNS.

    For what I need SRV records if they don't work reliably?

  8. #8
    Join Date
    September 2012
    Posts
    6,079
    If certain clients use bad / slow DNS servers there is nothing we can do about that. The timeout for which the client is waiting is fairly long (a few seconds) and DNS responses usually shouldn't take longer than a couple hundred milliseconds. However we cannot have the client wait forever for a DNS response that is probably never going to arrive (DNS is UDP after all) and as such the client just attempts to connect with whatever data arrived after the timeout. If there was no response the client caches that state for the domain (aka it marks it as not running TSDNS nor having SRV records) and then decreases the timeout in order to fasten future connection attempts to that server, since it would be a bad experience to have to wait the full timeout on every connection attempt just because there is no TSDNS / SRV Records on that address. The client will still query for those and if they arrive will remove the cached status, causing the client to wait the full timeout again.
    Even if a DNS server doesn't know whether there is a SRV record for that domain and has to ask another DNS server for it, it should usually not take as long as the timeout is. Even if it takes longer the client will once connect to the wrong server (or will fail to establish the connection) but the original DNS server queried by that client should have the answer cached the next attempt (unless the authoritative nameserver takes ages to respond as well) and it should work from that point on. If it doesn't the client might just be using a slow DNS server.

  9. #9
    Join Date
    December 2009
    Location
    Germany
    Posts
    105
    You have said the timeout is a few seconds. Is it less than 2 seconds? How long does the client save that a DNS server doesn't respond? Is it saved on hard disk or only in memory?

    In following log you see connection was initiated at 19:18:46, the first answer from the DNS server was received at 19:18:48 and the second answer (the right one) was also received at 19:18:48. However, the client has connected to port 9987.

    Code:
    26.04.2013 19:18:46    ClientUI    Info    Connect to server: subdomain.domain.net 
    26.04.2013 19:18:46    ClientUI    Info    Trying to resolve subdomain.domain.net    
    26.04.2013 19:18:47        Info    DNS resolve successful, "subdomain.domain.net"=1.2.3.4    
    26.04.2013 19:18:47    ClientUI    Info    Lookup finished: 1.2.3.4 9987 subdomain.domain.net 0 0    
    26.04.2013 19:18:47    ClientUI    Info    Resolve successful: 1.2.3.4:9987    
    26.04.2013 19:18:47    ClientUI    Info    Blacklist check ok    
    26.04.2013 19:18:47    ClientUI    Info    Initiating connection: 1.2.3.4:9987 subdomain.domain.net    
    26.04.2013 19:18:48        Info    DNS resolve successful, "blacklist.teamspeak.com"=176.9.148.78    
    26.04.2013 19:18:48    Windows Audio Session    Devel    DeviceDeleteList::waitForDeletes - enter    
    26.04.2013 19:18:48    Windows Audio Session    Devel    DeviceDeleteList::waitForDeletes - leave    
    26.04.2013 19:18:48    Windows Audio Session    Debug    WAS::openDevice-enter    
    26.04.2013 19:18:48        Info    SRV DNS resolve successful, "_ts3._udp.subdomain.domain.net"=>"1.2.3.4.domain.net:10000" = 1.2.3.4:10000    
    26.04.2013 19:18:48    Windows Audio Session    Debug    WAS Buffer size: 960    
    26.04.2013 19:18:48    Windows Audio Session    Debug    WAS::openDevice-leave    
    26.04.2013 19:18:48    Windows Audio Session    Debug    WAS::startDevice-enter    
    26.04.2013 19:18:48    Windows Audio Session    Debug    WAS::startDevice-leave    
    26.04.2013 19:18:48    Windows Audio Session    Devel    DeviceDeleteList::waitForDeletes - enter    
    26.04.2013 19:18:48    Windows Audio Session    Devel    DeviceDeleteList::waitForDeletes - leave    
    26.04.2013 19:18:48    PreProSpeex    Info    Speex version: speex-1.2beta3    
    26.04.2013 19:18:48    ClientUI    Info    Connect status: Connecting    
    26.04.2013 19:18:48    ClientUI    Info    Connect status: Connected    
    26.04.2013 19:18:49    G15 Plugin    Info    Clients online: 0    
    26.04.2013 19:18:49    ClientUI    Info    Connect status: Establishing connection    
    26.04.2013 19:18:49    G15 Plugin    Info    Clients online: 0    
    26.04.2013 19:18:49    ClientUI    Info    Connect status: Connection established
    The user has reconnected again 15 seconds later and then anything was fine. That's comprehensible because DNS server has cached the SRV entry.

  10. #10
    Join Date
    September 2012
    Posts
    6,079
    The server dns status is cached indefinitely and removed when it is detected there is a TSDNS / SRV record available.
    In the client log it seems that user had the server marked for not running TSDNS / SRV records thus started connecting with the IP. That status was cleared at 19:18:48 as the DNS answer for the SRV record came in. Any connection afterwards would've worked (provided DNS answers within the timeout).

  11. #11
    Join Date
    May 2012
    Location
    The 3rd dimension
    Posts
    956
    I have this exact same issue. I have the SRV records set all correctly yet sometimes people including myself have to connect 2 or 3 times or more sometimes. There have been 2 cases so far who are never able to connect using the SRV record address. I get so sick of the complaints, yet it seems I have done everything correctly.

Thread Information

Users Browsing this Thread

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

Similar Threads

  1. SRV Records
    By austin070 in forum Server Support
    Replies: 78
    Last Post: June 2nd, 2016, 06:32 PM
  2. TS3 SRV records not working
    By ApolloIXI in forum Server Support
    Replies: 3
    Last Post: January 31st, 2014, 10:20 AM
  3. TS3 suggestion - DNS PTR/SRV records
    By Audiobuzz in forum Suggestions and Feedback
    Replies: 14
    Last Post: January 19th, 2011, 03:53 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
  •