UT99.org | Unreal Tournament Community

Recently my in-game calls using the UBrowserHTTPClient Browse() function have been incredibly slow to respond (5+ seconds).

By looking at the server log, I discovered this is because it keeps resolving the domain name every time a request is made.

This only started happening a few weeks ago, with no changes to the code or server, so I'm not sure why it's suddenly slowed down.

Is the HTTPClient meant to cache DNS query responses, and if so, are there any details about how it does it?

I checked IPDrv.InternetLink but the Resolve() function is native so I can't see its source code.

It's highly unlikely that UT caches any DNS at all, since its networking support is fairly primitive, but I could be wrong.

Therefore, odds are that the ISP where your server is hosted at has a faulty DNS server overall which is taking too long to respond and resolve.

One way to test if this is the case is if you use another DNS server, such as: 8.8.8.8 (Google's public DNS server).
If it's an ISP DNS problem, this fixes it and you can issue a ticket to the ISP for them to fix the issue.

More likely that Windows is not caching them I would have thought.
Check to see if the Windows "DNS Client" service is running.
If you use large HOSTS lists it is possible it is off. Using tools like HostMan will often do, or suggest it.
If you have recently used a tweak tool or optimiser, there is a good chance it has set the cache time to 0
If you have installed a 3rd party DNS client such as DNSCrypt, it will be handling the caching. You should set it to something like 60 seconds.

If you want to compare your ISP DNS to others, try the DNSBench tool
https://www.grc.com/dns/benchmark.htm

Google resolvers should be faster for people in USA, but they will be logging everything.
Cloudflare and Quad9 run distributed DNS systems which will use the closest/fastest for you.
1.1.1.1 for Cloudflare
9.9.9.9 for Quad9

Thanks, both. It must be my server's ISP, because when I added the target hostname and IP to my local hosts file (/etc/hosts in the case of Linux), UT's HTTP requests started responding instantly.

Do not forget that when you add the IP addresses directly into /etc/hosts, you're essentially short-circuiting DNS altogether, meaning that the DNS problem could still be somewhere else, including in your own system.

If you really want to check with pretty much 100% certainty that it's the ISP fault, use one of the DNS addresses either me or Dr.Flay suggested to check that out.

UT's native address resolver does not have any buffer/database of any kind.
The OS is responsible for that in this case.