flyncodes
- flyncodes
- JIRAUSER765953
- Europe/Stockholm
- Yes
- No
MC-266246![[Mojang] Timur Nazarov](../../../data/avatars/users/18945.svg){kind=small}
flyncodes
The cause for slowdown is rDNS request when we have the IP but not the hostname.
We are doing that to check the hostname against the blocklists.
For most servers the request succeeds and there is no noticeable difference between how fast they are fully displayed in the server list.
For some (like the one from the bug description) though it takes a lot of time and fails. If it did not find anything it means it did not find anything in caches and had to actually query multiple DNS servers. It makes sense that it is slow in that case.
Hi, I tested with a few different methods, in an attempt to assure you it's not my internet connection. I will try to visit my local cafe next week using my laptop and their wifi and test on a fresh Minecraft client install as well, if you still have any concerns.
Tested on my desktop using a VPN with Ethernet: 609a6316989845586TmDlP161b[1].mp4
Tested on my desktop using mobile data over WIFI tether to my phone: 44f3311698984827OLbg1n171b[1].mp4
@henter5 Hi, sorry you haven't followed the reproduction steps, as you’re not using the server IP I provided, or haven't read that it seems to only effect certain IPs. If there are any questions as to whether it is just this IP address, I can get a few more IPs from different DigitalOcean Data centres. I can also try my best to find IPs that are not related to DigitalOcean, as there were a few comments on another website that have said this happens to them with other IPs.
Ah, no worries. I apologise I will start the server up again shortly.
Hmm, weird. Thank you both for checking and good idea trying 1.8.9 - I have setup 2 new servers with DigitalOcean. One in San Francisco, US and the other in Frankfurt, Germany. (Like to point out, these servers are running the Vanilla Minecraft Server 1.20.2 jar file, as you'd expect. With no changes at all made to the server configs, or Droplet configs or whatever) - The Falceso guy pointed out he's in the USA, where's I am in the UK, so I doubt it's related to where you are in the world. My friend suggested reverse DNS/rDNS/PTR Records could be the cause but I am yet to test that and I don't understand how that could be the cause.
I am on the hunt for more IP addresses effected by this, but it is a little costly trying different hosting providers to find if they're effected too.
San Francisco: 144.126.218.8 - sanfran.mcserver.gg
Frankfurt: 157.230.97.247 - frankfurt.mcserver.gg
I also tried using 1.8.9 and I still have the same problem, so not related to EULA blacklist check - how far back was the EULA blacklist check added? e9e71216990262453NJRyg165b[1].mp4
Good theory henter5, although primarily DNS is only used only for domains. As DNS's main job is to translate a domain to a direct IP, so the delay in theory should be the domain not the direct IP which isn't the case (refer to below..), it's the other way around.
I am using Google's DNS 8.8.8.8, 8.8.4.4 - if that helps.
But like my friend mentioned, maybe "reverse DNS" or "PTR records" are to blame, as they do what sort of what you're talking about henter5, they translate an IP address to a domain name - this is most likely our best lead at the moment, but I then put forward, why would the Minecraft client try to do "reverse DNS" or get a domain name when you're connecting with a direct IP, it shouldn't do that.. it doesn't need to? As we're using a direct IP - Before opening the bug report I tested with a Python script and pinged the server with it, it didn't experience any delay which leads me to believe it a problem within the Minecraft client it's self - maybe the EULA blacklist check is still in 1.8.9(honestly don't know)? And they need to do a reverse DNS lookup to get a domain name for an IP in an attempt to see if it's blacklisted, and that's causing the delay?
Just wanted to add, with that "reverse DNS" theory, I am also not sure why you, henter5 and Turbo are not experiencing the problem, maybe DNS caching and you did experience the delay at one point, but the result(which is that the IP address has no PTR/reverse DNS records) was cached which leads to no more delays, where's the rest of ours for whatever didn't cache the result saying the records don't exist.
I downloaded Wireshark to see what network packets were sent when you try with the direct IP, now I don't understand this and it would be helpful if someone else knew more. But it seems 3x "NBNS" - "Name query NBSTAT" packets are sent when you ping the IP, as you can see it works out to 6 seconds extra time it took before the first TCP packet to port 25565 was sent. Maybe this is due to the EULA check or reverse DNS/PTR, I have no clue why the 3 extra packets are sent, but I very strongly believe the Minecraft client is sending these packets for whatever reason.
In the screenshot below, I showed the Frankfurt IP but I tested all 3 IPs(London, San fran, Frankfurt) and they showed the same packets sent. The screenshot is from pinging the server with the 1.20.2 client, but the same things/packets happen when the 1.8.9 client is used.
(192.168.1.28 is my computers internal network IP, so there is also nothing to worry about it being exposed here)
I'm not sure how relevant this is but I'd like to add it - I used the command-line mcstatus Python script originally developed by Dinnerbone to get the status of the Frankfurt server with the direct IP and this was the Wireshark result, without any delay whatsoever, so clearly shows something is up with the Minecraft client.
(192.168.1.28 is my computers internal network IP, so there is also nothing to worry about it being exposed here)
Hi, could you tell me how this is "Works As Intended" and why it's resolved?