Inconsistency in handshake host name for SRV records (status request/join)

I don't understand the problem here. SRV records do work for subdomains. I have used them myself many times in different versions of Minecraft and server querying worked normally. It is also used by a existing public servers. Are you sure this is a Minecraft issue rather than a misconfiguration of some kind?

I will be trying to make a test really quickly and I'll come back to you.

Definitively not a Minecraft issue. This is my configuration:

SVR  _minecraft._tcp.mc.[domain]    0 0 25585     cloud.[domain]
A      cloud.[domain]    [server_ip]

Make sure that you have set:

query.port=[server port goes here]

Maybe that's the problem you're having. Both query.port and server-port should be set to the same value.

Hi! To make your bug report as effective as possible, please include the following information to help us understand your problem:

Steps to Reproduce:
1. (Explain what needs to be done for the issue to happen)
2.
3.

Observed Results:
(Briefly describe what happens)

Expected Results:
(Briefly describe what should happen)

Please also attach any needed commands, add-ons/behavior packs, data packs, resource packs, screenshots, videos, or worlds needed to help reproduce this issue and update the affected version/s if this is still an issue in 1.21.4.

Refer to the Bug Tracker Guidelines for more information about how to write helpful bug reports. Bug reports with insufficient information may be closed as Incomplete.

_{This issue is being temporarily resolved as Awaiting Response. Once the requested information has been delivered, the report will be reopened automatically.}

Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support (Technical Issues) – 📧 Microsoft Support (Account Issues)
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki

SRV records work, its about the host name in the handshake packet which is inconsistent, corrected it.

I can verify that this bug continues to exist in latest version.

This bug does not cause any gameplay impact to my knowledge on a vanilla minecraft server, so it would be difficult to demonstrate any issues in the vanilla game. If you investigate the packets sent to the server on join vs for a status ping is where you find the discrepancy.

Steps to reproduce:

1. Add a server to the multiplayer server list with a domain which has an SRV record pointing to a server on a different hostname/port (For example, adding test.example.com to your server list, with SRV record _minecraft._tcp.test.example.com pointing to example.com port 12345 and with example.com having its own A record pointing to the numeric IP)

2. Log the hostname and port sent in the initial handshake/intention packet

Observed result:

Connections to join the server with the above example would yield an intention packet in which the hostname field is set to “example.com” and the port set to 12345.

Status pings to the server with the above specified example would yield an intention packet in which the hostname field is set to “test.example.com” and port 25565 (Despite the fact that it correctly connects to example.com at port 12345)

Expected result:
The intention packets for both types would have the same hostname/port fields (set to example.com at port 12345, as is currently done on join but not on status ping)

The following is the reason I came up in my investigation that this occurs.

Login connections do the following (In net/minecraft/network/Connection.connect):

Optional<InetSocketAddress> resolvedAddress = ServerNameResolver.DEFAULT
   .resolveAddress(hostAndPort)
   .map(ResolvedServerAddress::asInetSocketAddress);


...

address = (InetSocketAddress)resolvedAddress.get();

...

ConnectScreen.this.connection
   .initiateServerboundPlayConnection(
      address.getHostName(),
      address.getPort(),
      ...
   );

The above code uses the resolver to resolve the address, and uses the InetSocketAddress returned by the resolver to supply the information passed into initiateServerboundPlayConnections which passes it through into the packet data.

Status connections do the following (In net/minecraft/client/multiplayer/ServerStatusPinger.pingserver):

final ServerAddress rawAddress = ServerAddress.parseString(data.ip);
Optional<InetSocketAddress> resolvedAddress = ServerNameResolver.DEFAULT.resolveAddress(rawAddress).map(ResolvedServerAddress::asInetSocketAddress);
if (resolvedAddress.isEmpty()) {
   this.onPingFailed(ConnectScreen.UNKNOWN_HOST_MESSAGE, data);
} else {
   final InetSocketAddress address = (InetSocketAddress)resolvedAddress.get();
   final Connection connection = Connection.connectToServer(address, eventLoopGroupHolder, null);
   
   ...

   try {
      connection.initiateServerboundStatusConnection(rawAddress.getHost(), rawAddress.getPort(), listener);
      connection.send(ServerboundStatusRequestPacket.INSTANCE);
   } catch (Throwable var11) {
      LOGGER.error("Failed to ping server {}", rawAddress, var11);
   }
}

Which instead has the call to initiateServerboundStatusConnection source the hostname and port from the raw, unresolved address as opposed to resolved version, and thus despite connecting to the correct resolved address it will provide incorrect hostname/port data.

Making it instead use the values sourced from the resolved address exactly as is done in the logic in ConnectScreen would resolve this issue.