Save hostnames in server lists instead of resolved IPs

[TridentSky]

Summary

When a server is added to favourites (or ends up in recently played / connect history) using a hostname, the client now keeps the hostname in coreconfig.xml instead of freezing the resolved IP. On load the hostname is resolved again, so saved entries keep working after the server moves to a new IP.

CServerListItem already had a strHostName field and SaveServerList already prefers it over the IP when writing the config — it just was never assigned anywhere. This fills it at the points where the typed address was discarded right after CServerListItem::Parse() resolved it: adding a favourite, loading the saved lists, updating recently played, and the connect history notification. The resolved IP stays as the internal key everywhere (address map, server cache, saved passwords), so caching and lookup behaviour doesn't change.

Two smaller things that came out of this:

• if a saved hostname fails to resolve at startup, the entry is now kept (null address, shows up as timed out, same as a dead IP) instead of silently disappearing from the config on the next save — previously one launch with DNS down would delete the favourite permanently
• OnFavouritesClick used the in_addr uninitialized when the typed address couldn't be resolved; it now bails out instead

Known limitation: two unresolved hostnames on the same port collapse into one entry, since (ip, port) is still the key. Same happens for two hostnames resolving to the same server, which seems like the right behaviour anyway.

Motivation

Fixes #1314 and covers the favourites part of #688. Advertising an IP is fragile — the moment a community changes hosts, every saved favourite and every posted address breaks. With this, players save the domain and an IP change only needs a DNS update.

Test plan

Testing against the CI build (draft until all of these pass):

• add favourite via domain → coreconfig.xml contains the domain, entry still connects after restart
• add favourite via IP → unchanged, IP saved as before
• connect via domain → recently played and connect history keep the domain across restarts
• hostname that doesn't resolve at startup survives a save/load cycle instead of being dropped
• old configs (IP-only) load exactly as before

Checklist

• Your code should follow the coding guidelines.
• Smaller pull requests are easier to review. If your pull request is beefy, your pull request should be reviewable commit-by-commit.

[Esteban528]

Tested by me. Works well

[TridentSky]

Thanks for taking the time to build and test it!

Out of curiosity, which cases did you run through? The one I'd most like a second pair of eyes on is the unresolvable hostname at startup — a favourite saved as a domain should now survive a launch with DNS down instead of being silently dropped from coreconfig.xml on the next save.

Keeping this as draft until the CI gets approved to run, so I can go through the full test plan against that build.

[vectorbasis]

In its current state, this doesn't fully solve the problem, it's more of a workaround, because the master list still only works with IP addresses, and there is no way to specify the displayed hostname in the server configuration, which the client could then use in the server browser.

[Disinterpreter]

In its current state, this doesn't fully solve the problem, it's more of a workaround, because the master list still only works with IP addresses, and there is no way to specify the displayed hostname in the server configuration, which the client could then use in the server browser.

Domain can be added by rules.
#3468

[Esteban528]

In its current state, this doesn't fully solve the problem, it's more of a workaround, because the master list still only works with IP addresses, and there is no way to specify the displayed hostname in the server configuration, which the client could then use in the server browser.

Why refuse to implement new features? We can start somewhere, and that's by adding local domain support. The master list doesn't need to implement this yet.

[Esteban528]

If loyal players on the servers save the domain names instead of the IP addresses, these servers can switch hosts without needing to communicate externally with the players. In other words, it's obvious why this is beneficial.

[TridentSky]

In its current state, this doesn't fully solve the problem, it's more of a workaround, because the master list still only works with IP addresses, and there is no way to specify the displayed hostname in the server configuration, which the client could then use in the server browser.

Implementing domain names instead of relying solely on IP addresses would be extremely beneficial for all servers.

1. They’re much easier to remember. For example, if you want to play Minecraft and join a server like Hypixel, the first thing you remember is that you just need to type mc.hypixel.net and you're good to go. It simply looks cleaner and is easier to remember than something like xxx.xx.xx.xxx. You understand what I’m trying to say, right?

2. Using a domain for this doesn’t even have to be mandatory. The system could resolve and cache the numerical IP address the first time the player connects. Then, whenever the client refreshes, if the domain fails to resolve, the system could attempt to connect using the cached backup IP—as long as the IP was previously resolved through DNS.

In fact, in MTA you can already connect using a domain and port, for example: mta.tridentsky.net:22003. The problem is that the domain itself is not stored on the player's client; it gets converted into a numerical IP address. So let's say that, for various reasons, I change hosting providers and my IP address changes. Logistically, that's a huge headache for a server owner because they have to promote the new IP address all over again across all their social media platforms.

The goal is to give the server a permanent, recognizable address that is easier to remember and connect to. If the host changes its IP address, the server owner should only need to update the IP associated with the domain, and that's it. I honestly don't know how difficult it would be to implement something like this.

FiveM, Minecraft, and even SA-MP already work this way.

[Esteban528]

The cost of this implementation is negligible in performance anyway. It's no bloat and will be useful

[vectorbasis]

Why refuse to implement new features? We can start somewhere, and that's by adding local domain support. The master list doesn't need to implement this yet.

No one said that the pull request would not be merged if it was implemented properly. The comment only represents my personal opinion and observation, nothing more. I also never said that we should not implement this change, only that it does not fully solve the problem yet.

@TridentSky, the main issue with your response is that it reads like an AI generated answer and does not really address the point I was making. It mostly explains things that are already known, but it does not provide a solution for the actual problem.

FiveM, Minecraft, and even SA-MP already work this way.

Similarly, but not exactly in the same way. This is the important distinction that I was trying to point out.

The current server browser does not display custom server addresses. Even if a player can manually save a server using a domain, servers discovered through the master list are still represented using raw IP addresses. This means the actual public server discovery experience still has the same limitation.

Based on Disi's response, this does not seem like a particularly difficult improvement. A possible implementation could be adding a new optional server browser rule, similar to the existing rules such as website_url, description, or tags, allowing servers to provide a custom address.

For example:

<rule name="server_address" value="play.example.com" />

When this rule is present and valid, the server browser could display and use this address instead of the raw IP address.

Of course, this should not be treated as a simple display only value. Some validation should be involved to prevent impersonation. The provided address should be verified, for example by requiring domain ownership verification through a DNS TXT record, and then confirming that the verified address actually points to the server endpoint.

If verification fails, the server browser should simply ignore the rule and fall back to displaying the normal IP address.

This would allow community servers to have a recognizable identity while avoiding cases where someone could claim an unrelated or official looking address.

[TridentSky]

@TridentSky, the main issue with your response is that it reads like an AI generated answer and does not really address the point I was making. It mostly explains things that are already known, but it does not provide a solution for the actual problem.

To start with, I think it’s completely unnecessary to say, “your comment was made with AI.” I’m Latino, I don’t speak English, and all I do is translate my suggestions into English. That has nothing to do with the actual point I’m making. And even if it were true, what would be so wrong with that?

It seems like a lot of people take things the wrong way whenever someone tries to suggest changes that are actually useful and as simple as this one, which is absurdly easy to implement.

I’ve been working in development for years, without AI. I don’t need to prove anything to anyone. If my mistake was simply translating my messages from Spanish into English, then there’s really nothing else to say.

Based on Disi's response, this does not seem like a particularly difficult improvement. A possible implementation could be adding a new optional server browser rule, similar to the existing rules such as website_url, description, or tags, allowing servers to provide a custom address.

For example:

<rule name="server_address" value="play.example.com" />

When this rule is present and valid, the server browser could display and use this address instead of the raw IP address.

I think it would be a good idea to do something like this. What are we waiting for to implement it?

Honestly, I don’t want to put time and effort into working on something only for it to be rejected later or dismissed because someone says it was made with AI. We’re already years behind on something so simple, yet genuinely useful and convenient for server advertising.

[AlexTMjugador]

What are we waiting for to implement it?

A thought experiment for you: the DNS server a player uses is determined by their network configuration and/or ISP, not by MTA server owners, and it is a widely known fact that DNS is not a tamper-proof protocol. What's your plan for handling the situation that will eventually arise when a domain name resolves to the wrong server IP?

Note that a variant of the above problem can also occur without any DNS tampering if the domain's TTL is set to such a high value that recursive DNS resolvers continue returning stale records for an extended period.

No matter whether this PR gets merged, when migrating servers to a different IP address, it's probably a good idea to keep a "stub" server listening on the previous socket address that redirects players to the new server for a transition period, economic considerations notwithstanding. That would make the migration as seamless as possible for everyone.

[TridentSky]

Stepping back a bit. My last reply was defensive and didn't really answer what either of you asked, sorry about that.

@vectorbasis you're right, this doesn't touch discovery. Servers coming from the master list still show up and get saved as raw IPs, this only keeps what the player typed by hand. I looked into the rule idea: the server side is mostly there since #3761 already loads <rule> entries from mtaserver.conf, but the browser doesn't read rules at all yet, the master list would need to carry the field, and then there's the TXT verification on top. That's a much bigger change than this PR and it deserves its own discussion, so my proposal is to keep this one limited to the manual/favourites path and open a separate issue for the server_address rule where the verification part can be worked out properly. If you'd rather have it all in one PR, tell me and I'll rework it.

@AlexTMjugador this PR doesn't change the trust model, it stores the string instead of the result of gethostbyname. Resolution happens at load with the same call that connect play.example.com goes through today, so a tampered or stale record sends the player to the same place it would if they typed the domain. The real difference is that a saved favourite re-resolves silently on every launch, and I agree that's worth being explicit about. Stale TTL means landing on the old IP, which is what a saved IP does now anyway, so the stub server you describe is the right advice in both cases and nothing on the client side replaces it.

Two changes I think make sense for this PR based on your comments:

1. Keep the last resolved IP next to the hostname in coreconfig.xml (host="play.example.com" ip="1.2.3.4"). If the lookup fails the entry falls back to the last known address instead of the null address it gets now, and the browser can show the IP it actually resolved to, so there's no hidden redirect.
2. Keep resolution at launch only. It already works that way (the browser never re-resolves in the background), but I'll make sure it stays like that so a player always connects to an address they can see.

I'll hold off on pushing anything until I hear whether that's the direction you want.

[Esteban528]

What are we waiting for to implement it?

A thought experiment for you: the DNS server a player uses is determined by their network configuration and/or ISP, not by MTA server owners, and it is a widely known fact that DNS is not a tamper-proof protocol. What's your plan for handling the situation that will eventually arise when a domain name resolves to the wrong server IP?

I dont think the DNS would be a problem, because this is just an alternative to keep favorites resolving IP automatically. In this case it makes things easier. And nowadays it's too difficult to be breached.

No matter whether this PR gets merged, when migrating servers to a different IP address, it's probably a good idea to keep a "stub" server listening on the previous socket address that redirects players to the new server for a transition period, economic considerations notwithstanding. That would make the migration as seamless as possible for everyone.

This is a great idea