#18 DNS SRV record detection

Unassigned
open
nobody
None
5
2016-03-12
2006-12-17
aef
No

This would be a great feature. So full DNS-name based hosting would be possible without standard ports (and with just one IP address of course) in a transparent und most RFC like way.

http://en.wikipedia.org/wiki/SRV_record

Discussion

  • Thorvald Natvig

    Thorvald Natvig - 2006-12-19

    Logged In: YES
    user_id=20066
    Originator: NO

    QHostInfo only has support for address records, meaning we'd have to add platform specific DNS code. Until QDns is fully ported to Qt4, we're unlikely to support any fancy DNS things :(

     
  • aef

    aef - 2006-12-19

    Logged In: YES
    user_id=1670878
    Originator: YES

    You could take the implementation from open source Jabber Instant Messenging Client Psi (www.psi-im.org). I know they have SRV code and they recently updated their dev branch to Qt 4.2. I'm sure that's what open source is all about.

     
  • Thorvald Natvig

    Thorvald Natvig - 2006-12-20

    Logged In: YES
    user_id=20066
    Originator: NO

    Psi uses JDNS, which is part of the iris package. That's fairly much code to include for one tiny feature.

    There's also another problem; murmur doesn't really support a concept of server farms, so we wouldn't be using the prioritizing and load balancing present in SRV, so it would just be a very fancy method of avoiding to write down the port number.

    SRV also makes much more sense in the scenario where many servers cooperate to provide the same virtual service, whereas murmur is designed to have many virtual services on the same server. SRV breaks down when you want to have 10 different murmurs running on the same physcial box. I don't know if it's easier to write "clanA.voip.server" than "voip.server port 123".

    If you can change my mind, I'll peek at adding support at least for Linux and Win32.

     
  • aef

    aef - 2006-12-20

    Logged In: YES
    user_id=1670878
    Originator: YES

    Sure the balancing feature isn't needed at the moment. The reason for giving the ability to use name based addressing instead of IP or port based addressing is, simply said, the same why DNS was invented. Because humans like to remember words better than numbers. On the other side the most people like it when they read or write their names! Possibly you could do it the host-header way HTTP does it. But it's less centralized to control and less RFCish.

     
  • SourceForge Robot

    Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • Nathan Phillip Brink

    This would be a nice enhancement because a domain may use a third-party VOIP hosting service. Users should only need to type the domain name (ex. example.org') into mumble instead of having users type a full-out subdomain likevoip.example.org' for the case where this is only one voicechat session at a site.

     
  • Greg Bell

    Greg Bell - 2012-07-07

    I would like to nominate this request for reopening, or at least initiate a new discussion on the matter.

    Support for SRV records would allow for easier end user setup, and automated failover for larger installations.

    As it is, server administrators are at the mercy of ISPs who do not honor the ttl on domain names. This makes automated failover difficult to implement, and in some cases it is completely impossible.
    (an isp that forces a 12 hour ttl for example completely prohibits any realtime changes)

    With srv records you can designate a priority order, allowing mumble to be aware of the primary and the secondary server at the same time.

    This allows the client to automatically switch to using the backup server as soon as it determines that the primary in unreachable.

    For gaming groups and hosting providers, being able to lose a server and force an instant reconnect to a different server can be a major advantage.

    Use case #1:

    Don is a web/email/chat hosting provider with 50 separate instances of murmur, and three sites at separate physical locations.

    Currently, Don uses srv records for both web and email. When site #1 goes down, all connections instantly migrate to site #2 without any user intervention.

    Don's DNS servers also instantly changes the dns A record for 'mumble.donsplace.com' to the ip address for site #2. This a record has a TTL (time to live) of 60 seconds.

    Ideally, this would mean that after 60 seconds, all of Don's mumble users would attempt to connect to 'mumble.donsplace.com', and receive the updated A record for site #2.

    Unfortunately, 30% of Don's mumble users are using "Slowlink ISP".
    Slowlink forces an 8 hour dns TTL, so everytime Don switches services to a different site it takes 8 hours before Slowlink changes their local dns server to match the correct data.

    Because of this, everytime Don has to switch to site #2, he loses several customers.

    Use case #2:

    Chad runs the murmer server for his Raiding guild.
    He has a large internet connection at work, and his boss allows him to run the server from there.
    Chad's guild leader also has a paid Virtual server with a limited amount of monthly bandwidth that chad can use as a backup for the server.

    On tuesday night, chad's raid group is halfway through running a 40 person raid when his bosses girlfriend dumps a drink onto the router at the office.

    Chad immediately changes the dns record for the mumble server to the backup, but only half of the group can connect to it immediately.

    They spend the next 30 minutes explaining how to connect directly to the backup via in game chat.
    In that time several members have to leave, and the raid has to be cancelled or rescheduled.

    SRV records are an excellent and simple way to allow for the end user to implement a backup for their server, and allow for hosting providers to offer higher reliability.

     
    • Christian Roy

      Christian Roy - 2013-03-19

      I support the request for reopening

       
  • Thorvald Natvig

    Thorvald Natvig - 2012-07-07

    Qt still doesn't resolve SRV records, meaning this would be a non-trivial amount of work to get it working across all platforms for something that benefits very few users.

     
  • Alice Bevan-McGregor

    SRV records are particularly useful for the mumble.com example of centralized hosting for gaming clans. Each gaming clan would have their own domain whose SRV record would point to their CNAME subdomain of mumble.com. This allows for maximum flexibility: the gaming clan distributes their own domain for connecting to, and mumble.com can dynamically manage the client subdomain CNAME mapping to real servers.

    I.e. bravecollective.net SRV bnicomms.mumble.com:1234 CNAME m12.mumble.com A 184.173.169.21 -- a real DNS query chain, just using a CNAME subdomain on the bravecollective.net side at the moment. And if we could possibly avoid confusing our newbie gamers with the concept of a "port number" all the better.

     
  • Brian

    Brian - 2013-05-16

    Can we get this reopened since QT now supports SRV records?

     
  • Mikkel Krautz

    Mikkel Krautz - 2013-05-16
    • status: closed --> open
    • Group: --> Unassigned
     
  • Mikkel Krautz

    Mikkel Krautz - 2013-05-16

    Reopening.

     
  • Mrd

    Mrd - 2014-02-13

    Can you we please get this feature!

     
  • Greg Bell

    Greg Bell - 2014-03-27

    Since it's now been 10 months since this was reopened and 2 years since qt implemented the feature for us, I would like to again request that someone look into adding this.

    This QT bug report contains the api code incorporated into QT if you need to look at it more closely.

    https://bugreports.qt-project.org/browse/QTBUG-10481

     
  • Luke Marlin

    Luke Marlin - 2014-04-08

    I would also really appreciate SRV records support for mumble..

     
  • Waka Flocka

    Waka Flocka - 2014-09-03

    Will mumble support this anytime soon ... been waiting for awhile now :(

     
  • Torge Tönnies

    Torge Tönnies - 2014-10-15

    Would be great for running multible servers or setting up fallback solutions in case one server is going down all people would nearly instantly reconnect to an other mumble at an other server...

     
  • Chamunks

    Chamunks - 2015-05-26

    This post sounded way more passive aggressive than I intended. This feature looks like its been requested since ages so I imagine it may not be coming.

     
    Last edit: Chamunks 2015-05-26

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks