-
Bug
-
Resolution: Unresolved
-
None
-
Minecraft 1.7.4, Minecraft 1.7.5, Minecraft 1.7.9, Minecraft 1.8, Minecraft 1.8.8, Minecraft 15w44b, Minecraft 15w47c, Minecraft 1.10.2, Minecraft 1.14.1, Minecraft 1.14.2, 1.18.2
-
Windows 7 x64
Sun JRE 8 update 102 x64 (was update 20 when reported first)
-
Community Consensus
-
Networking
-
Low
-
Platform
Short description
how to reproduce:
- use "nerdpol.org" in server name field.
- refresh server view or connect to the server
expected behaviour:
- minecraft looks up the SRV record and receives two results with different priority
- a connection is opened to minecraft.nerdpol.org:25565
- if the connection to minecraft.nerdpol.org:25565 fails a connection to minecraft.nerdpol.org:53 is opened
actual behaviour:
- minecraft looks up the SRV record and receives two results with different priority
- a connection to minecraft.nerdpol.org:25565 or minecraft.nerdpol.org:53 is opened randomly, ignoring the given priorities
Long description
I just noticed that minecraft randomly chooses one of the received DNS SRV records on each connect regardless of their priority values. This behaviour seems to apply to the server overview as well as to the actual connect.
Normally an application would connect to the specified host with the lowest given value in the priority field. A lower value means a higher priority.
I've set up two SRV records with different priorities in the domain nerdpol.org. The first record has a priority of 0 and leads to the default minecraft port 25565. The second record has a priority of 53 and leads to the port 53. This is for cases where users have no access to port 25565 from within their network. Port 53 leads to the very same server/port via a iptables redirect.
bind9 SRV records
_minecraft._tcp.nerdpol.org. 86400 IN SRV 53 0 53 minecraft.nerdpol.org.
_minecraft._tcp.nerdpol.org. 86400 IN SRV 0 0 25565 minecraft.nerdpol.org.
Some repeated connects and disconnects as seen in the Development Console
[14:31:19 INFO]: Client> [14:31:19] [Client thread/INFO]: Connecting to minecraft.nerdpol.org., 53
[14:31:44 INFO]: Client> [14:31:44] [Client thread/INFO]: Connecting to minecraft.nerdpol.org., 25565
[14:31:50 INFO]: Client> [14:31:50] [Client thread/INFO]: Connecting to minecraft.nerdpol.org., 53
[14:31:55 INFO]: Client> [14:31:55] [Client thread/INFO]: Connecting to minecraft.nerdpol.org., 25565
[14:32:01 INFO]: Client> [14:32:01] [Client thread/INFO]: Connecting to minecraft.nerdpol.org., 25565
[14:32:08 INFO]: Client> [14:32:08] [Client thread/INFO]: Connecting to minecraft.nerdpol.org., 25565
[14:32:08 INFO]: Client> [14:32:08] [Client thread/INFO]: Connecting to minecraft.nerdpol.org., 53
[14:32:09 INFO]: Client> [14:32:09] [Client thread/INFO]: Connecting to minecraft.nerdpol.org., 53
excerpt from rfc2782
Priority
The priority of this target host. A client MUST attempt to
contact the target host with the lowest-numbered priority it can
reach; target hosts with the same priority SHOULD be tried in an
order defined by the weight field. The range is 0-65535. This
is a 16 bit unsigned integer in network byte order.Weight
...
...
...
This process is repeated for each
Priority.
see: https://www.ietf.org/rfc/rfc2782.txt
Would be great to have this fixed. At least for our use case the impact of this behaviour isn't that hard so the priority of this bug report isn't very high either.