I saw that there was a feature request for this on the forum too back in November of 2016, with the latest post being from April of 2019.

How come this is still not implemented yet? Especially given development on new games too.

There was also a feature request for this on other games like Factorio, where it was requested in 2016 and implemented in 2019 - the developer response for the implementation can be found here.

It should be a pretty basic thing to make, without taking priority and weight into account (not needed), having the game client do the following when connecting using a domain name:

1. Check if SRV record exists for domain - if it does, use the target in the SRV record to resolve the host.
2. If no SRV record exists, get A (or AAAA) record as usual.

SRV records are really useful for hosting multiple Arma servers from the same host, since players won't have to remember the port, but can instead just remember a subdomain.

It's also great for hosting the game on one server and a webpage on another server, and having both be accessible with the same domain. For example, say you have play.example.com - you could then have the A-record point to a webserver and then add a SRV record (with the same subdomain!) pointing to another A-record for the gameserver!

Hoping you will take some time to try and implement this into the engine/game :)

2.20
https://community.bistudio.com/wiki/connectToServer

You can use that to mod a custom join button into the main menu, which will then look up the SRV record.
This is the solution for now, maybe we'll do something better later.

The issue is that direct connect was made to connect to a specific server on a specific port.
The UI does not let you have an empty port, if you leave it empty it will fill in 2302 for you.

SRV records brings issues to that.

• Multiple records per domain, now you have multiple servers even when you direct connect to one (We can just solve that by using the first and ignoring all other)
• Who wins, the port entered in direct connect dialog, or the SRV record? No matter who wins, both options will leave the other server inaccessible.

Say you have two servers on a machine, 2302 and 2312.
You have one SRV record on the domain pointing to the server and 2312. You also have an A record on the domain pointing to the same server.
Now when the user connects to the domain, with default port 2302 (or leaves the port empty which is same), what do we do?
Do we look up the SRV record and connect the player to 2312? Even though the user specifically entered 2302 to get to that one.
Do we ignore the SRV record and go to 2302? But the player intentionally left the port default/empty to let the SRV record connect them to 2312.

Should we just ignore the given port completely if we find a SRV record? Thus making any server running on the same domain but a different, inaccessible, unless you manually enter the IP, or a different domain pointing to same IP that won't find a SRV record?
That is the option that was proposed here, but I don't like the idea of making a server unjoinable/unfindable, even though you know it's there (if you were to follow the A record and ignore the SRV one).

Optimally, we would look up both the A record, and ALL SRV records. And display ALL the servers to the user to select from.
In most cases that will only be one server, and behavior will look to be the same. But if there are multiple, then no server will be inaccessible.
Direct connect in server browser anyway brings you to a server selection which currently only displays one server, it would be nice if we could display all the choices.
But our code doesn't support looking up multiple servers at once, that would require quite big changes.

And that leaves the -connect= start parameter, and the connectToServer script command unsolved too.
They also look up like direct connect in server browser, but hide the browser behind a loading screen. Thus a player cannot select a server if there are multiple options.
But for these two you can at least specifically specify no port, or port 0 to basically tell it to use the SRV record instead, which is what I'm doing now (doesn't work for -connect= because reasons)

Scratch some part of that.
I can use the same connectToServer hack also for the direct connect UI.
So you have to specifically enter domain and port 0 (or manually empty it (it will be default filled with 2302)) in direct connect.
Then it will try to resolve the port via SRV record, if that fails it falls back to 2302 (same as would've happened before if you left it empty or entered 0 manually)

So both connectToServer command, and the in-game direct connect UI. If you enter port 0, it will try to resolve SRV record.

Due to reasons, the usage in direct connect UI will be a bit annoying.
direct connect UI saves the last IP/Port you entered.

Say

arma.test.com.	IN	A	1.1.1.1
arma2.test.com.	IN	A	2.2.2.2
_arma3._udp.arma.test.com.	IN	SRV	0 0 2302 arma2.test.com.
_arma3._udp.arma.test.com.	IN	SRV	0 0 2312 arma.test.com.

You direct connect to arma.test.com with port 0.
Game will FIRST resolve the SRV to arma2.test.com/2302 and THEN save the last-used ip/port.
So when you next open the direct connect UI, it will pre-fill it with arma2.test.com/2302

We can consider fixing that some other day.

I don't see a problem with that solution. Using SRV records like that could work as some kind of shitty matchmaker if you follow the weight and priority parts of the SRV record, but if that is not intended then it's user error. But I'd imagine the main usage would be hosted solutions where multiple servers share the same IP as described by Jaffa, or like @HeroGamers games describes having something like mycommunity.org point to server4.coolgameservers.net, port 23456, both of which wouldn't be degraded by saving the last resolved host/port.