Mumble: Redirection feature

[HarpyWar]

Hello,.
A lot of hosters experiencing DDoS attacks on their servers and it occurs very often at the last time. In most cases a datacenter simply null-routed a server IP that was DDoSed for 24 hours, but the server is still available from other IP addresses (if binded).
I have an elegant suggestion how to solve this for Mumble servers. It should be easy to implement and saves a lot of nerves for hosters and end users :).

1. When user connecting to a Mumble server he should receive a first packet from the server with IP address list which Murmur is bind (host option from murmur.ini, or even a new option failoverhost that can have IPs from other physical servers).
2. These IPs should be saved into a client connection settings for that server (and updated for each next connection to keep up to date).
3. If a connection lost to the main server IP a Mumble client should check next IP from the list for availability and auto-reconnect to the server.

Thus, we have a simple and effective fail-over system. I hope it can be done in next Mumble release.
What are you thinking about it?

---

P.S. It will not work for new users who didn't connect to a server yet (because they didn't received a list with reserved IPs). But this should not be a problem, because there are mostly regular visitors for a single Mumble server, and above feature will allow teams save a voice communication during important events if their server is unreachable due to a DDoS.
Also the problem can be solved by informing each user about reserved IP. But actually this is not a solution and very uncomfortable. Most users will not add a reserved address to their Mumble clients until a first accident

[HarpyWar]

Also it will be great to add a redirection feature. It is already implemented in most famous protocols like HTTP, and even for Teamspeak 3 (called TSDNS).

When a client connecting a server should be able to return ip and port for redirect, and a client should be able to do the redirection. It will allow clients do not specify a port.
For example, a subdomain.example.com is binded to a Murmur server IP. User can only add this subdomain with _any port_. A server redirecton service returns new IP and port for that subdomain and user connects on a his server that can be even on different machine and port.
A redirection service can be implemented in Murmur and with possibility to make it stand-alone (like TSDNS for Teamspeak 3).

[Gunni]

Is this not already implemented using SRV records?

https://github.com/mumble-voip/mumble/pull/1306

[HarpyWar]

SRV records can be also added as an alternative to the redirection.
DNS records have a delay for end users when add or modify A or SRV records. But above suggestion will allow do it immediately.

[Gunni]

@HarpyWar but with SRV records you can add multiple levels of priority, if one level fails, it jumps to the next, no?

[HarpyWar]

Yes, failover ip works with Mumble SRV record. I din't know about that, thanks.
But anyway redirection service will add more flexebility:

• use wildcard for a subdomain
• add a redirection to any port using one record (like in TSDNS: *=12.13.14.15:$PORT)
• users can use default port 64738 with a subdomain that binded to a different port (as I described above)
• all changes applies immediately

It can be implemented as a standalone service on a separate listening port (like TSDNS). Also there SRV feature should be added for the redirection service.

How it's implemented in Teamspeak 3 is good described in tsdns_settings.ini and here. I think a mechanism should be the same.

In this case my first suggestion is not really needed. It also can be implemented but not only with Mumble, but also with Mumble redirection service (if users connect directly to IP). BUT I'm fine without implementing this, because SRV features should be enough for a redirection service.
All these features will give really complete, flexible and failover solution.

[Gunni]

@HarpyWar Again, SRV records are here to save the day.

_mumble._tcp.mumble.example.com. 900 IN SRV 10 1 64738 mumble.example.com.

As you can see there you can create a subdomain, and with SRV records point them to different ports.

Example:
Anyone connecting to that record above, when not defining a port should connect to port 64738 on mumble.example.com.

_mumble._tcp.mumble.example.com. 900 IN SRV 20 1 64739 mumble2.example.com.

And there if that server were to fail, this one is priority 20, so failover for that other one and clients should connect to this one, and automatically use port 64739.

You should read this if you havent already: https://en.wikipedia.org/wiki/SRV_record

Also, even if not instant, TTL can usually be set low enough in dns so centralized proxies should never be needed.

[HarpyWar]

Well, several examples from real life:
1) (user connection settings → redirection to real server address)
mumble.example.com:64738 → 12.34.56.78:55555
(with redirection service we can add a record mumble.example.com=12.34.56.78:55555 and user can set any port in a Mumble client, but connect to port 55555)
(I can't get it working using SRV, is there way to do the same?)

2) Switch IP for thousands of existing servers (failover):
mumble.example.com:64739 → 22.34.56.78:64739
mumble.example.com:64740 → 22.34.56.78:64740
...
(with redirection service we can change one record *=12.13.14.15:$PORT → *=22.13.14.15:$PORT)
(with SRV we must add/update two records (failover) for each server, right?)

3) Move a single virtual server to another machine with different port, but keep a connection from initial address:
mumble.example.com:64741(12.34.56.78:64741) → 22.34.56.78:64742
(with redirection service we can change mumble.example.com:64741=12.34.56.78:64741 → mumble.example.com:64741=22.34.56.78:64742 and a new server will be immediately available from mumble.example.com:64741)
(even if first point is available using SRV then anyway user will not able connect to a new server because of delay on DNS provider's side and user's computer DNS cache, desync users between two servers during all the day)

4) Users who have a domain want to bind a server to own subdomain.
(with redirection service he can only add A record to the service, all other changes can can do a hoster)
(with SRV user must manually edit these records if port/ip was modified)