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. :-)

Beware that some home routers are aggressive about tearing down UDP NAT tunnels if no data has flowed for, say, 30 seconds.
Thus, you probably want "idle" connections to send a message every 10 seconds or so.
If you don't need that online detection, then it's better to just tear down the connection, and start it up again when you need it again.

Separately, if you need to know which servers are currently working/active/alive, you probably want servers to re-list themselves every 5 or 10 seconds, and purge servers from the match list if you haven't heard from them in 15-30 seconds.
Else you will have users who host servers, then think better of it and kill their host (which may not have time to send a message to the master server) and then you'll have a stale listing on your master server that you send other players to, which leads to a bad experience.

One reason to use UDP is that you'll probably need to use UDP anyway to implement NAT punch-through introduction with your master server as introducer, and UDP works more reliably than TCP for that.

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.

need to create a master server application to maintain a list of all active servers

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.

You might have modal traffic which might define 2 different traffic patterns

Server is running a game (full or not taking new players) which doesnt need as many constant updates back to the 'server lister' server

and

Server being listed as taking/awaiting new players which has to be kept uptodate

Depending on your reestablishment of 'server-lister' server reconnection overhead (is it alot? or a significant delay involved?) you still might want the running game (but one without much other interaction with the SL server) keeping up its connection/listing.

The listing entry itself (on the SL server) doesnt have to immediately go away and can have a 'last heard fro' state with a longer timeout which could get keepalives much less frequent -- before it tiemsout and is removed from the listing.

Again dependant on the delays of a fully broken connection and its reestablishment - the actual traffic overhead is pretty minor fo the likely state traffic (unless you have some wieldly complex game status the listing has to maintain and frequently update -- which would also require constant incalls from clients so THEY get the updated server listing info)

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.