I'm working on a real-time game engine and need to create a master server application to maintain a list of all active servers, however I'm not sure which network protocol to use.

The engine itself uses a combination of TCP and UDP.

I'm not sure how much of an overhead TCP has in comparison to UDP when running idle and packages only have to be send every couple of minutes at most, so I'm currently leaning towards using UDP.

However, obviously I need to make sure that all servers actually support UDP and TCP, so to do that, I would need both for the master server as well.

How is this usually done? What else do I have to take into account? Would it even make a mentionable difference?

Use the protocol and system that makes the most sense.

Very often people will use libraries that implement both reliable and unreliable channels using UDP. Effectively they create their own TCP stack with sliding windows, some commands use the reliable communication methods, some commands use the unreliable methods.

I'm not sure how much of an overhead TCP has in comparison to UDP when running idle and packages only have to be send every couple of minutes at most

For a few minutes there is not a need for keepalive packets, that is often enough for routes to be maintained over the public internet.

There is an overhead of about 12 bytes as the TCP headers are larger than UDP headers, with potentially a few additional bytes of optional header data if the protocol needs to communicate some extra data.

How is this usually done? What else do I have to take into account? Would it even make a mentionable difference?

It depends on the situation. When it comes to server-to-server communication there is no 'usual' method. You could go with anything from a custom ultra light UDP protocol, or your own more complex protocols that you design and build, ranging through standardized systems like JDBC/ODBC, or even REST based calls. The knowledge of what to pick in individual scenarios is a reason network infrastructure engineers are paid so well. :-)

Um, he wrote "server to server", which should hopefully both be on the same network.

If you are trying to coordinate with home routers and NAT traversal instead of inside a single corporate network, then yeah you'll need to worry about punch-through and rapid tunnel closure and such.

I guess this can be read two ways! The way I think about it is as "counter-strike servers" (hosted by players) and the "game list master server."
Although now that you point it out, it could also be read as "company-hosted game instances" with a distributor/master server on the same network.

Haha, I guess we both see what we are used to. I had forgotten about that type of player-hosted servers, spending too long in the world where server farms host everything.

It took a few moments of cognitive dissonance trying to hold both in my brain at once, that you could have servers controlled by the player, along with all the trust violations that come with it. Along the lines of "Why would any group ever expose a server instance, let alone run it outside the network, for people to modify and exploit and hack through and ... oh yeah."

Getting back on topic for Silverlan, as you can see from the discussion you'll need to clarify your needs quite a lot before getting a good answer. In network development the implementation details are usually heavily influenced by the specific needs identified through careful study of the communication needs.